Mar
26

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 ms

Rack21SW1#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/3

  dscp: 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.

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website


You can leave a response, or trackback from your own site.

12 Responses to “Bridging the gap between 3550 and 3560 QoS: Part II”

 
  1. Carlo says:

    thanks for the post. i hope to read some more.
    Best regards from Sebbi

  2. Carlo says:

    nice post. thanks for sharing your traffic tips

  3. Ken says:

    interested post about traffic. i think is very useful

  4. [...] Listed below are some useful URLs that I have been/will be basing my notes on: Quality of Service Networking Cisco IOS Quality of Service Cisco Modular Quality of Service Command Line Interface Class-Based Weighted Fair Queueing Deploying Quality Of Service For Converged Networks Catalyst 3560 Switch Software Configuration Guide – Configuring QoS Catalyst 3550 Switch Software Configuration Guide – Configuring QoS Distributed Traffic Shaping Differentiated Services Compliant Distributed Weighted Random Early Detection Understanding and Configuring MDRR/WRED Bridging the gap between 3550 and 3560 QoS: Part I and Part II [...]

  5. Atif says:

    Thanks! I have a confusion about the mapping tables. When or how a prticular mapping table is called ? If we are trusting cos value of the incoming frames on a prticular interface then what table it should use and is it necessary to use a mapping table ? Same question when we are trusting dscp or precedence value.

  6. Peter says:

    Petr, could you explain the meaning of the columns in the “show mls qos interface fastEthernet 0/3 statistics” output?
    Thanks!

  7. to Peter

    OK we have two directions incoming/outgoing. DSCP tables are for 64 DSCP values, and each cell is displays the number of packets bearing this particular DSCP value. As you see, for DSCP tables we have 16 rows and 4 columns, and the DSCP values are depicted on the left part of the screen.

    The same goes to CoS tables, just they have only 8 values (2 rows by
    4 columns)

    Now if you mark packets on ingress, you will be able to see the new
    marking only on the egress port (where the packets get switched too). This is not like 3550, where you can monitor specific DSCP values ingress on each port.

  8. Vineet says:

    Peter, What do the 5 columns mean exactly in the output of the command: sh mls qos interface stats?
    Your answer only states 4 columns.

  9. timaz says:

    hi. today i got my 4 catalyst 3550 with “ipservicesk9-12.2(52)SE” for my lab. because i could not afford 3560. what kind of topics will i miss using 3550 (with most recent ios image) instead of 3560? can i do the labs with 3550s or the missing parts will affect the entire lab?

  10. wayne edwards says:

    is there any way of applying per port/per vlan for traffic that is passing through the device say on a trunk.Say i have switches which are connected together via a trunk which carries vlan 10 , each switch as access ports in Vlan 10 but does not have a interface vlan 10 itself. The two routers are connected in to these access ports and given the IP address of .1 & .2 , the switch itself as no ip address with in this vlan . Can i rate limit traffic on the trunk link between the switches just for Vlan 10 ?

  11. Hi,
    Can anybody help me to find the difference between cisco catalyst 3550 and catalyst 3560 .

    Guys, waiting for your reply..

    Regards
    Surjit

 

Leave a Reply

Categories

CCIE Bloggers