[j-nsp] Setting CoS bits on ingress frames
Dave Bell
me at geordish.org
Thu Jul 30 05:43:45 EDT 2015
Apply it to the port on SW3 that is facing SW2.
On 30 July 2015 at 10:02, Dave Bell <me at geordish.org> wrote:
> Hi Victor,
>
> I see two potential problems here.
>
> 1) SW2 is doing something weird and bleaching the frames before they
> reach SW3. You can apply a firewall filter to the ingress interface to
> match your .p bit value and count to check this.
>
> 2) As you don't have a classifier on your ingress interface, all
> traffic is getting placed in queue 0 by default, and your rewrite
> rules are now setting queue 0 to 0.
>
> To fix this one, you need a classifier on ingress. Try something like
> the following:
>
> class-of-service {
> classifiers {
> ieee-802.1 my-classifier {
> forwarding-class bk {
> loss-priority low code-points 000;
> }
> forwarding-class be {
> loss-priority low code-points 001;
> }
> forwarding-class ee {
> loss-priority low code-points 010;
> }
> forwarding-class ca {
> loss-priority low code-points 011;
> }
> forwarding-class vi {
> loss-priority low code-points 100;
> }
> forwarding-class vo {
> loss-priority low code-points 101;
> }
> forwarding-class ic {
> loss-priority low code-points 110;
> }
> forwarding-class nc {
> loss-priority low code-points 111;
> }
> }
> }
> interfaces {
> <ingress interface> {
> classifiers {
> ieee-802.1 my-classifier;
> }
> }
> }
> }
>
> Regards,
> Dave
>
> On 30 July 2015 at 05:39, Victor Sudakov <vas at mpeks.tomsk.su> wrote:
>> Alexander Arseniev wrote:
>>> > The FC in JUNOS is the same as "qos-group" in CSCO IOS - invisible
>>> > internal-only field which travels along with packet content across the
>>> > switch, but is never inserted in the actual packet. The FC has
>>> > significance for choosing output scheduling, RED drop, marking.
>>
>>
>> I have come across a problem with the fixed port classifier.
>>
>> I would be grateful if someone could help me out. My lab setup is at
>> ftp://ftp.sibptus.ru/pub/vas/lab2.pdf
>>
>> Normally I see frames from HostA arriving at HostC with COS=3. I also
>> want frames from HostB to arrive at HostC with COS=6.
>>
>> However, when I enable the rewrite-rules section at Sw3, frames from
>> HostA no more have COS=3 (i.e. the COS field is cleared).
>>
>> I am ready to provide any additional detail. Below is my QoS
>> configuration.
>>
>>
>> admin at sw-kedr> show configuration class-of-service | no-more
>> forwarding-classes {
>> queue 0 bk;
>> queue 1 be;
>> queue 2 ee;
>> queue 3 ca;
>> queue 4 vi;
>> queue 5 vo;
>> queue 6 ic;
>> queue 7 nc;
>> }
>> interfaces {
>> ge-0/0/0 {
>> unit 0 {
>> forwarding-class ic;
>> }
>> }
>> inactive: ge-0/0/22 {
>> unit 0 {
>> rewrite-rules {
>> ieee-802.1 output;
>> }
>> }
>> }
>> ge-0/0/23 {
>> unit 0 {
>> rewrite-rules {
>> ieee-802.1 output;
>> }
>> }
>> }
>> }
>> rewrite-rules {
>> ieee-802.1 output {
>> forwarding-class bk {
>> loss-priority high code-point 000;
>> loss-priority low code-point 000;
>> }
>> forwarding-class be {
>> loss-priority high code-point 001;
>> loss-priority low code-point 001;
>> }
>> forwarding-class ee {
>> loss-priority high code-point 010;
>> loss-priority low code-point 010;
>> }
>> forwarding-class ca {
>> loss-priority high code-point 011;
>> loss-priority low code-point 011;
>> }
>> forwarding-class vi {
>> loss-priority high code-point 100;
>> loss-priority low code-point 100;
>> }
>> forwarding-class vo {
>> loss-priority high code-point 101;
>> loss-priority low code-point 101;
>> }
>> forwarding-class ic {
>> loss-priority high code-point 110;
>> loss-priority low code-point 110;
>> }
>> forwarding-class nc {
>> loss-priority high code-point 111;
>> loss-priority low code-point 111;
>> }
>> }
>> }
>>
>> {master:0}
>> admin at sw-kedr>
>>
>> --
>> Victor Sudakov, VAS4-RIPE, VAS47-RIPN
>> sip:sudakov at sibptus.tomsk.ru
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
More information about the juniper-nsp
mailing list