[j-nsp] CoS Marking/Rewrite Theory
Derick Winkworth
dwinkworth at att.net
Sat Oct 4 11:37:02 EDT 2008
hmm...
###########
When you assign a rewrite rule to a subset of forwarding classes, the
commit does not fail, and the subset of forwarding classes work as
expected. However, the forwarding classes to which the rewrite rule is
not assigned are rewritten to all zeros.
For example, if you configure a Differentiated Services code point
(DSCP) rewrite rule, the bits in the forwarding classes to which you do
not assign the rewrite rule are rewritten to 000000; if you configure an
IP precedence rewrite rule, the bits in the forwarding classes to which
you do not assign the rewrite rule are rewritten to 000.
###########
and
############
For every incoming packet, the ingress classifier decodes the ingress
CoS bits into a forwarding class and packet loss priority (PLP)
combination. The egress CoS information depends on which type of rewrite
marker is active, as follows:
For IP precedence and DiffServ code point (DSCP) rewrite markers, the
marker alters the first three bits on the type-of-service (ToS) byte
while leaving the last three bits unchanged.
##############
1) Not sure I like the sound of either one of those. Sounds like you
MUST have a rewrite rule for all possible packets that need a marking if
you have a rewrite-map applied... or they will get rewritten to 0.
2) It only rewrites the first three bits? Really? So that means you
can't mark something EF 101110...
I say again hmm...
Chris Evans wrote:
> 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
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.173 / Virus Database: 270.7.5/1706 - Release Date: 10/3/2008 6:17 PM
>
>
More information about the juniper-nsp
mailing list