Tag :: Tapagg

This article describes a feature for Tap Aggregation mode, which strips IEEE 802.1BR E-Tag and Cisco VN-Tag headers from all tagged packets received on tap interface before delivering them out of tool interfaces.

This feature enables Tap Aggregation generic header removal on a tap port.

This feature terminates GRE packets on a TapAgg switch by stripping the GRE header and then letting the decapped packets go through the normal TapAgg path. With this feature, we can use an L3 GRE tunnel to transit tapped traffic to the TapAgg switch over an L3 network. That would widely extend the available use cases for TapAgg.

This feature extends the capabilities of Tap Aggregation traffic steering to allow for using interface traffic policies. Initially, interface traffic policies only allowed packet drop, count, qos (set traffic class, set dscp) and log actions.

This article describes the TAP Aggregation 802.1Q (VLAN) tag stripping feature. This feature allows up to two of the outermost incoming 802.1Q tags to be stripped, and can be configured on a traffic steering policy or a tool port.

This article describes the Tap Aggregation MAC Address Replacement feature. This feature provides the ability to configure user-specific values to replace the destination and source MAC addresses of packets forwarded by Tap Aggregation.

Support for independently editing packets copied to multiple tool interfaces.

A Tap Aggregation steering policy can redirect and replicate incoming traffic streams, as well as apply various packet editing actions, e.g., VLAN identity tagging, MAC address rewrite, timestamping, header removal, etc.

This feature provides support for packet counters for Tap Aggregation on default forwarding, GRE tunnel termination, traffic steering based on policy map and traffic steering based on traffic policy (Aegis). For brevity, counters for policy-map traffic steering will be referred to as policy-map counters, and counters for traffic-policy traffic steering will be referred to as traffic-policy counters.

As of EOS-4.25.2F some advanced Tap Aggregation features require the hardware forwarding profile to be set. On EOS-4.25.2F these features are MPLS Pop and 802.1br-E/VN Tag Stripping.

Timestamping is an important tool for network engineering and performance analysis. The timestamp can be applied to a packet as either an inserted header or replacing the source MAC address of the original packet. Timestamps are recorded on ingress and applied on egress.

This article describes how QoS attributes are handled on tap ports as of EOS 4.20.5F. Prior to EOS 4.20.5F, QoS

As of EOS 4.21.0F, CLI commands can specify different TCAM profiles for different linecards in Tap Aggregation mixed

The Tap Aggregation timestamping feature supports both timestamping packets in TAI (International Atomic Time)

Tap aggregation traffic steering allows users to redirect traffic flows received on TAP interfaces based on configurable policy-map rules. This feature enables the ability to define policy-map rules that filter on IP header fields on the following Ethernet-over-MPLS packet types.

Internal recirculation interfaces, IR interfaces, can be used to internally loop-back packets for a second pass through the packet forwarding pipeline. This is particularly useful with Tap Aggregation because some combinations of advanced Tap Aggregation features cannot be simultaneously applied to a packet. Using an IR interface however, a user can apply multiple Tap Aggregation egress editing features, overcoming previous limitations.

In TAP Aggregation mode, configuration options are provided to handle special packet types. When receiving a packet whose Frame Check Sequence (FCS) is corrupted, the default behavior is to replace the bad FCS with the correct value and forward it. Configuration options are available to control the FCS behavior, such as to discard errors, pass through the bad FCS, or append a new FCS.

While in Tap Aggregation mode, we support traffic only in one direction through either Tap ports receiving packets