GigaSMART Adaptive Packet Filtering (APF)
Required License: Adaptive Packet Filtering
Adaptive Packet Filtering (APF) provides filtering on specific encapsulation protocol parameters. Additionally, it has the ability to look beyond the encapsulation protocol parameters into the original (encapsulated) data packet, to filter on source and destination IP or Layer 4 port numbers. APF offers the ability to look for content anywhere in the data packet and make intelligent filtering and forwarding decisions.
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:
- On the left navigation pane, click , and then select Physical > Nodes
- From the left navigation pane, go to System > GigaSMART >GigaSMART Groups > GigaSMART Groups, and then click New.
- 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.
- From the device view, select GigaSMART > Virtual Ports, and then click New.
- On the Virtual Ports page, enter an alias and select the GigaSMART groups created in Step1, and then click Save.
- To enable the APF operation, do the following:
You can associate the GigaSMART Group with one or multiple eports. For APF, no GigaSMART parameters are required unless combined with other gsops.
- From the device view, select GigaSMART > GigaSMART Operations (GSOP) > GigaSMART Operation.
- On the GigaSMART Operations page, enter an alias in the Alias field
- In the GigaSMART Groups drop-down list, select the GigaSMART group from step 1.
- From the GigaSMART Operations (GSOP) list, select Adaptive Packet Filtering and select Enabled.
- Click Save.
Once APF is enabled, maps can be created that the APF and the virtual port.
- Create the first level map with virtual port created in step 2 as the destination and without applying a GigaSMART Operation.
- 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 1.
1 | 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 2.
2 | 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{4} as shown in 3.
3 | 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 4.
4 | Pattern Match for SSL Client Hello Packet |
APF allows masking when there is a match through pattern matching. Use masking with pattern matching to mask out a specific portion of a packet due to security reasons or to hide sensitive information in packets.
Multiple pattern matches are supported in a map. If there is masking associated with a rule and a packet matches multiple rules, the masking action is enforced for all the matching rules in the map.
The mask specifies that the matched pattern in the gsrule will be masked with the pattern specified in the 1-byte masking pattern.
The pattern specified in the gsrule will be overwritten. The overwritten length is the length of the matching pattern specified in either a string or a RegEx pmatch. Use the 1-byte to overwrite the original pattern match pattern. If there are multiple matches in the packet, up to 10 matches will be masked.
For example, to find Social Security numbers in the format xxx-xx-xxxx, between offset 40 and 80 and replace them with zeros, create a map with a pass rule in a Second Level byRule map with the regular expression \d{3}-?\d{2}-?{4} and a mask with a 1-byte masking value of 0 as shown in 5.
5 | Map Rule with RegEx for Masking SSNs |
To optimize APF pattern matching performance in second level maps with gsrules, you can optionally use a pattern matching hint.
6 | Pattern Match with Hint |
The addition of the hint leads to two levels of filtering. First, the packet is subjected to a check for the simpler match comprising “gamon|GIM”. If a match is found, a second level check for a match in the complete RegEx, “a[gG]igamon|aGIMO\\s[a-f]\\d{4}”, is performed.
A hint must be selected so that all the packets that are expected to match the actual RegEx must have that string in them, otherwise the first level check will not be cleared. The hint in the example, “gamon|GIM”, was selected because a packet containing either “gamon” or “GIM” in it is a potential match to the actual RegEx.
The pattern matching hint is optional and, to optimize performance, it should be specified for all gsrules in a map. In that map, its usage is all or none, meaning you cannot have a mix of gsrules with some having the pattern matching hint and others not. However, if there are two maps, one map can have gsrules that include the pattern matching hint, while the other map can have gsrules that do not.
The use of the pattern matching hint improves performance in complex RegEx patterns involving “lookbehind” and “lookahead” constructs of PCRE syntax. Using them in conjunction with maps with simple patterns, such as fixed length string, is not advisable as it might lead to performance degradation in some cases. Since the RegEx rule set is limitless, there are no specific rules in which the degradation happens. A best practice is to try out both options, with and without the pattern matching hint, to find out what works best.
The rule of thumb while constructing the pattern matching hint is to keep it as simple as possible. Also, it must be a subset of the configured RegEx pattern. First, try out a 3 to 6 character-wide hint. If that does not provide the necessary scale, you can make the hint wider and more specific to prevent false positives. A maximum length of 63 bytes is supported.
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.
You can enable or disable Cross-packet pattern matching from the GigaSMART GSOP operation.
1. | Select a Physical Node. |
2. | GigaSMART > GigaSMART > GigaSMART Groups. |
3. | Click New. The GigaSMART Group parameter page displays. |
4. | Click the Enable Cross-packet Match check box to enable. |
5. | Enter a range from 1 to 10 for the Cross Packet Match Flows parameter. Each unit is 100K bi-directional flows. |
6. | Click OK. |
Note: When disabling this functionality you will be notified that change will be effective only after chassis or GigaSMART card reboot.
1. | Repeat Steps 1 through 3 from the “Enabling Cross Packet Matching” task. |
2. | Uncheck the Enable Cross-packet Match check box to disable this functionality. |
3. | Click OK. |
1. | Select a Physical Node. |
2. | GigaSMART > GigaSMART > GigaSMART Groups. |
3. | Select a Group. |
4. | Click Edit. The GigaSMART Group parameters including cross pattern match details pane displays. |
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.