UFB 2M upload issues - DEI markings - Juniper
Hi all We have finally fixed our 2M upload issues on Chorus UFB accelerate plans. Skip to the end of this email if you just want an example fix. Along the way we established a couple of incorrect "facts". Some of which I shared with this list. These were: 1) DEI marked packets were being silently dropped on ingress from the Chorus handover 2) Junos 12.3 fixed this issue Recently I deemed that "fact" 1) was wrong and hence "fact" 2) was a bit irrelevant. Here's a crude diagram of our typical set-up: <Chorus handover> <-> [1] <MX80> [2] <-> MPLS/VPLS over Backhaul fibre <-> [3] <PMR MPLS MX> [4] <-> [5] <PMR BNG> Where the numbers in the square brackets are interfaces where I performed some traffic stats. I deemed that DEI=1 marked packets were still showing up at [1] and [3]. They were not showing up at interfaces [4] and [5]. This deemed my above "facts" incorrect. With Juniper CoS you classify on ingress and rewrite on egress. Once we deemed that DEI marked packets were not being dropped at [1] and instead were being dropped between [3] and [4] we can now rewrite these before interface [4]. As we need to rewrite on egress we'll do this at point [2]. In our test case interface [2] is actually xe-1/2/0.388 . And a simple fix for the issue is under the class-of-service section implement: interfaces { xe-1/2/0 { unit 388 { rewrite-rules { ieee-802.1ad { ieee-802.1ad-dei-rewrite; vlan-tag outer; } } } } } rewrite-rules { ieee-802.1ad ieee-802.1ad-dei-rewrite { forwarding-class best-effort { loss-priority low code-point 0000; loss-priority high code-point 0000; } } } The key is to use a ieee-802.1ad rewrite rule rather than a ieee-802.1 rule. The leftmost bit of the 4 bit code-point is the DEI bit. This is all assuming that all traffic is classified as best-effort at interface [1] - if that is not the case then re-write the DEI bit for your other queues as well. You only need to rewrite the outer vlan DEI bit. This is tested on Junos 12.3R8.7 on a MX80. Thanks to all involved in helping fix this - Steve K, Vance and Ivan especially. Cheers Dave
Hi all, A bit of necro-posting, but just found in Junos 14.2R2 release notes that they have fixed one of the parts causing the problem. • The Priority code point (PCP) and Drop eligible indicator (DEI) bit in 802.1Q header are preserved while packet gets routed within the same Packet Forwarding Engine (PFE). The expected behaviour is resetting the PCP and DEI bit when the packet is routed. PR1036756 It eliminates the need of workaround with manual DEI rewrite rule for outgoing packets mentioned here before. Kind regards, Dmitry Konchanin Senior Network Engineer _______________________________________________ ⇒ New Zealand Office: 0508 387 669/+(64) 4 918 0160 extn 118 ⇒ Australian Office: 1300 054 331/+(61) 7 5522 9726 extn 118 ⇒ Website: www.DTSanz.com http://www.DTSanz.com
On Wed, Feb 18, 2015 at 1:21 PM, Dmitry Konchanin < dmitry.konchanin(a)dtsanz.com> wrote:
Hi all,
Was it you that gave that talk? The DEI bug was fascinating! (and my fingers keep wanting to type that as DIE bug) I did glaze over at which points in the fiber network it was occurring in and on what technologies... is there a pdf of your talk available? And a question that I didnt get a chance to ask was why/when/how does the end user device assert this bit at all?
A bit of necro-posting, but just found in Junos 14.2R2 release notes that they have fixed one of the parts causing the problem.
• The Priority code point (PCP) and Drop eligible indicator (DEI) bit in 802.1Q header are preserved while packet gets routed within the same Packet Forwarding Engine (PFE). The expected behaviour is resetting the PCP and DEI bit when the packet is routed. PR1036756
It eliminates the need of workaround with manual DEI rewrite rule for outgoing packets mentioned here before.
Kind regards,
Dmitry Konchanin Senior Network Engineer _______________________________________________ ⇒ New Zealand Office: 0508 387 669/+(64) 4 918 0160 extn 118 ⇒ Australian Office: 1300 054 331/+(61) 7 5522 9726 extn 118 ⇒ Website: www.DTSanz.com
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
On Thu, Feb 19, 2015 at 10:25 AM, Dave Taht
On Wed, Feb 18, 2015 at 1:21 PM, Dmitry Konchanin < dmitry.konchanin(a)dtsanz.com> wrote:
Hi all,
Was it you that gave that talk? The DEI bug was fascinating! (and my fingers keep wanting to type that as DIE bug)
I did glaze over at which points in the fiber network it was occurring in and on what technologies... is there a pdf of your talk available?
And a question that I didnt get a chance to ask was why/when/how does the end user device assert this bit at all?
That was me. In all honesty it probably should have been a real talk rather than a lightning talk in the end. Was a lot of information to convey. The DEI bit was generated by Chorus (our main fibre operator here) for traffic outside of the CIR (2.5mbit L2). We then believed at some stage in our network we were dropping it. It ended up being an MPLS backbone of another operator that we used that was dropping the DEI marked packets but only because we were re-writing from the inner L2 to the outer L2. Happy to talk on or off list if you want more details. There's also a very long NZNOG thread about it back in July last year where I state some facts and make up some as well :) I am about to disappear for a couple of days though so replies might be delayed. Go the Black Caps! Cheers Dave
Resurrecting an old post of mine.
Today I was googling something and found this post as a source of what I
wanted to know. I didn't trust the author though. There's a very important
mistake below.
On Thu, Nov 6, 2014 at 3:39 PM, Dave Mill
In our test case interface [2] is actually xe-1/2/0.388 . And a simple fix for the issue is under the class-of-service section implement:
interfaces { xe-1/2/0 { unit 388 { rewrite-rules { ieee-802.1ad { ieee-802.1ad-dei-rewrite; vlan-tag outer; } } } } } rewrite-rules { ieee-802.1ad ieee-802.1ad-dei-rewrite { forwarding-class best-effort { loss-priority low code-point 0000; loss-priority high code-point 0000; } } }
The key is to use a ieee-802.1ad rewrite rule rather than a ieee-802.1 rule. The leftmost bit of the 4 bit code-point is the DEI bit. This is all assuming that all traffic is classified as best-effort at interface [1] - if that is not the case then re-write the DEI bit for your other queues as well.
Actually, the rightmost bit in the 4 bit code-point is the DEI/CFI bit. Lucky I checked in to this before implementation as we would have had all packets dropped with a .1p set to an odd number if I had blindly trusted myself :) Cheers Dave
participants (3)
-
Dave Mill -
Dave Taht -
Dmitry Konchanin