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 <[EMAIL PROTECTED]> > 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. > > > [EMAIL PROTECTED] 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; > } > > [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>: > > > > 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