Cisco 3850 switch sample QOS Configuration for Voice and Video

HINT: If you have soft-phones or Soft Video clients  on your network then this is not for you.  You might want to explore the use of access list instead. 

 

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Catalyst 3850 Configuration samples 

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

This configuration was designed to optimize a network that generates 30% Voip and Video  traffic whilst the remaining is bulk data.  This solution is currently  working perfectly in  an extremely busy network. The brief was that the configuration be kept simple yet effective. 

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Steps:: 

Create two class maps: The first class maps matches the DSCP  and COS markings of Audio and Video traffic:

class-map rtp_audio_and_video
match dscp af32 af33 cs4 af41 af42 af43 ef
match cos 4 5

class-map signal
description voip signal traffic
match dscp cs3 af31 af32 af33
match cos 3

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

One of the cool features of the 3850 switch is that it allows for the creation of two priority queues. So on this occasion, I placed both  Audio and Video traffic in the first priority queue while placing the VIOP and video signalling traffic in the second priority queue. However, please note that because Video traffic is more burst-y than RTP audio, it is better to place Video traffic in the second priority queue when designing qos for a network where there is an extensive video deployment.

Notice that at the end I just  added the command:  ‘ class call-default’ ? This is the ‘catch-all’ statement that matches any traffic that was not expressly matched by the   class-maps above.

policy-map media_priority
class rtp_audio_and_video
priority level 1 percent 35
class signal
priority level 2 percent 15
class class-default

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

The statement below can then be applied to all trunk interfaces. For trunk-groups/ether-channels, you can add the command in both input and output directions.

service-policy output media_priority

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

The following commands were placed on all the access ports. The first command tells the switch to only accept qos markings from  cisco-phones. However, the Cisco 3850 switch provides for  the ability to trust other devices like ,  Cisco Digital Media Player, Cisco TelePresence System, and  IP Video Surveillance Cameras.

The second line tells the Cisco phone to mark all traffic coming form the connected PC with  a COS value of 0.

One thing that should be noted is that by default, the Cisco 3850 switch will trust all QOS markings coming from attached devices so I would advise on using the ‘ trust device’ statements to lock-down  or prevent rouge devices from marking the QOS  values of their traffic too high.

trust device cisco-phone

switchport priority extend cos 0

service-policy output media_priority

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Now that we’ve talked about the configurations, let talk about how to check whether the qos is actually working.:

Looking that output below, you will notice that ‘bytes output’ and ‘total drops’ counters. These are the counters that you need to look out for: issue the command every few seconds and see whether the counters  are increasing.

You will also notice that the class-map counters are all zero. Don’t let this alarm you.  The qos is working; Cisco has just done what they do very well which is to get everyone startled. Ignore that part.  If in doubt, apply an aggressive policing  policy to the traffic that you are matching and see everything grind to a halt 🙂

BRAZIL-3850-STK1#show policy-map interface g1/0/1

GigabitEthernet1/0/1

Service-policy output: media_priority

queue stats for all priority classes:

Queueing

priority level 1

(total drops) 0

(bytes output) 893757086

queue stats for all priority classes:

Queueing

priority level 2

(total drops) 0

(bytes output) 34404961

Class-map: rtp_audio_and_video (match-any)

0 packets

Match:  dscp af32 (28) af33 (30) cs4 (32) af41 (34) af42 (36) af43 (38) ef (46)

0 packets, 0 bytes

5 minute rate 0 bps

Match: cos  5

0 packets, 0 bytes

5 minute rate 0 bps

Match: cos  4  5

0 packets, 0 bytes

5 minute rate 0 bps

Priority: 35% (350000 kbps), burst bytes 8750000,

Priority Level: 1

Class-map: signal (match-any)

0 packets

Match:  dscp cs3 (24) af31 (26) af32 (28) af33 (30)

0 packets, 0 bytes

5 minute rate 0 bps

Match: cos  3

0 packets, 0 bytes

5 minute rate 0 bps

Priority: 15% (150000 kbps), burst bytes 3750000,

Priority Level: 2

Class-map: class-default (match-any)

0 packets

Match: any

0 packets, 0 bytes

5 minute rate 0 bps

(total drops) 0

      (bytes output) 2422713863

Did you notice anything  odd about the Class-maps configurations above? Ok let me ask the question: Are those class-maps a ‘ match-any’ or ‘match-all’ statement?

We all know that if an Engineer  does not expressly configure her  class-map with a  ‘ match-any’ statement,  the class-map  will be set to  a ‘ match-all’ statement. But in the 3850 switches; this is not true.  A quick look at the output of the ‘show policy-map interface g1/0/1’ above will prove this.

Hope you find this helpful.

Cheers

Maxwell

Enterprise Qos Design and Configuration samples for 2960 LAN Lite ,3750 and 6509E Catalyst switches || part two

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Catalyst 6509  Configuration sample

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Thanks for dropping by again.  I have now added   this configuration sample as a follow up to  ‘ part one’ of this particular post.    This sample was applied a  Cisco 6509 switch stationed in a collapsed core. For clarity, I divided the configurations into three parts.

::::::::::::::::::::::::::::::::::::::::::::::::::

Egress Queuing Configurations

::::::::::::::::::::::::::::::::::::::::::::::::::

policy-map type lan-queuing Egress_1p3q8t
class cos_5
priority
class cos_6_&_7
bandwidth remaining percent 20
queue-buffers ratio 15
random-detect cos-based
random-detect cos 6 percent 98 100
random-detect cos 7 percent 98 100
class cos_2_3_&_4
bandwidth remaining percent 15
queue-buffers ratio 25
random-detect cos-based
random-detect cos 2 percent 80 90
random-detect cos 3 percent 90 100
random-detect cos 4 percent 90 100
class class-default
bandwidth remaining percent 35
queue-buffers ratio 40
random-detect cos-based
random-detect cos 0 percent 70 100
random-detect cos 1 percent 40 70

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Ingress Queuing Configurations

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

policy-map type lan-queuing Ingress_2q8t
class cos_5
bandwidth percent 30
queue-buffers ratio 10
queue-limit cos 5 percent 100
class class-default
bandwidth percent 70
queue-buffers ratio 50
queue-limit cos 1 percent 65
queue-limit cos 2 percent 65
queue-limit cos 0 percent 75
queue-limit cos 4 percent 80
queue-limit cos 3 percent 90
queue-limit cos 6 percent 100
queue-limit cos 7 percent 100

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

These Configurations were applied to every trunk port  to other switches and also to switch-ports connected to Unified Communications servers:

platform qos trust dscp

Service-policy type lan-queuing output Egress_1p3q8t

service-policy type lan-queuing input Ingress_2q8t

 

Hope you’ve found this useful.

Thanks for dropping by.  

 

Enterprise Qos Design and Configuration samples for 2960 LAN Lite ,3750 and 6509E Catalyst switches || part one.

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Catalyst 3750 Configuration samples 

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Over the past few weeks, I have been working on a number of quality-of-service (Qos) design and deployment projects so I  thought I’d just spend some time to blog about it since I loved it so much.   In the next few weeks, I will add new entries to this blog for each of the three switch models listed above. Today I will be focusing on the Catalyst 3750.

The Sample configurations below were designed to meet the needs of a branch office comprising of over 500 users.  I will not disclose the nature of the client’s business but it’s sufficient  to say that they generate a massive amount of telephone calls per day.  The client complained that the plague of bad call quality was never too far away from them. They were frustrated by the fact that they could hardly hear the people on the other side of the line and sometimes, the calls would just drop off mid-conversation.

The configurations below is a sample of one of  the configurations that I designed and deployed somewhere in the globe.  I have not added explanations for each configuration line because I thought I’d simply allow anyone to ask a question if they needed more explanation. The intention is to provide a sample config that could possibly be of use to someone out there.

::::::::::::::::::::::::::::::::::::::::::::::::::

Design Considerations:

::::::::::::::::::::::::::::::::::::::::::::::::::

This configuration was designed to optimize a network that generates 30% Voip  traffic whilst the remaining is bulk data.  This solution is currently  working perfectly in  an extremely busy network.

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

mls qos

mls qos srr-queue input priority-queue 2 bandwidth 30
mls qos map cos-dscp 0 8 16 24 32 46 48 56
mls qos srr-queue input bandwidth 70 30
mls qos srr-queue input threshold 1 75 90
mls qos srr-queue input threshold 2 90 100
mls qos srr-queue input buffers 85 15

mls qos srr-queue input cos-map queue 1 threshold 1 0 1 2
mls qos srr-queue input cos-map queue 1 threshold 2 3
mls qos srr-queue input cos-map queue 1 threshold 3  6 7
mls qos srr-queue input cos-map queue 2 threshold 2 4

mls qos srr-queue input cos-map queue 2 threshold 3  5

mls qos srr-queue input dscp-map queue 1 threshold 1 0 8 10  12  14 16 18 38

mls qos srr-queue input dscp-map queue 1 threshold 1 20 22 26 28 30 34 36

mls qos srr-queue input dscp-map queue 1 threshold 2 24
mls qos srr-queue input dscp-map queue 1 threshold 3 48 56

mls qos srr-queue input dscp-map queue 2 threshold 2 40 32

mls qos srr-queue input dscp-map queue 2 threshold 3 46

mls qos srr-queue output cos-map queue 1 threshold 3  5

mls qos srr-queue output cos-map queue 1 threshold 2 4
mls qos srr-queue output cos-map queue 2 threshold 3 6 7

mls qos srr-queue output cos-map queue 2 threshold 2 1 2

mls qos srr-queue output cos-map queue 3 threshold 3 3

mls qos srr-queue output cos-map queue 4 threshold 3 0

mls qos srr-queue output dscp-map queue 1 threshold 3 46 40 32

mls qos srr-queue output dscp-map queue 2 threshold 3 48 56

mls qos srr-queue output dscp-map queue 2 threshold 2 8 10 12 14 16 18 20 22

mls qos srr-queue output dscp-map queue 2 threshold 2 26 28 30 34 36 38

mls qos srr-queue output dscp-map queue 3 threshold 3 24

mls qos srr-queue output dscp-map queue 4 threshold 3 0
mls qos queue-set output 1 threshold 1 85 90 100 100
mls qos queue-set output 1 threshold 2 80 90 100 400
mls qos queue-set output 1 threshold 3 100 100 100 100
mls qos queue-set output 1 threshold 4 130 140 100 400
mls qos queue-set output 2 threshold 1 149 149 100 149
mls qos queue-set output 2 threshold 2 118 118 100 235
mls qos queue-set output 2 threshold 3 41 68 100 272
mls qos queue-set output 2 threshold 4 42 72 100 242

mls qos queue-set output 1 buffers 10 20 10 60
mls qos queue-set output 2 buffers 16 6 17 61

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

These Configuration were applied to every switch-port that was connected to a Cisco phone:

mls qos trust cos

switchport priority extend cos 0

mls qos trust device cisco-phone

priority-queue out

srr-queue bandwidth share 30 15 10 45

queue-set 1

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

These Configuration were applied to every trunk port.

mls qos trust cos

priority-queue out

srr-queue bandwidth share 30 15 10 45

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Hope you’ve found this useful.

Thanks for dropping by.