cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1382
Views
0
Helpful
6
Replies

Nexus 7000 QoS, What am I missing?

clark.adam.p
Level 1
Level 1

Hi all,

  I just spent 3 hours with TAC getting no where, but my problem seems simple.

Topology is below.

Each host has a primary VLAN (V1 and V2) with a default GW towards the Nexus, and a common VLAN (V3) between them

---- V1 |----| V2 ----

| A |----| N7K |----| B |

-----    | RTD |    -----

  |  V3  |-----|      |

  ----------------------

A is on a 802.1Q trunk with V1 and V3, B is also on an 802.1Q trunk with V2 and V3

Both interfaces are configured with a simple policy-map

class-map type qos match-any VOICE

  match dscp 46

policy-map type qos Test

  class VOICE

    set dscp 32

  class class-default

    set dscp 0

interface eth x/y , x/z

   service-policy type qos input Test

Any EF traffic, remark to CS4, otherwise mark default.

If I ping with ToS set to EF between the IP addresses on V1 and V2, which routes through the Nexus, remarking happens as expected.  Policy Map has hits.  Remark verified by tcpdump as CS4

If I ping with ToS set to EF between the common V3, which switches through, marking is not happening, Policy gets hits though, tcpdump show no marking change still EF.

I can even send packets with another value, say CS1, no remarking to default.

Is this a significant limitation with Nexus QoS?

Cheers

Adam


6 Replies 6

clark.adam.p
Level 1
Level 1

Bump. Anyone?

Sent from Cisco Technical Support iPhone App

Hello Adam-

Couple of questions:

1. What are the "A" and "B" devices?

2. Where do the ports on the common VLAN (V3) plugged to? My guess is still the Nexus but the diagram suggests otherwise

3. Can you post the configs for all of the ports connecting to the "A" and "B" devices?

4. Can you post your entire QoS config?

Neno,

  1.  A and B are B200M2s in a UCS environment running CentOS 6, one is pinned to Fab A (Po10), the other to Fab B (Po11)

  2. Yeah, all VLANs are through the Nexus

  3 & 4.   Configs below

!Command: show running-config interface port-channel10-11

!Time: Fri Feb 15 14:56:24 2013

version 6.1(1)

interface port-channel10

  description UCS-1 (Po10)   - Fabric A

  switchport

  switchport mode trunk

  switchport trunk allowed vlan 86-88,91,108,110-112,120-122,127

  switchport trunk allowed vlan add 137-138,149-150,152,192

  spanning-tree port type edge trunk

  mtu 9216

  service-policy type qos input UCS_Ports_In2

interface port-channel11

  description UCS-2 (Po11)   - Fabric B

  switchport

  switchport mode trunk

  switchport trunk allowed vlan 86-88,91,108,110-112,120-122,127

  switchport trunk allowed vlan add 137-138,149-150,152,192

  spanning-tree port type edge trunk

  mtu 9216

  service-policy type qos input UCS_Ports_In2

!Command: show running-config interface Ethernet1/1, Ethernet1/3, Ethernet2/1-4, Ethernet10/2, Ethernet10/4

!Time: Fri Feb 15 14:56:30 2013

version 6.1(1)

interface Ethernet1/1

  description UCS-1 (Eth1/1)

  switchport

  switchport mode trunk

  switchport trunk allowed vlan 86-88,91,108,110-112,120-122,127

  switchport trunk allowed vlan add 137-138,149-150,152,192

  mtu 9216

  channel-group 10 mode active

  no shutdown

interface Ethernet1/3

  description UCS-1 (Eth1/4)

  switchport

  switchport mode trunk

  switchport trunk allowed vlan 86-88,91,108,110-112,120-122,127

  switchport trunk allowed vlan add 137-138,149-150,152,192

  mtu 9216

  channel-group 10 mode active

  no shutdown

interface Ethernet2/1

  description UCS-2 (Eth1/2)

  switchport

  switchport mode trunk

  switchport trunk allowed vlan 86-88,91,108,110-112,120-122,127

  switchport trunk allowed vlan add 137-138,149-150,152,192

  mtu 9216

  channel-group 11 mode active

  no shutdown

interface Ethernet2/2

  description UCS-1 (Eth1/1)

  switchport

  switchport mode trunk

  switchport trunk allowed vlan 86-88,91,108,110-112,120-122,127

  switchport trunk allowed vlan add 137-138,149-150,152,192

  mtu 9216

  channel-group 10 mode active

  no shutdown

interface Ethernet2/3

  description UCS-2 (Eth1/4)

  switchport

  switchport mode trunk

  switchport trunk allowed vlan 86-88,91,108,110-112,120-122,127

  switchport trunk allowed vlan add 137-138,149-150,152,192

  mtu 9216

  channel-group 11 mode active

  no shutdown

interface Ethernet2/4

  description UCS-1 (Eth1/1)

  switchport

  switchport mode trunk

  switchport trunk allowed vlan 86-88,91,108,110-112,120-122,127

  switchport trunk allowed vlan add 137-138,149-150,152,192

  mtu 9216

  channel-group 10 mode active

  no shutdown

interface Ethernet10/2

  description UCS-2 (Eth1/1)

  switchport

  switchport mode trunk

  switchport trunk allowed vlan 86-88,91,108,110-112,120-122,127

  switchport trunk allowed vlan add 137-138,149-150,152,192

  mtu 9216

  channel-group 11 mode active

  no shutdown

interface Ethernet10/4

  description UCS-2 (Eth1/3)

  switchport

  switchport mode trunk

  switchport trunk allowed vlan 86-88,91,108,110-112,120-122,127

  switchport trunk allowed vlan add 137-138,149-150,152,192

  mtu 9216

  channel-group 11 mode active

  no shutdown

class-map type qos match-all VIDEO_BEARER

  match dscp 34

policy-map type qos UCS_Ports_In2

  class VOICE_BEARER

    set dscp 32

  class class-default

    set dscp 0

I am by no means a QoS expert but I thought that DSCP is layer 3 based while CoS is layer 2. Does the application mark its traffic based on CoS as well? If it is you can perhaps do something like this:

class-map type qos match-any VOICE

  match dscp 46

  match cos 5

Assuming that the the cos to dscp value is 5 to 46. Otherwise, you might have to create a cos-to-dscp map.

There is no problem with matching traffic, as I said in the original post, under both situations the policy map counters increase on the correct class.  If the packet is routed by the Nexus, remark happens, if it is switched, there is no modification.

The problem being is that I need to mark the packet for treatment on multiple hops, so the ToS byte needs to be marked.

This is stuff that has been around for years on 3x00 and 6500s.  If Nexus can't do it, that is a significant flaw.

Was hoping that someone was going to tell me outright that what I am trying to do is unsupported.

clark.adam.p
Level 1
Level 1

Hi all,

  Bit of an update.  It turns out M2 line cards are unable to mark DSCP values.  If you put a set DSCP statement in your policy map, it marks the equivelent CoS value.

This becomes a bit of an issue when you use OTV as it only used the DSCP value to populate the outer tunnel address and the subsequent CoS value at tunnel egress.

You can manually allocate an outer DSCP value based on an recieved CoS value on the OTV later 2 ports.

This is an internal bug.  Ask your TAC engineer about it:

CSCud65096    M2: Qos Policy on Vlan does  not reset DSCP for Bridged traffic

Review Cisco Networking for a $25 gift card