A typical multicast receiver expresses interest in a multicast stream by sending IGMP messages, the last hop router would then convert this IGMP to a PIM message and propagate upstream. As part of this feature when an IGMP message or PIM message is received in a VRF and there is a corresponding VRF leak configuration, the IGMP / PIM state is then leaked into the source VRF and processed only in the source VRF.

802.1X is an IEEE standard protocol that prevents unauthorized devices from gaining access to the network.

EOS 4.21.3F introduces support for BGP Flowspec, as defined in RFC5575 and RFC7674. The typical use case is to filter or redirect DDoS traffic on edge routers.

Bidirectional Protocol Independent Multicast (PIM) allows routers to build trees to deliver multicast traffic from sources to receivers. It is a variant of sparse-mode PIM that efficiently addresses the use case where receivers for a multicast group are also sources for that group.

PIM EOS 4.32.0F

This TOI describes a feature allowing packets that do not match any VLAN translations to be dropped from a port. This can be useful to drop selective Q-in-Q packets that do not receive a VLAN. The Configuration section details CLI commands used to configure the feature.

Link Flap Damping is a feature designed to detect situations when an interface is continuously flapping. If enough flaps are done, the damping mechanism is triggered temporarily holding the interface link-down. This smoothes out link flap occurrences and reduces churn in the network caused by link flaps.

Link Flap EOS 4.32.0F Damping Damp

ECMP Hash visibility CLI determines the output interface for an ECMP set based on the flow parameters supplied by the user. Ingress interface, source IP address, destination IP address and IP protocol are the required parameters. L4 source and destination ports and VLAN identifier are optional, but should be specified if the packet has them.

EosSdkRpc is an agent built on top of the Arista EOS SDK. It uses gRPC as a mechanism to provide remote access to the EOS SDK. The gRPC interface that EosSdkRpc supports closely matches the interface provided by EOS SDK, and the intent is that the .proto interface can be publicly supported. EosSdkRpc allows for remote access and using protobuf to specify the interface isolates user code from the Linux ABI issues that come with building C++ applications on different compiler, libc, and kernel versions.

Filtered mirroring allows certain packets to be selected for mirroring, rather than all packets ingressing or egressing a mirror source port.

This document describes the introduction and use of the global knob which facilitates the txQueue percentage-based allocations based on the available bandwidth of the parent interface.

Shaping EOS 4.32.0F txQueue

Support for ingress Port ACLs on GUE Packets. The matching of ACLs can be done on  outer IP header as well as UDP header fields for gue routed/bridged, decap/transit packets, and the ACL can be applied to Front Panel Ports.

ACL Gue EOS 4.32.0F Ingress ACL

Arista’s 7135 Connect Series of Layer 1+ switches are powerful network devices that allow for dynamic connections between various layer 1 components on the system, such as the front panel and FPGA. These connections are driven by an underlying CLOS network of crossbar switches. The following commands provide the ability to configure middle stage crossbar switches within the system to create dynamic layer 1 connections.

L1 Source EOS 4.32.0F 7135

On supported devices, a port-channel can be configured as a mirroring destination for both ingress and egress 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.

Mirroring Port Channel LAG EOS 4.32.0F

An interface may be a source for both a mirroring session and sFlow at the same time. For more information about mirroring and ingress and egress sFlow look in the Resources section below.

Mirroring Sflow EOS 4.32.0F

Mirrored packets may be configured to be truncated per mirroring session.

Mirroring Truncation EOS 4.32.0F

EOS supported two routing protocol implementations: multi-agent and ribd. The ribd routing protocol model is removed starting from the EOS-4.32.0F release. Multi-agent will be the only routing protocol model. Both models largely work the same way though there are subtle differences.

Routing BGP RIB EOS 4.32.0F ribd iprib Gated

This feature adds all-active (A-A) multihoming support on the multi-domain EVPN VXLAN-MPLS gateway. It allows L2 and L3 ECMP to form between the multihoming gateways on the TOR devices inside the site and on the gateways in the remote sites. Therefore, traffic can be load-balanced to the multi-homing gateway and redundancy and fast convergence can be achieved.

EVPN MPLS VXLAN EVPN Gateway EOS 4.32.0F

By default, the scheduling between parent interfaces and the attached shaped subinterfaces is done in strict priority mode where the parent interface has the highest priority. Subinterfaces that are not shaped use the same queues as the parent so the traffic on these subinterfaces will also have strict priority over shaped subinterfaces.

Subinterfaces EOS 4.32.0F

This feature provides a continuous, live, stream of ingress counters for Policy-Based Routing (PBR) rules in terms of bytes and packets. It is implemented as a special call in EosSdkRpc and follows this definition:

Counters PBR EosSdkRpc RPC EOS 4.32.0F

Port mirroring is used to send a copy of packets seen on one port to a network monitoring connection on another switch port. Port mirroring is commonly used with network probes or other monitoring devices; examples include intrusion detection devices, latency analyzers, or packet capture and protocol analysis tools.

Mirroring EOS 4.32.0F

The goal of route prioritization is to improve overall network behavior by ensuring that routes classified as having a higher priority are processed and installed in a timely fashion. Activity for lower priority routes must not significantly delay high priority route processing. For example, when a network event affects a large number of BGP routes causing them to be reprogrammed, the programming of an important IGP route that provides underlay connectivity and is affected by a subsequent event should not have to be queued behind the BGP routes. Prioritizing the IGP route programming will improve network convergence. It may also eliminate duplicate work for other routes depending on it.

EOS 4.32.0F Route Prioritization

This feature adds support for CPU traffic policy capable of matching and acting on IP traffic which would otherwise

This feature extends sampled flow tracker to support the selective sampling of certain traffic types (specified globally), such as routed IPv4, routed IPv6, and MPLS pop and route IPv4, per interface. The feature is applicable on interfaces, subinterfaces, port channels, and port channel subinterfaces.

Sub-interfaces can be grouped into logical units called scheduling groups, which are shaped as a single unit. Each scheduling group may be assigned a scheduling policy which defines a shape rate in kbps and optionally a guaranteed bandwidth, also in kbps.

This feature enables policer (using policy-map) on a VTEP to rate limit traffic per VLAN/VNI. The policer can be applied in both input and output directions to rate limit decapsulated and encapsulated VXLAN traffic, respectively. Prior to EOS-4.32.0F, the policers are not applicable on multicast traffic through the VTEP. For platforms supporting rate limiting of both bridged and routed encapsulated traffic, the rate limiting would be done on common policer limits.

This document describes the VRF selection policy and VRF fallback feature. A VRF selection policy contains match rules that specify certain criteria (e.g. DSCP, IP protocol) as well as a resulting action to select a VRF in which to do the FIB lookup.