Anue Net Tool Optimizer User Guide 109
Custom Dynamic Filtering
This section applies to all models except the 5204.
The NTO comes with several predefined fields for filtering traffic. Using those fields, you can specify the types of network packets allowed or not allowed to pass through a filter. The predefined filtering fields are available for network ports, tool ports, and dynamic filters. For a detailed explanation of how to use the predefined fields, see “Defining Filter Criteria for Ports, Port Groups, and Dynamic Filters” on page 96.
With Custom Dynamic Filtering, you can now define custom fields to use in your dynamic filters to match on parts of the packet headers and payload that are not accessible using the predefined fields. Custom fields allow you to match on 2- or 4-byte fields, up to 128 bytes deep into Ethernet packets. By defining your own custom fields, you can filter on specific bit patterns and values at selected
locations in a packet. This allows access to header and payload fields in protocols such as MPLS, GTP, GRE, HTTP, FCoE, FIP, iSCSI, L2TP, VoIP, RTP, and more.
Table 6-4 outlines the number and sizes of the custom fields available on each NTO model.
The NTO has built-in support for MPLS (all models) and GTP (5288/5293 models only), providing access to specific named fields within those protocols, avoiding the need to calculate the exact packet positions of the fields. You can also create
“raw” custom fields, or as the control panel refers to them, “Custom” fields. These more generic fields allow you to specify the size of the field and the offset from a location in the packet to the beginning of the field. The relative starting position for the offset can either be the beginning of the packet or the end of the Layer 2 header.
When using the raw custom fields, be aware that if you’re looking for a byte match at a certain offset, you can unintentionally match on random data at that offset. To
Models 5236/5273: Custom dynamic filtering is not supported on 5236/
5273 when IPv6 filtering is enabled (that is, when filter memory is allocated to support IPv6 filtering).
Table 6-4: Available Custom Fields on NTO Models
Model Available Custom Fields
5204 Custom dynamic filtering is not supported.
5236, 5273 Up to 8, 4-byte fields, with 4-byte boundaries and sizes to be even multiples of 4.
Note: In the specific case of using offset 0 from the start of a packet, the sizes allowed are 2 or 6.
5288, 5293 Up to 16, 2-byte fields, with 2-byte boundaries and sizes to be even multiples of 2
Chapter 6, Creating and Using Objects
110 Anue Net Tool Optimizer User Guide
avoid that, check some other field, such as the IP protocol or TCP source port, to confirm that the packet is of the correct type. When you use the built-in protocols, MPLS and GTP, the NTO automatically provides these confirmation fields for you.
Unlike the predefined fields, which you can use on network ports and tool ports, you can only use custom fields in the dynamic two-stage filters that connect network ports to tool ports on the NTO. A dynamic two-stage filter using custom fields is also referred to as a “custom filter.”
Some things to keep in mind when using custom filters are the following:
■ When using custom fields, not all predefined fields will be available in the same filter.
■ A network port can only be connected to one custom filter at a time.
■ A network port connected to a tool port through a standard dynamic filter cannot at the same time be connected to the same tool port through a custom filter.
In the NTO, custom fields are allocated in one or two “field sets.” These field sets appear on the Dynamic Custom Filtering dialog, where you define the custom fields. Access the dialog from the System Settings tab by clicking the link to the right of the Custom dynamic filtering field. You can enable and define one or two field sets, but only enable what you need because the field sets come with a price.
Each field set uses about 10% of the available dynamic filter and tool port filter memory, which reduces the amount of memory available for other types of filters.
If you enable two field sets, you have the choice of using them in the same filter or different filters. By using them in the same filter, you get up to 32 bytes of custom fields for a single filter. If you use them in different filters, you only get up to 16 bytes of custom fields in any one filter. You get “up to” an amount because, in most cases, you don't use up the full amount all at once. As you chose the composition of your custom fields, your choices use up bytes, usually in 2- or 4-byte increments, depending on the NTO model (see Table 6-4 on page 109).
Not all of your choices cost bytes. Some are “free.” They don't count against the total 16 or 32 bytes available. These are typically fields in the outer headers of tunneled packets, and the ones that you get for free depend on which layers and protocols you select to filter. For example, MPLS is a Layer 2 tunnel protocol which is identified by a specific Ethertype. When you choose MPLS & Custom as the types of fields you want to include in field set 1, Ethertype is provided as a free outer header field to use for confirmation.
As another example, GTP is a Layer 3 and 4 tunnel protocol which is identified by a specific UDP source port When you choose GTP & Custom (5288/5293 only) as the types of fields you want to include in field set 1, Outer IP protocol and outer L4 source port are provided as free outer headers to use for confirmation. Table 6-5 shows the free headers you get as optional confirmation fields with the
Custom Dynamic Filtering
Anue Net Tool Optimizer User Guide 111
custom field types you choose to filter. It also shows the optional additional outer header fields you can select at a cost of 10% filter memory.
Table 6-5: Free Outside & Additional Headers with Selected Field Types Selected Field
Field sets in same filter
Chapter 6, Creating and Using Objects
112 Anue Net Tool Optimizer User Guide
To use custom fields, perform the following tasks, explained in detail in the sections that follow:
1. Enable one or both field sets. If you enable both field sets, choose whether to use them in the same or different filters.
2. Select the network layer with headers that will be most useful for your filtering.
3. Assign pre-defined (GTP-C, GTP-U, or MPLS) or Custom fields and their associated confirmation fields to the field sets.
4. Use the fields in the field sets in one or more dynamic filters, specifying the values to be matched.
Once you enable field sets and select a packet header layer for the custom fields, you can start adding custom fields to the field sets. You can allocate fields to a field set until you use up the available bytes - 16 bytes for one field set, or 32 bytes when both field sets are enabled for use in the same filter. Depending on the field type you select, you will be prompted to enter additional information, such as enabling confirmation fields and configuring the number of optional header words.
Confirmation fields are necessary to ensure the pre-defined fields are actually there. For example, if you add a GTP-U tunneled IPv4 source address field to a field set, you are given the option to confirm that the outer IP protocol is UDP, the outer UDP destination port is 2152, and the inner IP version is IPv4. If you don’t check these confirmation fields you might match packets that are not GTP-U packets that just happen to have an IPv4 address (or even just some matching bits!) at the same location.
In many cases, the packet protocols provide for optional fields in the headers. For example, IPv4, IPv6, TCP, and GTP headers all include optional fields which may or may not be present in a particular packet. In tunneled packets, the IP and TCP NOTE If you enable field sets 1 and 2 to be used in the same filter, all the custom fields you create must be for the same layer type. For example, if you add a GTP-U field (Layer 3/4) to the field sets you cannot later add an MPLS field (Layer 2) to the field sets.
5236/5273 GTP custom fields are not available at this time.
NOTE When editing fields in field sets, an existing field may be removed as long as it is not either (a) in use in a Dynamic Filter or (b) saved as a filter template. If removal is attempted, and one of these conditions exists, an error message describing the above will be displayed. In that case, first delete its use in all Dynamic Filters and filter templates. The field can then be removed from the field set.
NOTE The 16-byte limit of one field set is only large enough for one IPv6 address. To filter on both the source and destination IPv6 address in one filter, you need to enable both field sets in the same filter.
Custom Dynamic Filtering
Anue Net Tool Optimizer User Guide 113
headers can appear both outside and inside the tunnel. In order to filter on custom fields, the NTO must know the exact offset from the start of the packet or the end of the outer Layer 2 header to that field. Therefore, if a custom field is deeper in the packet than one of the headers with optional fields, you must specify the size of those optional fields.
For example, if you want to add the pre-defined field “Tunneled IPv4 L4 Source Port” in a GTP-U packet, you must specify the number of 32-bit words in the optional fields in the GTP-U header plus the number of 32-bit words in the optional fields in the inner IPv4 header. If you need to filter on packets with different numbers of optional fields, you will have to add the pre-defined field multiple times, once for each different size of the optional fields.
As another example, to filter on fields inside MPLS tunnels you must specify the number of MPLS labels you expect in the packets, the service type (L2 VPN or L3 VPN), whether the pseudowire code word is present, and the number of VLAN tags in the tunneled frame.
If one of the pre-defined GTP or MPLS fields does not suit your needs, you can also define raw custom fields, specifying your own offsets and field sizes. You specify a byte offset relative to the start of the packet or the end of the Layer 2 header and a byte length (or size). The byte offset and length must be multiples of 2 on the 5288/5293 and multiples of 4 on the 5236/5273. By selecting the end of the Layer 2 header, you can avoid having to account for any VLANs or
variations in Ethernet frame formats (for example, Ethernet II, 802.2, LLC/SNAP, etc.). Be sure to account for any optional headers beyond the relative starting position when you define a Custom field. You must also specify a name for this field. The name is limited to 32 characters and must be unique across all custom fields. This name will appear in the dynamic filter dialog to allow you to filter on this custom field.
To perform custom filtering, complete the following two main tasks:
1. “Define Custom Fields” on page 114.
2. “Use Custom Fields in Filters” on page 118.
For a quick example of these two main tasks, see “Quick Example: GTP-U Custom Filtering Field (5288/5293 only)” on page 119.
Tip: A network protocol analyzer tool like Wireshark can help you
determine information you need before you create custom filters. Using a tool like Wireshark, you can examine some sample traffic to determine the following kinds of information:
• MPLS — How many MPLS labels are present
• MPLS — How many VLAN tags are present in the inner L2 header
• GTP-U — How many words are in the optional fields in your GTP-U headers
• Raw — The size of bytes, that is, the number of words in an optional field, like the IPv4 header options values
Chapter 6, Creating and Using Objects
114 Anue Net Tool Optimizer User Guide