About Classifier-based configuration

Traffic classes and software releases

The Classifier feature introduces:

  • A finer granularity than globally configured features for placing network traffic (IPv4 or IPv6) into classes that can be used in cross-feature software configurations

  • Additional policy actions, such as rate limiting and IP precedence marking, to manage selected traffic

  • The configuration of service policies for classified traffic with the following software features:

    • Quality of Service (QoS)

    • Traffic mirroring

    • Policy Based Routing (PBR)

  • The application of service policies to specific inbound traffic flows on individual port and VLAN interfaces (rather than only on switch-wide or port-wide traffic).

Using CIDR notation for IPv4/IPv6 addresses

You can use CIDR (Classless Inter-Domain Routing) notation to enter an IPv4 mask-length or an IPv6 prefix-length with a source and destination address that are used as match criteria in a match/ignore statement. The switch interprets the IP address with CIDR notation to compute the range of corresponding IP source or destination addresses in packet headers that are considered to be a match for the traffic class.

When the switch uses a match/ignore statement to compare an IP address and corresponding mask/prefix length to the IP source/destination address carried in a packet, the IPv4 mask-bit settings and IPv6 prefix-bit settings select packets in different ways.

  • An IPv4 mask length creates a mask in which:

    • A mask-bit setting set to 0 (off) requires the corresponding bit in a packet's IPv4 source/destination address to be the same binary value as the mask-bit in the matching IPv4 source/destination address.

    • A mask-bit setting set to 1 (on) is used as a wildcard and allows the corresponding bit in a packet's IPv4 source/destination address to be either binary value (0 or 1).

      How CIDR notation is used with IPv4 SA/DA match criteria

      IPv4 Source/Destination address used with CIDR notation in a Match/Ignore statement Resulting mask Range of IPv4 addresses selected by the match criteria
      10.38.240.125/15 0.1.255.255 The leftmost 15 bits must match; the remaining bits are wildcards.
      10.38.240.125/20 0.0.15.255 The leftmost 20 bits must match; the remaining bits are wildcards.
      10.38.240.125/21 0.0.7.255 The leftmost 21 bits must match; the remaining bits are wildcards.
      10.38.240.125/24 0.0.0.255 The leftmost 24 bits must match; the remaining bits are wildcards.
      18.38.240.125/32 0.0.0.0 All bits must match.
  • An IPv6 prefix-length creates a mask in which:

    • A mask-bit setting set to 1 (on) requires the corresponding bit in a packet's IPv6 source/destination address to be the same binary value as the mask-bit in the matching IPv6 source/destination address.

    • A mask-bit setting set to 0 (off) is used as a wildcard and allows the corresponding bit in a packet's IPv6 source/destination address to be either binary value (0 or 1).

      How CIDR notation is used with IPv6 SA/DA match criteria

      IPv6 source/destination address used with CIDR notation in a Match/Ignore statement Resulting mask Range of IPv6 addresses selected by the match criteria
      2001:db8:0:7::5/64 FFFF:FFFF:FFFF:FFFF:: The leftmost 64 bits must match; the remaining bits are wildcards.
      2001:db8:0:7::5/72 FFFF:FFFF:FFFF:FFFF:FF00:: The leftmost 72 bits must match; the remaining bits are wildcards.
      2001:db8::244:17ff:feb6:d37d/126 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFC The first 126 bits mst match; the C value in the mask allows four possible combinations (D37C, D37D, D37E, and D37F) in the last block of a matching IPv6 address.
      2001:db8:0:7:af:e2:c1:5/128 FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF All bits must match.

    [NOTE: ]

    NOTE: Although IPv4 and IPv6 masks are applied in opposite directions:

    • An IPv4 mask-length is applied from right to left, starting from the rightmost bits.

    • An IPv6 prefix-length is applied from left to right, starting from the leftmost bits.



    The behavior of IPv4 and IPv6 masks as match criteria and wildcards is the same.


Where to go from here

Classifier-based service policies are designed to work with your existing globally-configured software settings. While existing software features allow you to globally manage all network traffic on a switch or port, classifier-based service policies allow you to zoom in on subsets of network traffic to further manage it on a per-port or per-VLAN basis.

You can use the match criteria described in this chapter across software features to configure classes of traffic for use in feature-specific service policies.

After you decide on the IPv4 and IPv6 network traffic you want to manage, see the Management and Configuration Guide for more information about how to configure and use classifier-based quality-of-service and mirroring policies.

Traffic class-based configuration model

Traffic class-based software configuration consists of the following general steps:

  1. Determine the inbound traffic you want to manage and how you want to manage it. For example, you may want to rate limit certain traffic, prioritize it, mirror it, and so on.

  2. Classify the traffic that you want to manage by configuring a class, using match and ignore commands. A traffic class is configured separately from service policies and can be used in various policies.

  3. Configure a service policy for one or more address classes, including an optional, default class. A policy consists of configuration commands executed on specified traffic classes for one of the following software features:

    • Quality of Service (policy qos command)

    • Port and VLAN mirroring (policy mirror command)

    • Policy Based Routing (policy pbr command)

  4. Assign the policy to an inbound port or VLAN interface using the interface service-policy in or vlan service-policy in command.

The following figure shows an overview of traffic class-based software configuration:

Traffic class-based configuration model

Traffic class-based configuration model

Creating a traffic class

In the traffic class-based configuration model, you use match criteria to create a class of IPv4 or IPv6 traffic and select the packets you want to manage. In a traffic class configuration, match criteria consist of match and ignore commands. These commands determine the packets that belong to a class. (Match/ignore criteria are modelled on the permit/deny criteria used in ACLs.)

The traffic classes you configure can be used later in the service policies you create for different software features, such as QoS and port mirroring. The match criteria used in match/ignore statements are the same across software features.

Using match criteria

To identify the packets that belong to a traffic class for further processing by policy actions, use match and ignore commands in a class configuration:

match commands

Define the values that header fields must contain for a packet to belong to the class and be managed by policy actions.

ignore commands

Define the values which, if contained in header fields, exclude a packet from the policy actions configured for the class. An ignored packet is transmitted without having a policy action performed on it.

The switch compares match/ignore statements to the values in packet fields. It compares the specified criteria in the sequential order in which the statements are entered in the class, until a match is found. Be sure to enter match/ignore statements in the precise order in which you want their criteria to be used to check packets.

  • As soon as a field in a packet header matches 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.

  • If a packet matches the criteria in an ignore statement, the sequential comparison of match criteria in the class stops, and no policy action is performed on the packet.

If a packet does not match the criteria in any match/ignore statement in a traffic class configuration, one of the following actions is taken:

  • The packet is transmitted without a policy action performed on it.

  • If a default class is configured in the policy, the actions specified in the default-class command are performed on packets that do not match the criteria in preceding classes in the policy.

The following match criteria are supported in match/ignore statements for inbound IPv4/IPv6 traffic:

  • IP source address (IPv4 and IPv6)

  • IP destination address (IPv4 and IPv6)

  • Layer 2 802.1Q VLAN ID

  • Layer 3 IP protocol

  • Layer 3 IP precedence bits

  • Layer 3 DSCP bits

  • Layer 4 TCP/UDP application port (including TCP flags)

  • VLAN ID

Using zone classes

Zone classes are used in conjunction with a technology called Transparent Mode. Both zone classes and Transparent Mode are supported on the HP 5400zl and 8200zl Switch Series when:

  • The switch is running software version K.14.58 and above

  • An HP AllianceONE Extended Services zl Module is installed in the switch

Transparent Mode enables the HP 5400zl or 8200zl switch to intercept packets that match certain criteria and redirect them to an application that is running on an HP AllianceONE Extended Services zl Module. In effect, Transparent Mode allows that application to be in the path of packet flow. (Applications that run on AllianceONE Extended Services zl Modules are referred to as ONE applications.)

Packet interception differs from port mirroring. With port mirroring, the switch copies the packets being sent from a particular source port to a particular destination port and sends these packets to a mirror port. The original packets continue to be sent from the source port to the destination port without interruption.

With packet interception, on the other hand, the switch does not copy packets to another port. Instead the switch actually intercepts the packets and forwards them to the ONE application. The ONE application can then make decisions based upon those packets and control or modify the packets before they are delivered to their final destination.

After intercepting and redirecting the packets to the ONE application, the HP 5400zl or 8200zl switch does not perform any further action on the intercepted packets.

Because a ONE application is required to act on the intercepted packets, Transparent Mode is available only when an HP AllianceONE Extended Services zl Module is installed in the zl switch. In addition, the switch must also be running software version K.14.58 or above.)


[NOTE: ]

NOTE: Check the release notes for the switch software you are using to ensure it supports the ONE application that is running on your AllianceONE Extended Services zl Module.


You will configure Transparent Mode commands only when your ONE application supports this functionality.

Troubleshooting problems

If you experience problems with your Transparent Mode configuration but cannot pinpoint the cause, you can use the following command to gather detailed information about your Transparent Mode configuration:

HP Switch#: show tech transparentmode

The output from this command is displayed on your terminal emulator. However, using your terminal emulator's text capture features, you can save show tech transparentmode data to a text file for viewing, printing, or sending to an associate or even HP Support. For example, if your terminal emulator is the HyperTerminal application available with Microsoft® Windows® software, you can copy the show tech transparentmode to a file and then use either Microsoft Word or Notepad to display the data. (In this case, Microsoft Word provides the data in an easier-to-read format.)

Where to go from here

Zone service policies are designed to work with ONE applications that support Transparent Mode. (ONE applications run on HP AllianceONE Extended Services zl Modules.) See the ONE application's documentation for detailed information on how to configure zone classes and zone policies.