Just a followup on this. Juniper has acknowledged this to be a problem, and have opened an internal ticket after reproducing the issue in their lab. Thanks for the responses/suggestions.
David 2008/11/29 Mark Austen <marka...@gmail.com>: > My understanding is the explict EXP classifer will not overide the default > VPLS EXP classifer. The explict EXP classifer will apply to non-VPLS traffic > though. > > > -Mark > > 2008/11/29 David Ball <davidtb...@gmail.com> >> >> JUNOS 9.2R2.15, T640 with IQ2 gig PIC and IQ 10Gig PIC (testing >> with that an an MX960 non-EQ DPCs in the lab). No tunnel services >> PICs, so am using 'no-tunnel-services' in my routing-instances, which >> someone else has indicated may point to a default VPLS classifier >> being applied to incoming VPLS packets based on the EXP bit. But, >> shouldn't my explicit EXP bit classifier be overruling this? I have >> the following classifier and rewrite-rule applied to my core-facing >> interfaces. >> >> >> db...@router# show classifiers exp default-core-exp-classifier >> forwarding-class scavenger-fc { >> loss-priority high code-points 001; >> } >> forwarding-class be-low-fc { >> loss-priority high code-points 000; >> } >> forwarding-class af-low-fc { >> loss-priority low code-points 010; >> } >> forwarding-class af-high-fc { >> loss-priority low code-points 011; >> } >> forwarding-class ef-high-fc { >> loss-priority low code-points 101; >> } >> forwarding-class nc1-fc { >> loss-priority low code-points 110; >> } >> forwarding-class nc2-fc { >> loss-priority low code-points 111; >> } >> >> db...@router# show rewrite-rules exp default-core-exp-rewrite >> forwarding-class scavenger-fc { >> loss-priority high code-point 001; >> } >> forwarding-class be-low-fc { >> loss-priority high code-point 000; >> } >> forwarding-class af-low-fc { >> loss-priority low code-point 010; >> } >> forwarding-class af-high-fc { >> loss-priority low code-point 011; >> } >> forwarding-class ef-high-fc { >> loss-priority low code-point 101; >> } >> forwarding-class nc1-fc { >> loss-priority low code-point 110; >> } >> forwarding-class nc2-fc { >> loss-priority low code-point 111; >> } >> >> >> 2008/11/27 Sean Clarke <s...@clarke-3.demon.nl>: >> > >> > In which JUNOS version ? >> > With which hardware ? >> > >> > >> > I do this all the time (in fact last week) and haven't noticed an issue >> > - >> > I'm not saying there isn't one - just curious as to why you've seen a >> > problem >> > >> > cheers >> > Sean >> > >> > >> > >> > David Ball wrote: >> >> >> >> I discovered that for both BGP- and LDP-signalled VPLS, either a >> >> classifier or rewrite rule is breaking at some point along the way (or >> >> the handling of assigning traffic to queues, or something). Ingress >> >> queues look good on ingress PE (T-series), as do egress queues facing >> >> the core. Unfortunately, on the adjacent T-series (whose core port >> >> doesn't support ingress queues, unfortunately), the egress queues are >> >> all messed up facing the customer. I reproduced this in the lab >> >> between a T- and an MX960 as well. >> >> I have a ticket open with Juniper and Eng says my config is good, >> >> and that they've reproduced the problem in their lab, but surely I >> >> can't be the first to have encountered this. Anyone else run across >> >> this behaviour before? L2VPNs and L2Circuits work fine....the wheels >> >> fall off for VPLS for some reason. >> >> >> >> David >> >> _______________________________________________ >> >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> >> >> >> >> >> >> > >> > >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp