playing with VLAN-based QoS

A friend of mine brought up an interesting question yesterday:

Will the "mls qos vlan-based" command mark packets if the packets aren't routed by the SVI where the service policy is applied?

I had never even considered this before, so I guessed "no" before reading the docs. Then I set it up in the lab, and the answer (superficially) still seemed to be "no". Then, however, I executed the old RTFM maneuver: the docs made it sound like the answer should be "yes". So I thought I'd have a closer look. Here are the details.

The test topology looks like this:

R5---Switch1---Switch2---Cat3750---R6

• R5 & R6 are 2800 series routers.
• Switch1 and Switch2 are 3560s.
• Cat3750, unsurprisingly, is a Catalyst 3750, and the subject of the test.

All of the inter-switch links are 802.1q trunks, and the two routers are connected to access ports in VLAN 6.

• R5's interface IP address is 10.6.6.5, with a loopback of 5.5.5.5.
• R6's interface IP address is 10.6.6.6, with a loopback of 6.6.6.6.
• R5 and R6 are running OSPF on all interfaces and are neighbors when the test begins.

First, I set up a QoS policy on the 3750 that would make packets distinguishable from each other:

ip access-list extended ALL
permit ip any any
!
class-map match-any FOO
match access-group name ALL
!
policy-map IN-MARKING
class FOO
set ip dscp cs2
class class-default
set dscp cs1

Then I applied the policy-map to an unrouted SVI for VLAN 6:

interface Vlan6
no ip address
service-policy input IN-MARKING

Then I set R6's access port for VLAN-based QoS:

interface FastEthernet1/0/2
switchport access vlan 6
switchport mode access
mls qos vlan-based
spanning-tree portfast

Since all traffic should be marked as CS2, the OSPF hello packets being exchanged between R5 and R6 should get marked immediately if the policy is working, but I also generated some ICMP and telnet traffic just for good measure.

My superficial, pre-RTFM diagnosis, said it wasn't working:

c3750#sh policy-map interface
Vlan6

Service-policy input: IN-MARKING

Class-map: FOO (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name ALL
0 packets, 0 bytes
5 minute rate 0 bps

Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
0 packets, 0 bytes
5 minute rate 0 bps

After my RTFM episode, I started wondering if the packets were getting marked anyway, but not counted by the switch. Idecided to try applying a service policy on R5 that would have rather dramatic effects if the packets were in fact marked:

class-map match-any CM_CS2
match ip dscp cs2
!
policy-map PM_DROP_CS2
class CM_CS2
drop

then...

R5(config)#int f0/0
R5(config-if)#service-policy input PM_DROP_CS2
R5(config-if)#
R5(config-if)#
*Nov 18 15:37:18.097: %OSPF-5-ADJCHG: Process 1, Nbr 20.1.1.6 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired

R5#sh policy-map interface f0/0 input class CM_CS2
FastEthernet0/0

Service-policy input: PM_DROP_CS2

Class-map: CM_CS2 (match-any)
20 packets, 1880 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs2 (16)
20 packets, 1880 bytes
5 minute rate 0 bps
drop

So... in conclusion: the "mls qos vlan-based" command does indeed work for service policies applied to interfaces that don't route packets for the VLAN... essentially, the command causes the access port to inherit the QoS policy applied to the SVI, and the SVI doesn't count them. This does actually make sense, but it took working through the lab to make my brain process it correctly.