Community discussions

MikroTik App
 
mikeeg02
Member Candidate
Member Candidate
Topic Author
Posts: 162
Joined: Fri Mar 30, 2018 2:28 am
Location: Pennsylvania

MPLS EXP to COS copy drops to 0 at second router

Mon Nov 23, 2020 3:39 am

Currently running 6.47.7

**Updated to hopefully make things a little clearer.**

Ive been trying to track down an issue I have been having with priorities, and believe I have narrowed it down, but cannot figure out why its happening and need some advice. Diagram below shows whats going on but I will give some text. The ldp interface on the routers are set to explicit null to not have this problem, but its here. The interfaces between routers are tagged.

Packet ingress to router1, vpls tunnel, then goes out router1 out-interface with proper EXP and COS, and on in-interface of router2 still has proper EXP and COS priority. Packet leaves router2 out-interface, still looks correct. Router3 in-interface for packet has lost COS but retains EXP. But a if a packet ingress vpls at router2, the in-interace of router3 has proper EXP and COS. (eliminating link between r2 and r3)

Is this something simple I am overlooking? It doesnt seem to matter where in the chain of routers the vpls encapsulated packet traverses, the next router properly copies the EXP to the COS on the outgoing interface, but the second router it goes though doesnt copy it? I had initially thought it was the link between routers, but on the interfaces where it drops the COS, it still retains the COS from packets that initiate at the previous router.


packetflow.png
You do not have the required permissions to view the files attached to this post.
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

Re: MPLS EXP to COS copy drops to 0 at second router

Mon Nov 23, 2020 4:48 am

Hi,

Yes, we experienced this problem long ago. This works fine with CHR but not with any hardware routers - if you are running any hardware router and not CHR, it ends up being COS 0 after the second router. The only workaround we found was to add a single port bridge on the second router, with the only port being the ingress port the packet comes in, then in Bridge->Filters add any passthrough rule (ex. output chain, ingress priority != 0, passthrough). After that it starts working. We discovered this by mistake because we found that the COS was being properly set on only one P router but no others, and that particular P router had bridge filter rules that the others didn't have, and the MPLS packet was arriving on a bridge port.

I think the cause is that MPLS fastpath (which cannot be disabled) skips reading the ingress priority, and somehow the combination of the bridge with a single port on the ingress interface plus the bridge filter rule disables MPLS fastpath.
 
mikeeg02
Member Candidate
Member Candidate
Topic Author
Posts: 162
Joined: Fri Mar 30, 2018 2:28 am
Location: Pennsylvania

Re: MPLS EXP to COS copy drops to 0 at second router

Mon Nov 23, 2020 7:44 pm

Hi,

Yes, we experienced this problem long ago. This works fine with CHR but not with any hardware routers - if you are running any hardware router and not CHR, it ends up being COS 0 after the second router. The only workaround we found was to add a single port bridge on the second router, with the only port being the ingress port the packet comes in, then in Bridge->Filters add any passthrough rule (ex. output chain, ingress priority != 0, passthrough). After that it starts working. We discovered this by mistake because we found that the COS was being properly set on only one P router but no others, and that particular P router had bridge filter rules that the others didn't have, and the MPLS packet was arriving on a bridge port.

I think the cause is that MPLS fastpath (which cannot be disabled) skips reading the ingress priority, and somehow the combination of the bridge with a single port on the ingress interface plus the bridge filter rule disables MPLS fastpath.
That did the trick. Did I miss that in the manual somewhere? (that its exclusive to non-chr) Thats been a frustrating thing. I've read some of your other posts/threads about needing to use the bridge for qos of mpls packets on incoming/outgoing interfaces. But dropping the COS on ingress downstream is an interesting "bug".
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

Re: MPLS EXP to COS copy drops to 0 at second router

Mon Nov 23, 2020 9:02 pm

That did the trick. Did I miss that in the manual somewhere? (that its exclusive to non-chr) Thats been a frustrating thing. I've read some of your other posts/threads about needing to use the bridge for qos of mpls packets on incoming/outgoing interfaces. But dropping the COS on ingress downstream is an interesting "bug".
No, you didn't miss it in the manual. I think somebody made a mistake when they were writing the Fast path code, and CHR is not affected by this issue because it has no Fast path support. Unfortunately there is no on/off switch for MPLS Fast path - it is locked on. Fast path is only supposed to bypass unnecessary processing of the packet, but in this case they have accidentally bypassed some necessary processing.

What is supposed to happen is that the second P router is supposed to read the MPLS EXP bits from the incoming packet, store that value in ingress-priority, automatically copy ingress-priority to priority, and then use priority to set the CoS on the packet when it has the new VLAN tag applied on egress. Instead, it fails to read the EXP bits of the incoming packet and store it in ingress-priority, so ingress-priority is always 0 regardless of the EXP bits, the 0 gets copied to priority and then the 0 is set in the CoS on the packet on egress.

Doing that wonky workaround of creating a single port bridge and the passthrough bridge filter rule seems to make the router disable MPLS Fast path for ingress packets on that interface, and then it correctly reads the EXP bits of the incoming packet and stores it in ingress-priority. I only found it as a fluke because it worked on the one router that had the bridges and bridge filter rules but not on the others.

Make sure you disable STP for that single port bridge, otherwise it can go into spanning tree blocking in extreme traffic situations like DoS or DDoS.

I would like to see this issue fixed at some point - we have many extra bridges on our routers that we otherwise do not need simply to work around this issue.

Who is online

Users browsing this forum: No registered users and 14 guests