Archive

Archive for the ‘qos’ Category

Some QoS Notes on Cisco Nexus 7k

February 4, 2014 3 comments

Now that I have moved a significant portion of my enterprise network to our new core based on Nexus 7k switches, I need to start thinking about how to implement QoS as I am in a healthcare environment and some traffic MUST make it to its destination regardless of congestion. Currently, I don’t see any congestion on our network but traffic is always increasing and a good QoS policy will keep the business running.

Here are some important things to remember:
– QoS is on by default and cannot be turned off.
– There are default class-maps and policy-maps configured and applied to all interfaces by default.
– default policy-map cannot be modified.
– Ports trust CoS by default and use it for inbound and outbound queue selection.
– The 7k assigns EGRESS traffic to queues based on CoS even if the egress interface does not carry CoS in the frame (i.e. it’s a L3 interface).
– Interface based QoS takes precedence over VLAN based
– VLAN based QoS policy is configured in VLAN Database, no SVI is required.

There are four default rules to remember for CoS/DSCP and queue assignment. I copied these verbatim from the BRKDCT-3346 slide deck presented by Lukas Krattiger at CLUS 2013:

For Bridged Traffic:
If CoS and DSCP is present:
– CoS is used for ingress queue selection
– CoS is preserved
– DSCP is unmodified
– CoS is used for egress queue selection

If only DSCP is present:
– No CoS is treated as CoS 0 on ingress
– CoS 0 is used for iungress and egress queue selection
– DSCP is unmodified

For Routed Traffic
If CoS and DSCP is present:
– Cos is used for ingress queue selection
– DSCP is preserved and rewrites CoS (top 3 bits)
– Re-written CoS is used for egress queue selection

If only DSCP is present:
– No CoS gets treated as CoS 0 in ingress
– DSCP is preserved and rewrites CoS (top 3 bits)
– Re-written CoS is used for egress queue selection

Default Policy
Nexus 7k’s do have a default QoS policy in place that is applied to all interfaces in all VDC’s which assigns COS 5-7 on the ingress side to queue 1 and everything else to the default queue. On the egress side COS 5-7 is assigned to the egress priority queue and everything else to the default queue as shown below:

sh class-map type queuing Type queuing class-maps ======================== class-map type queuing match-any 8q2t-in-q1 Description: Classifier for ingress queue 1 of type 8q2t match cos 5-7 class-map type queuing match-any 8q2t-in-q-default Description: Classifier for ingress default queue of type 8q2t match cos 0-4 class-map type queuing match-any 1p7q4t-out-pq1 Description: Classifier for egress priority queue of type 1p7q4t match cos 5-7 class-map type queuing match-any 1p7q4t-out-q-default Description: Classifier for egress default queue of type 1p7q4t match cos 0-4

The above queue structure is from a M2 10gig module which has 8 ingress queues with 2 tail drop thresholds per queue and on the egress side there is 1 priorty queue and 7 queues with 4 tail drop thresholds each. Each module is different though. For example, a M148GS-11L module which has 48 1gig ports has a 2q4t ingress queue structure and a 1p3q4t egress queue structure. The class maps for it would resemble the one above except with fewer queues to map to.

So back to the defaults, there is also a default policy map applied to all ports using the above COS to queue mappings:

sh policy-map type queuing Type queuing policy-maps ======================== policy-map type queuing default-in-policy class type queuing in-q1 queue-limit percent 50 bandwidth percent 80 class type queuing in-q-default queue-limit percent 50 bandwidth percent 20 policy-map type queuing default-out-policy class type queuing out-pq1 priority level 1 queue-limit percent 16 class type queuing out-q2 queue-limit percent 1 class type queuing out-q3 queue-limit percent 1 class type queuing out-q-default queue-limit percent 82 bandwidth remaining percent 25

You can see on ingress, 50% of the queues are allocated to queue 1 and the other half to the default inbound queue. On the outbound side, pq1 is defined as the priority queue given a percentage of the queue space as are queue 3,4 and the default queue. Notice the names don’t match up with the actual class-map names. These are default class-map names that match on any queue type, for example:

class-map type queuing match-any in-q1 Description: This is a default class-map name. Prefix the module queue type to this class name to see the actual cos2 map (e.g. To print in-q1, use 2q4t-in-q1 or 8q2t-in-q1)

Where do I configure these things?
– Class maps for queue selection are done in the admin/default VDC and apply to all interfaces across all VDC’s.
– Policy maps are configured per VDC and are assigned on a per-port or per-vlan basis.

If you configure a custom class map, be sure to assign queue-limits within your policy map for your queues. If you do not, no queue space will be allocated for that queue and you will start tail dropping traffic assigned to that queue immediately.

I will post more on this topic as I flesh out my QoS policy a little more and we can get into creating custom class-maps and policy-maps.

Categories: nexus, qos

Simplified QoS on 3850 with MQC

August 9, 2013 13 comments

Configuring QoS has been much improved in Cisco’s new 3850 line of switches thanks to its implementation of MQC (Modular QoS Cli) configuration instead of the old “mls qos” commands from the 3750 and 3560 lines of switches.  Here I will show just how easy it is to generate a simple QoS config to handle voice and video traffic.

First we define what traffic we would like to work with.  In this case it is voice traffic marked as dscp ef and video traffic marked as dscp af41.

class-map match-any VIDEO match ip dscp af41 class-map match-any VOICE match ip dscp ef

Easy enough. Now lets configure the policy maps to actually do something with this traffic. I will configure two separate policy maps. one for user facing ports and one for the uplinks to my distribution layer.

I would like to prioritize both voice and video traffic over everything else but I want voice to be prioritized over everything. The 3850 actually has 2 priority queues that enable me to do this, a level 1 and level 2 priority queue.

policy-map UPLINK class VOICE priority level 1 percent 10 police cir percent 10 conform-action transmit exceed-action drop class VIDEO priority level 2 percent 20 police cir percent 20 conform-action transmit exceed-action drop class class-default bandwidth remaining percent 100 policy-map USER class VOICE priority level 1 percent 1 police cir percent 1 conform-action transmit exceed-action drop class VIDEO priority level 2 percent 5 police cir percent 5 conform-action transmit exceed-action drop class class-default bandwidth remaining percent 100

Above I have separate policy maps based on if it’s a user or uplink port. For user ports, voice traffic is put in priority queue 1 and guaranteed 1% or 10Mbps of throughput. I also capped it at 10Mbps with the police command to prevent this queue from hogging bandwidth. Same process is followed for voice. It is placed in priority queue 2 and it is guaranteed 50Mbps throughput. On the uplinks, the only change is the percentages of guaranteed bandwidth has been increased.All other traffic gets 100% of the remaining bandwidth.

All that is left is to apply these policy maps to some interfaces.

interface GigabitEthernet1/0/1 switchport access vlan 302 switchport mode access switchport voice vlan 402 trust device cisco-phone spanning-tree portfast service-policy output USER interface GigabitEthernet1/1/1 description --- UPLINK --- switchport trunk allowed vlan 302,402 switchport mode trunk service-policy output UPLINK ip dhcp snooping trust

Done! We can even get some meaningful stats now as well. I haven’t pushed any traffic through this switch yet but you get the idea.

3850#sh policy-map int gig 1/1/1 GigabitEthernet1/1/1 Service-policy output: UPLINK queue stats for all priority classes: Queueing priority level 1 (total drops) 0 (bytes output) 0 queue stats for all priority classes: Queueing priority level 2 (total drops) 0 (bytes output) 0 Class-map: VOICE (match-any) Match: ip dscp ef (46) Priority: 10% (100000 kbps), burst bytes 2500000, Priority Level: 1 police: cir 10 % cir 100000000 bps, bc 3125000 bytes conformed 0 bytes; actions: transmit exceeded 0 bytes; actions: drop conformed 0000 bps, exceed 0000 bps Class-map: VIDEO (match-any) Match: ip dscp af41 (34) Priority: 20% (200000 kbps), burst bytes 5000000, Priority Level: 2 police: cir 20 % cir 200000000 bps, bc 6250000 bytes conformed 0 bytes; actions: transmit exceeded 0 bytes; actions: drop conformed 0000 bps, exceed 0000 bps Class-map: class-default (match-any) Match: any Queueing (total drops) 0 (bytes output) 0 bandwidth remaining 100%

As you can see pretty painless QoS implementation. Of course you can get much more complicated if needed with nested policy-maps, table maps etc. Here is the IOS-XE QoS documentation if you want to delve further into QoS IOS XE QoS Config Guide”

Categories: 3850, cisco, qos