CS3850 voice VLAN QoS

[gcook0001]

I may be missing something here.  We have two CS3850 switches in our data center that will never have a VOIP device attached to them.   They do carry VOIP traffic over a dedicated vlan.   Everything I read has to do with setting up QoS per port.  I would just like to setup QoS on the switches to prioritize our VOIP traffic based on the vlan.

Topology wise.   In our office we have a HP Procurve switch that our phones connect to.  This switch is connected to one CS3850 in our data center.  The CS3850 is connected to our primary firewall.  It is also connected to second CS3850 (no stack) which is connected to our secondary firewall.  I have QoS configured on the HP and the firewalls.  Just not sure about the CISCO switches.  We are using polycom phones with hosted PBX.

I did find the following

class-map match-any VOIP_bearer

match ip dscp EF

class-map match-any VOIP_signaling

match ip dscp CS3

policy-map VOICE-Policy

class VOIP_bearer

priority percent 33

class VOIP_signaling

bandwidth percent 10

I am not completely sure if this is going to do what I want it to do.  

[Georg Pauwen]

Hello,

the config looks good actually, apply it to an SVI (Vlan interface) and you should be good to go...

[gcook0001 · Accepted solution]

So if I made the following  changes (I did find an article showing this) I should be good.  Also it is a catalyst CS3850 running ver 16.3.5b

class-map match-any VOIP_bearer

match ip dscp EF

class-map match-any VOIP_signaling

match ip dscp CS3

policy-map VOICE-Policy

class VOIP_bearer

priority level 1 percent 33

police cir percent 10 conform-action transmit exceed-action drop

class VOIP_signaling

bandwidth percent 10

interface GigabitEthernet1/0/4

description to firewall-1

switchport access vlan 301

switchport mode access

switchport voice vlan 301

service-policy output VOICE-Policy

service-policy input VOICE-Policy

interface GigabitEthernet1/0/21

description "TRUNK TO OFFICE (dedicated VLS between locations)"

switchport trunk allowed vlan 290,300-302,307-309,400

switchport mode trunk

channel-group 5 mode on

service-policy output VOICE-Policy

service-policy input VOICE-Policy

spanning-tree portfast trunk

[weylin.piegorsch]

Looks good to me.

If it helps, this is my QoS profile I use on Catalyst 9300s running 16.6 (basically the same as 3850/16.3), except I manually removed the CoPP stuff, and manually added some extra line breaks for readability.

As an explanation of the "set ip dscp" lines consider that when you set a DSCP, the switch automatically sets a related CoS based on a table-map (it's really poorly documented, but there's a default table-map in the configuration).  If you're not worried about QoS normalization, you don't need to worry about that.

rive150-td001es01#sh run | sec ^(policy|class)-map                
class-map match-any network-control-mgmt
 match cos  6  7 
 match ip dscp cs6  cs7 
!
class-map match-any voice-rtp
 match cos  5 
 match ip dscp ef 
!
class-map match-any voice-signalling
 match cos  3 
 match ip dscp cs3 
!
class-map match-any Layer3-mgmt
 match cos  6 
 match ip dscp cs6 
!
class-map match-any Layer2-mgmt
 match cos  7 
 match ip dscp cs7 
!
!
!
policy-map qos-ingress-marking
 description QoS Marking on frame ingress
 !
 class Layer2-mgmt
  set ip dscp cs7
 !
 class Layer3-mgmt
  set ip dscp cs6
 !
 class voice-rtp
  set ip dscp ef
 !
 class voice-signalling
  set ip dscp cs3
 !
 class class-default
  set dscp default
!
!
!
policy-map qos-egress-user
 description QoS Egress Queue management: host interface
 !
 class voice-rtp
  priority level 1
  police cir percent 1 conform-action transmit  exceed-action drop 
 !
 class voice-signalling
  bandwidth remaining percent 1 
  queue-buffers ratio 10
 !
 class network-control-mgmt
  bandwidth remaining percent 1 
  queue-buffers ratio 10
 !
 class class-default
  bandwidth remaining percent 98 
!
!
!
policy-map qos-egress-uplink
 description QoS Egress Queue management: network interface
 !
 class voice-rtp
  priority level 1
  police cir percent 10 conform-action transmit  exceed-action drop 
 !
 class voice-signalling
  bandwidth remaining percent 10 
  queue-buffers ratio 10
 !
 class network-control-mgmt
  bandwidth remaining percent 10 
  queue-buffers ratio 10
 !
 class class-default
  bandwidth remaining percent 80 
rive150-td001es01#



rive150-td001es01#sh run int t1/0/1
Building configuration...
 
Current configuration : 502 bytes
!
interface TenGigabitEthernet1/0/1
 description rive150-b02ap01 10.18.43.40
 switchport access vlan 2200
 switchport mode access
 switchport nonegotiate
 switchport voice vlan 2400
 device-tracking attach-policy DT_HOST
 power inline port 2-event
 power inline police action errdisable
 history BPS all
 udld port aggressive
 no vtp
 spanning-tree portfast
 spanning-tree guard root
 service-policy input qos-ingress-marking
 service-policy output qos-egress-user
 ip dhcp snooping limit rate 15
end
 
rive150-td001es01#



rive150-td001es01#sh run int t1/1/1
Building configuration...
 
Current configuration : 434 bytes
!
interface TenGigabitEthernet1/1/1
 description rive150-dist-gw01 (128.197.254.43) te6/2
 switchport trunk native vlan 2800
 switchport trunk allowed vlan 2000,2200,2400,2600,2800,3000,3200
 switchport mode trunk
 switchport nonegotiate
 device-tracking attach-policy DT_NETWORK
 history BPS all
 udld port aggressive
 no vtp
 service-policy input qos-ingress-marking
 service-policy output qos-egress-uplink
 ip dhcp snooping trust
end
 
rive150-td001es01#

[gcook0001]

Thanks for the feedback. Much appreciated.
On a side note, how do you like the 9300s. We are looking at switching over to them and possibly implement DNA.

[weylin.piegorsch]

In terms of "it's just a switch," they're pretty solid platforms.  The 3560X made out with the fixed-form main switches and the modular network ports, the 3850s and 9300s are continuing in that and it's working really good.  The UADP2 controller on the 9300 is basically the same (is the same?) as the 3850, so that's nice; on 16.6, the only difference *at all* is that the 3850 can configure 97 VTYs and the 9300 can configure 98, to-date that's literally the only command difference we've found in the models.

I've started using PRIME Infrastructure for automation, some of the things that can't be automated in IOS XE I fire up and do in TCLSH, the 16.6 codebase has the GuestShell that I can access if I really need something like that (though I'd like to avoid going that route if I can...).

Basically though we've started considering a Campus Fabric aka SD-A paradigm similar to what you're alluding, which is why we shifted to the 9300s.  We have a few thousand 3850s so it's gonna be a while, but at least the 3850 supports the first few iterations of SD-A.

We already using ISE for wireless authentication, and we just got DNA-C for wireless experience analytics processing/reporting, so we're starting to get the needed pieces positioned to be able to do it.

The bigger problem for us is that we have a lot of cleanup to do before we can truly go that route (70,000 ports but only DHCP on 25% of those; no 802.1x anywhere on the wired side; etc), so we have to go through the pain of addressing the shortcomings and then maybe 5yr from now we can actually implement SD-A.  By then hopefully they'll have a solid validated design with the bugs worked out :-)

[gcook0001]

Well thanks again and good luck. Seems like you have your work cut out for you.

[weylin.piegorsch]

You too.  Glad you got the issue resolved.

[weylin.piegorsch]

I'm not sure specifically what you mean by a "CS3850".  I'm going to assume you mean Catalyst 3850.  It also depends what version of code you're using; different versions have slightly different syntax and operation.

So, how are you using these switches?

• If these are transparent bridges, then you cannot configure QoS on the VLANs, but rather you would need to configure QoS on the physical interfaces (transparent bridges can only use VLAN interfaces for management traffic, not client traffic).
• If you're using this as a gateway router, and your next-hop egresses a routed physical interface, then you still need to configure QoS on the physical egress interface since the physical interface doesn't align with the VLAN interfaces
• If you're using these devices as a gateway router with switched egress interfaces, with either static, default, or dynamic routing to determine the next hop, then although these are switches, you can then configure the devices with some amount of QoS support on the VLAN interface (see next).

However, if you're looking to shift to a VLAN-based QoS paradigm, you need to be careful:

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/3se/qos/configuration_guide/b_qos_3se_3850_cg/b_qos_3se_3850_cg_chapter_011.html#concept_BD36944957EF4A6BBE45A3DE058217C9

At first glance, this appears to be what you're asking for:

"allows the user to perform QoS treatment at the VLAN level (classification and QoS actions) using the incoming frame’s VLAN information."

But note, its not quite what you're hoping for.  That's only for an incoming frame.  Policing is almost always done on egress frame.  So can egress policing be done on the VLAN interface?

"Although the policy map is applied to the VLAN interface, any policing (rate-limiting) action can only be performed on a per-port basis. You cannot configure the policer to take account of the sum of traffic from a number of physical ports. Each port needs to have a separate policer governing the traffic coming into that port."

And there lies the kicker.  The VLAN interface on a Catalyst 3850 has no policing capability.  So although you can punt some QoS aspect to the VLAN interface, if you're looking to use a policer you still need to apply a QoS policy to the physical interface because that's the only place the Cat3850 has the capability of doing policing.

Then there's additional caveats about doing VLAN-based QoS.  Let's say you have ingress traffic on one port, and egress another port within the same VLAN (these are still switches at heart, after all).  In that case, if it's a trunk port, how do you handle that?  Which VLAN QoS traffic marking policy to you apply on the interface?  Or does it change dynamically to switch to the correct VLAN?  Or do you still need to apply a QoS policy to the physical interface anyway, if the QoS mechanism only kicks-in if the Ethernet frame's destination MAC address is the VLAN interface's MAC address?

Ultimately, applying a QoS policy on the interface becomes the easiest and most straight-forward approach.

weylin

[weylin.piegorsch]

And lest I forget - if you just want to define a QoS policy based on the VLAN, I'll suggest that's not enough.  What you really want to do is set head-of-the-line priviledges for the RTP traffic (that's the traffic that actually carries the audio), and police it so that noone takes advantage of the QoS, either maliciously or because of an errant process.

You could setup the class-map to match against the VLAN ID.  And that would work.  But, that catches everything in the VLAN.  Spanning-tree; ARP; and other traffic is still running on the VLAN.  RTCP is a companior protocol to RTP, and runs in the same subnet/VLAN.  I'm not sure what VoIP management protocol you're using, but whether H.323, SCCP, Skinny, or SIP, they also all run in the same VLAN.  But you only want to specifically match the RTP traffic, and only give *those* packets head-of-line queuing.  having fluctuations in RTP delivery times, such as the tiny RTP packets sitting behind several really fat email packets on another VLAN, are noticeable to the users (variation in one-way delivery time is referred to as "jitter").

You can match on DSCP if you want, it certainly can't hurt.  But typically, DSCP and CoS are strictly aligned (there's lots of sites that give the industry de facto CoS values, unfortunately not a lot of sites that say it simply); and typically, that alignment is enforced on ingress.  Assuming that alignment is enforced, then you only need match CoS, since each of these traffic classifications is (typically) set to different CoS values.  Then, you can quickly identify the RTP packets, and put them in the priority queue, with everything else going in the standard queue(s); and, police the priority queue so that it at-most only consumes some nominal amount of capacity (usually 10%).

weylin