Tag :: EOS 4.22.0F

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

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.

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.

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.

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.

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

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.