Filtering in Distributed Taps
Application Note
TM
By default, VSS Distributed Taps copy traffic
received on the network input port(s) and
forward it to the monitor output port(s) as defined
by the user through selective aggregation. By
adding a filter (or filters) to that traffic, users
can define which packets are passed to the
monitor port(s) based on packet content.1
Each filter is defined as a set of user-specified
data values which will be compared to the
data in network port received packets. These
comparison values are specified for one or
several standard packet fields (e.g. the MAC
destination address field). Packets which
contain the specified data values in the specified
packet fields result in a filter “match” (“true”).
Packets which do not contain the specified
data values are a “non-match” (“false”).
Each filter can be configured so that only
matching packets are copied (in order to
monitor only the specified type of packet), or
so that all packets except matching packets
are copied (in order to monitor all except the
specified type of packet). Matching packets
can be defined by complex expressions.
Filtering & Latency
VSS filtering is implemented
in hardware, requiring no
software or CPU processing.
Thus, it operates in real time,
introducing virtually no latency
from the network inputs to the
monitor outputs.
Filter Condition Comparison Fields
The following packet fields can be compared within any filter:
MAC Source Address
Ethernet (IEEE 802.3 - Layer 2) source address.
MAC Destination Address
Ethernet (IEEE 802.3 - Layer 2) destination address
Etype
Ethernet Type
VLAN ID
IEEE 802.1q VLAN ID (if a tagged packet)
Priority IEEE 802.1p/q Priority (if a tagged packet)
IEEE 802.1p/q Priority (if a tagged packet)
IP Source Address IP (layer 3) source address (if an IP packet)
IP (Layer 3) source address (if an IP packet)
IP Destination Address
IP (Layer 3) destination address (if an IP packet)
IP Version
IP Protocol Version (if an IP packet)
IPv4 Type of Service
IP Type of Service field (if an IPv4 packet)
IPv6 Traffic Class
IP Traffic Class field (if an IPv6 packet)
IPv6 Flow
IP Flow field (if an IPv6 packet)
IPv4 Protocol
IP Protocol field (if an IPv4 packet)
IPv6 Next Header
IP Next Header field (if an IPv6 packet)
TCP/UDP Source Port
TCP or UDP Source Port field (if a TCP/UDP packet)
TCP/UDP Destination Port
TCP or UDP Destination Port field (if a TCP/UDP packet)
Custom
User-specified
A filter condition <expression> is specified with packet field
names, and values to be compared against the packet field:
packet field [=] value
Multiples of such comparisons may be joined using the keywords
“and” or “or”. Compound expressions (using “and”/”or”) are
evaluated left-to-right, but an explicit evaluation order may be
specified using “(“ and “)”.
Examples:
mac source = 00AA00112233
ethernet source 00AA00112233
or ethernet destination 00AA00112233
(destination ip address 1.2.3.4 or source ip address 1.2.3.4)
and ip prot=6
(1) Filtering applies only to the monitor port. The data passing from one network port to the other
(when configured as inline tap ports) is always unaffected and is passed-through completely transparently.
2
Offset Filters
Offset (custom) filtering allows the user to create a byte filter window, beginning at the MAC, IP, TCP, or UDP header, for
comparison with all packets that pass through the filter. Within the “window”, the user specifies an offset from the beginning of
the “window” and the desired hexadecimal data pattern to be compared to received packets.
For example, offset 6 (MAC header plus 6) against the pattern “00dd00112233”. As another example, ip offset 15 = 02
specifies a comparison of the last byte of the IPv4 Source field (IP header plus 15 bytes) against the single-byte pattern “02”.
Masking
A “mask” command is a qualifier for the data pattern entered in bits. This will cause the value specified to be “AND’ed” with the
packet data. The result will be compared with the comparison data entered and if this data equates, the filter will see a match.
This masking feature allows the user to isolate single bits or groups of bits as desired (for filtering on partial bytes). For example,
to filter only packets where the low-order bit of the IPv4 Source address is a 1, specify ip offset 15 = 01 mask 01.
Packet Fields
The following packet field names can be used in a condition <expression>:
Packet Fields
Alternate Forms
v2
v3
Comparison Value
48-bit Ethernet address, entered
mac source
as 12 hexadecimal digits, with
mac source address, ethernet
source [address], source
<mac|ethernet> [address]
optional embedded space, ‘-‘ or ‘:’
charac¬ters for readability, e.g.:
00dd00 112233
mac destination
<mac|ethernet> dest[ination]
[address], dest[ination]
<mac|ethernet> [ad¬dress]
etype
[mac|ethernet] etype
vlan
[mac|ethernet] [outer]
vlanid, [mac|ethernet]
[outer] vid
priority
[same as mac source]
16-bit hexadecimal value (four
hexadecimal digits)
Decimal value in the range 0-4095
[mac|ethernet] [outer] pri,
[mac|ethernet] [outer] qos
Decimal value in the range 0-7
To specify an IPv4 address, enter
the address using standard .
delimited decimal notation, e.g.:
192.168.0.250.To specify an
IPv6 address, enter the address
as an IPv6 128-bit address using
hexadecimal digits delimited by
ip source
ip src [address],
<source|src> ip [address]
Range
optional:
mask
<value>
“:” after every two bytes. A range
of IPv4 or IPv6 addresses may also
be specified by entering a base
address and a range mask, e.g.
IP destination 192.168.0.0 mask
255.255.255.0 (a received packet
with an IP destination address
anywhere within the specified range
is considered a pattern match).
ip destination
ip dest [address],
dest[ination] ip [address]
ip version
ip ver
Range
optional:
mask
<value>
[same as ip source]
4 or 6
3
– continued on next page
Packet Fields
Alternate Forms
ip tos
ip tos
ip protocol
ip prot
ip flow
ip flow
v2
v3
Comparison Value
8-bit value specified as two
hexadecimal digits
20-bit value specified as 5
hexadecimal digits, as per
RFC3232
Decimal value 0-65535
Decimal value 0-65535, or a
range of values separated by a ‘-‘
[tcp|udp] <src|source> port,
<source|src> [tcp|udp] port
Range
Range
tcp destination
[tcp|udp] dest[ination]
port, dest[ination]
[tcp|udp] port
Range
Range
[same as tcp source]
offset nnn
[mac|ip|tcp|udp] offset nnn
optional:
mask
<value>
optional:
mask
<value>
Hexadecimal, with a max value of
tcp source
character, e.g.: “80-81”; or “even”
or “odd”.
127.
*Items noted above with Range may optionally be specified with a range of values, e.g. “value1-value2”.
The number of packet fields per filter and the number of values compared against each field per expression depend on the
specific model. For the majority of VSS Distributed Taps with filtering, there is no per-filter limitation.
2
Filter Examples
The following filter will match only HTTP request packets:
ip protocol 6 and tcp destination port 8
The following filter will match only FTP packets (FTP Control or FTP Data):
ip protocol 6 and tcp destination port 20-21
To monitor all traffic to or from a particular node/pc, the node’s Ethernet/MAC address (00AA00123456 in this example)
can be used in a filter expression such as:
mac source 00AA00123456 or mac destination 00AA00123456
Alternatively, the node’s IP address could be used (1.2.3.4 in this example):
ip source 1.2.3.4 or ip destination 1.2.3.4
To monitor one particular connection/conversation/session between two nodes (1.2.3.4 and 5.6.7.8 in this example)
use an expression like this:
(ip source 1.2.3.4 and ip destination 5.6.7.8) or (ip source 5.6.7.8 and ip source 1.2.3.4)
To monitor one particular TCP/IP protocol (in this example HTTP) use an expression such as this, which filters IP protocol 6
(TCP) and IP port 80 (HTTP):
ip protocol 6 and (tcp source port 80 or tcp destination port 80)
Or, in a combination of the above, to monitor a particular protocol (e.g. HTTP) from one particular node (e.g. 1.2.3.4):
(ip source 1.2.3.4 or ip destination 1.2.3.4)and ip protocol 6 and (tcp source port 80 or tcp
destination port 80)
(2) In this case, the per-filter packet field limitation is equal to the total packet field limit of the tap.
4
Creating and Applying Filters with a Web Browser
The Filter Library
User-defined filters are stored within a Filter Library. A collection of many filters can be predefined by the user, and then specific
filters called upon as the need arises. Once a filter has been defined in the library, that filter can then be used repeatedly on
multiple ports at any time without the need to re-define the entire filter each time. Filters are identified by user-defined symbolic
names.
Creating Filters
Selecting the Filter Library link on the main page will bring up a screen which allows the configuration of all monitor filters. The
currently-defined filters (if any) will be shown on the screen.
The top-left of the page displays a list of the
currently-defined filters. To view an existing filter, simply
click once on the name of the filter.
To add a new filter to the Filter Library, click once on “+
Add new filter”. In the entry box labeled “Filter Name”,
type the desired symbolic name for the new filter; enter
the new filter specifications in the fields below, then
click the “Save Filter” button to add the new filter to the
library.
To change an existing filter, first select the filter by
clicking once on its name, and then enter the new filter
specifications in the fields below; finally click the “Save Filter” button. Note that changing an existing filter will automatically
update the filter on all ports to which the filter has already been applied.
To remove an existing filter, first select the filter by clicking once on its name, and then click the “Delete Filter” button. A pop-up
dialog box will ask for confirmation before deleting the filter.
Below the filter list is a text input field showing the text of the selected filter conditional expression. You can enter a conditional
expression directly into the input field if desired. Alternatively, below the conditional expression are three tabs labeled Quick,
Detailed, and Advanced. Each of these represents a different way to configure the filters, although all result in a single conditional
expression which becomes a part of the Filter Library.
In most cases, the Quick tab is the easiest way
to configure filters, and is recommended and
appropriate for most filtering situations. This tab
allows easy specification of MAC address, IP
address, and/or protocol.
The Detailed tab allows more advanced
configuration of the individual conditions. This
tab allows configuration of parameters not
available under the Quick tab, including VLAN
ID and IP Type of Service (TOS).
The Detailed tab contains input fields to
configure all of the possible fields for which to
compare against received packets. To change
a setting, simply click within the field and enter
the desired value. To remove (disable) a setting
(to make it “don’t care” or “any value”), simply
click within the field and delete the field value (making it empty or blank). Fields for which settings have been made (non-blank
fields) will be highlighted on the screen for emphasis; blank (“don’t care”) fields are not highlighted.
5
The Advanced tab facilitates direct entry of the text of a
conditional expression. Directly entering the conditional
expression allows for complex combinations of ANDing
and ORing, which would not be available from the other
tabs. This tab displays a help screen showing the available
packet fields and their associated expression keywords. To
directly enter an expression, click in the “Condition” input
box and type the desired expression.
Be aware that all three of the tabs create a single conditional
expression (each is just a different method of creating an
expression). Entering something on one tab will create new
text (visible in the “Condition” text box) that will overwrite
anything that might have been previously entered using a
different tab., i.e. if you create a filter in the Advanced
tab, the filter settings will be overwritten if you then use the
Quick tab to modify these settings.
Note: If you go from less advanced to more, you retain the settings. If you go from more to less, you lose the settings!
Applying Filters
After the desired filters have been added to the Filter Library, it is then possible to apply the filters to specific network ports. The
method of applying filters varies slightly for each available platform type; however, in all cases, the application of filters is done
in conjunction with mapping network inputs to monitor outputs (selective aggregation), as well as other traffic distribution options
such as load balancing.
Frequently Asked Questions
How do I specify an IP range filter?
For the v2 platform, an IP range filter is specified by using a hyphen between the range’s start and end IP addresses:
IP destination 192.168.0.200-192.168.10.250
In the v3 platform, an IP range filter is specified using a mask:
IP destination 192.168.0.0 mask 255.255.255.0
The above expression would filter all IP addresses including and between 192.168.0.0 and 122.168.0.255.
I only want to see RTP traffic. How do I filter for this?
The easiest method to filter RTP would be to find out the UDP port range used by your particular network for RTP packets.
This can vary, but typically, the following port numbers apply:
TCP/UDP 8000-65355 where RTCP port = RTP port + 1
Another method for filtering RTP would be to create a custom filter that defines RTP traffic by the type of payload associated with
that packet. For example, to filter RTP with payload type 20:
udp offset 10 14 mask 7f
How do I create a filter for VoIP traffic?
VoIP traffic is application dependent so methods of filtering this traffic will vary. Typically, VoIP traffic would be defined by
TCP/UDP port, RTP payload type (custom filter), and/or other protocol type e.g. SIP (custom filter).
How do I apply a filter to GTP tunneled traffic?
The GTP Tunneling Protocol is encapsulated within UDP, using the fixed UDP port number 2152. The GTP header follows the UDP
header, and following the GTP header is the user’s original IP datagram.
6
As GTP headers are variable in length, it is not possible to create any single filter which under all conditions can examine
the contents of the encapsulated user IP datagram. In order to accomplish this, the user needs to know the length of the GTP
header being used in his/her application, and adjust the filter accordingly.
The below example assumes the GTP header is 12 bytes in length.
The following expression will filter just GTP packets (IP protocol UDP dest port = 2152):
ip protocol 17 and udp destination port 2152
The GTP header begins at offset 8 from the start of the UDP header (since the UDP header is 8 bytes long) so:
udp offset 8
will point to the GTP header. If we assume a 12-byte GTP header then:
udp offset 20
will point to the start of the user’s encapsulated IP datagram.
The IP source address is found at offset 12 within an IP header. Therefore, the following will point to the IP source address
within the GTP user’s encapsulated datagram:
udp offset 32
Combine the above as desired to create a complete filter expression, e.g. to filter user’s IP source address 1.2.3.4
(hex 01020304):
ip protocol 17 and udp destination port 2152 and udp offset 32 01020304
or to filter user’s IP destination address 5.6.7.8 (hex 05060708):
ip protocol 17 and udp destination port 2152 and udp offset 36 05060708
An optional “mask” parameter can also be specified following the “offset” custom packet field, to include/exclude individual
bits/nibbles/bytes within the field. So, this could be used if it was desired to filter on a particular user’s encapsulated subnet,
e.g. assuming a subnet mask of 255.255.255.0., then user subnet 1.3.6/ could be filtered with:
ip protocol 17 and udp destination port 2152 and udp offset 32 010306 mask fffffc
If desired, the above could be made more specific/complex to filter, for example, traffic only to a specific GTP destination,
e.g. 192.168.10.250:
ip destination 192.168.0.250 and ip protocol 17 and udp destination port 2152 and udp offset 36
05060708
Note: All of the above-defined filters may (depending on the network traffic) result in some additional packets passing the filter (which could simply be ignored
in the monitor output stream), e.g., if there is any other kind of traffic carried on UDP port 2152.
For more information please contact us at info@vssmonitoring.com
VSS Monitoring is a world leader in network packet brokers (NPB), providing a visionary, unique systems approach to integrating
network switching and the broad ecosystem of network analytics, security, and monitoring tools.
VSS Monitoring, the VSS Monitoring logo, vBroker Series, Distributed Series, vProtector Series, Finder Series, TAP Series, vMC, vAssure,
LinkSafe, vStack+, vMesh, vSlice, vCapacity, vSpool, vNetConnect and PowerSafe are trademarks of VSS Monitoring, Inc. in the United
States and other countries. Any other trademarks contained herein are the property of their respective owners.
www.vssmonitoring.com
© Copyright 2003 – 2014. VSS Monitoring Inc. All rights reserved.
1200-20110127.0920r-001