Mailing List Archive

CoS on Junos5.3
Hi all,

Recently I started on configuring CoS on Junos5.3R3.4 using the new
syntax.

The goal is to tag the IP-precedence bits (not DSCP) coming in from our
WAN interface to 001, while maintaining other traffic untouched.

On the incoming WAN interface, I have added the following firewall filter:

[firewall filter acl-wan-in]

term permit-any-any {
then {
count permit-any-any;
loss-priority high;
forwarding-class class-0;
accept;
}
}

On other interfaces, The loss-priority bit of incoming packets is
untouched.

Then I configured a rewrite policy on the CoS, following sample config on
the Junos docs:

forwarding-classes {
queue 0 class-0;
queue 1 class-1;
queue 2 class-2;
queue 3 class-3;
}
interfaces {
fe-0/2/0 {
unit 0 {
rewrite-rules {
inet-precedence tag-traffic;
}
}
}
}
rewrite-rules {
inet-precedence tag-traffic {
forwarding-class class-0 {
loss-priority low code-point 000;
loss-priority high code-point 001;
}
}
}

Interface fe-0/2/0.0 is the FE interface facing our internal network. Thus
the tagging is done when the packet leaves the router.

The peculiar thing observed is that, the first time when the interface and
rewrite-rules are "commit"-ed at the same time, the TOS bits were not
rewritten. Only when I de-activate the interface under CoS hierarchy (then
commit) and then re-activate the inteface (then commit again) that the TOS
bits were rewritten. I verified the TOS bits by sniffing the fe-0/2/0.0
using tcpdump.

Is this the expected behaviour, or have I missed anything out?

Many thanks for any help rendered.

regards,
sonny
CoS on Junos5.3 [ In reply to ]
At 07:38 AM 11/25/2002, Sonny wrote:
>Hi all,
>
>Recently I started on configuring CoS on Junos5.3R3.4 using the new
>syntax.
>
>The goal is to tag the IP-precedence bits (not DSCP) coming in from our
>WAN interface to 001, while maintaining other traffic untouched.
>
>On the incoming WAN interface, I have added the following firewall filter:
>
>[firewall filter acl-wan-in]
>
>term permit-any-any {
> then {
> count permit-any-any;
> loss-priority high;
> forwarding-class class-0;
> accept;
> }
>}
>
>On other interfaces, The loss-priority bit of incoming packets is
>untouched.
>
>Then I configured a rewrite policy on the CoS, following sample config on
>the Junos docs:
>
>forwarding-classes {
> queue 0 class-0;
> queue 1 class-1;
> queue 2 class-2;
> queue 3 class-3;
>}
>interfaces {
> fe-0/2/0 {
> unit 0 {
> rewrite-rules {
> inet-precedence tag-traffic;
> }
> }
> }
>}
>rewrite-rules {
> inet-precedence tag-traffic {
> forwarding-class class-0 {
> loss-priority low code-point 000;
> loss-priority high code-point 001;
> }
> }
>}
>
>Interface fe-0/2/0.0 is the FE interface facing our internal network. Thus
>the tagging is done when the packet leaves the router.
>
>The peculiar thing observed is that, the first time when the interface and
>rewrite-rules are "commit"-ed at the same time, the TOS bits were not
>rewritten.

Sonny,
can you send me the message log which contains the time-frame
where you performed the commit initially and also send me the show version
and show chassis hardware. Just to confirm you message. You can not
reproduce the symptom again as it did only happen the first time, correct ?

thanks
Josef




> Only when I de-activate the interface under CoS hierarchy (then
>commit) and then re-activate the inteface (then commit again) that the TOS
>bits were rewritten. I verified the TOS bits by sniffing the fe-0/2/0.0
>using tcpdump.
>
>Is this the expected behaviour, or have I missed anything out?
>
>Many thanks for any help rendered.
>
>regards,
>sonny
>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>http://puck.nether.net/mailman/listinfo/juniper-nsp
CoS on Junos5.3 [ In reply to ]
Hi Josef,

Would the symptom comes back if we cold reboot the router?

thanks,
sonny
----- Original Message -----
From: "Josef Buchsteiner" <josefb@juniper.net>
To: "Sonny I Franslay" <sonnyfranslay@pacific.net.sg>
Sent: Tuesday, November 26, 2002 4:09 PM
Subject: Re: [j-nsp] CoS on Junos5.3


> At 12:50 AM 11/26/2002, Sonny I Franslay wrote:
> >Hi Josef,
> >
> >I 've never attempted the cos on any other interface but FE and GigE. I'm
> >afraid I may not have a conclusive answer to your question, but we only
see
> >this symtom when applying the CoS on these two interfaces so far.
> >
> >How would it make any difference whether it is a broadcast interface or
not?
>
>
> Sonny,
> I strongly believe you were running into a known problem report
> PR26012.
> This happen after software upgrade and/or initial CoS Configuration and
related
> to Ethernet Interfaces. We had to enable to cache the re-write for all
> interfaces
> which we had not done before. The same symptom will happen with ieee
rewrite.
> It is also related to the default exp rewrite we do all the time.
> Once it is working you should not see nay troubles anymore.
>
> Once you deactivate/activate the interface or the
class-of-service
> stanza
> cosd ( the daemon on the RE) will download all class-of-service related
> configuration setting to the i/o Asic on the FEB or FPC which is the
reason
> why it worked after you have done this since you just reprogrammed the
> Asic.
>
>
> hope this helps
> Josef
>
>
>
> >thanks & regards,
> >Sonny
> >
> >----- Original Message -----
> >From: "Josef Buchsteiner" <josefb@juniper.net>
> >To: "Sonny Franslay" <sonnyfranslay@pacific.net.sg>
> >Sent: Tuesday, November 26, 2002 3:22 AM
> >Subject: Re: [j-nsp] CoS on Junos5.3
> >
> >
> > > Sonny,
> > > one last question and then I can think ca confirm
> > > and have all the puzzles together. Have you ever seen this
> > > symptom on non-broadcast interfaces ?
> > >
> > > thanks
> > > Josef
> > >
> > >
> > > At 03:44 PM 11/25/2002, Sonny Franslay wrote:
> > > >Hi Josef,
> > > >
> > > > >
> > > > > is interface fe-0/2/0 also configured with vland-id's ?
> > > > > did you had also configured in the very begin classifiers
> > > > > as well or only the re-write rule as mentioned in the note ?
> > > > >
> > > >
> > > >Nope, it is not configured wtih vlan-id. Below is the interface
config:
> > > >
> > > >fe-0/2/0 {
> > > > description "VLAN1 10.10.90.0/24";
> > > > unit 0 {
> > > > family inet {
> > > > address 10.10.90.4/24;
> > > > }
> > > > }
> > > >}
> > > >
> > > >I did not use any classifier. I used the loss-priority bit to
> > > >differentiate the packets coming in via the WAN interface from the
> >others.
> > > >I connfigured the rewrite rule at the same time as I configured the
> > > >interface (to apply the rewrite rule policy to the interface).
> > > >
> > > >Do I need to define the rewrite rules seperately from applying it on
the
> > > >interface? Meaning I have to do 2 separate "commits"?
> > > >This is what I want to find out actually.
> > > >
> > > >thanks & regards,
> > > >sonny
> > >
>
CoS on Junos5.3 [ In reply to ]
At 05:29 PM 11/27/2002, Sonny I Franslay wrote:
>Hi Josef,
>
>Would the symptom comes back if we cold reboot the router?

it should not

Josef


>thanks,
>sonny
>----- Original Message -----
>From: "Josef Buchsteiner" <josefb@juniper.net>
>To: "Sonny I Franslay" <sonnyfranslay@pacific.net.sg>
>Sent: Tuesday, November 26, 2002 4:09 PM
>Subject: Re: [j-nsp] CoS on Junos5.3
>
>
> > At 12:50 AM 11/26/2002, Sonny I Franslay wrote:
> > >Hi Josef,
> > >
> > >I 've never attempted the cos on any other interface but FE and GigE. I'm
> > >afraid I may not have a conclusive answer to your question, but we only
>see
> > >this symtom when applying the CoS on these two interfaces so far.
> > >
> > >How would it make any difference whether it is a broadcast interface or
>not?
> >
> >
> > Sonny,
> > I strongly believe you were running into a known problem report
> > PR26012.
> > This happen after software upgrade and/or initial CoS Configuration and
>related
> > to Ethernet Interfaces. We had to enable to cache the re-write for all
> > interfaces
> > which we had not done before. The same symptom will happen with ieee
>rewrite.
> > It is also related to the default exp rewrite we do all the time.
> > Once it is working you should not see nay troubles anymore.
> >
> > Once you deactivate/activate the interface or the
>class-of-service
> > stanza
> > cosd ( the daemon on the RE) will download all class-of-service related
> > configuration setting to the i/o Asic on the FEB or FPC which is the
>reason
> > why it worked after you have done this since you just reprogrammed the
> > Asic.
> >
> >
> > hope this helps
> > Josef
> >
> >
> >
> > >thanks & regards,
> > >Sonny
> > >
> > >----- Original Message -----
> > >From: "Josef Buchsteiner" <josefb@juniper.net>
> > >To: "Sonny Franslay" <sonnyfranslay@pacific.net.sg>
> > >Sent: Tuesday, November 26, 2002 3:22 AM
> > >Subject: Re: [j-nsp] CoS on Junos5.3
> > >
> > >
> > > > Sonny,
> > > > one last question and then I can think ca confirm
> > > > and have all the puzzles together. Have you ever seen this
> > > > symptom on non-broadcast interfaces ?
> > > >
> > > > thanks
> > > > Josef
> > > >
> > > >
> > > > At 03:44 PM 11/25/2002, Sonny Franslay wrote:
> > > > >Hi Josef,
> > > > >
> > > > > >
> > > > > > is interface fe-0/2/0 also configured with vland-id's ?
> > > > > > did you had also configured in the very begin classifiers
> > > > > > as well or only the re-write rule as mentioned in the note ?
> > > > > >
> > > > >
> > > > >Nope, it is not configured wtih vlan-id. Below is the interface
>config:
> > > > >
> > > > >fe-0/2/0 {
> > > > > description "VLAN1 10.10.90.0/24";
> > > > > unit 0 {
> > > > > family inet {
> > > > > address 10.10.90.4/24;
> > > > > }
> > > > > }
> > > > >}
> > > > >
> > > > >I did not use any classifier. I used the loss-priority bit to
> > > > >differentiate the packets coming in via the WAN interface from the
> > >others.
> > > > >I connfigured the rewrite rule at the same time as I configured the
> > > > >interface (to apply the rewrite rule policy to the interface).
> > > > >
> > > > >Do I need to define the rewrite rules seperately from applying it on
>the
> > > > >interface? Meaning I have to do 2 separate "commits"?
> > > > >This is what I want to find out actually.
> > > > >
> > > > >thanks & regards,
> > > > >sonny
> > > >
> >
>
>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>http://puck.nether.net/mailman/listinfo/juniper-nsp
CoS on Junos5.3 [ In reply to ]
At 10:24 AM 11/28/2002, Josef Buchsteiner wrote:
>At 05:29 PM 11/27/2002, Sonny I Franslay wrote:
>>Hi Josef,
>>
>>Would the symptom comes back if we cold reboot the router?
>
>it should not

Sonny,
want to add to my statement that it 'may work' after
a cold reboot. If the logical interface number changes after
a reboot we still fail to rewrite ieee. PR26012 has been
fixed but is not available on any released version yet. For
the time being the only workaround is to deactivate/activate
the class-of-service stanza.

hope this helps
Josef


>Josef
>
>
>>thanks,
>>sonny
>>----- Original Message -----
>>From: "Josef Buchsteiner" <josefb@juniper.net>
>>To: "Sonny I Franslay" <sonnyfranslay@pacific.net.sg>
>>Sent: Tuesday, November 26, 2002 4:09 PM
>>Subject: Re: [j-nsp] CoS on Junos5.3
>>
>>
>> > At 12:50 AM 11/26/2002, Sonny I Franslay wrote:
>> > >Hi Josef,
>> > >
>> > >I 've never attempted the cos on any other interface but FE and GigE. I'm
>> > >afraid I may not have a conclusive answer to your question, but we only
>>see
>> > >this symtom when applying the CoS on these two interfaces so far.
>> > >
>> > >How would it make any difference whether it is a broadcast interface or
>>not?
>> >
>> >
>> > Sonny,
>> > I strongly believe you were running into a known problem report
>> > PR26012.
>> > This happen after software upgrade and/or initial CoS Configuration and
>>related
>> > to Ethernet Interfaces. We had to enable to cache the re-write for all
>> > interfaces
>> > which we had not done before. The same symptom will happen with ieee
>>rewrite.
>> > It is also related to the default exp rewrite we do all the time.
>> > Once it is working you should not see nay troubles anymore.
>> >
>> > Once you deactivate/activate the interface or the
>>class-of-service
>> > stanza
>> > cosd ( the daemon on the RE) will download all class-of-service related
>> > configuration setting to the i/o Asic on the FEB or FPC which is the
>>reason
>> > why it worked after you have done this since you just reprogrammed the
>> > Asic.
>> >
>> >
>> > hope this helps
>> > Josef
>> >
>> >
>> >
>> > >thanks & regards,
>> > >Sonny
>> > >
>> > >----- Original Message -----
>> > >From: "Josef Buchsteiner" <josefb@juniper.net>
>> > >To: "Sonny Franslay" <sonnyfranslay@pacific.net.sg>
>> > >Sent: Tuesday, November 26, 2002 3:22 AM
>> > >Subject: Re: [j-nsp] CoS on Junos5.3
>> > >
>> > >
>> > > > Sonny,
>> > > > one last question and then I can think ca confirm
>> > > > and have all the puzzles together. Have you ever seen this
>> > > > symptom on non-broadcast interfaces ?
>> > > >
>> > > > thanks
>> > > > Josef
>> > > >
>> > > >
>> > > > At 03:44 PM 11/25/2002, Sonny Franslay wrote:
>> > > > >Hi Josef,
>> > > > >
>> > > > > >
>> > > > > > is interface fe-0/2/0 also configured with vland-id's ?
>> > > > > > did you had also configured in the very begin classifiers
>> > > > > > as well or only the re-write rule as mentioned in the note ?
>> > > > > >
>> > > > >
>> > > > >Nope, it is not configured wtih vlan-id. Below is the interface
>>config:
>> > > > >
>> > > > >fe-0/2/0 {
>> > > > > description "VLAN1 10.10.90.0/24";
>> > > > > unit 0 {
>> > > > > family inet {
>> > > > > address 10.10.90.4/24;
>> > > > > }
>> > > > > }
>> > > > >}
>> > > > >
>> > > > >I did not use any classifier. I used the loss-priority bit to
>> > > > >differentiate the packets coming in via the WAN interface from the
>> > >others.
>> > > > >I connfigured the rewrite rule at the same time as I configured the
>> > > > >interface (to apply the rewrite rule policy to the interface).
>> > > > >
>> > > > >Do I need to define the rewrite rules seperately from applying it on
>>the
>> > > > >interface? Meaning I have to do 2 separate "commits"?
>> > > > >This is what I want to find out actually.
>> > > > >
>> > > > >thanks & regards,
>> > > > >sonny
>> > > >
>> >
>>
>>
>>_______________________________________________
>>juniper-nsp mailing list juniper-nsp@puck.nether.net
>>http://puck.nether.net/mailman/listinfo/juniper-nsp
>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>http://puck.nether.net/mailman/listinfo/juniper-nsp