Derive CoS values from DSCP values / QoS Questions

  • 0
  • 2
  • Question
  • Updated 4 years ago

Hey Folks!

today i was working with classifying / marking traffic on the A2/A4/B3/B5 Platforms (latest Firmware).

Basically i want my QoS Setup based on DSCP values, because its end to end.

As far as i could figure out, ETS switching does its priority internally on CoS values.
Does anyone of you know, if this is correct?
So that means somehow the CoS values must be set.

I found that this configuration is pretty doing this job (B5 Plattform):

set policy profile 1 name "QoS" cos 0 cos-status enable
set policy rule 1 iptos 32  mask 8 cos 1 forward
set policy rule 1 iptos 40  mask 8 cos 1 forward
set policy rule 1 iptos 64  mask 8 cos 2 forward
set policy rule 1 iptos 72  mask 8 cos 2 forward
set policy rule 1 iptos 96  mask 8 cos 3 forward
set policy rule 1 iptos 104  mask 8 cos 3 forward
set policy rule 1 iptos 128  mask 8 cos 4 forward
set policy rule 1 iptos 136  mask 8 cos 4 forward
set policy rule 1 iptos 184  mask 8 cos 5 forward
set policy rule 1 iptos 192  mask 8 cos 6 forward
set policy rule 1 iptos 224  mask 8 cos 7 forward
set policy port *.*.* 1

But the last two rules will never set cos 6 or cos 7, they set always cos to 5. Does anyone has an explaination for this?

Ok, this config does its job on untagged ports before a tag is imposed.
We have here also a couple router (firewall) on a stick scenarios; (CoS) marked tagged frames are going to the firewall, but they coming (CoS) unmarked and tagged back.

How do i derive CoS values from the DSCP values on tagged ports?

The A2 switch does not support the syntax of the b5 (i guess through the legacy device).
But anyway is there a option to do the same thing on the B5 platform?

any help would be great guys

Photo of dirk

dirk

  • 150 Points 100 badge 2x thumb

Posted 4 years ago

  • 0
  • 2
Photo of Paul Poyant

Paul Poyant, Employee

  • 3,536 Points 3k badge 2x thumb
You've posed quite a number of questions.

As far as i could figure out, ETS switching does its priority internally on CoS values.
Does anyone of you know, if this is correct?
So that means somehow the CoS values must be set.
> By default, txq assignment (a primary purpose of "CoS") is based on incoming packet priority, either ingress port based or via ingress VLAN tag override. By default, no attention is paid to the DSCP field or in fact to the entire ToS byte.
> Background: 7584, "Default 802.1p Priority to Transmit Queue mapping" (http://bit.ly/1fVaacc)

But the last two rules will never set cos 6 or cos 7, they set always cos to 5. Does anyone has an explaination for this?
> For the Stackable products including the C5, priorities 6 and 7 are reserved for stacking. Only values 0-5 are assignable.
> Background: 14109, "C2/B2 f/w x.02.13 Strict Priority configuration may not correctly reload" (http://bit.ly/1cV1DDH)

How do i derive CoS values from the DSCP values on tagged ports?
> On the C5, Policy may be used for this purpose. It should work for either VLAN-tagged or VLAN-untagged ingress traffic.
> Background: 7589, "How to Prioritize traffic based on DSCP marking, on SecureStacks" (http://bit.ly/18ffoh8)

The A2 switch does not support the syntax of the b5 (i guess through the legacy device).
But anyway is there a option to do the same thing on the B5 platform?
> Though not a directly equivalent feature, DiffServ may be used for this purpose on the A2.
> Background: 5848, "Configuring DiffServ on the SecureStacks/D-Series" (http://bit.ly/18F0WPL)

That should at least get you pointed in the right direction.
Note that the subject matter in general, though not exactly Rocket Science, can get deep rather quickly...
Photo of dirk

dirk

  • 150 Points 100 badge 2x thumb

Hi Paul,

thanks for you time.

I see, enterasys take a different approch, instead of of putting packets based on their markings in the appopriate queues, packets receive their markings based on the queue they are in.
That also explains why i didnt see cos 6 / cos 7 packets.

> Background: 7589, "How to Prioritize traffic based on DSCP marking, on SecureStacks" (http://bit.ly/18ffoh8)
Well, the posted solution uses "cos 6", which tries to mark with cos 6, which wont work.
Apart of that the big difference between that solution and my proposal is eventual the mask 6 vs. my mask 8. I reviewed my traffic (ECN is not set so it should not be a difference), but anyway retestet the configuration on tagged traffic. Tagged traffic is not remarked.
Do you have another option to put tagged traffic based on the dscp values in the correct queues?


> Background: 5848, "Configuring DiffServ on the SecureStacks/D-Series" (http://bit.ly/18F0WPL)
As far as i read the syntax you can remark dscp values, or mark dscp bits based on traffic conditions (src / dst ip etc.).
I played around with the 'diffserv' syntax. But as you said, i need a way to put packets based on their dscp marking in the correct queue.
I do not see any option on the syntax to do so.
Do you have a guess, how to put traffic based on the dscp values in the correct queues on the A2 platform?

Photo of Paul Poyant

Paul Poyant, Employee

  • 3,536 Points 3k badge 2x thumb
I see, enterasys take a different approch, instead of of putting packets based on their markings in the appopriate queues, packets receive their markings based on the queue they are in.That also explains why i didnt see cos 6 / cos 7 packets.
> Not quite true.  If configured to pay attention to tos/dscp markings, this will yield a cos which in turn yields a queue assignment and optionally a rewrite of markings.

Well, the posted solution uses "cos 6", which tries to mark with cos 6, which wont work.
> I appreciate you pointing out the inconsistency of KB 7589 assigning cos 6 for default use of txq 5. That article predates the time at which the highest priority was reserved for system/stacking use. I've adjusted it to make reference to cos 5, for default use of txq 4.

Do you have another option to put tagged traffic based on the dscp values in the correct queues?
> In the ingressing VLAN-tagged traffic used for your testing, what is the value of the full 8 bits of the IP header's TOS byte?

I played around with the 'diffserv' syntax. But as you said, i need a way to put packets based on their dscp marking in the correct queue.
I do not see any option on the syntax to do so.
Do you have a guess, how to put traffic based on the dscp values in the correct queues on the A2 platform?
> There is no syntax for this, per se. Just mark using the ef/46 value, and the txq assignment upgrade will take place in the background:
"Note: If DiffServ is used to mark the DSCP value of a frame based on a keyword of "ef" or a value of 46 (with either of these yielding L3 Express Forwarding), as a side-function the outgoing L2 frame will be placed into the highest priority hardware queue (Queue 5) for transmission (5859)."
My speculation in consideration of the above discussion is that this will now go to txq 4 rather than txq 5, but the upshot is that it will be "highly prioritized".
Photo of dirk

dirk

  • 150 Points 100 badge 2x thumb

> In the ingressing VLAN-tagged traffic used for your testing, what is the value of the full 8 bits of the IP header's TOS byte?

In my testing today my ToS byte had 192 the ECN bits were not set. But yesterday i tried a couple of other values as well.

> "Note: If DiffServ is used to mark the DSCP value of a frame based on a keyword of "ef" or a value of 46 (with either of these yielding L3 Express Forwarding), as a side-function the outgoing L2 frame will be placed into the highest priority hardware queue (Queue 5) for transmission (5859)."

Ok, i see. I can try that. Will this work also on trunks? What is then the queue mapping for other DSCP values, or does this only apply for EF traffic?

I keep you posted on this, hopefully tomorrow.


Photo of Paul Poyant

Paul Poyant, Employee

  • 3,536 Points 3k badge 2x thumb
A ToS byte value of 192 (DSCP 48) should hit on this rule in your sample config:
'set policy rule 1 iptos 192  mask 8 cos 6 forward'.
As discussedd, with current firmware this should yield priority 5, for either tagged or unntagged traffic.
If it does not, then I'd get a GTAC Support case open to dig into that further.

The auto-queue-bump logic only applies to ef/46 traffic.

On the stackables, using the 'set policy port <port#> <profile#>' command it is not supported to port-assign a static policy to a LAG aggregator port either by direct reference (lag.x.y) or by implied reference via wild card (lag.*.* or *.*.*).  I'm offhand not aware of any such restriction for the diffserv command set (A2-Series).
(Edited)
Photo of dirk

dirk

  • 150 Points 100 badge 2x thumb

Yes that was the command i tried already since my very first posting here.

Thanks Paul, for clarifiing some Enterasys internal stuff to me.


I think i will raise a GTAC call next week.


Thanks!

Photo of Paul Poyant

Paul Poyant, Employee

  • 3,536 Points 3k badge 2x thumb
You're welcome.

With benefit of hindsight it's possible that the remaining issue here is Policy being applied to a LAG Aggregator (with underlying physical ports). Though typically a LAG in its role as an InterSwitch Link is VLAN-tagged, these two attributes (LAG, VLAN Tagging) are in fact independent and each has its own functional expectations.
Photo of dirk

dirk

  • 150 Points 100 badge 2x thumb

I just want to let you know i did the test on the A2 platform.

I created a diffserv policy - a bit senseless but just to do something, to work with that traffic.

set diffserv class create all DSCPEF
set diffserv class match iptos DSCPEF B8 FF
set diffserv policy create DSCP in
set diffserv policy class add DSCP DSCPEF
set diffserv policy mark ipdscp DSCP DSCPEF ef
set diffserv service add in fe.1.1 DSCP
set diffserv service add in fe.1.2 DSCP


Testtraffic marked with dscp 46 (doesnt matter if access or trunk ports), are forwarded with cos 0.

I will follow up with the GTAC as you suggested.


dirk