blog
    Comparing Traffic Policin ...
    11 September 08

    Comparing Traffic Policing Features in the 3550 and 3560 switches

    Posted byPetr Lapukhov
    facebooktwitterlinkedin
    news-featured

    People are often confused with per-VLAN classification, policing and marking features in the Catalyst 3550 and 3560 models. The biggest problem is lack of comprehensive examples in the Documentation CD. Let's quickly review and compare traffic policing features available on both platforms. The material below is a condensed excerpt of several Catalyst QoS topics covered in the “QoS” section of our IEWB VOL1 V5. You will find more in-depth explanations and large number of simulation-based verifications in the upcoming section of the workbook.

    Per-Port QoS ACL based classification in the 3550 and 3560

    This feature works the same in both switches. Even though it is common to see this method named as “QoS ACLs” classification, it actually uses MQC syntax with class-maps and policy-maps. The term “QoS ACL” comes from the Catalyst OS PFC-based QoS model where you apply QoS ACLs directly to ports. In IOS-based switches, you use the familiar MQC syntax.

    Look at the following example. Here we mark IPX packets (classified based on SNAP Protocol ID) with CoS value of 5, ICMP packets with IP Precedence 2 and ICMP packets with DSCP value of 24 (CS3). All remaining traffic, be it IP or non-IP, matches class-default and the system trusts the CoS values in the frame header. If a packet matches “class-default” but has no CoS value in the header, the system uses the default value from the interface, specified with mls qos cos 1

    Example 1:

    !
    ! Access-Lists. IPX SNAP Protocol ID is 0x8137
    !
    mac access-list extended IPX
    permit any any 0x8137 0x0
    !
    ip access-list extended ICMP
    permit icmp any any
    !
    ip access-list extended TELNET
    permit tcp any any eq telnet
    permit tcp any eq telnet any

    !
    ! Class Maps
    !
    class-map match-all TELNET
    match access-group name TELNET
    !
    class-map match-all ICMP
    match access-group name ICMP
    !
    class-map match-all IPX
    match access-group name IPX

    !
    ! Note that we set DSCP under non-IP traffic class. The switch computes
    ! the respective CoS value using DSCP-to-CoS table.
    !
    policy-map CLASSIFY
    class IPX
    set dscp ef
    class ICMP
    set dscp cs3
    class TELNET
    set precedence 2
    class class-default
    trust cos

    !
    ! Apply the policy
    !
    interface FastEthernet 0/6
    mls qos cos 1
    service-policy input CLASSIFY

    Note the use of set dscp command on non-IP packet. You cannot set CoS value directly, with one special case for the 3550 switches. Therefore, you should use the command set dscp for both IP and non-IP packets if you want to change the CoS field.

    You may apply the same policy in the 3550 models, but with one special limitation. The “class-default” should be split into two user-defined classes matching IP and non-IP traffic. I never seen "class-default" working properly in the 3550 models, so if you have a working example with verifications, please let me know :). Here is a workaround, that shows how to police both IP and non-IP traffic simultaneously in the 3550 model:

    Example 2:

    !
    ! All IP traffic
    !
    ip access-list standard IP_ANY
    permit any
    !
    ! All non-IP traffic
    !
    mac access-list extended MAC_ANY
    permit any any 0x0 0xFFFF
    !
    class-map IP_ANY
    match access-group name IP_ANY
    !
    class-map MAC_ANY
    match access-group name MAC_ANY
    !
    mls qos aggregate-policer AGG256 256000 32000 exceed-action drop
    !
    policy-map AGGREGATE_LIMIT
    class IP_ANY
    police aggregate AGG256
    class MAC_ANY
    police aggregate AGG256

    Per-Port Per-VLAN Classification in the 3550 switches

    This feature is unique to the 3550 switches. You may configure traffic classification that takes in account VLAN for input traffic. Unfortunately, you can only apply it at a port-level. There is no option to classify the traffic entering VLANs on any port using a single policy, like there is in the 3560 model. Note that you can apply per-port per-VLAN policy on a trunk or an access port. Of course, in this case the access port must be in a VLAN matched by the policy-map. Here is an example of per-VLAN classification and marking in the 3550 models. What it does, is sets different DSCP and CoS values for IPX and ICMP packets coming from VLAN146 only. Other VLANs on a trunk port will remain intact.

    Example 3:

    mls qos
    !
    ! Acess-Lists
    !
    ip access-list extended ICMP
    permit icmp any any
    !
    mac access-list extended IPX
    permit any any 0x8137 0x0

    !
    ! Second-level class-maps
    !
    class-map ICMP
    match access-group name ICMP
    !
    class-map IPX
    match access-group name IPX

    !
    ! First-level class-maps
    !
    class-map VLAN_146_ICMP
    match vlan 146
    match class-map ICMP
    !
    class-map VLAN_146_IPX
    match vlan 146
    match class-map IPX

    !
    ! Policy-maps. Note that we set DSCP for IPX packets
    ! In fact, this is the internal DSCP value, not the IP DSCP.
    ! You cannot set CoS directly – only when trusting DSCP.
    ! DSCP 16 translates to CoS 2 by the virtue of the
    ! default DSCP-to-CoS table.
    !
    policy-map PER_PORT_PER_VLAN
    class VLAN_146_ICMP
    set dscp CS3
    class VLAN_146_IPX
    set dscp 16

    !
    ! Apply the policy-map
    !
    interface FastEthernet 0/4
    service-policy input PER_PORT_PER_VLAN

    Note the special syntax used by this features. All classes in the policy-map must use match vlan statement on their first line and match another class in their second line. The second-level class-map should use only one statement, e.g. match access-group name. The access-group itself may have variable number of entries.

    Per-Port Per-VLAN Policing in the 3550

    The following example is just a demonstration of applying policing inside VLAN-based policy-map in the 3550. This feature is a regular policer, just the same you can use in a per-port policy-map. You can either drop packet or re-mark the internal DSCP. With the 3550 it is even possible to use aggregate policer shared between several VLANs on a single port.

    The example remarks IP traffic exceeding the rate of 128Kbps with DSCP value of CS1. Prior to metering, the policy map marks traffic with AF11. The policy map marks non-IP traffic with a CoS value of three, and drops packets that exceed 256Kbps. All classification and policing procedures apply only to packets in VLAN146.

    Example 4:

    mls qos
    mls qos map policed-dscp 10 to 8

    !
    ! Acess-Lists
    !
    ip access-list extended IP_ANY
    permit IP any any
    !
    mac access-list extended NON_IP_ANY
    permit any any 0x0 0xFFFF

    !
    ! Second-level class-maps
    !
    class-map IP_ANY
    match access-group name IP_ANY
    !
    class-map NON_IP_ANY
    match access-group name NON_IP_ANY

    !
    ! First-level class-maps
    !
    class-map VLAN_146_IP
    match vlan 146
    match class-map IP_ANY
    !
    class-map VLAN_146_NON_IP
    match vlan 146
    match class-map NON_IP_ANY

    !
    ! Since we are not limited, we use any burst values
    ! Policy map matches first-level class-maps
    !
    policy-map POLICE_PER_PORT_PER_VLAN
    class VLAN_146_IP
    set dscp af11
    police 128000 16000 exceed-action policed-dscp-transmit
    class VLAN_146_NON_IP
    set dscp cs3
    police 256000 32000

    !
    ! Apply the policy-map
    !
    interface FastEthernet 0/4
    service-policy input POLICE_PER_PORT_PER_VLAN

    Per-VLAN Classification in the 3560

    Switch-wide per-VLAN classification is feature specific to the 3560. You can apply a service-policy to SVI, listing class-map and respective mark actions in the policy-map. Note that you cannot usethe police command in a service-policy applied to SVI. All packets in the respective VLAN entering the switch on the ports enabled for VLAN-based QoS are subject to inspection by service-policy on the SVI. The effect is that QoS marking policy is now switch-wide on all ports (trunks or access) having the respective VLAN activated (allowed and STP forwarding state).

    The following example sets DSCP EF in the TCP packets entering VLAN146 and CoS 4 in the IPX packet transiting the switch across VLAN 146. Note that all ports with VLAN146 that are configured for VLAN QoS will be affected by this configuration.

    Example 5:

    mls qos
    !
    ! Enable VLAN-based QoS on interfaces
    !
    interface FastEthernet 0/1
    mls qos vlan-based

    !
    ! Enable VLAN-based QoS on the trunks
    !
    interface range FastEthernet 0/13 - 21
    mls qos vlan-based

    !
    ! Access-Lists
    !
    ip access-list extended TCP
    permit tcp any any
    !
    mac access-list extended IPX
    permit any any 0x8137 0x0

    !
    ! First-level class-maps
    !
    class-map TCP
    match access-group name TCP
    !
    class-map IPX
    match access-group name IPX

    !
    ! VLAN-based policy-map
    !
    policy-map PER_VLAN
    class TCP
    set dscp ef
    class IPX
    set dscp 32

    !
    ! Apply the policy-map to SVI
    !
    interface VLAN 146
    service-policy input PER_VLAN

    As mentioned above, you cannot use policing in SVI-level policy map. This eliminates the possibility of having policer aggregating traffic rates for all ports in a single VLAN. However, you can still police per-port per-VLAN in the 3560 using the following feature.

    Per-Port Per-VLAN Policing in the 3560

    This feature uses second-level policy-maps. The second-level policy-map must list class-maps satisfying specific restrictions. The only “match” criterion supported in those class-maps is match input-interface. You can list several interfaces separated by spaces, or use interface ranges, separating interfaces in a range by hyphen. The only action supported in the second-level policy-map is the police command. As usual, you can drop exceeding traffic or configure traffic remarking using policed DSCP map. The police action applies individually to every port in the range.

    You cannot use aggregate policers in the second-level policy-maps. Another restriction – if you apply a second-level policy-map (interface-level map) inside “class-default” it will have no effect. You need to apply the second-level policy-map inside user-defined classes.

    The following example restricts IP traffic rate in VLAN146 on every trunk port to 128Kbps and limits the IP traffic in VLAN146 on the port connected to R6 to 256Kbps.

    Example 6:

    mls qos map policed-dscp 18 to 8
    

    !
    ! For 2nd level policy you can only match input interfaces
    !
    class-map TRUNKS
    match input-interface FastEthernet 0/13 - FastEthernet 0/21

    !
    ! The second class-map matches a group of ports or a single port
    !
    class-map PORT_TO_R6
    match input-interface FastEthernet 0/6

    !
    ! IP traffic: ACL and class-map
    !
    ip access-list extended IP_ANY
    permit ip any any
    !
    class-map IP_ANY
    match access-group name IP_ANY

    !
    ! Second-level policy-map may only police, but not mark
    !
    policy-map INTERFACE_POLICY
    class TRUNKS
    police 128000 16000 exceed policed-dscp-transmit
    class PORT_TO_R6
    police 256000 32000

    !
    ! 1st level policy-map may only mark, not police
    ! VAN aggregate policing is not possible in the 3560
    !
    policy-map VLAN_POLICY
    class IP_ANY
    set dscp af21
    service-policy INTERFACE_POLICY
    !
    interface Vlan 146
    service-policy input VLAN_POLICY

    !
    ! Enable VLAN-based QoS on the ports
    !
    interface FastEthernet 0/6
    mls qos vlan-based

    !
    ! Enable VLAN-based QoS
    !
    interface range FastEthernet 0/13 - 21
    mls qos vlan-based

    This is it for the comparison of most common policing features on the 3550 and 3560 platforms. Digging deeper in the areas of Catalyst QoS would probably takes us far beyond the size of a post the a normal human can read :)

    Hey! Don’t miss anything - subscribe to our newsletter!

    © 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo