Advanced Mirroring Features

eos.arista.com/eos-4-20-1f/advanced-mirroring-features

By Michael (Mike) Fink

This article describes various advanced mirroring features.

Filtered Mirroring
Mirroring to Gre
Sampled Mirroring
Rate Limiting of Mirrored Traffic
Mirroring and sFlow
Mirroring Truncation
Mirroring to Port-Channel

Contents [hide]

Filtered Mirroring
Current Behavior
Overview
Platform compatibility
Configuration
Status
Show Commands
Syslog Messages
Troubleshooting
Filtered Mirroring does not work
Troubleshooting Mirroring ACL with UDFs
Limitations
DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R,
and DCS-7500R2 Features and Limitations
Enabling Filtered Mirroring
User Defined TCAM Profiles
Source Interface in Multiple Sessions
Priorities
TCAM Utilization
UDF Constraints
Forwarding Behaviour of Mirrored Traffic
Mirrored traffic and egress ACLs
DCS-7010T, DCS-7050/7050X, DCS-7060X, DCS-7250X, DCS-7260X,
DCS-7300X Features and Limitations
Other Platform Limitations
MAC ACL limitations
Change Log
Mirroring To GRE
Current Behavior
1/30
 Overview
Platform Compatibility
Configuration
DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-
7500R, and DCS-7500R2 Advanced Features
GRE Payload Type
Configuration
Encapsulation of Non-routed Packets
GRE Key Metadata
Egress Port Metadata
Configuration
Status
Show Commands
Syslog Messages
Troubleshooting
Mirroring to GRE Tunnel does not work
Limitations
DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R and
DCS-7500R2 Features and Limitations
ECMP Semantics
Forwarding Behavior of Mirrored Traffic
Priority of mirrored packets
Resource Limitations
TTL and DSCP limits
Other Platform Limitations
SVIs
Change Log
Sampled Mirroring
Rate Limiting of Mirrored Traffic
Current Behavior
Overview
Configuration
Syslog Messages
DCS-7280R, DCS-7280R2, DCS-7280E, DCS-7500R, DCS-7500R2,
and DCS-7500E Features and Limitations
Enabling Rate Limiting
Profile Limitations
Rate is per Ingress Core per Session
Mirroring to GRE Rate Limit
DCS-7050X, DCS-7060X, DCS-7250X, DCS-7260X, DCS-7300X
Features and Limitations
Rate is per egress chip
Mirroring to GRE Rate Limit
Troubleshooting
Change Log
Mirroring and sFlow
2/30
 Current Behavior
Overview
Platform Compatibility
Configuration
DCS-7280R, DCS-7280R2, DCS-7280E, DCS-7500R, DCS-7500R2,
and DCS-7500E Features and Limitations
Some Packet Types No Longer Sampled by sFlow
Feature Compatibility
Change Log
Mirroring Truncation
Current Behavior
Overview
Platform Compatibility
Configuration
Status
Show Commands
Platform Independent
Syslog Messages
DCS-7280R, DCS-7280R2, DCS-7500R, DCS-7500R2 Features and
Limitations
Nominal Truncation Size
GRE Encapsulation
Change Log
Mirroring to Port-Channel
Current Behavior
Overview
Platform Compatibility
Configuration

Filtered Mirroring

Current Behavior

Overview
Filtered Mirroring allows certain packets to be selected for mirroring, rather than all packets
ingressing or egressing a particular port.

Platform compatibility
DCS-7010T, DCS-7050X, DCS-7060X, DCS-7250X, DCS-7260X, DCS-7300X, DCS-
7280E, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R, DCS-7500R2, and DCS-
7020 are supported.

Configuration

3/30
Note: To use this feature on the DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2,
DCS-7500R and DCS-7500R2 series, a platform configuration may be required to enable
the mirroring ACL profile. See the platform-specific section for instructions.

Filtered mirroring is configured by creating an IPv4, IPv6 or MAC access-list and then
attaching it to a monitor session. For example:

Arista(config)#ip access-list acl1

Arista(config-acl-acl1)#10 permit tcp any any rst
Arista(config-acl-acl1)#20 permit tcp any any syn
Arista(config-acl-acl1)#30 permit tcp any any ack

Arista(config)#monitor session 1 source Ethernet1 rx ip access-group acl1

Arista(config)#monitor session 1 source Ethernet2 rx ip access-group acl1
Arista(config)#monitor session 1 destination Ethernet3

Arista(config)#ipv6 access-list acl2

Arista(config-ipv6-acl-acl2)#10 permit ipv6 any any

Arista(config)#monitor session 2 source Ethernet4 rx ipv6 access-group acl2

Arista(config)#monitor session 2 destination Ethernet5

Possible destinations are CPU, Ethernet ports, Port-Channels, and Tunnel interfaces:

Arista(config)#monitor session 1 destination ?

Cpu Cpu port(s)
Ethernet hardware Ethernet interface
Port-Channel Lag interface
tunnel tunnel keyword

For details on how to use a monitoring session to CPU please refer to the followingTOI.

All standard IPv4 and MAC qualifiers are supported. Support for IPv6 access-lists is
included as of the 4.18.4 release. Packets matching permit statements within the access-
list will be mirrored. Packets matching deny statements will typically not be mirrored, unless
the packet matches both an IP and MAC access-list. More on this below.

Contrary to normal port mirroring, it is possible for the same monitor source to appear in
multiple monitor sessions, provided that access-lists are used in each such session. For
example:

Arista(config)#monitor session 1 source Ethernet1 rx ip access-group acl1

Arista(config)#monitor session 1 destination Ethernet2

Arista(config)#monitor session 2 source Ethernet1 rx ip access-group acl2

Arista(config)#monitor session 2 destination Ethernet3

The behaviour of such single-source multiple-session configuration varies between the

supported platforms.

On the DCS-7010T, DCS-7050/7050X, DCS-7060X, DCS-7250X, DCS-7260X, and DCS-

7300X series, multiple mirrored copies will be generated and forwarded to the relevant
destinations.

4/30
On the DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R and DCS-
7500R2 series, only one mirrored copy will be generated. Access-list priorities are used to
dictate the matching order across multiple access-lists attached to the same monitor
source. For example:

Arista(config)#monitor session 1 source Ethernet1 rx ip access-group acl1 priority

10
Arista(config)#monitor session 1 destination Ethernet2

Arista(config)#monitor session 2 source Ethernet1 rx ip access-group acl2 priority

20
Arista(config)#monitor session 2 destination Ethernet3

As with access-list entries (10, 20, 30), a lower priority number denotes a higher priority.
For Ethernet1 in the example above, acl1 will be looked-up before acl2. If a permit or deny
match occurs in acl1, acl2 will not be looked up. One way to think about access-list
priorities is that all access-lists for a given monitor source are implicitly combined into a
single aggregate access-list as follows:

The entries in the aggregate access-list will be looked up sequentially and only the first
match will take effect.

A given monitor session may include multiple monitor sources, with independent access-
lists (and independent priorities in the case of DCS-7280SE, DCS-7500E, DCS-7280R,
DCS-7280R2, DCS-7500R and DCS-7500R2). For example:

Arista(config)#monitor session 1 source Ethernet1 rx ip access-group acl1 priority

10
Arista(config)#monitor session 1 source Ethernet2 rx ip access-group acl1 priority
30
Arista(config)#monitor session 1 destination Ethernet3

It is possible to specify both an IPv4 and a MAC access-list for the same monitor source,
but these must appear in different monitor sessions. A given monitor session must contain
only one access-list type.

Arista(config)#monitor session 1 source Ethernet1 rx ip access-group acl1

Arista(config)#monitor session 1 destination Ethernet2

Arista(config)#monitor session 2 source Ethernet1 rx mac access-group acl2

Arista(config)#monitor session 2 destination Ethernet3

5/30
On the DCS-7010T, DCS-7050/7050X, DCS-7060X, DCS-7250X, DCS-7260X, and DCS-
7300X series, when a packet matches an entry in both access-list types, two mirrored
copies will be generated and forwarded to their respective destinations.

On the DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R, and DCS-

7500R2 series, only one mirrored copy will be generated. The following tie-breaking logic
used when a packet matches an entry in both access-list types:

If one of the matched entries is a permit and the other is a deny, the permit wins.
If both matched entries are permit entries, the MAC access-list wins.
If both matched entries are deny entries, the packet is not mirrored.

Filtered Mirroring access-lists also support User-defined Field (UDF) qualifiers. This adds
the ability to match packets using arbitrary user-defined patterns. UDFs are configured as
follows:

Arista(config)#ip access-list ipAcl1

Arista(config-acl-ipAcl1)#permit ip any any payload header [start|end] offset
<offset> pattern <patternVal> mask <maskVal>

The header keyword denotes whether the offset should begin from the start or end of the IP
header. This keyword is supported only for IP access-lists. If not specified, the offset begins
at the end of the IP header. For MAC access-lists the offset will always begin at the end of
the Ethernet header.

The offset keyword specifies an offset in 4-byte units from the base established by the
above.

The pattern keyword specifies a 4-byte hexadecimal pattern.

The mask keyword specifies a 4-byte hexadecimal mask applied to the pattern.

Here are some examples:

Arista(config-acl-ipAcl1)#10 permit ip any any payload header end offset 3 pattern

0xabcd0000 mask 0x0000ffff

This will match a 2-byte pattern, 0xabcd, beginning at byte 12 following the end of the IP
header.

Arista(config-acl-ipAcl1)#20 permit ip any any payload header start offset 5 pattern

0xdeadbeef mask 0x00000000

This will match a 4-byte pattern, 0xdeadbeef, beginning at byte 20 following the start of the
IP header.

Status

Show Commands
Platform Independent

6/30
The show monitor session command may be used to examine the status of mirroring
sessions, including Filtered Mirroring and Mirroring to GRE sessions. Here is an example of
a session using both of these features:

Arista#show monitor session 1

Session 1
------------------------
Source Ports:
Rx Only: Po10(ip Acl: Acl1 [ prio 10 ])
Rx Only: Et4/4(ip Acl: Acl1 [ prio 10 ])

Destination Ports:
status source dest ttl dscp proto fwd-drop
Destination Ports:
Et4/5 : active

The Source Ports section lists the ports on which mirroring is enabled (Port-Channel 10
and Ethernet 4/4). Mirroring is enabled in the RX (ingress) direction, an IP access-list Acl1
is applied to both sources with priority 10. (Reminder: priorities only apply to the DCS-
7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R and DCS-7500R2 series.)

The Destination Ports section outlines the destination information. The active keyword
indicates that this destination is in effect.

DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R, DCS-7500R2

Arista#show platform fap acl tcam summary

The output of this command displays for each forwarding ASIC the number of TCAM
entries consumed per ACL type, and in which TCAM bank the entries are installed. A
mirroring ACL will not consume TCAM resources unless it is attached to a mirroring source
interface, and a mirroring destination is configured. If the mirroring destination is a GRE
tunnel, at least one nexthop entry for the tunnel destination must be resolved before a
TCAM entry is installed.

Sample output:

========================================================
Arad0:
========================================================
Bank Used Used % Used By
0, 1 2 0 IP Mirroring
Total Number of TCAM lines used is: 4
========================================================
Arad1:
========================================================
Bank Used Used % Used By
2 1 0 Mac Mirroring

In the sample output, three TCAM entries are consumed across two forwarding ASICs, two
for IP ACLs and one for MAC ACLs.

Arista#show platform fap acl mirroring

7/30
The output of this command displays at a glance all installed mirroring ACLs. If a single
source interface is used in multiple monitor sessions, the command lists the components of
all internal aggregate ACLs and their respective priorities.

Sample output:

==============
Aggregate ACLs
==============

(list2:0->2) type=2; version=0

- list2 [ prio 0 ] => session 2

(list1:10->1,list3:20->3) type=0; version=13

- list3 [ prio 20 ] => session 3
- list1 [ prio 10 ] => session 1

======================
Interface-ACL Mapping
======================

Ethernet1 => (list1:10->1,list3:20->3) [ ipv4 ]

Ethernet33 => (list2:0->2) [ mac ]

In the sample output, three mirroring ACLs are configured: two IPv4 ACLs and one MAC
ACL. The two IPv4 ACLs, list1 and list3, are attached to the same mirror source interface,
Ethernet1. The resulting aggregate is represented as list1:10->1,list3:20->3.

DCS-7010T, DCS-7050/7050X, DCS-7060X, DCS-7250X, DCS-7260X, DCS-7300X

The following platform command can be used to display the mirroring parameters
programmed in the switch ASIC for all the configured mirror sessions. The displayed
information include the source and destination interfaces, mirroring ACLs (if any), and next-
hop MAC (in case of GRE Tunnel destinations).

Arista#show platform trident mirroring

Sample output:

Session SrcIntf Acl DestIntf NextHopMac OutIntf

====== ====== ==== ======= ========== =======

mir-sess1 Et16/1(rx) Gre1 00:1c:73:5b:a4:84 Et25/1

00:1c:73:5b:a4:84 Et23/1
00:1c:73:5b:a4:84 Et25/4

mir-sess2 Et32/1(rx) mirAcl2 Gre2 00:1c:73:5b:e5:1a Et21/1

00:1c:73:5b:e5:1a Et22/1

The following platform command can be used to list various mirroring ACLs that are
programmed in the switch ASIC. The displayed information include the corresponding
mirror session names, ACL names, and source interfaces.

Arista#show platform trident tcam mirror [detail]

8/30
Sample output:

=== Mirroring ACLs on switch Linecard0/0 ===

Session: mir-sess2

INGRESS ACL mirAcl2* uses 2 entries

Assigned to ports: Ethernet32/1

With the detail keyword, the output of this command lists each entry in the mirroring ACLs,
as well as, other details like its entry ID, qualifier fields, actions, and its hit count. Sample
output:

=== Mirroring ACLs on switch Linecard0/0 ===

Session: mir-sess2

=== INGRESS ACL mirAcl2* uses 2 entries ===

Assigned to ports: Ethernet32/1

Id | Seq | Proto | Src IP | Src Mask | Src Port |Hits
DSCP | Frag | Flags | Dest IP | Dest Mask | Dest Port |Action
-----------------------------------------------------------------------
2070 |5 | 0x04 | 175.175.175.2| *| *|8
| * | | 153.153.153.1| *| *|Mirror 1
2071 |10 | * | * | *| *|2
| * | | * | *| *|None

Syslog Messages

DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R, DCS-7500R2

SAND_MIRRORING_ACL_HW_RESOURCE_FULL/NORMAL

The full message indicates that the hardware resources are insufficient to program all
mirroring ACLs. The message may emit when attempting to attach an ACL to a mirror
source interface. The normal message will emit when all configured mirroring ACLs are
programmed in hardware.

SAND_MIRRORING_UDF_ACL_HW_RESOURCE_FULL/NORMAL

The full message indicates that the hardware resources are insufficient to program all
mirroring ACLs with UDFs. The message may emit when attempting to attach an ACL with
UDFs to a mirror source interface if the maximum number of UDF resources is exceeded.
The normal message will emit when all configured mirroring ACLs with UDFs are
programmed in hardware.

DCS-7010T, DCS-7050/7050X, DCS-7060X, DCS-7250X, DCS-7260X, DCS-7300X

STRATA_UDF_HW_RESOURCE_FULL/NORMAL

The full message indicates that the hardware resources are insufficient to program the
configured UDFs with mirroring ACLs. The normal message is generated when the switch
recovers and is able to successfully program all the configured UDFs with mirroring ACLs.
9/30
STRATA_MIRRORING_ACL_HW_RESOURCE_FULL/NORMAL

The full message indicates that hardware resources are insufficient to program the
configured mirroring ACLs. The normal message will be generated when the switch
recovers and is able to successfully program all the configured mirroring ACLs.

Troubleshooting
The first step is to verify that the mirror session and the ACLs are correctly configured and
programmed in the switch chips using the show commands. The next step is to check for
syslog messages, if any.

Additional troubleshooting steps for common scenarios are provided below.

Filtered Mirroring does not work

ACLs may not be programmed due to TCAM resource exhaustion. Check syslog
messages. On DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R
and DCS-7500R2, use show platform fap acl tcam summary command to find the
details about TCAM usage. On DCS-7010T, DCS-7050/7050X, DCS-7060X, DCS-
7250X, DCS-7260X, and DCS-7300X, use show platform trident tcam mirror
[detail] command.
On DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R and DCS-
7500R2, the hardware TCAM profile may be set to Default. The show hardware
tcam profile command gives the currently configured mode. It needs to be set to
mirroring-acl for Filtered Mirroring.

Troubleshooting Mirroring ACL with UDFs

It is a good practice to calculate the amount of UDF resources that the configuration
is going to consume. Each unique header start/end, offset, and mask combination
will consume a UDF resource. On DCS-7280SE, DCS-7500E, DCS-7280R, DCS-
7280R2, DCS-7500R and DCS-7500R2, the mask will determine if a 16b or a 32b
UDF resource is needed.
On DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R and DCS-
7500R2, the number of UDF resources supported are 2x32b IP, 4x16b IP, and 2x16b
MAC UDFs. Use show platform fap acl udf summary command to check the
availability of UDF resources. Please refer to UDF constraints listed in the DCS-
7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R and DCS-7500R2
Features and Limitations section for more information.
On DCS-7010T, DCS-7050/7050X, DCS-7060X, DCS-7250X, DCS-7260X, and
DCS-7300X, maximum of 32 bytes UDF per packet type (or per Ethertype) is
supported.

Limitations
Filtered Mirroring is supported only in the RX direction at this time.

Only one access-list type may be used per monitor session. That is, a given session may
contain only one of IPv4 or IPv6 or MAC access lists.
10/30
IPv6 access-lists are supported for Filtered Mirroring as of the 4.18.4 release.

Access lists are not supported on source interfaces in a forwarding drop session (supported
only on DCS-7010T, DCS-7050/7050X, DCS-7060X, DCS-7250X, DCS-7260X, DCS-
7300X).

Please refer to the DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R

and DCS-7500R2 Features and Limitations section for more platform-specific
limitations on these platforms.

Please refer to the DCS-7010T, DCS-7050/7050X, DCS-7060X, DCS-7250X, DCS-

7260X, DCS-7300X Features and Limitations section for more platform-specific
limitations on these platforms.

DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R, and

DCS-7500R2 Features and Limitations

Enabling Filtered Mirroring

In order to conserve hardware resources, only IPv4 filtered mirroring on standard fields is
enabled by default. On older EOS releases, filtered mirroring is disabled by default. To
enable support for matching on MAC, IPv6, and user-defined fields, the following config-
mode command to enable the “Mirroring ACL” profile is required.

Arista(config)#hardware tcam profile mirroring-acl

The table below shows the types of matching supported in the default and Mirroring ACL
profiles:

Profile IPv4 IPv6 MAC UDF

default YES NO NO NO

mirroring-acl YES YES YES YES

IPv4: src IP, dst IP, dscp, protocol, l4 src port, l4 dst port, tcp control flags, fragment flags

IPv6: src IP, dst IP, traffic class, l4 src port, l4 dst port, protocol, tcp control flags

MAC: src addr, dst addr, ethertype

UDF: arbitrary 16 or 32 bit pattern within first 128B of packet.

Enabling the mirroring-acl profile will cause the SandAcl and SandTcam agents to restart.
The restart of these agents does not impact traffic through the switch. The outcome of the
profile change can be monitored using the show hardware tcam profile command.

Arista#show hardware tcam profile

Configuration Status
Linecard4 Mirroring-ACL Mirroring-ACL
Linecard3 Mirroring-ACL Mirroring-ACL
Linecard6 Mirroring-ACL Mirroring-ACL

11/30
Note: routed IPv4/IPv6 packets and bridged IPv6 packets are not subject to MAC mirroring-
ACLs.

The following features are not supported while the mirroring-acl profile is enabled:

VXLAN
MPLSoGRE Tunnel Termination
Tap Aggregation
Policy-based Routing
Security ACLs on IPv6 SVIs
MPLS Routing

User Defined TCAM Profiles

A user defined TCAM profile, a feature introduced in EOS 4.20.5f, may be used to extend
or modify the set of match criteria available in a mirroring-acl. The TOI for this feature can
be found here.

Below is an example of how to add support for matching on the outer VLAN ID in IP
mirroring-acls using a user defined TCAM profile:

Arista(config)#hardware tcam
Arista(config-hw-tcam)#profile vlan-match copy default
Arista(config-hw-tcam-profile-vlan-match)#feature mirror ip
Arista(config-hw-tcam-profile-vlan-match-feature-mirror-ip)#no key field tcp-control
Arista(config-hw-tcam-profile-vlan-match-feature-mirror-ip)#key field outer-vlan-id
Arista(config-hw-tcam-profile-vlan-match-feature-mirror-ip)#exit
Arista(config-hw-tcam-profile-vlan-match)#exit
Saving new profile ‘vlan-match’
Arista(config-hw-tcam)#system profile vlan-match
Arista(config-hw-tcam)#exit

Note in the example above the key field tcp-control had to be removed first before adding
outer-vlan-id. Most TCAM features are configured by default to use the maximum
available resources, so configuring a user defined TCAM profile often involves trade-offs.
In this example we have removed the capability to match on TCP flags in IP mirroring-acls
in order to gain support for matching on outer VLAN ID. User defined TCAM profiles are
generally reserved for special use cases and customers considering creating one should do
so in consultation with a TAC engineer.

Source Interface in Multiple Sessions

Priorities
Only one mirrored copy can be generated per source interface. Priorities will be used to
dictate the matching precedence across ACLs. Here is an example:

12/30
Arista(config)#monitor session session1 source et3/1 rx ip access-list IPACL1
priority 10
Arista(config)#monitor session session1 destination <dest1>

Arista(config)#monitor session session2 source et3/1 rx ip access-list IPACL2

priority 20
Arista(config)#monitor session session2 destination <dest2>

In case of overlapping ACLs, the priority will dictate which ACL will take effect. In this
scheme, a lower number will be treated as higher priority. E.g., prio=10 is higher priority
than prio=20.

Priorities will only take effect across ACLs of the same type. It is not possible to specify
relative priorities between different ACL types, e.g., between MAC and IP ACLs. Hence, the
priorities in the following example will not take effect:

Arista(config)#monitor session session1 source et3/1 rx mac access-list MACACL1

priority 10
Arista(config)#monitor session session1 destination et4/1

Arista(config)#monitor session session2 source et3/1 rx ip access-list IPACL1

priority 20
Arista(config)#monitor session session2 destination et5/1

If a MAC ACL and an IP ACL are configured on the same source interface, the MAC ACL
has higher priority.

TCAM Utilization

Attaching multiple ACLs to the same source interface will have an impact on TCAM
utilization. These ACLs will be internally flattened and combined into distinct sets of ACL
entries. Consider the following example:

Arista(config)#monitor session session1 source et3/1 rx ip access-list IPACL1

priority 10
Arista(config)#monitor session session2 source et3/1 rx ip access-list IPACL2
priority 20
Arista(config)#monitor session session3 source et3/2 rx ip access-list IPACL1
priority 10
Arista(config)#monitor session session4 source et3/3 rx ip access-list IPACL2
priority 20

In this case, the ACLs are associated to interfaces as follows:

Et3/1 => IPACL1, IPACL2

Et3/2 => IPACL1

Et3/3 => IPACL2

Assuming that IPACL1 and IPACL2 each consume 100 ACL entries, a total of 400 entries
will need to be programmed. However, other source interfaces on the same chip may share
IPACL1, IPACL2, and the IPACL1+IPACL2 combination without additional TCAM

13/30
expenditure, provided that they part of the same mirroring sessions and the same priority
values are used.

UDF Constraints

Several unique UDF qualifiers are supported per ACL type.

IPv4 : 4 x 16b + 2 x 32b

MAC : 2 x 16b

UDF qualifiers are treated as a global shared resource. They are allocated on-the-fly, per
ACL type, when unique header + offset combinations are encountered in the ACL
configuration. For example, the following two ACLs would allocate all the available IPv4
UDF resources:

Arista(config)#ip access-list ipacl1

Arista(config-acl-ipacl1)#10 permit ip any any payload header start offset 0 pattern
0xabcdabcd mask 0x00000000
Arista(config-acl-ipacl1)#20 permit ip any any payload header start offset 14
pattern 0xdeadbeef mask 0x00000000
Arista(config-acl-ipacl1)#30 permit ip any any payload header end offset 18 pattern
0x0000aaaa mask 0xffff0000

Arista(config)#ip access-list ipacl2

Arista(config-acl-ipacl2)#10 permit ip any any payload header end offset 25 pattern
0x0000abcd mask 0xffff0000
Arista(config-acl-ipacl2)#20 permit ip any any payload header end offset 32 pattern
0xab0000cd mask 0x00fffff00

ipacl1:10 and ipacl1:20 would each require a 32b UDF (if available) or 2 x 16b UDFs.

ipacl1:30 and ipacl2:10 would each require a 16b UDF.

ipacl2:20 would use the two remaining 16b UDFs (or a single 32b UDF if it were available).

At this point, all UDFs would be used up and it would no longer be possible to define new
header+offset combinations in IPv4 mirroring ACLs. However, it would still be possible to
reuse existing header+offset combinations with different patterns. For example:

Arista(config)#ip access-list ipacl3

Arista(config-acl-ipacl3)#10 permit ip any any payload header start offset 0 pattern
0xcdcdcdcd mask 0x00000000
Arista(config-acl-ipacl3)#20 permit ip any any payload header start offset 14
pattern 0xddeeddee mask 0x00000000
Arista(config-acl-ipacl3)#30 permit ip any any payload header end offset 18 pattern
0x0000bbbbb mask 0xffff0000
Arista(config-acl-ipacl3)#40 permit ip any any payload header end offset 25 pattern
0x0000ef12 mask 0xffff0000
Arista(config-acl-ipacl3)#50 permit ip any any payload header end offset 32 pattern
0xcd0000ef mask 0x00ffff00

When reusing UDFs in this manner, the mask must cover the same bytes. For example, if
the original mask is 0x0000ffff, the new rule could use 0x0000ffff, 0xf0f0ffff, etc., but not
0xffff0000 or 0x00ffff00.

14/30
Forwarding Behaviour of Mirrored Traffic
Mirrored traffic and egress ACLs
Mirrored traffic is not subject to egress ACLs. Mirrored packets going out an interface on
which an egress ACL is configured are not filtered.

DCS-7010T, DCS-7050/7050X, DCS-7060X, DCS-7250X, DCS-7260X,

DCS-7300X Features and Limitations
Each source interface may be active in at most one IPv6 monitor session. Adding a source
to an additional IPv6 session will result in that source being inactive in that session. When
the active session is removed from a source, one of the inactive sessions on that source
will become active.

IPv6 filtered mirroring is not supported on the DCS-7010T series.

Other Platform Limitations

MAC ACL limitations

MAC mirroring ACLs will not match routed IPv4/IPv6 packets or bridged IPv6 packets.

Change Log
4.15.3F – Initial release

Egress ACLs apply to mirrored packets

4.15.4F

Egress ACLs do not apply to mirrored packets

4.17.1F/4.16.7M/4.15.5F

Egress ACLs apply to mirrored packets

Support for IP mirror-acls in default TCAM profile (no UDFs)

4.18.1F

Egress ACLs do not apply to mirrored packets

4.18.4F

Support for IPv6 mirror-acls

4.20.5F

Support for DCS-7020

Mirroring To GRE

15/30
Current Behavior

Overview
Mirroring to GRE Tunnel allows mirrored packets to transit a L3 network using GRE
encapsulation.

Platform Compatibility
DCS-7010T, DCS-7050X, DCS-7060X, DCS-7250X, DCS-7260X, DCS-7300X, DCS-
7280E, DCS-7500E, DCS-7280R, DCS-7500R, DCS-7280R2, DCS-7500R2, and DCS-
7020 are supported.

Configuration
A mirroring to GRE destination can be configured as follows:

Arista(config)#monitor session 1 source <source> rx

Arista(config)#monitor session 1 destination tunnel mode gre
source <sourceIp>
destination <destIp>
[ ttl <value> ]
[ dscp <value> ]
[ protocol <value> ]
[ vrf <value> ]

The rx keyword specifies that incoming packets should be mirrored. Only ingress mirroring
is currently supported.

The tunnel keyword specifies that the destination is a tunnel. Only the GRE mode is
currently supported.

The source keyword specifies the IP address to use as the source IP in the outer IP header
of the GRE-encapsulated mirrored packet.

The destination keyword specifies the IP address to use as the destination IP in the outer
IP header of the GRE-encapsulated mirrored packet. The destination must be reachable.

The optional ttl keyword specifies the decimal TTL value to use in the outer IP header of
the GRE-encapsulated mirrored packet.

The optional dscp keyword specifies the decimal DSCP value to use in the outer IP header
of the GRE-encapsulated mirrored packet.

The optional protocol keyword specifies the hexadecimal protocol type value to use in the
GRE header of the GRE-encapsulated mirrored packet.

NOTE: Support to configure mirroring into GRE tunnel in a VRF was added in EOS release
4.20.6F

16/30
The option vrf keyword specifies the routing table to use for resolving the GRE destination.
Only interfaces added to the specified VRF can be selected as a mirror destination.
Omitting this keyword means the default VRF will be used.

Here is an example:

Arista(config)#monitor session abc source Ethernet1 rx

Arista(config)#monitor session abc destination tunnel mode gre source 1.1.1.1
destination 2.2.2.2 ttl 128 dscp 0 protocol 0x88be

On DCS-7010T, DCS-7050/7050X, DCS-7060X, DCS-7250X, DCS-7260X, DCS-7300X, a

special GRE tunnel destination is supported to mirror ingress packets that are dropped
during ASIC forwarding. This GRE destination is referred as the “forwarding-drop”
destination, and the corresponding session is called as the “forwarding-drop” session. A
forwarding-drop session is configured by using the forwarding-drop keyword when
configuring the GRE destination:

Arista(config)#monitor session 1 source <source>

Arista(config)#monitor session 1 forwarding-drop destination tunnel mode gre
source <sourceIp>
destination <destIp>
[ ttl <value> ]
[ dscp <value> ]
[ protocol <value> ]
[ vrf <value> ]

DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R, and DCS-

7500R2 Advanced Features
GRE Payload Type
For routed packets, a payload type may be configured that results in the inclusion or
exclusion of the terminated headers of the original packet in the mirrored packet for all
mirroring sessions. In the default behavior, the terminated headers (this frequently means
the L2 header) of the original packet are not included in the mirrored packet. The GRE
header in the mirrored packet is directly followed by the L3 header of the original packet.
To compensate for the lack of L2 information, the GRE key is, by default, populated with
the following metadata: 2-byte VLAN ID followed by a 2-byte ingress port ID. More on this
below.

Configuration
The GRE payload type can be configured as follows:

Arista(config)#monitor session default encapsulation gre payload <inner-packet|full-

packet>
Arista(config)#[no|default] monitor session default encapsulation gre payload

The default keyword after monitor session specifies that the setting will apply to all
mirroring sessions. Only default settings are currently supported.

The encapsulation keyword specifies that the setting applies to a type of encapsulation.
Only the GRE mode is currently supported via the gre keyword.

17/30
The payload keyword specifies the type of payload included in the GRE-encapsulated
mirrored packet.

The inner-packet keyword specifies that terminated headers are not included in the GRE-
encapsulated mirrored packet.

The full-packet keyword specifies that the complete original packet is included in the GRE-
encapsulated mirrored packet.

The no or default keyword specifies that the switch-default behavior should be used. This
is the inner-packet behavior for DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2,
DCS-7500R, and DCS-7500R2.

Encapsulation of Non-routed Packets

For non-routed packets (e.g., bridged packets or ARP), the L2 header of the original header
is preserved and included directly after the GRE header. The GRE key is also populated
with the configured metadata. More on this below.

GRE Key Metadata

On mirrored packets an 8-byte GRE header is located between the outer IPv4 header and
the inbound source packet. The lower 4-bytes of the GRE header contains the GRE key,
which encodes certain metadata about the inbound source packet. The contents of the
GRE key may be configured to provide additional information about the encapsulated
packet. The default behavior is as follows:

The lower two bytes of the GRE key contains the ingress port ID, a number that uniquely
identifies a physical port on the switch. For incoming bridged frames, the higher two bytes
of the GRE key is zero, whereas for incoming routed frames it contains the internal VLAN
ID of the ingress interface.

The GRE key metadata may also be configured to include the egress port in the upper two
bytes of the GRE key. The lower two bytes remain the ingress port ID.

Egress Port Metadata

For unicast IPv4 traffic that is forwarded via a physical port or a non-hardware LAG, it
contains the SysPhyPort, which can be mapped to an interface using the show platform fap
mapping command.

For unicast IPv4 traffic that is forwarded via a hardware LAG, it contains the Arad
SysPortAgg ID. Note, the SysPortAgg ID in the destination case only contains the LAG ID,
and not the member ID index, i.e., it is not possible to determine the particular LAG
member that distributed the packet.

Configuration
The GRE key metadata can be configured as follows:

Arista(config)#monitor session default encapsulation gre metadata <egress-

port|ingress-vlan> ingress-port
Arista(config)#[no|default] monitor session default encapsulation gre metadata

18/30
The default keyword after monitor session specifies that the setting will apply to all
mirroring sessions. Only default settings are currently supported.

The encapsulation keyword specifies that the setting applies to a type of encapsulation.
Only the GRE mode is currently supported via the gre keyword.

The metadata keyword specifies the information included in the GRE key of the GRE-
encapsulated mirrored packet.

The egress-port keyword specifies that the egress port ID is included in the higher two
bytes of the GRE key.

The ingress-vlan keyword specifies that the VLAN ID is included in the higher two bytes of
the GRE key.

The ingress-port keyword specifies that the ingress port ID is included in the lower two
bytes of the GRE key.

The no or default keyword specifies that the switch-default behavior should be used. This
is the ingress-vlan ingress-port behavior for DCS-7280SE, DCS-7500E, DCS-7280R,
DCS-7280R2, DCS-7500R, and DCS-7500R2.

Status

Show Commands
Platform Independent

The show monitor session [detail] command may be used to examine the status of
mirroring sessions, including Filtered Mirroring and Mirroring to GRE sessions. Here is an
example of a session using Mirroring to GRE:

Arista#show monitor session 1

Session 1
------------------------
Source Ports:
Rx Only: Et4/4

Destination Ports:
status source dest ttl dscp proto fwd-drop
Gre1 : active 100.100.100.1 200.200.200.1 128 0 0x88be no
next hop interfaces: Et4/10/1 Et4/10/2

The Source Ports section lists the ports on which mirroring is enabled (Ethernet 4/4).
Mirroring is enabled in the RX (ingress) direction.

The Destination Ports section outlines the destination information. As this is a Mirroring to
GRE session, the GRE tunnel status is displayed. The status field indicates that this
destination is in effect. The source, dest, ttl, dscp, and proto fields correspond to the

19/30
configured values. The fwd-drop field indicates whether this is a “forwarding-drop”
destination, a feature that is only supported on DCS-7010T, DCS-7050/7050X, DCS-
7250X, and DCS-7300X series.

The next hop interfaces row lists the physical ports that can reach the destination IP. This
may be a single routed port, the members of a routed LAG, or a set of ports in an ECMP
group. If no next-hop interfaces appear, the destination is not reachable and Mirroring to
GRE will not work.

With the detail keyword the GRE payload type and GRE key metadata is also displayed.
Here is an example:

Arista#show monitor session 1 detail

Session 1
------------------------
Source Ports:
Rx Only: Et4/4

Destination Ports:
status source dest ttl dscp proto fwd-drop
Gre1 : active 100.100.100.1 200.200.200.1 128 0 0x88be no
next hop interfaces: Et4/10/1 Et4/10/2

GRE Payload Type: inner-packet

GRE Key Metadata: ingress-port vlan

DCS-7010T, DCS-7050/7050X, DCS-7060X, DCS-7250X, DCS-7260X, DCS-7300X

The following platform command can be used to display the mirroring parameters
programmed in the switch ASIC for all the configured mirror sessions. The displayed
information include the source and destination interfaces, mirroring ACLs (if any), and next-
hop MAC (in case of GRE Tunnel destinations).

Arista#show platform trident mirroring

Sample output:

Session SrcIntf Acl DestIntf NextHopMac OutIntf

====== ====== ==== ======= ========== =======

mir-sess1 Et16/1(rx) Gre1 00:1c:73:5b:a4:84 Et25/1

00:1c:73:5b:a4:84 Et23/1
00:1c:73:5b:a4:84 Et25/4

mir-sess2 Et32/1(rx) mirAcl2 Gre2 00:1c:73:5b:e5:1a Et21/1

00:1c:73:5b:e5:1a Et22/1

DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R, DCS-7500R2

The following platform command can be used to display the mirror session information in
the switch ASIC. The displayed information includes the source and destination interfaces,
direction and probability factor (derived from the Cli configured sampling rate).

20/30
Arista#show platform fap mirroring

Sample output:

|-------------------------------------------------------------------------------------
----------|
| Mirroring Table
|
|-------------------------------------------------------------------------------------
----------|
| Source | Destination | Direction |
Probability Factor |
|-------------------------------------------------------------------------------------
----------|
| Ethernet3/1/2 | Ethernet3/1/1 | Ingress | 1
|
| Ethernet3/1/3 | Ethernet3/1/1 | Ingress | 1
|
| Ethernet3/2/2 | Ethernet3/2/1 | Ingress | 65534
|
| Ethernet3/2/2 | Ethernet3/2/1 | Egress |
|
| Ethernet3/2/3 | Ethernet3/2/1 | Ingress | 65534
|

Syslog Messages
DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R, DCS-7500R2

SAND_ROUTING_GRE_TUNNEL_RESOURCE_FULL/NORMAL

The full message indicates that the hardware resources are insufficient to program all GRE
tunnel entries. The message may emit when attempting to configure a GRE tunnel as a
mirror destination. The normal message will emit when a previously failed tunnel
destination is successfully programmed.

SAND_MIRRORING_LAG_HW_RESOURCE_FULL/NORMAL

The full message indicates that the hardware LAG resources are insufficient to program a
mirroring to GRE destination. The message may emit when the maximum number of LAGs
are configured prior to attempting to configure a mirroring to GRE session. The normal
message will emit when a previously failed monitor session is successfully programmed.

Troubleshooting
The first step is to verify that the mirror session and the ACLs are correctly configured and
programmed in the switch chips using the show commands. The next step is to check for
syslog messages, if any.

Additional troubleshooting steps for common scenarios are provided below.

Mirroring to GRE Tunnel does not work

21/30
Mirroring to GRE Tunnel requires reachability to the GRE destination. If no next-hop
interface appears under show monitor session <monitor-session> command output:

There may be no route present for the GRE destination, or the route is not resolved.
The show ip route command can be used to check the route reachability.
On DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R and DCS-
7500R2: There is a route but hardware egress encapsulation resource (EEDB)
utilization is high and because of this, a next-hop for mirroring session can’t be
programmed in hardware. The show hardware capacity command gives the detail
about the utilization of this hardware resource.

Limitations
Mirroring to GRE requires IP routing to be enabled.

Mirroring to GRE is supported only in the RX direction at this time.

Sub-interfaces are not supported as source interfaces.

A maximum of one forwarding drop session can be configured on the switch (supported
only on DCS-7010T, DCS-7050/7050X, DCS-7060X, DCS-7250X, DCS-7260X, DCS-
7300X).

Access lists are not supported on source interfaces in a forwarding drop session (supported
only on DCS-7010T, DCS-7050/7050X, DCS-7060X, DCS-7250X, DCS-7260X, DCS-
7300X).

DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R and

DCS-7500R2 Features and Limitations

ECMP Semantics

On the 7280SE, 7500E, 7280R, 7280R2, 7500R, and 7500R2 series, the hardware does
not natively support mirroring to ECMP. This places certain restrictions on how an ECMP
group may be constructed for Mirroring to GRE.

Only one port that can reach the GRE next-hop per switch chip for a given monitor
session.
If using LAGs to reach the next-hop, multiple members can reside on the same
switch chip and the LAG members can span across different switch chips, however a
given switch chip may not be shared with another port that can reach the GRE next-
hop for the same monitor session.
The total number of individual ports and LAG members in a monitor session is limited
by the current configured LAG width. E.g., 1024×16 can support up to 16 total ports.

Forwarding Behavior of Mirrored Traffic

Priority of mirrored packets

22/30
Traffic streams are assigned to queues based on their traffic class; traffic class 0 has
lowest priority. Mirrored packets are assigned the lowest priority to ensure that they are not
given precedence over other data streams with respect to queueing if network congestion
occurs.

Resource Limitations
TTL and DSCP limits
The TTL and DSCP fields in the outer IPv4 header of mirrored packets are configurable.
Across all monitor sessions, you can configure up to a maximum of four unique TTL values
and eight unique DSCP values. There are no restrictions on sharing TTL and DSCP values
between monitor sessions.

Other Platform Limitations

SVIs

A switch virtual interfaces (SVIs) cannot be specified as a mirror source interface.

Change Log
4.15.3f – Initial release

4.20.1f

Payload type and GRE key metadata added

4.20.5f

Support for DCS-7020 platform

4.21.0f

Support for configuring VRF on GRE destination

Support for sub-interface destinations.
Support for switch virtual interface (SVI) destinations.

Sampled Mirroring
The sampled mirroring TOI is here.

Rate Limiting of Mirrored Traffic

Current Behavior

Overview

23/30
Rate limiting of mirrored traffic provides support to control the rate of mirrored traffic that
can egress the switch. This feature can be applied to both regular port mirroring and
encapsulated mirroring (e.g., mirroring to GRE).

Configuration
Rate limiting can be configured per monitor session as follows:

Arista(config)#monitor session 1 rate-limit <per-ingress-chip|per-egress-chip>

<rate> [bps|kbps|mbps]

Arista(config)#no monitor session 1 rate-limit <per-ingress-chip|per-egress-chip>

The keyword rate-limit enables rate limiting for the configured monitor session.

The keyword per-ingress-chip|per-egress-chip specifies whether rate limiting is enforced

on ingress or egress switch chips. (On DCS-7280R, DCS-7280R2, DCS-7280E, DCS-
7500R, DCS-7500R2, and DCS-7500E, only per-ingress-chip is supported. On DCS-
7050X, DCS-7060X, DCS-7250X, DCS-7260X and DCS-7300X only per-egress-chip is
supported.) For example, if user configures per-ingress-chip 100 kbps rate limiting for one
mirroring session whose source (ingress) ports are distributed in 5 different chips, the traffic
to mirroring destination of this mirroring session could be 500 kbps at most. Similar rate
limiting enforcement will be applied to egress chips with destination ports if per-egress-
chip keyword is used for configuration.

The keyword no disables rate limiting for the configured monitor session.

Here is an example:

Arista(config)#monitor session abc source Ethernet1 rx

Arista(config)#monitor session abc destination Ethernet2

Arista(config)#monitor session abc rate-limit per-ingress-chip 50 mbps

Monitor session status:

Session abc
------------------------
Source Ports:
Rx Only: Et1
Destination Ports:
Et2 : active
Rate Limit per-ingress-chip : 50000000 bps

The Rate Limit section displays the limiting rate and the type of chip on which rate limiting
is enforced.

Syslog Messages
DCS-7280R, DCS-7280R2, DCS-7280E, DCS-7500R, DCS-7500R2, and DCS-7500E

SAND_MIRROR_RATE_LIMIT_INCOMPATIBLE

24/30
The full message indicates that two incompatible features are enabled at the same time.
The message may emit when attempting to configure rate limiting and an incompatible
feature at the same time. The following features are not supported when rate limiting is
enabled:

Qos acl-based policing; and

Storm Control.

DCS-7280R, DCS-7280R2, DCS-7280E, DCS-7500R, DCS-7500R2, and

DCS-7500E Features and Limitations

Enabling Rate Limiting

Rate limiting is only supported in the default and mirroring-acl profiles (see also Filtered
Mirroring – Limitations).

Rate limiting is only applied to RX traffic entering monitor source ports on which a mirroring
ACL is applied. Traffic entering monitor source ports with no mirroring ACL applied is not
subject to rate-limiting, nor will such traffic be considered when calculating the rate of
mirrored traffic associated with a monitor session.

It is recommended to ensure that all monitor sources in a session with rate-limiting enabled
have ACLs applied. Using a session-based ACL will automatically apply the ACL to all
monitor sources in the session. If no ACL filtering is required for a monitor session, you may
still enable rate limiting by attaching a session-based ACL with a single ‘permit ip any any’
rule.

Profile Limitations

The default TCAM profile provides support for IP mirroring ACLs without UDFs. The
mirroring-acl TCAM profile provides support for IP mirroring ACLs, MAC mirroring ACLs,
IPv6 mirroring ACLs, and UDFs.

Rate is per Ingress Core per Session

The configured rate limit of one mirroring session is applied to mirrored RX traffic in each
core in each ingress chip separately (e.g. DCS-7500R chips have dual cores). For
example, if a 100 kbps rate limiting is set for one mirroring session and its source ports are
distributed over five different cores, the traffic to the mirroring destination of this mirroring
session is limited to 500 kbps. Mapping information between ports and cores be found by
the command show platform fap mapping.

Mirroring to GRE Rate Limit

The rate limit is not adjusted for the overhead of GRE packet headers. The actual rate limit
is larger than the configured rate limit by the ratio between the egress mirroring to GRE
packet size and the ingress source packet size.

DCS-7050X, DCS-7060X, DCS-7250X, DCS-7260X, DCS-7300X Features

and Limitations
25/30
Rate is per egress chip

The configured rate limit is applied to each egress chip separately. For example, if a 100
kbps rate limit is set for a mirroring session and its mirror egress ports are distributed over
two different chips, the traffic to the mirroring destination is limited to 200 kbps.

Mirroring to GRE Rate Limit

The rate limit for mirroring to a GRE tunnel is applied to the GRE tunnel. If there are
multiple mirroring sessions sending to the same GRE tunnel (destination IP, source IP and
DHCP values all match), the rate limit on the tunnel will be set to the highest configured
rate for all sessions using that GRE tunnel, and all sessions will share the same rate limit.

Two GRE tunnels that differ only in TTL and/or protocol are treated as a single tunnel for
rate limiting purposes.

If there is a mirror session to a GRE tunnel with no rate limit configured, and another mirror
session to the same GRE tunnel that has a rate limit configured, the configured rate limit for
the second session will apply to both sessions on that tunnel.

Troubleshooting
The first step is to verify that the mirror session and the ACLs are correctly configured and
programmed in the switch chips using the show commands. The next step is to check for
syslog messages, if any.

On DCS-7280R, DCS-7280R2, DCS-7280E, DCS-7500R, DCS-7500R2, and DCS-7500E,

if rate limiting is not working correctly, please try the following:

1. Disable then re-enable rate limiting on the monitor session having issues;
2. Shutdown and restart the SandAcl agent;
3. Refer to the release notes for particular issues that may be relevant.

Change Log
4.18.3 – Initial release

Mirroring and sFlow

Current Behavior

Overview
An interface may be a source for both a mirroring session and sFlow at the same time.

Platform Compatibility
DCS-7280R, DCS-7280R2, DCS-7280E, DCS-7500R, DCS-7500R2, DCS-7500E, DCS-
7050X, DCS-7060X, DCS-7250X, DCS-7260X, and DCS-7300X are supported.
26/30
Configuration
There is no configuration for this feature.

DCS-7280R, DCS-7280R2, DCS-7280E, DCS-7500R, DCS-7500R2, and

DCS-7500E Features and Limitations

Some Packet Types No Longer Sampled by sFlow

When a port is a source for both a mirroring session and sFlow, certain packet types cannot
be sampled by sFlow. The following packet types are not sampled with mirroring and sFlow
that are sampled with only sFlow:

STP BPDUs
LACP frames
LLDP frames
OSPF packets
PIM HELLO packets
Packets dropped due to VLAN violations

Feature Compatibility

Mirroring and sFlow on the same source port is not compatible with TAP Aggregation
mode. When TAP Aggregation mode is enabled source ports configured as a source for
both a mirroring session and sFlow will only mirror packets; no sFlow samples will be
produced.

Change Log
4.18.4F- Initial release

Mirroring Truncation

Current Behavior

Overview
Mirrored packets may be truncated per mirroring session.

Platform Compatibility
DCS-7280R, DCS-7280R2, DCS-7500R, DCS-7500R2 are supported.

Configuration
Mirroring truncation can be configured per monitor session as follows:

Arista(config)#monitor session 1 truncation

Arista(config)#monitor session 1 truncation size [128|192]

27/30
The keyword no disables truncation for the configured monitor session.

Here is an example:

Arista(config)#monitor session abc source Ethernet1 rx

Arista(config)#monitor session abc destination Ethernet2

Arista(config)#monitor session abc truncation size 128

Status

Show Commands
Platform Independent
The show monitor session [detail] command may be used to examine the status of
mirroring sessions. Here is an example of the session configured above:

Arista#show monitor session abc

Session abc
------------------------
Source Ports:
Rx Only: Et1
Destination Ports:
Et2 : active
Truncation: active

Nominal truncation size in bytes: 128

The Truncation line displays whether truncation is active and the Nominal truncation line
displays the truncation size in bytes.

Syslog Messages
DCS-7280R, DCS-7280R2, DCS-7500R, DCS-7500R2

MIRRORING_TRUNCATION_NOT_SUPPORTED

This message applies to mixed systems where one or more system type is not supported.
The full message indicates that traffic on mirroring source ports residing on unsupported
forwarding chips will not be truncated.

DCS-7280R, DCS-7280R2, DCS-7500R, DCS-7500R2 Features and

Limitations

Nominal Truncation Size

Truncated packet sizes in mirroring sessions with truncation enabled will be smaller than
the nominal truncation sizes of 128 and 192 bytes. The labels represent the size category
rather than the actual packet size. Due to hardware limitations, the actual size of the
truncated packet may vary depending on the treatment of the original source packet. Users
can expect packet sizes ranging from 30 to 40 bytes smaller than the nominal truncation
size.
28/30
GRE Encapsulation

The truncation of mirror packets occurs before encapsulation. GRE encapsulation of mirror
packets will add an additional 30 to 40 bytes.

Change Log
4.19.2F – Initial release

Mirroring to Port-Channel

Current Behavior

Overview
A Port-Channel can be configured as a mirroring destination for both (tx, rx) source
directions. Traffic mirrored to a Port-Channel is load-balanced based on the global Port-
Channel load-balance configuration, which is the same for other Port-Channels.

Platform Compatibility
DCS-7010T, DCS-7050X, DCS-7060X, DCS-7250X, DCS-7260X, DCS-7300X, DCS-
7280E, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R, DCS-7500R2, and DCS-
7020 are supported.

Configuration

Arista(config)#monitor session 1 destination ?

Cpu Cpu port(s)
Ethernet hardware Ethernet interface
Port-Channel Lag interface
tunnel tunnel keyword

Arista(config)#monitor session 1 destination Port-Channel ?

$ end of range
<1-2000> Lag interface number

Arista(config)#monitor session 1 destination Port-Channel 1

Please note, even if a Port-Channel is not configured yet, you still can configure it as
mirroring destination, but its state is inactive.

Arista(config)#show port-channel 1
Port-Channel1 not configured as LAG

Arista(config)#show monitor session

Session 1
------------------------
Source Ports:
Destination Ports:
Po1 : ( inactive:Interface Mode Conflict )

29/30
When the Port-Channel is configured, it will become active:

Arista(config)#show port-channel
Port Channel Port-Channel1:
Active Ports: Ethernet1/1

Arista(config)#show monitor session

Session 1
------------------------
Source Ports:
Both: Et1/2
Destination Ports:
Po1 : active

30/30