QoS on the VSS

Unanswered Question
Jan 5th, 2009

HI,

I moved my network to VSS and I found the following:

1.- I've been configured the interfaces between access level and distribution level with:

interface gigabitEthernetX/Y

mls qos trust dscp

and interfaces between distribution and the CORE (VSS) with the same command:

interface tengigabitEthernet1/7/1

mls qos trust dscp

But the VSL is configured to trust CoS:

interface TenGigabitEthernet1/5/4

mls qos trust cos

channel-group 1 mode on

Is necesary to change the configuration of uplinks (parameters of QoS can't be modified on VSL ports...)

2.- By default the queueing-mode in interface tengigabit is mode-cos is this incompatible with trust dscp?

switch#sh queueing int ten1/7/1

Interface TenGigabitEthernet1/7/1 queueing strategy: Weighted Round-Robin

Port QoS is enabled

Port is untrusted

Extend trust state: not trusted [COS = 0]

Default COS is 0

Queueing Mode In Tx direction: mode-cos

Transmit queues [type = 1p7q4t]:

...

when i tried to change this mode to "mode-dscp" I lost the conectivity with the devices...

Thanks

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Tue, 01/06/2009 - 10:23

Hello Sonia,

in general if the ports are trunk ports CoS bits are a copy of the CS bits of the DSCP field.

So until it is so there is neither a perfect corrispondence neither a total incompatibility.

For the specific of VSS you could start look at

Configuring VSL QoS

The virtual switching system automatically configures VSL ports for trust CoS, using default CoS mappings (you cannot change the mappings on VSL ports).

For switching modules that support per-ASIC configuration, the VSL configuration applies to all ports on the same ASIC (including any non-VSL ports).

The virtual switching system disables the QoS commands on VSL ports (and any non-VSL ports on the same ASIC). For example, you cannot use QoS queuing or map commands on VSL ports.

To ensure that all eight QoS receive queues are enabled for the 10-Gigabit Ethernet ports on the supervisor engine, enter the mls qos 10g-only global configuration command.

In Cisco IOS Release 12.2(33)SXI and later releases, when the mls qos 10g-only command is entered and only one of the two 10-Gigabit Ethernet ports on the supervisor engine is a VSL port, the non-VSL 10-Gigabit Ethernet port can be configured for QoS.

see

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/vss.html#wp1060412

Hope to help

Giuseppe

sdurn Wed, 01/07/2009 - 01:16

Sorry, I don't understand very well ... all ports between access, distribution and core switches are trunk. So, if I configure these ports as mls qos trust DSCP is sufficient even if the mode is queuing

Queuing Mode In Tx direction: mode-cos and the VSL ports have mls qos trust Cos?

Giuseppe Larosa Wed, 01/07/2009 - 01:44

Hello Sonia,

because you cannot use trust DSCP on VSL links to be sure that you will not have problems you should trust CoS everywhere on all trunk ports directly connected to the VSS.

In this way you can be sure of consistency in QoS treatment.

However, all multilayer switches use internal DSCP tags for QoS classification of flows and the default action is that CoS field is a copy of CS bits of DSCP so there shouldn't be frames without CoS configured on trunks to the VSL.

Hope to help

Giuseppe

sdurn Wed, 01/07/2009 - 02:33

Thanks for the answer.

The problem is that I have a device that marks IP packets with ToS = 184 which corresponds with DSCP = 46 so I have to trust the DSCP value ...

if I configure the trunks to "trust CoS" switch makes the mapping of CoS-DSCP by default?

thanks

Giuseppe Larosa Wed, 01/07/2009 - 03:47

Hello Sonia,

if you trust CoS the internal DSCP tag is chosen from the CoS to DSCP mapping table.

the trust applies to incoming traffic only not to outgoing.

So you face a problem with trust Cos only on trunk links access ports where no CoS can be seen (no vlan tagging is in use)

You probably can:

trust DSCP on the link to the device.

This DSCP is mapped to an internal DSCP according to DSCP to DSCP mapping table.

on the outgoing uplink the CoS value should be set to reflect the internal DSCP tag chosen before in ingress.

That CoS value is then perceived by the VSS that will provide QoS accordingly.

in your case with CoS DSCP 46 is seen as CoS 5.

This is the sense of CoS being a copy of CS bits of DSCP byte.

So this traffic will be treated accordingly to CoS 5 with default settings.

Hope to help

Giuseppe

Actions

This Discussion