VLAN Based QOS on 3750

[Alain Cloet]

Dear,

I've been looking through the SW-config guide, some fora, some QOS-best practices, VACL,...  but it only confuses me more...

In our network, which are mainly all Cisco 3750-range switches, I want to prioritize a specific VLAN, but I can't figure out where to start, or maybe, it's the start that confuses me...

And as I don't have spares in a test-environment, I should apply this on the productive system immediatelly... Somehow I rather don't crash my network .  Except for the inter-switch connections all ports are access-ports.

So basicly, I want to set - probably all my access-ports - to VLAN-based QOS (mls qos vlan-based).  Do you need to do this on all (access-)ports, or only those where the specific VLAN is attached to ?  Can/Should this also be set on trunk ports?

But even then, saying it's VLAN-based doesn't seem to be enough, the VLAN-based settings should be made first ...

What I found is that I have to start with an ACL, which should define the VLAN.  However it all starts from IP-addresses, does this mean I can't actually make an ACL on VLAN ?

With the configurations I found, I would make this (configuring VLAN 20 with 192.168.20.0/24 ; I don't need the same priority for routed traffic from/to this VLAN):

Switch(config)# Switch(config)#access-list 101 permit ip 192.168.20.0 0.0.0.255 192.168.20.0.0 0.0.0.255

The next info I found binds this ACL to a specific VLAN, for example:

Switch(config)# interface VLAN 20
Switch(config-if)# ip access-group 101 in

Is this enough to make this ACL ?  And what would happen if some traffic with the same IP-range is used in another VLAN (I don't use the switch as router, so at the moment it wouldn't be a problem) ?

I also found this description to bind a ACL to a VLAN.

(config)#vlan access-map map-VLAN20

(config-access-map)#match ip address 101

(config-access-map)#action forward

(config-access-map)#exit

(config)#vlan filter map-VLAN20

Could it be I only need to do one of these steps ?

Or even just use the previous made ACL to an access-map?

(config)#class-map match-all cm-VLAN20

(config-cmap)#match access-group 101

Can someone make this a bit more clear to me ?  I do think not all of the above is needed, but I'm not sure what I should take...

And maybe if that is clear, what I should do to really prioritize this (I found info on policy-maps, service-policys,... but like said, all this info seems to make it more confusing to me... Maybe I should start with a course 'QoS for dummies' )

Thanks,

Alain

[Shashank Singh]

Hi Alain,

Vlan based QoS can be used to apply QoS  (and hence prioritize) traffic on interfaces belonging to a particular  vlan. The interface on which you intend to apply QoS should be  configured with 'mls qos vlan-based' and the actual QoS service policy  should be configured under the vlan interface. See below:

!--- Section A (Classification of traffic on which QoS needs to be appplied)

Distribution1(config)#ip access-list extended voice-traffic
Distribution1(config-std-nacl)#permit ip 192.168.100.0 0.0.0.255 any (suppose this is your vlan 10 subnet)
Distribution1(config-ext-nacl)#exit

Distribution1(config)#class-map  Class-A
Distribution1(config-cmap)#match access-group name voice-traffic
Distribution1(config-cmap)#exit

!--- Section B (Marking the classified traffic)

Distribution1(config)#policy-map sample-policy1
Distribution1(config-pmap)#class Class-A
Distribution1(config-pmap-c)#set dscp af21  (you can include all the QoS config here)
Distribution1(config-pmap-c)#exit
Distribution1(config-pmap)#exit


!--- Section C (Apply QoS to the interface)

(config) interface gigabitethernet 1/2 
(config-if)#switchport access vlan 10 
(config-if)#mls qos vlan-based <<---- You apply vlan-based QoS on the physical interface
(config-if)#exit 

(config-if)#interface vlan 10 
(config-if)#service-policy input sample-policy1 (This Service policy will now be applied to gi1/2)

For all the interfaces on which you intend to apply QoS, mls qos vlan-based needs to be configured and the  service policy just
needs to be configured under the interface vlan.

Instead of using vlan based qos, you can also apply the service policy directly under the physical interfaces.


Hope this helps to clarfiy some of your doubts.  If you have any more queries, please feel free to let me know.

Cheers,
Shashank


Please rate this answer if you found the content useful

[Alain Cloet]

Hi Shashank,

Thanks for the reply.  It is very clear what I have to do, but it doesn't solve all my doubts .  Next to that I prefer to understand what I do, so I can make some interpretation on the possible problems...

It does make clear that even if it's called 'VLAN-based', you still have to configure every port for it... which was (is) in my opinion a contradiction.

Now the questions I still have:

* If you would change a port setting to access another vlan, but forget to remove the "mls qos vlan-based", would this cause a problem if the specific vlan doesn't have a service-policy set to it ?  Or should every VLAN have a service-policy in all cases ?

* In your example, the priority is set via dscp af21.  If I understand this correct, this is a "assured forwarding", with the lowest drop rate for "class 2".  I didn't find (or I overlooked it) any info if there is a priority between classes (which can be 1 to 4), and if the fact it is set to a class gives it priority to "undefined" traffic (eg the VLANs without priority, or the port where I forgot to set "mls qos vlan-based").  This last part should be so in my opinion, as it is called "assured", but confirmation would be nice...

* Does setting this up can cause interruptions on on-going traffic ?  Because it is impossible to set all ports in all stacks at the same moment... With proper preparation, this can be reduced to minimum, but not to 0.

Thanks, and a happy New-Year,

Alain

[Shashank Singh · Accepted solution]

Hi Alain,

Happy new year! Please find the answers inline.

* If you would change a port setting to access another vlan, but forget to remove the "mls qos vlan-based", would this cause a problem if the specific vlan doesn't have a service-policy set to it ?  Or should every VLAN have a service-policy in all cases ?

mls qos vlan-based under a port tells the switch to look for the corresponding service policy under that respective interface vlan. If a port has mls qos vlan-based configured but there is no service policy under that interface vlan, there will not be any problem as such, but the command will be meaningless. It is not necessary to have a service policy configured under all interface vlans.

* In your example, the priority is set via dscp af21.  If I understand this correct, this is a "assured forwarding", with the lowest drop rate for "class 2".  I didn't find (or I overlooked it) any info if there is a priority between classes (which can be 1 to 4), and if the fact it is set to a class gives it priority to "undefined" traffic (eg the VLANs without priority, or the port where I forgot to set "mls qos vlan-based").  This last part should be so in my opinion, as it is called "assured", but confirmation would be nice...

yes, there is a priority associated to each af value. Every af has a corresponding dscp associated to it. Higher is the dscp value, better are the chances of the packet not being dropped during a congestion.

                       Class 1    Class 2    Class 3    Class 4

                      +----------+----------+----------+----------+

     Low Drop Prec    |  001010  |  010010  |  011010  |  100010  |

     Medium Drop Prec |  001100  |  010100  |  011100  |  100100  |

     High Drop Prec   |  001110  |  010110  |  011110  |  100110  |

                      +----------+----------+----------+----------+

In case of congestion, the drop precedence of a packet determines the relative importance of the packet within the AF class. A congested DS node tries to protect packets with a lower drop precedence value from being lost by preferably discarding packets with a higher drop precedence value.

In a DS node, the level of forwarding assurance of an IP packet thus depends on (1) how much forwarding resources has been allocated to the AF class that the packet belongs to, (2) what is the current load of the AF class, and, in case of congestion within the class, (3) what is the drop precedence of the packet.

If you do not configure mls-qos vlan based under a port, the traffic on that port will not be considered for any qos marking, even though a service policy exists under corresponding interface vlan.

* Does setting this up can cause interruptions on on-going traffic ?  Because it is impossible to set all ports in all stacks at the same moment... With proper preparation, this can be reduced to minimum, but not to 0.

Yes, setting up QoS on one vlan can affect traffic on other vlans. QoS just helps to forward certain important traffic at the cost of other non important traffic in a congested environment. So it needs to be planned beforehand as to what traffic needs to be marked important.

Hope this helps.

Shashank

Please rate this and previous answers if you found the content useful

[mattbaylor]

What counters can I look at to ensure that the appropriate QoS policy is being applied? BTW thanks for

the great information.

[Shashank Singh]

Hi Matt,

'sh mls qos interface   statistics'  is an interface level command that shows the marking of the packets (both cos and dscp) ingressing and egressing on this interface. It also shows number of packets enqueued and dropped along with respective queues and thresholds.

Hope this helps.

Shashank

Please rate this answer if you found the content useful