GigaSMART Adaptive Packet Filtering (APF)

Adaptive Packet Filtering includes fragmentation awareness whereby all IP fragments associated with the filtered data packet are always forwarded allowing a complete view of the traffic stream for accurate analytics. APF also provides a powerful filtering engine that identifies content (based on patterns) across any part of the data packet, including the data packet payload.

APF filters packet-by-packet, but does not have the concept of sessions. For Application Session Filtering (ASF) and packet buffering on ASF, refer to Application Session Filtering with Buffering.

APF operations can be assigned to GigaSMART groups consisting of multiple engine ports. Refer to Groups of GigaSMART Engine Ports for details.

In APF second level maps, a maximum of five (5) maps can be attached to a virtual port (vport). Each map can contain up to 25 gsrules.

Adaptive Packet Filtering (APF) goes deeper into packets to search for a condition, then filter and forward packets to tools, as follows:

■

Content-based Filtering

■

Encapsulation Awareness

■

Pattern Matching

To create vports through the UI and implement APF, do the following:

1. On the left navigation pane, click , and then select Physical > Nodes
2. From the left navigation pane, go to System > GigaSMART >GigaSMART Groups > GigaSMART Groups, and then click New.
3. On the GigaSMART Group page, select an available engine ports in the Port List field to associate group with one of the available engine ports.

You can associate the GigaSMART Group with one or multiple eports. For APF, no GigaSMART parameters are required unless combined with other gsops.

4. From the device view, select GigaSMART > Virtual Ports, and then click New.
5. On the Virtual Ports page, enter an alias and select the GigaSMART groups created in Step1, and then click Save.
6. To enable the APF operation, do the following:

1. From the device view, select GigaSMART > GigaSMART Operations (GSOP) > GigaSMART Operation.
2. On the GigaSMART Operations page, enter an alias in the Alias field
3. In the GigaSMART Groups drop-down list, select the GigaSMART group from step 1.
4. From the GigaSMART Operations (GSOP) list, select Adaptive Packet Filtering and select Enabled.
5. Click Save.

Once APF is enabled, maps can be created that the APF and the virtual port.

6. Create the first level map with virtual port created in step 2 as the destination and without applying a GigaSMART Operation.

7. Create a second level map with the APF GigaSMART operation, the virtual port as the source, and a rule. The following figure shows an example.

This completes the process to create an APF GigaSMART operation and corresponding rules. To learn more about the rules applicable for APF, see following sections.

Content-based filtering is based on packet contents beyond Layer 2, 3, and 4 headers. The following four groups of attributes of rules in a map support content-based filtering.

The first group of attributes has the following format:

	<attribute> <address> <cidr>|<mask>

The first group of attributes that use this format are as follows:

■

ipv4 src and dst

■

ipv6 src and dst

■

mac src and dst

The following figure shows the attributes as displayed in the UI.

The second group of attributes has the following format:

	<attribute> min <value> max <value> subset <odd|even|none> pos

The second group of attributes that use this format are as follows:

■

vlan id

■

mpls label

■

l4port src and dst

■

ethertype

■

ipv4 ttl, tosval, and protocol

■

ipv6 flow-label

■

vntag dvifid, svifid, and viflistid

The following figure shows the attributes as displayed in the UI.

The third group of attributes has the following format: <value> <position>

	<attribute> value <value> pos <0|1|..|n>

The third group of attributes that use this format are as follows:

■

ipv4 dscp and frag

■

ipv6 dscp

■

ipver

The following figure show the attributes as displayed in the UI.

The fourth group of attributes has the following format:

	<attribute> value <value> mask <mask> pos <0|1|2|3>

The fourth group of attribute that uses this format is as follows:

■

tcp ctl

The following figure shows the attribute as displayed in the UI.

The maximum occurrences of each attribute supported are as follows:

Attribute	Maximum Occurrences
Attributes in IPv4 header	3
Attributes in IPv6 header	3
Attributes in MAC header	3
VLAN ID	4
MPLS label	4
Attributes in L4port	3
Ethertype	6
Attributes in VNTag header	3
Attributes in TCP header	3
IP ver	3

Encapsulation awareness offers filtering across advanced encapsulation headers, including GTP tunnel ID, VXLAN ID, ERSPAN ID, and GRE key.

The following attributes of rules in a map support encapsulation awareness:

1.

Enter a GTP tunnel identifier as a four-byte hex value, either a range or a single value.

2.

Enter a VXLAN ID as a three-byte hex value, either a range or a single value.

3.

Enter an ERSPAN ID as a decimal value from 1~1024, either a range or a single value using the corresponding arguments.

4.

Enter a GRE key as a four-byte hex value, either a range or a single value.

Use APF to create pattern matching filters in which the pattern is a particular sequence of data bytes at a variable or fixed offset from the start of a packet. Thus you can filter on any data patterns within a packet.

Pattern matching identifies content based on patterns in any part of the packet, including the payload. Patterns can be a static string at a user configured offset or a subset of Perl Compatible Regular Expression (PCRE) at a variable offset.

The Pattern Match attribute in a map rule supports pattern matching.

Multiple pattern matches are supported. A map can have multiple gsrules, each rule can have a pattern matching expression, and a single packet can match multiple rules.

The Pattern Match attribute in a map rule is shown in Figure 1.

Figure 45

Use Pattern Match Under Maps for Pattern Matching

After selecting pattern matching for the rule, you can enter a Perl-compatible regular expression or a string to be used as a filter when pattern matching. For example to pass all packets including the string www.gigamon.com select string as type for the pattern match as shown in Figure 2.

Figure 46

Pattern Match with Type String

To pass packets that match any phone number in the nnn-nnn-nnnn format, select regex for the pattern match type and enter the following regular expression in the value field: \d{3}-d{3}-d{3} as shown in Figure 3.

Figure 47

Pattern Match with Type RegEx

The offset is a value or range from 0 to 1750. The offset indicates where the pattern under search is located, specify, a value to indicate that the pattern has to start at that offset in the packet in order to be considered a match. Specify a range (beginning and ending) to indicate that the pattern can be anywhere in the packet in that range.

The optional protocol argument of the Pattern Match specifies that the matching will start after the protocol header specified in the command (IPv4, IPv6, TCP, or UDP). Pos 1 or 2 indicates the position. For example, position 2 indicates that matching is to start after the second protocol header. The offset and start and end values are also counted after the protocol header.

For example, to mask an SSL client hello packet pattern starting from the first position after the TCP header with an offset of 0 (located right after the TCP header), you define the pattern match rule as shown in Figure 4.

Figure 48

Pattern Match for SSL Client Hello Packet

Cross-packet pattern matching refers to a scenario where a match initiates in one packet and ends in a subsequent packet. Staring with Gigamon software release 5.4 this feature enhancement extends the support for GSOP cross packet pattern spanning two packets.

Cross packet matching applies to connection oriented exchanges only and available for 5-tuple flows. Cross packet matching scan will be performed on frames with the following header encapsulations:

■

IPv4/TCP, IPv4/UDP

■

IPv6/TCP, IPv6/UDP

■

IPv4/IPv6/TCP, IPv4/IPV6/UDP

■

IPV6/IPv4/TCP, IPV6/IPv4/UDC

Every packet of a flow is subjected to pattern matching scan starting with the inner most L4 payload section. For example, 5-tuple TCP session with nested TCP layer will position the scan starting from start of innermost TCP payload to the end of frame. Bi-directional flow maintains match context for each direction separately and this feature supports up to 1Million flows.

The figure below illustrates the Cross-packet pattern matching concept where the pattern search “abcdef” spans two packets.

The following constraints exist with this functionality.

■

Cannot coexist with other GSOPs on same gsgroup.

■

Only one second level map is allowed for each vport attached to the gsgroup.

■

Disabling the feature requires a GigaSMART card reboot.

Go to Map > Statistics to display counts of the rules that actually matched in a map. A single packet can match one or more rules. For example, if a single packet matches multiple rules in an APF map, all matching rules will have that packet counted against them and the overall map status pass counter will show 1.

Refer to APF Statistics Definitions for descriptions of these statistics as well as to GigaSMART Operations Statistics Definitions.