02-14-2013 12:45 AM - edited 03-07-2019 11:42 AM
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
02-14-2013 03:26 PM
Bump. Anyone?
Sent from Cisco Technical Support iPhone App
02-14-2013 07:11 PM
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?
02-14-2013 07:58 PM
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
02-14-2013 08:45 PM
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.
02-14-2013 09:32 PM
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.
02-20-2013 07:05 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide