[j-nsp] CoS Marking/Rewrite Theory

Alex alex.arseniev at gmail.com
Sun Oct 5 04:00:28 EDT 2008


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 
  To: Alex 
  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 






More information about the juniper-nsp mailing list