Per-VLAN QoS on a 3650 with DSCP

peter5 · ‎02-14-2018

I have been reading up on applying QoS on a per VLAN basis on the 3650. I effectively have a switch which is trunked with an ESXI host and would like to ensure that bandwidth is shared amongst the VLAN's traversing the trunk - but at the same time if available I would like any VLAN to utilise additional bandwidth if available rather than policing a hard limit. Although I want to ensure traffic on vlan 10 always has a reserved amount of bandwidth.

I have the following configuration and would appreciate a second on opinion on whether the below will meet the above requirements:

# enable qos globally
mls qos

# define traffic i.e. everything
access-list 100 permit ip any any

# traffic classification
class-map qos_vlan10_cm
match access-group 100

class-map qos_vlan20_cm
match access-group 100

class-map qos_vlan30_cm
match access-group 100

# tag traffic with DSCP values
policy-map qos_vlan10_pm
class qos_vlan10_cm
set ip dscp 40

policy-map qos_vlan20_pm
class qos_vlan20_cm
set ip dscp 10

policy-map qos_vlan30_pm
class qos_vlan30_cm
set ip dscp 0

int gi0/1
description portchannel with esxi host
switchport mode trunk
switchport trunk native vlan 1000
switchport trunk allowed vlans 10,20,30
srr-queue bandwidth share 25 25 25 25
srr-queue bandwidth shape 16 0 0 0
mls qos trust dscp
mls qos vlan-based
switchport nonegotiate
channel-group 1 mode on

# apply service policies on SVI's
int vlan 10
service-policy input qos_vlan10_pm
service-policy output qos_vlan10_pm

int vlan 20
service-policy input qos_vlan20_pm
service-policy output qos_vlan20_pm

int vlan 30
service-policy input qos_vlan30_pm
service-policy output qos_vlan30_pm

From this configuration I expect traffic from the different VLAN's to hit separate queues - does the above configuration reflect that?

Joseph W. Doherty · ‎02-14-2018

"From this configuration I expect traffic from the different VLAN's to hit separate queues - does the above configuration reflect that?"

I cannot say for sure, as I haven't worked with the 3650 or 3850 (also haven't studied their QoS support). However, going on experience from earlier Cisco switches and other Cisco routers, I would expect it does (assuming your DSCP markings send the traffic to different egress queues). That said, I don't believe what you have exactly accomplishes what you desire, and what you have may be more complicated than it needs to be.

You say you want your VLANs to be able to use additional available bandwidth and VLAN 10 to have a guarantee. Well, assuming your 3 VLANs are directed to 3 different egress queues, your share statement should insure each obtains a equal share of bandwidth, which with only 3 active queues should be at least minimum of a third to any one VLAN. However, your shape statement will limit the bandwidth available to that queue. (I.e. delete your "srr-queue bandwidth shape 16 0 0 0" statement.)

It may be possible to have a single policy that can identify source VLAN, but if not, your service polices should only need a default class that sets the DSCP marking.

e,g,
rather than:
access-list 100 permit ip any any
class-map qos_vlan10_cm
match access-group 100
policy-map qos_vlan10_pm
class qos_vlan10_cm
set ip dscp 40
perhaps:
policy-map qos_vlan10_pm
class class-default
set ip dscp 40

Further, don't believe you need the VLAN interfaces' output polices, or the trunk's MLS QOS statements.

Understand, you can allocate bandwidth guarantees from your VLANs to your ESXI, but the converse depends (mostly) on your ESXI QoS capabilities. (Mostly - because you may be able to manage QoS to the fabric, but that's seldom a bottleneck.)

peter5 · ‎02-15-2018

Understand, you can allocate bandwidth guarantees from your VLANs to your ESXI, but the converse depends (mostly) on your ESXI QoS capabilities. (Mostly - because you may be able to manage QoS to the fabric, but that's seldom a bottleneck.)

I don't think I quite follow you here - I was under the impression that applying the inbound service policy I was ensuring that QoS is being applied on ingress traffic from the ESXI host interface to the switch(?)

Can you elaborate on what options (and where) would have to be applied on the ESXI side? I am limited to a standard vSwitch (i.e. no vDS) and according to the documentation only have the option of performing traffic shaping on traffic bound from the VM to the vSwitch and not traffic from the 3650 to the vSwitch.

I feel in that case without QoS / traffic shaping on the vSwitch that theoretically one of the vSwitches sharing the trunk between ESXI and the 3650 could saturate the it during congestion. Setting up traffic shaping on the vSwitches would help limit bandwidth - however I presume I would lose any kind of ability to 'share' the bandwidth between the vSwitches?

Joseph W. Doherty · ‎02-15-2018

"I don't think I quite follow you here - I was under the impression that applying the inbound service policy I was ensuring that QoS is being applied on ingress traffic from the ESXI host interface to the switch(?)"

Yes, and no. Yes, ingress policy would be applied, but it wouldn't have any impact on how the ingress bandwidth on the trunk link is shared.

"Can you elaborate on what options (and where) would have to be applied on the ESXI side?"

Unfortunately, I'm unfamiliar what you can do on the ESXI side.

"I feel in that case without QoS / traffic shaping on the vSwitch that theoretically one of the vSwitches sharing the trunk between ESXI and the 3650 could saturate the it during congestion. Setting up traffic shaping on the vSwitches would help limit bandwidth - however I presume I would lose any kind of ability to 'share' the bandwidth between the vSwitches? "

Yea, it's likely congestion could form on traffic to the 3650, but again, I'm unfamiliar with the ESXI to make and suggestions.