cisco Nexus9000 C92160YC-X qos question

[FAAA]

Hi

I have a couple of cisco Nexus9000 C92160YC-X as core switches. I have 6 pairs of catalyst 9300 switches connected via VPC to these cores. I was configuring auto qos voip trust on these access switches but I came across an issue on the core switches. Since these are nexus i couldn't do auto qos. 

My question is, do i have to manually configure qos on the core nexus switches or is there a default on the switch which will handle and keep the dscp/cos markings?

Thanks

[Enes Simnica]

hello, Great question, and u're right to notice the difference. Your Nexus 9000 C92160YC-X core switches don’t support Auto QoS like the Catalyst 9300s. That’s expected since Nexus platforms use a more manual, policy-based QoS model.

By default, Nexus switches preserve DSCP and CoS markings — they won’t strip or remark them unless you explicitly configure a policy to do so. So if your access switches (the 9300s) are marking traffic correctly (e.g. with auto qos voip trust), and ur Nexus core doesn’t have any policies applied, those markings will still make it through.

However, just preserving the markings isn’t enough if u want real priority treatment for VoIP or other critical traffic. For that, u’ll need to manually configure QoS on the Nexus, define class maps for DSCP values like EF, build policy maps, and apply them to interfaces.

So in short: u don’t have to configure QoS to keep the markings, but you do need to if you want the core to act on them.

also, let me know if u'd like help creating a basic Nexus QoS config for voice! also we can lab this too....

check the link G: 

• https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/qos/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Quality_of_Service_Configuration_Guide_7x.html 

-Enes

[Enes Simnica]

also G: 

• https://www.youtube.com/watch?v=vCqG1cCCedo 
• https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/105x/configuration/qos/cisco-nexus-9000-series-nx-os-quality-of-service-configuration-guide-105x.pdf 

hope it helps... and again, u can lab this on EVEng before going live....

-Enes

[FAAA]

Wow thanks so much! I basic config would be greatly appreciated. Also I have a question around webrtc traffic. If I have auto qos trust voip on the access switches would it appropriately prioritise webrtc traffic as well as voip traffic? 

Could do with a qos policy which prioratises webrtc traffic and voip traffic however sometimes our core switches are hitting 100% cpu briefly so I don't want there to be a big performance hit. 

Thanks

[Enes Simnica · Accepted solution]

Ur welcome @FAAA , and If u're using auto qos voip trust on ur Catalyst 9300 access switches, it trusts DSCP markings, but WebRTC traffic isn’t always marked correctly by default, it depends on the browser or app. If WebRTC is marked as AF41 or AF42, it will be prioritized; if it's unmarked (DSCP 0), it’ll fall into best/effort unless u re mark or classify it upstream.

-On the Nexus 9000 core, since Auto QoS isn’t available, u’ll need a manual QoS policy to ensure VoIP (EF) and WebRTC (AF41) are treated properly. The config below keeps things lightweight to avoid any major CPU impact, no shaping or policing, just classification and simple queuing..

here is the config G:

! Enable system-wide hardware QoS (critical for VPC and CPU offload)
system qos

! Class Maps: Identify VoIP and WebRTC traffic
class-map match-any VOICE
  match dscp ef

class-map match-any WEBRTC
  match dscp af41 af42

! Policy Map: Prioritize VoIP, guarantee bandwidth for WebRTC
policy-map QOS-POLICY
  class VOICE
    priority level 1       ! Strict priority (lowest latency)
  class WEBRTC
    bandwidth percent 20   ! Guaranteed minimum bandwidth
  class class-default
    bandwidth percent 50   ! Best-effort traffic

Apply to ALL relevant interfaces:
1. Uplinks (for example/ Eth1/1)
int E1/1
  service-policy type qos output QOS-POLICY

2. VPC Peer-Link (MUST include this)
interface port-channelX     Replace X with your VPC peer-link number
  service-policy type qos output QOS-POLICY

3. VPC Member Ports (optional, if needed)
interface port-channelY    ! Replace Y with VPC member port-channel
  service-policy type qos output QOS-POLICY

and use these commands for verification: 

• #show policy-map interface ethernet1/1
• #show policy-map interface port-channelX
• show system resources | inc CPU

hope it helps...

-Enes

[FAAA]

Thank you very much. Much appreciated. 

[Joseph W. Doherty]

The config below keeps things lightweight to avoid any major CPU impact, no shaping or policing, just classification and simple queuing..

BTW, usually switches support their QoS features in hardware (i.e. other than CPU), which is why their QoS support is generally more feature limited than a software based router's.  I.e. using QoS features usually doesn't load up the CPU or make much, if any, degradation of a switch's performance.

Also, generally the Nexus series hardware is oriented toward moving lots and lots (and lots) of bits.  So, often you'll find its QoS features more limited than on Catalyst switch.

Also, as switch hardware evolves, advanced features, often only found on software based routers, appear on switches.

[Enes Simnica]

yesssiirrr. also I love the Nexus world, man… it’s just sick. even though not the most flexible with QoS, but the way it moves massive traffic effortlessly is wild. Cool to see hardware QoS catching up bit by bit too.....

[Joseph W. Doherty]

policy-map QOS-POLICY

  class VOICE

    priority level 1 ! Strict priority (lowest latency)

  class WEBRTC

    bandwidth percent 20 ! Guaranteed minimum bandwidth

  class class-default

    bandwidth percent 50 ! Best-effort traffic

In concept, probably such a policy, or something similar, would be fine.

In practice, how that policy actually works, isn't necessarily obvious, and without fully understanding how it works can cause "unexpected" issues.

I'm very rusty in me Nexus QoS, especially as I recall it can vary much between different Nexus series, so take the following with a grain of salt.

Generally, a priority statement, on a switch, is PQ, which provides absolute priority over all other traffic.

Class bandwidth statements don't necessarily guarantee the bandwidth shown, what they effectively do, is determine relative dequeuing bandwidth ratios.  So, in this policy, if there's congestion, the Voice class will obtain whatever bandwidth that's possible, and Webrtc and ALL other traffic will split the remaining AVAILABLE bandwidth in a 2:5 ratio.  This may be just fine, but possibly not, especially for Webrtc traffic.

Although there's a comment that the class-default is best-effort traffic, it may important to realize, in this case, it's any traffic without a DSCP EF, AF41 or AF42 marking.

Especially with priority classes, you really want to insure someone doesn't abuse the class.  (Imagine FTP traffic with a DSCP EF marking.  Probably something we want to insure cannot happen, OR, we otherwise "pull its fangs".)

Lastly, regarding using AutoQoS, is convenient, but just like the above, you should verify what it will do, won't lead, later on, to an unpleasant surprise.

[MHM Cisco World]

One Q

Why you need QoS in Core SW if you enable auto qos in access SW?

MHM

[Joseph W. Doherty]

Why you need QoS in Core SW if you enable auto qos in access SW?

To provide QoS to the Nexus interfaces.

Consider multiple downstream devices, like FEXs, sending enough data to another downstream device, enough, in sum, to exceed the (downlink) bandwidth to the destination device.  I.e. the classical multiple to one situation.

[MHM Cisco World]

You are admin of your network' so simply use PO between SW to make host/server get as much as it need.

The BW percent is only need core interface toward WAN router or ISP.

MHM

[Joseph W. Doherty]

The BW percent is only need core interface toward WAN router or ISP.

By the same logic, why not just increase bandwidth to your WAN or ISP?

However the problem with the PO approach is, okay, so you increase bandwidth to a bandwidth hungry downstream attached device, but as bandwidth is usually symmetrical, that downstream device can now, by sending at the increased bandwidth rate, overrun any other edge device with less bandwidth.  I.e. the other classical congestion cause, faster to slower.

To make these two classical bottlenecks situations clearer.  Consider a 48 gig port switch with 47 workstations and one file server.  Just two workstations, let alone 47, can bottleneck sending to the server.

Further, let's say the 48 gig port switch supports 4 10g ports.  If we connect the server to a 10g port, it could handle 10 workstations sending it data.  But, now you have the server can send 10g to any one workstation, another bottleneck.

If you want to guarantee performance, often it cannot be done by just adding bandwidth.  That's not to imply QoS eliminates the need for bandwidth, just that often, again, adding bandwidth, is insufficient, by itself, to guarantee some quality of service metric.

As aside, often these bottlenecks are unnoticed because congestion is brief and/or not too adverse, most of the time, to the application.  Something, though, like VoIP service needs are a tad more stringent than your grandparent's FTP service needs.

Even without the distinction between VoIP and FTP service needs, personally I like apps to perform as I expect ALL the time, not just SOME of the time.

[MHM Cisco World]

Check photo I attach.

This cisco recommend' no need BW allocation only in link to WAN

Between his core and Access SW no need so that why I ask why you want auto qos.

Access SW can do job of classify' no need to make core reclassify or bw allocation for traffic.

Anyway that all I have.

Sorry my time is limit 

MHM

[Joseph W. Doherty]

---

@MHM Cisco World wrote:

Check photo I attach.

This cisco recommend' no need BW allocation only in link to WAN

---

You mean the "photo", below?  If so, Access, WAN and Distribution all have QoS features noted!

Bandwidth allocation, would likely fall under the topics of Access:  Egress Queue Scheduling, and for Distribution:  Egress Scheduling, (Multiple Queues with WRR), and Priority Queuing for VoIP.  As @Enes Simnica suggested using an CBWFQ policy for Nexus interface egress, that would certainly align with the "Photo".

Actually, only the WAN doesn't explicitly mention Egress Scheduling, but it should.  It does mention Bandwidth Provisioning (meaning only total, not app specific, like for VoIP?), Admission Control, and Shaping.  It also mentions Link Fragmentation and Interleaving, and Header Compression.  The latter two, I haven't found much need for since the days my WANs had less than 256 Kbps.  (So, how old was the documentation using this photo?)

Unfortunately, as you note your time is limited, you likely don't have the time to actually learn QoS beyond the most basic level and, IMO, as I consider much QoS material deplorable (like that photo), it's difficult to get beyond a basic understand of QoS level.

When you get beyond a basic understanding of QoS, you then you'll likely understand why statements like, below, are often, ah, incorrect:

---

@MHM Cisco World wrote:

. . . no need to make core . . . bw allocation for traffic.