Nexus 5000 mls qos trust DSCP on Fabric Extender ports
I am really new to the Nexus 5000 and it's 2148 fex modules. I have no SAN interfaces (FCoE) installed only ethernet interfaces. I understand that qos is enabled default and the trust state of every port is "trust cos".
I only want to trust servers QoS settings and forward them unmodified to my upstream Cat.6509 in the correct queue.
So I guess no extra configuration is needed on dot1q ports if servers are able to mark cos bits. Am I correct?
But what about access ports attached to physical servers on 2148 fex modules. On IOS I would configure "mls qos trust dscp" on this ports, but Í think that is not possible on NX-OS.
on an access port of a Nexus 5020 "mls qos trust dscp" is ON by default and
on a trunk port of a Nexus 5020 "mls qos trust cos" is ON by default
So no extra configuration is needed (as long as the Server will do the correct marking) and the traffic is forwarded based on the uplink 1P6Q0T queuing policy.
Am I right Jerry?
Attached is a show version output as well as an output of "show interface capabilities" and "show queuing interface". It looks to me that 1P6Q0T is not enabled by default on this uplink port. Is this a software issue???
Hi Jeye, This is from the N5K qos config guide. (1) By default, all Ethernet interfaces are trusted interfaces. A packet tagged with an 802.1p CoS value is classified into a system class using the value in the packet. (2) Any packet that is not tagged with an 802.1p CoS value is classified into the default drop system class. If the untagged packet is sent over a trunk, it is tagged with the default untagged CoS value, which is zero. From point (2), it seems that access port will not have 802.1p CoS and will be put into default drop system class rather than trusting the DSCP. I will test it out in my lab tomorrow to verify. THanks Eng Wee
Let me clarify the default drop class and trusting DSCP. By default, on access port, since it is not a trunk, no COS value will be received (everything in the port will be consider as COS 0 for ingress queueing). However, if application/end host's IP header has sat the DSCP value, that value will not be changed. The N5K is trusting the value marked by the end host unless there is a service policy at the ingress to remark it to different value.
The bottom line is COS and DSCP are in different headers. Unless you configured a policy to change the DSCP value, everything will be preserved.
I am still looking for a sample configuration. I just don't know if I can edit the default system policy maps and just add some qos-groups or if I have to define new policy maps etc. There must be some documentation?
So the incoming interfaces are trusted by default for cos and dscp.
Can you provide me with a sample configuration for the egress queueing so that voice (5/EF) will be put in a priority queue and signalling (3/AF31) as well as Video (4/AF41) will be put into the right queue?
Moquery is the command line cousin of Vizore, it's very helpful and efficient sometimes during the troubleshooting. This article aims to provide moquery cheat sheet to the users for some most common seen scenarios.
Here is the checklist before customers/partners contact Cisco TAC:
Firmware Version of APIC and Switch
Download Switch and APIC techsupport logs
Problem description (Symptoms with details)
Business impact (eg, what kind of services...
moquery usageAPIC moquerySwitchmoquery
This document discuss a common issue observed during the VMM integration & VM workload migration to ACI fabric.
VMware Virtual machines are hosted in Cisco UCS-B seri...