• Tag : tap aggregation


TAP Aggregation: Traffic Steering to Nexthop Groups (GRE)

Description Traffic steering to nexthop groups allows specifying one or more nexthop groups as the destination for a TAP aggregation steering policy. Traffic steering is a TAP aggregation process that uses class maps and policy maps to direct data streams received on TAP ports. A nexthop group is a data structure that defines a list of nexthop addresses and a tunnel type for packets routed to the specified address. Platform Compatibility DCS-7280R3 DCS-7500R3 Linecards DCS-7800R3 Linecards Feature History Release Update 4.26.3 Initial introduction Configuration A nexthop group destination in a TAP aggregation steering policy can be configured as either a...
Continue reading →

Multiple Steering/Filtering Layers

Greetings, I’m using 7504R switch as tap aggregation mode, and want to steer/filter the traffic from tap ports to a tool ports based on source and destination IP addresses. As the list has more than 400+ subnets (example below), steering or filtering the traffic using policy-map or class-map within a policy-map, requires applying 20,000+ rule: 1- source:, destination: or or or 2- source:, destination: or or or 3- source:, destination: or or or 4- source:, destination: or or 5- source:,...
Continue reading →

Selective Packet Truncation in Tap Aggregation

Selective Packet Truncation in Tap Aggregation Packet Truncation in tap aggregation mode allows tapped traffic to be truncated to a smaller size before being transmitted. It can be used to reduce the amount of traffic received by analysis devices, if only the headers are to be analyzed while the payload of the packets is irrelevant or unwanted for practical or legal reasons. Truncation is applied either at the tap or tool port. This means that all traffic either arriving from a source or sent to a tool is subject to the truncation setting. In practice, it may be desirable to...
Continue reading →

TAP Aggregation – Traffic Steering to Match Inner Header Fields

Description Traffic steering is an existing Tap Aggregation feature that supports redirection of traffic based on configurable policy map rules. This article describes an extension to Tap Aggregation TCAM profiles that allows matching the inner header fields (either IPv4 or IPv6 inner fields) of encapsulated traffic. The following convention is adopted when describing an encapsulated traffic: <inner-protocol>-over-<outer-protocol>. For example, the IPv4-over-IPv6 packet indicates that the inner fields belong to IPv4 protocol and the outer fields belong to IPv6 protocol. Platform compatibility DCS-7280R/R2/R3 series DCS-7500R/R2/R3 series DCS-7020R series Supported packet types and inner header fields The types of traffic for which...
Continue reading →

Tap Aggregation and Mirror to GRE Timestamping in UTC Time Scale

Description Previously, Tap Aggregation and Mirror to GRE timestamping only supported timestamping packets in International Atomic Time ( TAI ). This release introduces a new feature on the Sand platform to allow for timestamping packets in UTC. UTC only differs from TAI by being behind by 37 leap seconds than TAI. Additional leap seconds will then be added or subtracted by the International Earth Rotation and Reference Systems Service ( IERS ) when needed. Generally, the PTP grandmaster propagates the leap second information downstream to all its slaves. For the Arista switch to know the number of leap seconds, this...
Continue reading →

TAP Aggregation – 80-Bit ACL Rule Support

Description TAP Aggregation traffic steering feature relies on access control list (ACL) rules to filter and match traffic. The creation of user-defined TCAM profiles is required to match some particular types of traffic with ACLs. User created TCAM profiles are defined by packet, key and action attributes. Packet and key defines the packet types and the header fields that apply to the selected features, action defines the action to perform on matched packets. Previously, we could only have key sizes of 160 or 320 bits. Not all types of ACL entries require such large key sizes and can actually fit...
Continue reading →

Arista LAG with TAP Aggregation

Hi All, I am planning to use the Arista Matrix switches in a LAG configuration to expand the ports for the Fiber TAP aggregation solution. But I would like to know how the Tool port and Tap port in a LAG group to be configured for TAP Aggregation.If switch 1 is connected to the Analyser. switch 2 needs to send the Aggregated traffic from the TAP ports to the the switch 1 using the LAG port group. How to configure the Port-channel for the correct TAP and Tool port group ?. Regards, Raj

Tap Aggregation traffic steering

Hello community,we are currently running a POC for TapAggregation at a customer site.They have a – in my opinion – quite simple requirement:– Traffic comes in from tap ports e1-e8– All traffic should leave tool port po25– A subset of the traffic – defined by an ACL – should also leave tool port po27 Now we have several issues:– An IP ACL on tool port po27 does not show any effect. I read that egress ACL might not be compatible with every platform so I guess that’s the reason (we use a 7280SE-64)– An IP ACL on the tap ports...
Continue reading →

Traffic Steering using User-Defined Fields

This article describes the TAP Aggregation User-Defined Fields feature. The purpose of the User-Defined Fields feature is to provide custom offset pattern matching to be used in TAP Aggregation Traffic Steering. This allows for deeper packet inspection of up to 128 bytes. User-Defined Fields, or UDFs, are defined as part of an access-list filter and are comprised of an offset, length and pattern match. This describes a single portion of any incoming packet to match the provided value upon. Access-list filters containing a UDF are then applied as usual as part of a TAP Aggregation Traffic Steering policy. UDFs may also be...
Continue reading →

TapAgg truncation

EOS-4.18.1F added truncation capability for Tap Aggregation, which allows tapped traffic to be truncated to a smaller size before being transmitted. It can be used to reduce the amount of traffic received by analysis devices, if only the headers are to be analyzed while the payload of the packets is irrelevant or unwanted for practical or legal reasons. An example could be the analysis of packets in a video streaming network where packets would typically have large payloads that are not necessarily useful for the analyzers. Packet truncation can be configured on tap or tool ports: Truncation configured on a...
Continue reading →

Packet Time Stamping on the 7500R/7280R/7500E/7280E

Time stamping is an important tool for network engineering and performance analysis. EOS-4.18.1F added header time stamping of all packets received on any tap interface in Tap Aggregation mode at line rate (only supported on the 7500R/7280R/7500E/7280E series). A timestamp is taken on ingress and then inserted in packet headers on egress. Time Synchronization and Time Keeping In order to have accurate time stamps, the system must be set up to synchronize its time keeping engine on the data plane to a master clock. Prior to 4.20.5F, the clocks used for time stamping are not synchronized with external sources. Beginning...
Continue reading →

Model validating PTP timestamping in a distributed Tap-Agg network

Abstract This is a test setup using common servers to validate PTP timestamping accuracy of Arista 7150 switches. Introduction Tap Aggregation devices are a growing monitoring model, allowing monitoring applications to analyze a huge set of data sources. In some application monitoring, it’s critical to correlate time to achieve high precision information, where we can measure the precise time in a packet path. For this purpose we have hardware time-stamping, a feature where the tap aggregation device stamp a time reference in each packet. This subject is explored in this article. Devices performing timestamp in packets must use a common...
Continue reading →

Understanding Deduplication in Tap Aggregation (NPB)

  1) What is deduplication ? Deduplication in the context of packet broker networks (Tap Aggregation) is the ability to detect duplicates of a packet, allowing only the first packet and dropping other iterations of the same packet.   2) Hardware impacts the Deduplication performance Deduplication, like many features, requires certain hardware characteristics to be supported by the silicon (network processor), which is the foundation of hardware packet processing and forwarding in networking/Ethernet equipment. It allows matching packet, manipulating, and making forwarding decisions in hardware.   2.1) Processing performance The Arista switches are based on high performance network processors of different...
Continue reading →

Deep Packet Inspection with Tap Aggregation

Introduction In this article we will focus on the Deep Packet Inspection access list enhancements available in Tap Aggregation Exclusive mode on the Arista 7150 series switches. Deep Packet Inspection (DPI) is an Access List enhancement that was introduced in EOS 4.14.0.F. This feature allows the administrator to inspect and match additional bytes in the packet header after the Layer 2, Layer 3 or Layer 4 header. DPI was designed to be utilized while in Tap Aggregation exclusive mode. Typical Use cases for DPI are: Identifying custom fields in Day zero attacks SLA Enforcement via identifying illegal content Behavioural targeting...
Continue reading →

DANZ Table of Contents

Tap Aggregation Introduction to Tap Aggregation Basic Use of Aggregation Groups Tab Aggregation Basic Settings Before You Start Filtering with Port ACLs Tap Aggregation VLAN List Filtering Tap Aggregation Traffic Steering Deep Packet Inspection Truncation on Tap and Tool Ports LLDP on Tap Ports Common Challenges with TapAgg TapAgg Glossary Advanced Mirroring Introduction to Port Mirroring Filtering with Port ACLs Latency Analyzer (LANZ) LANZ Architectures and Configuration LANZ Buffer Tuning Timestamping TimeStamping on the 7150 Timestamping Deep Dive and Frequent Questions Optics Tap Aggregation Optics Selection  

Data Analyzer (DANZ) Glossary

Access List (ACL) The switch configuration used for the purpose of filtering Layer 2, Layer 3, or Layer 4 traffic. See Filtering with Port ACLs Advanced Mirroring An Arista feature set which includes support for filtered, multi-destination mirroring, mirroring to EOS of data plane traffic, advanced load-sharing, and packet truncation.   Aggregation Group A configuration or grouping of Tap and Tool ports together where traffic from all Tap ports in a group will be replicated to all Tool ports in the same group.  A tool port can be a member of multiple aggregation groups whereas a tap port is allowed...
Continue reading →

DANZ Tap Aggregation – Filtering on inner Q-in-Q header, and stripping outer header – At the same time

  This article documents the ability, for the Arista 7150S in Tap Aggregation mode, to selectively filter on inner Q-in-Q header, and also strip the outer  header on egress, effectively allowing a granular selection of what Q-tagged traffic tools will be receiving. Let’s take as traffic example some Q-in-Q traffic: Outer Q-header (Eth-type 0x88a8) – STAG – VLAN ID = 100 Inner Q-header (Eth-type 0x8100) – CTAG – VLAN ID = 101, 102   Packet capture example for this Q-in-Q traffic:   7150S(config)#bash sudo tcpdump -nni mirror0 [...] 22:23:44.040896 00:ab:00:00:02:23 > 00:1c:73:86:00:69, ethertype 802.1Q-QinQ (0x88a8), length 1020: vlan 100, p...
Continue reading →

Basic Use of Aggregation Groups

Introduction Aggregation groups provide a means of grouping tool ports to simplify the mapping of a tap port to multiple tools and allow grouping of alike applications. In current releases, each tap port can only be bound to one default aggregation group at any time. A tool port however, can simultaneously be a member of multiple aggregation groups. This is important as it allows multiple tools or tool servers to receive any of the multiple traffic flows input to the tap ports. The Tap Aggregation operator can for example have an IDS/IPS tool receiving the same traffic as an application...
Continue reading →

Common challenges with TAP aggregation

Introduction Capturing raw network packet data, whether it be from a mirror port or through an aggregation infrastructure, is often perceived to be a complex task. In reality, most of the anomalies or limitations faced by those starting out with capture have simple explanations and are usually not due to problems with the source devices but instead the capturing tool. This article provides a brief of commonly reported issues and some suggested avenues of investigation. Timestamping Timestamps missing or corrupt Check timestamping is configured correctly to match the hosts’ expectations (i.e. is the host looking in the right place for...
Continue reading →


Get every new post on this blog delivered to your Inbox.

Join other followers: