Bridging the gap between 3550 and 3560 QoS: Part II
Classification, Policing and Marking on the 3560 model.
As we remember, 3560 uses the concept of internal QoS label, which contains both the CoS and DSCP values for a packet. Only one value is actually taken (trusted) from the packet or interface (either CoS or DSCP), and the other one is deduced using the configurable mapping tables. As it has been described previously, we are allowed to map CoS/DSCP values to queues/thresholds separately. This allows for different service policies to be configured with respect to non-IP and IP traffic. The value that has been trusted (CoS/DSCP) is used as the key selector to either the CoS or DSCP based mapping tables.
What are the available classification options? You can match an access-list (MAC, IP or IPv6), an input interface (only for hierarchical policy-maps to be discussed later) and IP DSCP or Precedence values. Note that CoS value could not be matched, you may configure to trust them. You can trust either CoS, DSCP or IP precedence values from IP/IPv6 or non-IP packet. If a packet has no CoS assigned, the default CoS value is set when interface is set to trust CoS.
Now for the “set” operation – you can only set either IP/IPv6 DSCP or Precedence fields, but not CoS field directly. Does that mean we are not allowed to change the CoS value? No, it is still possible to change the CoS value by using “set dscp” command and DSCP to CoS mapping table – the indirect way. This is a way to extend DSCP-based operations to CoS only bearing packets by use of mapping tables. For example the following configuration will change CoS value of any non-IP packet to “5” (equivalent to DSCP EF):
!
! Match any ether-type, e.g. IPX packets
!
mac access-list extended TEST
permit any any 0x0 0xFFFF
!
class-map match-all TEST
match access-group name TEST!
! Match the Non-IP packets and set DSCP value
!
policy-map TEST
class TEST
set dscp ef!
! Connected to R1
!
interface FastEthernet 0/1
service-policy input TEST
Verification – configure IPX on R1 and R3, e.g. using the IPX network “135” and SNAP encapsulation.
Rack21R1#ping 135.0011.920e.5620
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to 135.0011.920e.5620, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 msRack21SW1#show mls qos interface fastEthernet 0/3 statistics
FastEthernet0/3
cos: incoming
-------------------------------0 - 4 : 175 0 0 0 0
5 - 7 : 0 0 0
cos: outgoing
-------------------------------0 - 4 : 664 0 0 0 11
5 - 7 : 5 0 1
Policer: Inprofile: 0 OutofProfile: 0
For example, with policer markdown action, we use the configurable mapping table to map DSCP value to a new policed-down equivalent. When the markdown action is applied to a CoS-marked packet (non-IP) the CoS-to-DSCP mapping table is used to deduce the DSCP value, then the other table (DSCP to Policed DSCP) is used mark the DSCP value down, and finally the marked-down DSCP value is mapped back to the CoS value (DSCP to CoS map).
!
! DSCP to Policed-DSCP map
!
mls qos map policed-dscp 0 to 8!
! Match the Non-IP packets and set DSCP value
!
policy-map TEST
class TEST
police 64000 8000 exceed policed
!
! Connected to R1
!
interface FastEthernet 0/1
service-policy input TEST
As with the 3550 model, 3560 allows policers to be applied ingress on any port. The limit is 64 policers per port ingress, and 256 policers per ASIC. However, no egress policers are available on this platform. Aggregate policers could also be configured, with the same restrictions as the 3550 had.
Another feature, known on the 3550 models as the Per-Port Per-VLAN classification is implemented using the hierarchical policy-maps. The concept is better illustrated using an example:
!
! Any non-IP traffic
!
mac access-list extended MAC_ANY
permit any any 0x0 0xFFFF!
! Any IP traffic
!
ip access-list extended IP_ANY
permit ip any any!
! Class for any non-IP traffic
!
class-map MAC_ANY
match access-group name MAC_ANY!
! Class for any IP traffic
!
class-map IP_ANY
match access-group name IP_ANY!
! Class to match the port connected to R1
!
class-map PORT_R1
match input-interface FastEthernet 0/1!
! Class to match the port connected to R3
!
class-map PORT_R3
match input-interface FastEthernet 0/3!
! Inteface-level policy-maps, limit rate per-port (R1 & R3)
!
policy-map PORT_R1
class PORT_R1
police 64000 8000!
policy-map PORT_R3
class PORT_R3
police 512000 64000!
! VLAN policy-map; two levels
!
policy-map VLAN_POLICY
class IP_ANY
set dscp 24
service-policy PORT_R1
class MAC_ANY
set dscp ef
service-policy PORT_R3
!
! Attach a switch-wide VLAN policy
!
interface VLAN 1
service-policy input VLAN_POLICY
!
! Enabe VLAN based-QoS on some ports
!
interface range FastEthernet 0/1, FastEthernet 0/3
mls qos vlan-based
What is that configuration intended to do? It defines two VLAN-wide classes, which apply to all ports belonging to this VLAN (including trunks) that has VLAN-based QoS enabled. Therefore, for any IP traffic on VLAN1 we set DSCP to 24, and for any non-IP traffic we set CoS to 5 (implicitly, using the “set dscp” command). Additionally, for IP traffic only, we limit port Fa 0/1 to 64Kbps, and for non-IP traffic we limit port Fa0/3 to 512Kbps. The policing is the only thing that is allowed to be configured on the “child” policy-map, and you can only match input-interfaces as a classification criteria for second-level policy-maps. The “child” (second-level) policy maps are unnecessary, and could be omitted from your configuration (i.e. you can use only a single-level policy-map). However, you must enable vlan-based QoS on the ports that needs to be affect by SVI-level policy-map.
The biggest difference from the 3550 model is that per-port, per-VLAN classification is now switch-wide (not port-wide), so it’s better called “per-VLAN” classification. You still may control which ports are affected, and use second-level policy-map to control the incoming rate per-class/per-port. For example, you may use the same range of ports under all class-maps and specify different rates for different types of traffic.
And finally, for verification techniques. The most used command to verify your QoS implementation is probably show mls qos interface x/y statistics which displays the number of packets with respective DSCP/CoS values entering/leaving a given port.
Rack21SW1#show mls qos interface fastEthernet 0/3 statistics
FastEthernet0/3dscp: incoming
-------------------------------0 - 4 : 2124 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 0
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 0 0 0 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
dscp: outgoing
-------------------------------0 - 4 : 3053 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 98
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 0 0 0 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 1458 0 0 0
60 - 64 : 0 0 0 0
cos: incoming
-------------------------------0 - 4 : 5914 0 0 0 0
5 - 7 : 0 0 0
cos: outgoing
-------------------------------0 - 4 : 7991 0 0 98 11
5 - 7 : 2762 0 2
Policer: Inprofile: 0 OutofProfile: 0
The other show commands are also useful, like show policy-map, show class-map, show access-list, show mls qos interface. There are also «esoteric» commands under the show platform but those are «deep technical» and are not well documented on the DocCD.
