[j-nsp] End-to-end classification/queuing not being performed well for VPLS (LDP- or BGP-signalled)

[Mark Austen]

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 <davidtball at 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.
>
>
> dball at 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;
> }
>
> dball at 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 <sean at 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 at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >>
> >>
> >>
> >
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>