Matching Rules

What is a Matching Rule?

Matching rules define the criteria used by PacketWise to identify traffic types. Every traffic class must have at least one matching rule. When traffic discovery creates a traffic class, it creates one or more matching rules to characterize the traffic type. In a similar fashion, when you create a class manually, you must specify the matching rules that describe the application's flows.

A traffic class can have multiple matching rules, which are treated as separate, distinct specifications. When PacketWise tries to map a traffic flow to a class, it compares the flow with the criteria in the class' first matching rule. If PacketWise does not find a match, it continues through the rules until a match is found or until it runs out of matching rules, in which case it moves on to the next class in the tree. If a specific traffic class cannot be found for a flow, the traffic is classified in the Default traffic class for the subtree.

The fields described here are found in the New Traffic Class and New Matching Rule windows.  show screen

The following sections describe the criteria that can be specified in a matching rule:

Device

Server Location

Host/Subnet

Application-Specific Criteria

Diffserv Matching Rule

MPLS Classification

VLAN Identification

Device

To match traffic that is passing through a specific interface, you can create a class that specifies a physical port on the PacketShaper. For example, you can create a class that classifies all outbound traffic on the upper LAN Expansion Module (LEM). You can then turn on class discovery for the LEM class and PacketWise will auto-discover all the applications, services, and protocols on this LEM. The Device field lists only the installed interfaces on your unit. The possible values are:

any (will not classify by device)
main (built-in)
lower (lower LEM) or left (left LEM)
upper (upper LEM) right (right LEM)

Server Location

For IP protocol traffic classes, the matching rule syntax uses the terms inside and outside to refer to an application's server location, relative to the unit. If your site router is your access router, inside hosts are on your LAN and outside hosts are on the WAN or Internet.

Tip: When setting Inside or Outside, answer the question: "If the chosen service uses a server, is the server found on the inside or outside of the unit?"

If you wish to capture traffic in a given class regardless of server location, select any. You will want to do this when creating a matching rule by client IP address or subnet. PacketWise will create two matching rules — one for inside and one for outside. Also, PacketWise does not support the concept of a server for non-IP protocols—NetBEUI, IPX, AppleTalk, SNA, DECnet, and FNA — so these protocols do not have an inside or outside reference. For these protocol types, select any for the server location.

Classifying by Server Location

If you want to manage the traffic more precisely, create separate classes for the inside and outside server locations—that is, /Inbound/HTTP/Inside, /Inbound/HTTP/Outside, /Outbound/HTTP/Inside, and /Outbound/HTTP/Outside. For example, you may want to create these separate classes to be able to distinguish between uploads and downloads.

Example of Server Location

You can manually create traffic classes to account for an application's server location. For example, MySportsCompany, Inc. (a fictitious company) installed a unit on its network. The MySportsCompany web designer downloads images from the ESPN website.

The following table describes the traffic activity and the class that matches the activity:

Ports

In the Inside and Outside Port(s) field, you can list the port or ports associated with the services for this class. In general, you should specify a port number only if you want to restrict classification to a specific port. Since many applications no longer limit transmissions to assigned port numbers, it is better to specify a service name.

You can define a service on a nonstandard port; however, the non-standard port must be a number that has not already been assigned. For example, in the matching rule, you can define the service as HTTP and the port as 8088.

For details about port number assignments, refer to the Internet Assigned Number Authority (IANA — www.iana.org).

Port Number Range

To specify a range of port numbers—for example, 5001 through 5005 — use a dash (-) to separate the low and high values of the range (5001-5005).

Non-Contiguous Port Numbers

To specify non-contiguous port numbers — for example, only ports 5001 and 5025—define separate matching rules within the same class.

Proxy this Service to a Non-Standard Port

A service proxy lets you identify applications running on ports that do not comply with the well-known port numbers defined by IANA. For example, you may know that a certain host (often a proxy server) is running a particular service on a specific non-standard port. In the matching rule, specify a combination of attributes, like host and port, and then use the Proxy this Service to a non-standard port option to associate the traffic with a known service.

Host/Subnet

Use the Host/Subnet matching rule field to isolate a single host or a range of hosts — perhaps the network administrator's PC or a group of high-priority users.

You can specify source and destination hosts in a number of ways: by name, IP address, a range of IP addresses, a list of names, or subnet address and mask.

Name

If you have configured a DNS server in PacketWise, you can specify a domain name in a matching rule. Also, if you configured a default domain name, you can use non-fully qualified domain names. If the name does not exist when you create the matching rule, PacketWise warns you about the unknown name.

PacketWise refreshes DNS name lookups in matching rules whenever they expire, according to the life that is returned in the lookup. This is configured separately at each name server. This client behavior is compatible with dynamic DNS.

IP Address

You can specify an IP address using one of the following ways:

• Enter a single IP address in dotted decimal notation — for example, 207.78.98.254.
• Specify a range of IP addresses by separating the first and last addresses with a dash — for example, 10.10.10.10-10.10.10.20.
  
  Note: When a parent class has an Inside IP address range and its child class has an Outside IP address range different from the parent range, you need to specify the parent's Outside IP range in the child class' matching rule. (The range is not inherited.) If you neglect to input the parent's range, a matching rule incompatibility error will occur.
• For multicast services, enter the keyword multicast to specify Class D IP addresses (224.0.0.0 through 239.255.255.255) for the destination side — that is, inside for inbound classes, outside for outbound classes.
  
  The classification process can handle broadcast and other multicast traffic if you specify a particular multicast address in the matching rule. In this case, PacketWise assumes that, since it is bridging this traffic to remote sites, it needs to count this traffic.
• Use any to indicate any host — that is, no particular address.

Host List

A host list contains IP addresses, DNS names, and/or subnets that traffic class matching rules can reference. Host lists let you specify many hosts in a single traffic class matching rule. The addresses in a host list do not need to be contiguous. See Create a Host List.

Subnet and Mask

Specify a subnet mask to mask off network address bits, thereby defining a subset of hosts in a network — for example, 255.255.255.0

MAC Address

Enter a MAC address for IP or non-IP protocols to enable classification of traffic to and from a known host. The address must be entered in six-octet format — for example, 08:12:34:56:A1:5C. Note that you cannot classify Ethernet broadcasts (FF:FF:FF:FF:FF:FF).

When the host resides outside the unit, you must specify the MAC address in the "Outside" column. If the host is on the inside of the unit, use the "Inside" column. If you wish to match all traffic from a host, regardless of whether it is inside or outside of the unit, you need to create two separate matching rules.

This functionality allows you to create classes for traffic going through a specific router and/or router interface. For example, suppose your PacketWise unit is connected to two WAN routers. With this feature, you can create a separate class for each router by specifying the router's interface MAC address in the matching rule. You can then assign a partition to each class to control bandwidth usage of the link.

Application-Specific Criteria

The Criterion field near the bottom of the New Matching Rule and New Traffic Class windows is available for certain types of traffic, specifically Citrix-ICA, DICOM, FTP-Data-Clear, HTTP, HTTP-Tunnel, ICMP, NNTP-Clear, Oracle-netv2, PostgreSQL, RTCP-I, RTP-I, SMTP-Clear, SOAP-HTTP, SSL, and WAP. This field allows you to further differentiate these types of traffic. For example, web traffic can be differentiated by host DNS name or address, URL, content type, or web browser (user agent).

For details, see Application-Specific Matching Rule Criteria.

Diffserv Matching Rule

When you choose diffserv when creating a class or matching rule, the Matching Rule: Diffserv window appears. In this window, you can select either Code Point or COS/TOS.

Diffserv Type: Code Point

The Type of Service (TOS) field in the IP header is known as the Differentiated Services field, as defined in the Differentiated Services specification (RFC 2474). This field is divided into the following subfields:

• Differentiated Services Code Point (DSCP) (6 bits)
  Enter a value from 0 through 63.
• Currently unused (CU) (2 bits)

Diffserv Type: COS/TOS

Many routing protocols make routing decisions based on the Type of Service (TOS) field in the IP header. This field is an indicator of the quality of service that is expected.

The TOS field contains:

• IP Precedence subfield, also known as the Class of Service (COS) sub-field, which is a 3-bit field
• Type of Service (TOS) subfield, which is a 4-bit field
• Unused bit that is set to zero

Applications set this field to tell routers how to prioritize packets. For example, weighted fair queuing (WFQ) algorithms in routers use this information.

You can tell PacketWise to match on these IP precedence bits during classification of IP protocols, then apply specific policies to manage these traffic types. For example, you could apply a policy that substitutes a different precedence value so that you can control the packet's priority when it reaches the router. For details on using a policy to substitute an IP precedence value, see Substitute Diffserv Values.

In the IP Precedence (COS) field, specify the IP precedence value to match. Enter a precedence value from 0 to 7 (where 7 is the highest precedence), or a range of values.

PacketWise can check the Type of Service (TOS) field in the IP header to match on a service level for an application. Select one of the following values to match:

8 = minimize delay

4 = maximize throughput

2 = maximize reliability

1 = minimize monetary cost

0 = normal service

You might match on this TOS field, then use a policy to change the value.

MPLS Classification

Multiprotocol Label Switching (MPLS) is a method of forwarding packets at a high rate of speed. As packets go through routers on the edge of the network, the router attaches a label that contains information about the packet's destination, bandwidth, delay, source IP address, Layer 4 socket number, and differentiated service. PacketWise is able to classify traffic based on the MPLS label. Packeteer's implementation of MPLS support is based on RFC 3031 and 3032 (that is, the relevant subset that is applicable to Packeteer products; some of the sections in these RFCs apply to routers and switches only). For details related to this standard, go to ietf.org.

You can create an MPLS matching rule that is based on:

• a single MPLS label (a number between 0 and 1048575)
• a range of MPLS labels (for example, 250-350)
• any traffic flow that has an MPLS label (specify any instead of a specific number)

To set up an MPLS matching rule, click mpls when creating a class or matching rule. Then enter the MPLS label in the Matching Rule: MPLS window.

VLAN Identification

PacketWise has the ability to classify application traffic within multiple virtual LANs on a single Ethernet segment (an 802.1q trunk). For a multiple VLAN environment (where packets passing through the unit will have more than one VLAN header), only the outermost VLAN header is used for classification. The other headers are ignored.

You can create a VLAN identification matching rule that is based on:

• a single VLAN ID (a number between 0 and 4095)
• a range of VLAN IDs (for example, 100-200)
• any traffic flow that has a VLAN ID (specify any instead of a specific number)

To set up a VLAN identification matching rule, click vlan when creating a class or matching rule. Then enter the VLAN identification value in the Matching Rule: VLAN window.