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

[David Ball]

  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 <marka888 at 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 <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
>
>