HP NetworkiNg ProVisioN switcH software classifier syNtax

Business white paper

Table of contents
Executive summary Introduction The business challenge Solution overview Traffic classification Service policy Applying a policy Solution scenarios VoIP implementation Debugging your QoS policy Limiting Web-browser traffic Trusting your signaling traffic Remote mirroring with a mirror policy ACL validation using a mirror policy Enforcing security on your network using PBR Why use classifier 3 3 3 3 4 5 6 6 6 7 8 8 8 9 10 11

Executive summary
This white paper discusses the ProVision switch software classifier syntax, which provides a consistent and highly extensible framework for deploying different classifier features across all ProVision-based switch platforms. As networks become more complex, providing enhanced classification capabilities to control and monitor the network traffic becomes more important. This white paper strives to provide a better understanding of the features, and how these features monitor and configure the network for more stable and predictable behavior.

Introduction
Starting with the software release K.14.xx, the classifier syntax provides a highly capable framework for deploying classification of traffic. This release offers the following benefits: More control of network traffic Clear and understandable syntax to express the criteria for traffic classification and the subsequent actions performed on classified traffic The ability to use the same syntax for both quality of service (QoS) and mirroring Starting with software release K.15.06.xxxx, the classifier syntax also supports policy-based routing (PBR)*. As applications such as voice, video, and data appear on converged networks, the need for more control over network traffic has become crucial. Organizations particularly, organizations managing large networks must ensure efficient traffic handling throughout the network, while keeping the most important traffic moving at an acceptable speed, regardless of current bandwidth usage. Businesses must also be able to provision and classify network traffic so that voice traffic gets higher priority than Web-browsing traffic. Once you have classified your traffic, you can apply QoS to ensure that your critical data gets higher priority. You can monitor your network traffic and use the information to fine-tune your switch configuration. PBR policies allow you to manipulate the path a packet follows in order to load balance traffic or to direct confidential traffic over a more secure network path.

The business challenge

With converging networks, congestion management has become critical. Network congestion and dropping of packets severely affects latency-sensitive traffic such as voice and video. Adding bandwidth is often a good idea, but is not always feasible, and does not eliminate the potential for network congestion. There are always points in the network where multiple traffic streams merge or where network links change speed and capacity. The impact and number of these congestion points increase over time as more applications and devices are added to the network. Latency-sensitive traffic needs to be switched as quickly as possible. Based on the packet contents, it is beneficial to treat packets differently as they transit a network device. In order for a company to efficiently utilize its network resources, it must identify critical traffic in the network and allocate appropriate resources to support time-sensitive data. If voice is present in the network, it must get priority over all other traffic to avoid issues with voice quality. Voice and video applications are delay and jitter-sensitive. For example, if you are the network administrator of a student dorm you give higher priority to voice traffic rather than traffic generated from browsing the internet. If a student is downloading a movie you limit the rate of that traffic. You also monitor the traffic that is going into the switch.

Solution overview
The classifier feature offers fine granularity for classifying network traffic (Internet Protocol version 4 [IPv4] or IPv6) into classes that can be used across different features. In K.15.06.xxxx software releases, the classifier feature is used to configure QoS, PBR, and traffic mirroring.*

* PBR is only supported in HP 5400 and 8200 switch series that have all v2 modules.

There are three steps to using the classifier feature. Traffic classification: This process distinguishes one type of traffic from another by examining the fields in the packet header. Classification can be done for all IP (IPv4 and IPv6) traffic. Defining a policy: Specify what actions to take with a class of traffic once it has been identified. This step can be considered the actual construction of a policy. Applying the policy: Assign service policies to specific inbound traffic flow on individual port and VLAN interfaces. Traffic classification To identify the packets that belong to a traffic class for further processing by policy actions, use match and ignore commands. Match and ignore statements compare the values in packet fields with specified criteria in sequential order with statements entered in the class, until the first statement meets the criteria. A match command defines the value that a header field must contain for a packet to belong to the class and be managed by policy actions. When fields in a packet header pass the criteria in a match statement, the sequential comparison of match criteria in the class stops, and the policy actions configured for the class are executed on the packet. An ignore command defines the value which, if contained in header fields, exclude a packet from the policy actions configured for the class. An ignored packet does not have a policy action performed on it. If the fields in a packet pass the criteria in an ignore statement, the sequential comparison of statements in the policy stops, and no policy action is performed on the packet. To configure a traffic class to be used in one or more policies, you enter the class command from the global configuration context. [no] class < ipv4 | ipv6 > <classname > You enter one or more match or ignore commands from the class configuration context to filter traffic and determine the packets on which policy actions are performed. [no] [seq-number] <match | ignore> <ip-protocol> <source-ipaddress> [comparisonoperator <source-tcp-udp port>] <destination-ipaddress> [comparison-operator <destination-tcp-udp port>] [dscp codepoint] [precedence precedence-value] [tos tosvalue] [vlan vlan-id] In the following example, we create classes to classify VoIP traffic, VoIP signaling, video traffic, and video signaling. class ipv4 VOIP-traffic
Note: Match all User Datagram Protocol (UDP) packets with source port 5200 from any source IP address to any destination IP address.

Source address range match match match match udp udp udp udp any any any any eq 5200 any range 50000 50100 range 50000 50100 range 50000 50100

destination address range any range 50000 50100 any range 5200 5263 any range 53500 59999 any eq 5060 any any any any any any any range range range range range range range 1024 4999 1024 4999 6000 7000 10000 10384 49000 51000 3200 3247 49000 51000

Note: Match all UDP packets with source port range between 50000 to 50100 from any source IP address to any destination IP address with destination port range between 5200 and 5263.

class ipv4 VOIP-signaling match tcp any eq 5060 class ipv4 video-traffic match udp any range 1024 4999 match udp any range 1024 4999 match udp any range 49000 51000 match udp any range 49000 51000 match udp any range 49000 51000 match udp any range 49000 51000 match udp any range 3200 3247 class ipv4 video-signaling match tcp any match tcp any

any eq 1720 any eq 4840

Service policy
In release K.15.06.xxxx, we support the following types of policies: QoS policies on port and VLANs Mirroring policies on ports and VLANs. PBR policies on VLANs Each feature supports different actions for managing selected packets. To create a service policy that performs feature-specific actions on selected packets, you enter the policy <mirror | pbr | qos > <policyName> from the global configuration context. To configure the actions that you want to execute on packets that correspond to the match criteria in a specified class, you enter one or more class action commands from the policy configuration context. [no] [seq-number] class <ipv4 | ipv6> <classname> action <qos-action> [action <qos-action> ...] The following QoS commands are supported by the QoS action parameter: rate-limit <kbps kbps> priority <priority-value> dscp <dscp-value>

ip-precedence <precedence-value> Mirroring policies support: Mirror destination assignments for matching packets. The syntax for a mirror policy is [no] [seq-number] class <ipv4 | ipv6> <className> action mirror <mirror-session> When configuring PBR policies, there is a separate action context. After specifying the class address family and name, you enter into the action context: HP-switch(policy-pbr)#class ipv4 tcp HP-switch(policy-pbr-class)# The syntax for the PBR action context: action < ipv4 | ipv6> <next-hop | default-next-hop> <IP addr> <IP addr>... OR action interface <tunnel <tunnel ID> | NULL> <tunnel <tunnel ID> | NULL>... NOTE: Up to 8 PBR actions may be configured for a class. If interface null is specified, no more actions may be configured for the class. The precedence of the actions is determined as they are configured for a class. If a higher precedence action is unreachable, the next reachable action becomes active. If none of the specified actions are reachable the default behavior is to route the packet as if no policy were applied. The default behavior for a class may be changed to drop by specifying interface null. The following PBR commands are supported by the PBR action parameter: IPv4 or IPv6 next-hop <IP address> IPv4 or IPv6 default-next-hop <IP address> interface tunnel <tunnel ID> interface NULL A policy consists of one or more actions that are taken on each class of traffic. You can configure multiple classes in a policy. The configured actions are executed on packets that pass the criteria for a match statement in a class. No policy action is performed on packets that match an ignore statement. Be sure to enter classes in a policy in the precise order in which you want packets to be checked and handled by class action commands.

The default class manages packets that do not pass the criteria for any match or ignore statement in all classes in a policy, and otherwise would have no actions performed on them. The default class differs from other classes because it contains no match or ignore statements and uses implicit match ipv4 any any and match ipv6 any any statements that match all unmatched packets of both address families. If the default class is not configured, unmatched packets are transmitted without an action performed on them. Below we create a policy on the above example of VoIP traffic, VoIP signaling, video traffic, and video signaling traffic and apply QoS actions on the classified traffic.
Note: Match all UDP packets with source port 5200 from any source IP address to any destination IP address.

policy qos Port-QOS-inbound class ipv4 VOIP-traffic action dscp ef action priority 7 class ipv4 video-traffic action dscp af41 action priority 6 class ipv4 voip-signaling action dscp cs5 action priority 5 class ipv4 video-signaling action dscp cs5 action priority 5 default-class action dscp default action priority 0

Applying a policy
To apply feature-specific service policies to an inbound port or VLAN, use the interface service-policy in or VLAN service policy in command. interface A1-A20 service-policy Port-QOS-inbound in The following service policy restrictions apply to all classifier features: Only one feature-specific policy (for example, QoS or mirroring) is supported on a port or VLAN interface. For example, you can apply one QoS policy and one mirror policy on a port or a VLAN. A service policy is supported only on inbound traffic. PBR policies are only supported on inbound routed traffic on VLAN interfaces

Solution scenarios
In this section we provide a few examples of how to use the new classifier syntax. VoIP implementation This example describes a scenario for implementing VoIP in your company. Create four classes to classify the traffic (as shown in the configuration below) and assign different priorities to the traffic streams. In the example below, the traffic assigned with the highest priority is voice traffic, which is the most sensitive to delay. The next highest priority is video, followed by voice and video signaling. You also create a default class to assign the lowest priority to all other types of traffic. class ipv4 VOIP-traffic match udp any eq 5200 any match udp any range 50000 50100 any range 50000 50100 match udp any range 50000 50100 any range 5200 5263 match udp any range 50000 50100 any range 53500 59999 class ipv4 VOIP-signaling match tcp any eq 5060 any eq 5060 class ipv4 video-traffic match udp any range match udp any range match udp any range match udp any range match udp any range match udp any range match udp any range 1024 4999 any range 1024 4999 1024 4999 any range 1024 4999 49000 51000 any range 6000 7000 49000 51000 any range 10000 10384 49000 51000 any range 49000 51000 49000 51000 any range 3200 3247 3200 3247 any range 49000 51000

class ipv4 video-signaling match tcp any any eq 1720 match tcp any any eq 4840

policy qos Port-QOS-inbound class ipv4 VOIP-traffic action dscp ef action priority 7 class ipv4 video-traffic action dscp af41 action priority 6 class ipv4 voip-signaling action dscp cs5 action priority 5 class ipv4 video-signaling action dscp cs5 action priority 5 default-class action dscp default action priority 0 interface A1-A20 service-policy Port-QOS-inbound in

Debugging your QoS policy

To rate limit all TCP traffic entering your VLAN to 1 Mb/s and all other IP traffic to 2 Mb/s. You create two classes to classify all TCP traffic and all IP traffic. class ipv4 ip-traffic match ip any any class ipv4 tcp-traffic match tcp any any Create an all-traffic QoS policy to rate limit your traffic and apply it to VLAN 1. policy qos ipv4-traffic class ipv4 ip-traffic action rate-limit kbps 2000 class ipv4 tcp-traffic action rate-limit kbps 1000 vlan 1 service-policy all-traffic in The first match in a policy dictates the action on a packet. Subsequent matches are ignored. All TCP traffic matches the match ip any any statement in the ip-traffic class. As a result all traffic (including TCP traffic) is rate-limited to 2 Mb/s. Use the show statistics command to debug your configuration. The command shows the number of packets (in parentheses) that have passed the criteria in the match and ignore statement for each class in the QoS policy and have been processed by the action configured for the class. The switch maintains a running total since the last counter reset. The meter shows the total number of kilobits that matched the class. show statistics policy all-traffic vlan 1 in the following: HitCounts for Policy all-traffic Total 10 class ipv4 ip-traffic action rate-limit kbps 2000 [ Meter 200 kilo bits ] (15622) 10 match tcp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 20 class ipv4 tcp-traffic action rate-limit kbps 1000 [ Meter 0 kilo bits ] (0) 10 match ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 You can see that the HitCounts for the match tcp any any statement remains 0 whereas the HitCounts for match ip any any increments. As a general rule, the more specific match statements should precede the more generic ones. The correct policy is: policy qos ipv4-traffic class ipv4 tcp-traffic action rate-limit kbps 1000 class ipv4 ip-traffic action rate-limit kbps 2000 show statistics policy all-traffic vlan 1 in HitCounts for Policy all-traffic Total (300) 10 class ipv4 tcp-traffic action rate-limit kbps 1000 [ Meter 200 kilo bits ] 10 match tcp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 20 class ipv4 ip-traffic action rate-limit kbps 2000 [ Meter 837 kilo bits ] (1331) 10 match ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

Limiting Web-browser traffic

Your company has been experiencing high levels of Web-browser traffic. This traffic has been interfering with your day-to-day network operation. You decide to limit the Web-browser traffic. To limit Web-browser traffic you classify the HTTP traffic and apply a QoS policy. In the policy you rate limit the traffic and assign a lower DiffServ Code Point (DSCP) codepoint. class ipv4 http match tcp match tcp match tcp match tcp match tcp any any any any any any any any any any eq eq eq eq eq 80 443 8000 8001 8080

policy qos meterAndPrioritizeHttpTraffic class ipv4 http action rate-limit kbps 1000 action priority 0 action dscp default vlan 10 service-policy meterAndPrioritizeHttpTraffic in

Trusting your signaling traffic In the following example you want to trust the assigned priority and DSCP values of all IP Remote Authentication Dial-In User Service protocol (RADIUS) (port 1812 and port 1813) and Terminal Access Controller Access-Control System (port 49) traffic from subnet 10.0.8.0/24 to 169.254.0.0/16 and lower the priority and DSCP of all other IP traffic. class ipv4 signaling ignore tcp 10.0.8.0/24 ignore udp 10.0.8.0/24 ignore tcp 10.0.8.0/24 ignore udp 10.0.8.0/24 ignore tcp 10.0.8.0/24 ignore udp 10.0.8.0/24 match ip any any 169.254.0.0/16 169.254.0.0/16 169.254.0.0/16 169.254.0.0/16 169.254.0.0/16 169.254.0.0/16 eq eq eq eq eq eq 49 49 1812 1812 1813 1813

policy qos signalingPriority class ip rateLimitClass action dscp default priority 0 vlan 1 service signalingPriority in Remote mirroring with a mirror policy A remote mirror destination is very helpful in troubleshooting a network without being physically present at the switch. Any preconfigured mirror destination may be used with a mirror policy. Configure a remote mirror on the sending switch: mirror 2 remote ip 3.3.3.3 65500 4.4.4.4 Here, 3.3.3.3 is the IP address of the subnet on which you want the traffic to leave the switch, 65500 is the destination UDP port of the remote mirroring packets, and 4.4.4.4 is the IP address of the receiving switch. Configure the remote mirror endpoint on the receiving switch: mirror endpoint ip 3.3.3.3 65500 4.4.4.4 port a1 Configure a v4-telnet class to classify IPv4 telnet traffic and v6-telnet class to classify IPv6 telnet traffic. The mirror policy Telnet assigns the mirror session identity to the classified traffic. class ipv4 v4-telnet match tcp any any eq 23 match udp any any eq 23 class ipv6 v6-telnet match tcp any any eq 23 match udp any any eq 23

policy mirror Telnet class ipv4 v4-telnet action mirror 2 class ipv6 v6-telnet action mirror 2 Once the policy Telnet is applied to either a port or a VLAN, the traffic that is matched by the class is mirrored remotely to the switch with destination IP 4.4.4.4 via UDP destination port 65500 and viewable via a traffic analyzer on port A1. ACL validation using a mirror policy You can use a mirror policy to validate or debug an Access Control List (ACL). In some cases traffic is denied when it is expected to be permitted. A mirror policy can easily help you determine if the entries in an ACL are too permissive, too restrictive, or written incorrectly. In this example ACL NoManagement is applied to VLAN 10. The goal is to deny all secure shell (SSH), Telnet, HTTP, and SNMP traffic from entering the VLAN, but allow all other traffic. ip access-list extended NoManagement permit tcp 1.1.1.1/24 2.2.2.2/24 permit udp 1.1.1.1/24 2.2.2.2/24 deny tcp 1.1.1.1/24 2.2.2.2/24 deny udp 1.1.1.1/24 2.2.2.2/24 deny tcp 1.1.1.1/24 2.2.2.2/24 deny udp 1.1.1.1/24 2.2.2.2/24 deny tcp 1.1.1.1/24 2.2.2.2/24 deny udp 1.1.1.1/24 2.2.2.2/24

range 22-23 range 22-23 eq 80 eq 80 eq 161 eq 161

vlan 10 ip access-group NoManagement vlan The ACL is applied to VLAN 10 and you notice that you can access the switch via Telnet. Configuring the following mirror policy can help you determine that the ACL is configured incorrectly. All permit statements in the ACL are replaced by match statements in the class and all deny statements are replaced by ignore statements. In this instance, the ignore statements are not needed but are left for clarity. mirror 2 port A1 class ipv4 NoManagement match tcp 1.1.1.1/24 match udp 1.1.1.1/24 ignore tcp 1.1.1.1/24 ignore udp 1.1.1.1/24 ignore tcp 1.1.1.1/24 ignore udp 1.1.1.1/24 ignore tcp 1.1.1.1/24 ignore udp 1.1.1.1/24 2.2.2.2/24 2.2.2.2/24 2.2.2.2/24 2.2.2.2/24 2.2.2.2/24 2.2.2.2/24 2.2.2.2/24 2.2.2.2/24

range 22-23 range 22-23 eq 80 eq 80 eq 161 eq 161

policy mirror NoManagement class ipv4 NoManagement action mirror 2 vlan 10 service-policy NoManagement in When you attach a traffic analyzer to port A1 and examine the traffic sent when you try to telnet from 1.1.1.1 to 2.2.2.2 via TCP destination port 23, you see the traffic and realize the ACL was configured incorrectly. The more restrictive TCP and UDP entries should be listed first in the ACL followed by the more permissive statements. It is also possible to use remote mirror as the destination for the mirror policy for off-switch debugging.

Enforcing security on your network using PBR You can use as PBR policy to route your traffic over different paths based on the IP header attributes of a packet. In the following example, a university wants all traffic generated by students to first go through a firewall, if the path to the firewall is unreachable, the traffic should be dropped. The professors and staff need no such restriction. class ipv4 Students 10 match ip 1.1.1.1 0.0.0.255 any exit class ipv4 Staff 10 match ip 2.2.2.2 0.0.0.255 any exit policy pbr SecureNetwork 10 class ipv4 Students action ip next-hop 7.7.7.7 action interface NULL exit 20 class ipv4 Staff action ip next-hop 8.8.8.8 exit exit HPSwitch(config)# vlan 1 service-policy SecureNetwork in There are two ways to determine what actions are active in a class within a policy. 1. Show statistics HPSwitch(config)# show statistics policy SecureNetwork vlan 1 in HitCounts for Policy SecureNetwork Total 10 class ipv4 Students action ip next-hop 7.7.7.7 ( 100 ) 10 match ip 1.1.1.1 0.0.0.255 0.0.0.0 255.255.255.255

20 class ipv4 Staff action ignore ( 300 ) 10 match ip 2.2.2.2 0.0.0.255 0.0.0.0 255.255.255.255 The output shows that 100 student packets went through the firewall via IP next-hop 7.7.7.7 and that 300 staff packets followed the default routing path as IP next-hop 2.2.2.2 was unavailable. 2. Debug logging debug ip pbr debug destination session When a PBR policy is applied to a VLAN the debug logging output displays the following: 0000:00:01:40.87 PBR:01/01/90 00:00:56 PBR Policy SecureNetwork, Class Students, action IP NEXT-HOP 7.7.7.7 0000:00:01:40.99 PBR:01/01/90 00:00:56 PBR Policy SecureNetwork, Class Staff, action IGNORE 10

Why use classifier

Classifier feature in ProVision switch software reduces complexity of managing your network by unifying the conceptual model and syntax for configuration of classifier-based features. The model uses concepts and structure similar to, but less complex in comparison to others in the industry. The classifier syntax produces well structured configurations that are easy to understand and intuitive to implement. It also scales easily from simple to complex applications of policies.

To utilize your network resources efficiently and improve your QoS, visit www.hp.com/networking.

1 1

Get connected
www.hp.com/go/getconnected

Get the insider view on tech trends, alerts, and HP solutions for better business outcomes

Copyright 2009, 2011 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. 4AA2-9182ENW, Created October 2009, Updated October 2011, Rev. 1