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

[David Ball]

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