Tag :: EOS 4.22.0F

When a switchport receives its own STP BPDU, the port goes into role ‘Backup’ and state ‘Discarding’. The

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.

This feature can be divided into 3 parts. Enable support for different threshold per Color per TX queue  We

Ethernet VPN (EVPN) networks normally require some measure of redundancy to reduce or eliminate the impact of outages and maintenance. RFC7432 describes four types of route to be exchanged through EVPN, with a built-in multihoming mechanism for redundancy. Prior to EOS 4.22.0F, MLAG was available as a redundancy option for EVPN with VXLAN, but not multihoming. EVPN multihoming is a multi-vendor standards-based redundancy solution that does not require a dedicated peer link and allows for more flexible configurations than MLAG, supporting peering on a per interface level rather than a per device level. It also supports a mass withdrawal mechanism to minimize traffic loss when a link goes down.

This feature introduces the hardware forwarding support for IPv4 over IPv4, GRE-Tunnel interfaces on Arista Switches. A GRE-Tunnel interface acts as a logical interface which performs the GRE encapsulation or decapsulation. IPv6 payload over IPv4 GRE-Tunnel interfaces is supported with limitations (see Limitation section).

The Interface Reflector feature allows performing certain actions (such as source/destination MAC address swap) on bridged packets that are reflected back from the interface. It is useful to test properties and SLAs before deploying the service for a customer.

The main motivation for the feature is to provide high availability to the ManagementActive interface (Management0) via multiple redundant paths in the modular system. The ManagementActive interface(Management0) is a virtual interface pointing to the active supervisor.

The objective of Maintenance Mode on MLAG is to gracefully drain away the traffic (L2 and BGP) flowing through a switch

Normally, Multiprotocol Label Switching (MPLS) determines the packet forwarding destination based on the top most

The PIM routing protocol builds multicast routing state based on control packets and multicast data events. In our current implementation, we rely on theLinux kernel to notify the PIM agents regarding the multicast data events. Also, the Linux kernel forwards a multicast data packet before hardware gets programmed to do so. As an alternative to the Linux kernel, Multicast Forwarding based on BESS ( Berkeley Extensible Soft Switch ), MFA, can be used to generate multicast data events and forward multicast data packets.

An introduction to Nexthop-groups can be seen in the Nexthop-Group section of EOS. With this feature, IP packets matching a static Nexthop-Group route can be encapsulated with a GRE tunnel and forwarded.

EOS supports reading and streaming various OpenConfig configuration and state models over gNMI (gRPC Network Management Interface), RESTCONF, and NETCONF transports. A subset of the configuration models may also be modified over these transports

Secure boot is a security feature available in Aboot (Arista bootloader) that verifies the cryptographic signature of the EOS SWI (software image) before it is booted. Aboot embeds certificates that allow it to recognize and validate official EOS releases from Arista. If the signature verification is successful, the secure boot check passes and Aboot proceeds to boot the SWI. If the signature verification fails, the boot is aborted.

Segment Routing Traffic Engineering Policy (SR-TE) aka SR Policy makes use of Segment Routing (SR) to allow a headend to steer traffic along any path without maintaining per flow state in every node. A headend steers traffic into an “SR Policy”. EOS 4.21.0F adds support for SR Policy for the MPLS dataplane (SR-MPLS) for Type-1 SR Policy segments with BGP and locally configured policies as sources of SR Policies on Arista’s 7500, 7280 families of switches.

This feature modifies the display format of “show interface Tunnel <num> counters” on hardware

This feature modifies the display format of “show interface Tunnel <num> counters”. 

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

BGP routing information often contains more than one path to the same destination network. The BGP best-path selection algorithm determines which of these paths should be considered as the best path to that network

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.