[j-nsp] CoS Marking/Rewrite Theory

[Chris Evans]

Yea I don't want to assign them to seperate queues, but I do not want
packets that already have a DSCP bit assigned to be rewritten. If I have
more differentiated traffic then classes available on the box, I'm out of
luck essentially. Also I'm not using the M320 or T series.. I'm really
working with the other M series, MX switches and EX series switches.

I'm going to discuss this with our SEs.. We're just now starting to use
Juniper. We mark on the ingress quite often as we have many legacy
applications that don't support marking the traffic themselves. This could
be a show stopper for Juniper in our environment until this feature is
added.

Chris

On Sun, Oct 5, 2008 at 4:00 AM, Alex <alex.arseniev at gmail.com> wrote:

>  Chris,
> If you don't need to use a separate queue for all 20 classes and want just
> to rewrite DSCP on egde for all 20 classes, you can do it using FC+LP
> combination as distinct attributes to match upon in "rewrite-rule". You will
> need M320 or T-series to do that
> http://www.juniper.net/techpubs/software/junos/junos92/swconfig-cos/configuring-forwarding-classes.html
> But if you want to assign every class (out of 20) to the separate
> queue then it's going to be difficult to say the least - AFAIK, no core
> router is capable of handling 20 queues in hardware. Please enlighten me if
> you know better.
> Rgds
> Alex
>
> ----- Original Message -----
> *From:* Chris Evans <chrisccnpspam at gmail.com>
> *To:* Alex <alex.arseniev at gmail.com>
> *Cc:* juniper-nsp at puck.nether.net
> *Sent:* Saturday, October 04, 2008 2:46 PM
> *Subject:* Re: [j-nsp] CoS Marking/Rewrite Theory
>
> I'm working with the M and MX series primarily, but want to expand on this,
> what I gave was just one example. What if I had 20 other streams of traffic
> that is marked and passing through the box? I still see this as a limitation
> as I don't have enough forwarding-classes to define all this traffic into.
>
> Also, yes you are correct on the L2-CoS for routers. Cisco is like Juniper
> in that aspect, the L2 is stripped at the interface level and processed
> through the box with just the packet information.
>
> As Mark wrote, sounds like we need a feature request.
>
> Thanks very much
>
> Chris
>
> On Sat, Oct 4, 2008 at 3:57 AM, Alex <alex.arseniev at gmail.com> wrote:
>
>> Chris,
>> I believe that in Cisco world the Layer-2 CoS header information can be
>> modified only on egress, see
>>
>> http://www.cisco.com/en/US/docs/ios/12_1t/12_1t5/feature/guide/cbpmark2.html#wp1058304
>> "A CoS value marking can only be applied to output traffic policies (which
>> are attached using the service-policy output command). "
>>
>> In Juniper world the equivalent is "rewrite-rule". It can be defined
>> selectively to a combination of "forwarding-class"+"loss-priority".
>> The "forwarding-class"/FC (for the purposes of this discussion) is roughly
>> equivalent to the Cisco "qos-group" and "loss-priority"/LP - to the Cisco
>> "discard-class".
>> The number of supported FC differs between Juniper platforms and currently
>> stands at 16 (on T-series). With 2 LP, it gives you maximum 32 combinations
>> to apply the rewrite-rules to.
>> Now back to your router example. The default behaviour is to preserve the
>> TOS byte. To selectively remark previously unmarked (let's assume TOS==0x00
>> here) packets to DSCP46, define a FW filter which classifies TOS==0x00
>> packets into FC=="EF" and LP=="low". You also need to classify DSCP43, for
>> instance, into FC=="ef"+LP="high" : you can do it in the same FW filter or
>> you can do it with custom BA classifier. Then, define a DSCP rewrite-rule
>> which rewrites FC=="ef"+LP="low" to DSCP46 and FC=="ef"+LP=="high" to
>> DSCP43.
>> Finally, attach your FW filter and custom BA classifier to the ingress
>> interface(s) and rewrite-rule to the egress interface(s).
>> Rgds
>> Alex
>>
>> ----- Original Message ----- From: "Chris Evans" <chrisccnpspam at gmail.com
>> >
>> To: <juniper-nsp at puck.nether.net>
>> Sent: Saturday, October 04, 2008 3:45 AM
>> Subject: [j-nsp] CoS Marking/Rewrite Theory
>>
>>
>>   First of all please forgive me if I cause confusion on this and let me
>>> know
>>> if I can clarify things more..
>>>
>>> I come from a Cisco world and am learning JUNOS. I have a question in
>>> regards to CoS markings on packets. In Cisco devices I can modify Layer2
>>> or
>>> Layer3 CoS header information INGRESS an interface. From my reading in
>>> Juniper Devices you can only write that information EGRESS an interface
>>> and
>>> it comes from the 'rewrite-map'.
>>>
>>> With Juniper devices you apply an input firewall filter that matches the
>>> traffic and then you define it to a forwarding class. Traffic is then
>>> forwarded through the device and once it reaches its egress interface
>>> using
>>> the rewrite-map it marks the packet CoS information based on the
>>> forwarding-class the packet was defined to. Also as we know, if filters
>>> aren't applied to force traffic forwarding classification the
>>> 'classifier'
>>> map is used to correlate the CoS markings to forwarding classes by
>>> default.
>>> We also know that if a rewrite-map isn't defined the traffic passes out
>>> and
>>> interface unmodified.
>>>
>>>
>>> Here's my question. Say I have a router with 3 interfaces, 2 interfaces
>>> are
>>> input and 1 output. Interface #1 and #2 are input and #3 would be output.
>>> On
>>> interface #1 I want to mark the traffic as its currently unmarked and I
>>> want
>>> it marked to DSCP EF(46). I have to apply the firewall filter and define
>>> this traffic into the expedited forwarding class. To make traffic egress
>>> of
>>> the router have this marking I have to also apply the dscp rewrite-map on
>>> interface #3. On interface #2 the traffic is already marked to DSCP43. As
>>> I
>>> do not have a firewall filter applied, the default classifer map kicks in
>>> and maps the DSCP 43 traffic to expedited forwarding class as well. Once
>>> this traffic exits the router out of interface #3, the rewrite map that
>>> had
>>> to be defined for interface #1 will rewrite this traffic to DSCP 46,
>>> overwriting my original markets. Now I cannot differentiate the traffic
>>> further on in the network.
>>>
>>>
>>> I see this is as a big limitation. Are there workarounds that I'm
>>> missing?
>>>
>>>
>>> Thanks
>>>
>>> BuckWeet
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>
>>
>