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's 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:

Server Location

Host/Subnet

Application-Specific Criteria

Diffserv Matching Rule

MPLS Classification

VLAN Identification

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. 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 web site.

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 non-standard 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.

Address

You can specify an 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's 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.
• Enter a MAC address for non-IP protocols to enable classification of traffic to and from a known host. This feature is particularly intended to support bridging, where a site router is not specified or non-IP traffic normally would not get counted. A MAC address must always be combined with a non-IP service in a matching rule.
  
  Enter the address in six-octet format — for example, 08:12:34:56:A1:5C.
  
  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.

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

Host List

A host list contains a set of IP addresses and/or DNS names that traffic class matching rules can reference. Host lists let you specify many IP addresses and/or names in a single traffic class matching rule. Unlike the option to specify a range of IP addresses, the addresses in a host list do not need to be contiguous.

The Host List Editor provides an interface for creating, updating, and deleting host lists.

To create a host list:

1. While creating a class or adding a matching rule, select Host List in either the Inside or Outside column.

2. Click the icon. The Host List Editor window opens.

3. Enter a name in the New host list field.

4. Click add list to generate the new host list.

5. Enter an IP address or DNS name in the New hosts field.

The host list editor accepts any addresses and/or names that are syntactically correct. It does not validate the existence of the entries.

6. Click add host.

7. Continue adding addresses or names to complete the list and then click done to return to the Matching Rule or Traffic Class window.

8. To include the selected host list in the matching rule definition, click apply changes.

Note: A single Host List Editor session is limited to the creation of 32 host lists. A message window warns when this limit is reached. To initiate a new session to add more host lists, close the Host List Editor window and the Matching Rule window and then open them both again.

See also Modify a Host List.

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 HTTP, Citrix-ICA, ICMP, Oracle-NetV2, and RTP-I. 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 PacketShaper/AppVantage; 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.