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

[David Ball]

  Just an update on this issue for anyone who cares.  Problem was EXP
classification for VPLS routing instances.

  Juniper confirms a problem with default EXP classifier for VPLS on
at least the T-series (meaning, it was broken).  As someone else
suggested in the thread, the default classifier is NOT overwriteable
with a custom one on the T-series (it IS on MXs).  To compound the
problem, if you attempted to apply a custom one via [edit
class-of-service routing-instances], not only would it not work, but
you'd have to restart the FPC to 'get it outta there'.
  9.2R3 has fix for default EXP classifier for VPLS, though problem
with breaking it by trying to apply a custom classifier still exists,
so you just need to 'remember' not to try to apply one.
  Uncovered other issues such as the way the PLP bit is maintained on
the T-series (needed to use 'copy-plp' hidden knob), and bug with
forwarding class mapping (needed to create a placeholder FC to my
queue #4, which wasn't previously used), but these are workaroundable.

David


2008/12/11 David Ball <davidtball at gmail.com>:
>  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
>>
>>
>