Home > 3850, cisco, qos > Simplified QoS on 3850 with MQC

Simplified QoS on 3850 with MQC

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
  1. August 9, 2013 at 9:41 am

    Reblogged this on ytd2525.

  2. Dom
    February 12, 2014 at 2:23 pm

    Very good and concise explanations. Thank you!

    • March 28, 2014 at 5:43 pm

      Appreciate it. Glad it helped out.

  3. March 11, 2014 at 3:48 pm

    Thanks! This is way better the the CISCO kitchen sink dribble!

  4. ONeil Brown
    May 3, 2014 at 6:25 am

    The “exceed-action” does not exisit on the 3850 see excert

    NAUSNYCHUD3850_136(config)#policy-map AUTOQOS-SRND4-CISCOPHONE-POLICY
    NAUSNYCHUD3850_136(config-pmap)# class AUTOQOS_VOIP_DATA_CLASS
    NAUSNYCHUD3850_136(config-pmap-c)# set dscp ef
    NAUSNYCHUD3850_136(config-pmap-c)# police 128000 8000 exceed-action policed-dscp-transmit
    ^
    % Invalid input detected at ‘^’ marker.

    NAUSNYCHUD3850_136(config-pmap-c)# class AUTOQOS_VOIP_SIGNAL_CLASS
    NAUSNYCHUD3850_136(config-pmap-c)# set dscp cs3
    NAUSNYCHUD3850_136(config-pmap-c)# police 32000 8000 exceed-action policed-dscp-transmit
    ^
    % Invalid input detected at ‘^’ marker.

    NAUSNYCHUD3850_136(config-pmap-c)# class AUTOQOS_DEFAULT_CLASS
    NAUSNYCHUD3850_136(config-pmap-c)# set dscp default
    NAUSNYCHUD3850_136(config-pmap-c)# police 10000000 8000 exceed-action policed-dscp-transmit
    ^
    % Invalid input detected at ‘^’ marker.

  5. Pix User
    September 27, 2014 at 8:26 pm

    Thanks for the post. This help me tremendously.

    Cheers, Pixuser

  6. January 28, 2016 at 3:49 pm

    I will definetely try this configuration and will let you know

  7. Gary
    April 10, 2016 at 12:14 am

    Thank you so much for this. Cisco documentation as ever is pretty poor.

  8. TudorAdrian
    September 13, 2016 at 10:04 am

    nice post! One question: on the USER-facing port, would you not have to apply the policy inbound and not outbound? Outbound would be traffic flowing through the switch towards the user’s PC/phone. Inbound would throttle traffic the user would be sending on to the network. Would this make more sense or how is best to do it?

    • November 2, 2016 at 1:45 pm

      There’s no point to applying a QoS policy inbound other than to remark traffic as it is already on the wire and will come into the port as it was sent. There are fewer queus as well in the receive side of the port as opposed to the transmit side where we can shape/police/prioritize traffic as we need.

  9. oliver
    October 12, 2016 at 4:54 am

    Thanks for this as i was left scratching my head with MQC. We have avaya phones physical phones and softphones. What command would i replace the “trust device cisco-phone” with as i have read that doesn’t work? All i can find is auto qos commands.

    • christian
      July 26, 2017 at 2:28 am

      i have the same question. how can i trust the incoming traffic from a non cisco client?

      • July 26, 2017 at 2:41 pm

        the 3850 trusts DSCP by default on all ingress ports. You don’t have to do anything. “trust device cisco-phone” sets both DSCP and CoS values to 0 if the device connected to the port is not a cisco phone.

  10. Marcus
    March 31, 2017 at 1:18 pm

    Thank you my friend !!!! Excellent !!!!

  11. christian
    July 27, 2017 at 2:39 am

    so how do i translate the DSCP to COS values for traffic coming in the LAN-Ports? is the 3850 even looking at the DSCP values when i only have L2 on it? We don’t do Routing on the access-switches and need to send traffic prioritized by COS to send it to the aggregation switches, which have SVI’s on them.

  12. Nathan
    September 11, 2017 at 11:39 am

    Thanks for the simplified explanation. It was exactly what I was looking for.

  13. Darren Carr
    May 24, 2018 at 5:08 pm

    I’m trying to create a shaping configuration for my 3850 that shapes traffic based on a number of destination IPs. The switch takes the configuration, but when I attempt to apply it to an interface outbound, I receive an error stating that the classification must be based on dscp, cos, ip precendence, etc… so it looks like it doesn’t like the use of an ip address for the class-map… have you experienced anything like this or are aware why this may be the case?

    • May 29, 2018 at 9:02 am

      You need an inbound service policy to mark the traffic first then based on those markings you can police it on the outbound interface. For example, using an ACL, set the qos-group of all traffic destined to 1.1.1.1 to 10. Then on the outbound interface, match traffic with qos-group 10 and police it to whatever bandwidth you prefer.

  14. Darren Carr
    May 29, 2018 at 11:50 am

    Thanks! I raised a TAC case with Cisco and got the same reply, much appreciated 🙂

  1. No trackbacks yet.

Leave a comment