About TAP Aggregation
Network TAPs
You can use various methods to monitor packets. One method uses physical hardware test access points (TAPs).
Network TAPs can be extremely useful in monitoring traffic because they provide direct inline access to data that flows through the network. In many cases, a third party monitors the traffic between two points in the network. If the network between points A and B consists of a physical cable, a network TAP might be the best way to accomplish this monitoring. The network TAP has at least three ports: an A port, a B port, and a monitor port. A TAP inserted between the A and B ports passes all traffic through unimpeded, but it also copies that same data to its monitor port, which could enable a third party to listen.
TAPs have the following benefits:
-
They can handle full-duplex data transmission.
-
They are unobtrusive and not detectable by the network (with no physical or logical addressing).
-
Some TAPs support full inline power with the capability to build a distributed TAP.
If you are trying to gain visibility into the server-to-server data communication at the edge or virtual edge of your network or to provide a copy of traffic to the Intrusion Prevention System (IPS) appliance at the Internet edge of your network, you can use network TAPs nearly anywhere in the environment. However, this deployment can add significant costs, operation complexities, and cabling challenges in a large-scale environment.
TAP Aggregation
TAP aggregation is an alternative solution to help with monitoring and troubleshooting tasks in the data center. It works by designating a device to allow the aggregation of multiple test access points (TAPs) and to connect to multiple monitoring systems. TAP aggregation switches link all of the monitoring devices to specific points in the network fabric that handle the packets that need to be observed.
In the TAP aggregation switch solution, a Cisco Nexus 9000 Series switch is connected to various points in the network at which packet monitoring is advantageous. From each network element, you can use switched port analyzer (SPAN) ports or optical TAPs to send traffic flows directly to this TAP aggregation switch. The TAP aggregation switch is directly connected to all of the analysis tools used to monitor the events in the network fabric. These monitoring devices include remote monitor (RMON) probes, application firewalls, IPS devices, and packet sniffer tools.
You can configure the TAP aggregation switch to filter specific traffic and redirect it to one or more tools. In order to redirect the traffic to multiple interfaces, a multicast group is created internally on the switch, and the interfaces that are part of the redirect list are added as member ports. When an access control list (ACL) policy with the redirect action is applied to an interface, the traffic matching the ACL rule is redirected to the internal multicast group that is created.
Guidelines and Limitations for TAP Aggregation
Note |
For scale information, see the release-specific Cisco Nexus 9000 Series NX-OS Verified Scalability Guide. |
TAP aggregation has the following guidelines and limitations:
-
TAP aggregation:
-
Supported on all Cisco Nexus 9000 Series switches and the 3164Q, 31128PQ, 3232C, and 3264Q switches.
-
Supported on 100G ports.
-
Supports only on switch ports and only in the ingress direction.
-
Supports IPv4 ACLs with UDF-based match for Cisco Nexus 9200, 9300, and 9300-EX Series switches.
-
Supported on Cisco Nexus 9300-FX, 9300-FX2, 9300-FX3, 9300-GX, 9300-GX2, 9500-EX, and 9500-FX platform switches.
-
Maximum redirect ports supported are 32 interfaces.
-
-
Beginning with Cisco NX-OS Release 9.2(1), TAP aggregation filters on MPLS tags are supported on the following Cisco Nexus platform switches:
-
Cisco Nexus 9000 platform switches, including the 9700-EX and 9700-FX line cards.
-
Cisco Nexus 9200 platform switches.
-
Cisco Nexus 9300 platform switches.
-
Cisco Nexus 9500 switches.
-
-
TAP aggregation filters on MPLS tags are not supported on the following Cisco Nexus Series switches, line cards, and fabric modules:
Table 1. Cisco Nexus 9000 Series Switches Cisco Nexus 3164Q-40GE
Cisco Nexus 9372PX
Cisco Nexus 9372PX-E
Cisco Nexus 9372TX
Cisco Nexus 9372TX-E
Cisco Nexus 9332PQ
Cisco Nexus 3232C
Cisco Nexus 93120TX
Cisco Nexus 31128PQ
Cisco Nexus 3264Q-S
—
—
Table 2. Cisco Nexus 9000 Series Line Cards and Fabric Modules N9K-M6PQ
N9K-X9632PC-QSFP100
N9K-X9536PQ
N9K-X9432C-S
N9K-C93128TX
N9K-C9396PX
N9K-X9432PQ
N9K-X9464TX
—
-
Cisco Nexus 9700-EX and 9700-FX line cards support TAP aggregation with IPv4, IPv6, and MAC ACLs.
-
Only Layer 2 interfaces support the TAP aggregation policy. You can apply the policy to a Layer 3 interface, but the policy becomes nonfunctional.
-
The redirect port must be part of the same VLAN as the source (TAP) port.
-
Each rule must be associated with only one unique match criterion.
-
When you enter a list of interfaces for the TAP aggregation policy, you must separate them with commas but no spaces. For example, port-channel50, ethernet1/12, port-channel20.
-
When you specify target interfaces in a policy, make sure that you enter the whole interface type and not an abbreviated version. For example, make sure that you enter ethernet1/1 instead of eth1/1 and port-channel50 instead of po50.
-
HTTP requests with tcp-option-length and VLAN ID filters simultaneously are not supported. Traffic match against ACE may not work if you configure both filters at a time.
-
When configuring ACL entries with redirect to port-channels that are yet to be configured, the user must take care to configure the specified port-channels at a later point of time.
-
To allow double VLAN tags on ingress interface, the switchport trunk allow-multi-tag command must be configured correctly as mentioned below:
-
On Cisco Nexus 9300-FX2 switches, this command must be used only if NDB is configured.
-
On Cisco Nexus 9300-GX/GX2 switches, this command is not required if NDB is configured.
-