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:
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:
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:
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:
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:
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:
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 CLASSIFYNote 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 AGG256Per-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_VLANNote 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_VLANPer-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_VLANAs 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-basedThis 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
0 comments:
Post a Comment