Tag :: EOS 4.36.2F

RPKI serves as a security mechanism to mitigate specific instances of inadvertent route leaking and deliberate route hijacking.

Support for DHCPv4 (RFC 2131) and DHCPv6 Server (RFC 8415) was added to EOS-4.22.1 and EOS-4.23.0 respectively. EOS DHCP server leverages ISC Kea as backend. The router with DHCP Server enabled acts as a server that allocates and delivers network addresses with desired configuration parameters to its hosts.

Virtual Router Redundancy Protocol (VRRP) provides high availability for the default gateway within a broadcast domain. Previously, in VRRP-based deployments with DHCP Relay, each participating router forwarded DHCP requests using its interface IP address, which resulted in duplicate relay requests, duplicate DHCP server ACKs, and increased control-plane noise. This feature solves these issues by making DHCP relay processing VRRP state-aware.

This feature introduces a per-VRF table "FIB route count" for hardware FIB tables, and associated actions to. The "FIB route count" for a VRF table includes FIB routes from most protocol sources (e.g., BGP, IGP, static) in each VRF and address-family (IPv4 and IPv6). Once a VRF table's FIB route count reaches a configured limit, routes can be suppressed or evicted based on the configured action.

EOS supports the ability to match on a single VLAN tag (example: encapsulation dot1q vlan 10) or a VLAN tag pair (example: encapsulation dot1q vlan 10 inner 20) to map matching packets to an interface. In this case, the encapsulation string is considered consumed by the mapped interface before forwarding, which means that the tags are effectively removed from the incoming packet for the purposes of any downstream forwarding.

To address these challenges, AristaAppForSplunk is integrated directly into EOS. The application now ships with the SWI image and will automatically enable once the Splunk Universal Forwarder is installed on the switch. Not only does it reduce potential compatibility breakages to a large extent, but also eliminate the installation step of the AristaAppForSplunk extension.

Protocol Independent Multicast (PIM) distributes multicast data using routes gathered by other protocols. PIM Sparse Mode (PIM-SM), defined in RFC 4601, is a multicast routing protocol intended for networks where multicast group recipients are sparsely distributed, including wide-area and inter-domain networks.

IS-IS multi-topology (MT) allows separate topologies for IPv4 and IPv6, enabling independent shortest path (SPF) computations for each address family. While MT provides flexibility, some deployments may seek to migrate from multi-topology to single-topology mode to reduce resource consumption from redundant SPF computations.

Pseudowires can be used to connect geographically separated L2 networks by emulating an L2 point-to-point connection over a MPLS backbone. While each pseudowire can be configured manually, a L2VPN solution can be used to perform auto-discovery and signaling of the desired pseudowires. VPWS (Virtual Private Wire Service) can be used for auto-discovery and signaling of point-to-point pseudowires. The pseudowires in each VPWS instance can be signaled by LDP or BGP. When signaled using BGP, there are two VPWS sub-types:

This Cli command places the forwarding ASIC into a reduced clock-frequency ( low-power ) operating mode to allow energy savings in exchange of reduced throughput in supported platforms.

Currently, EOS supports only a global configurable EAPoL destination MAC address under mac security mode. This feature extends the support to allow EAPoL packets to the physical MAC address of the port which is also referred to as burned in address with the standard EtherType for ingress direction and a configurable destination MAC address for egress direction.

Container-based deployments make creating cloud portable applications extremely easy. An application can be written on normal build infrastructure, that in turn can be run on a EOS switch or any Linux device that runs docker runtime engine. So the same applications that are run on a server for microservices can be run on a switch with Arista EOS. Since Arista extensible operating system is simply linux (AlmaLinux 9.7 at this time – 2026) we are able to integrate a container runtime engine into the operating system.

Arista switches provide several mirroring features. Filtered mirroring to CPU adds a special destination to the mirroring features that allows the mirrored traffic to be sent to the switch supervisor. The traffic can then be monitored and analyzed locally without the need of a remote port analyzer. Use case of this feature is for debugging and troubleshooting purposes.

On Arista 7130 devices, the transmit and receive paths of front panel Ethernet interfaces are inherently independent. An interface can have a fully operational transmit path while the receive is down, yet the existing show interfaces output only displays a single combined link status. This can cause confusion when the interface state shows "down" even though the TX path is actively passing traffic.

This article provides a general introduction to Precision Time Protocol (PTP) supported within EOS. PTP is aimed at distributing time with sub-microsecond accuracy. PTP support is based on the IEEE-1588 specification for version 2 of the protocol.

RADIUS over DTLS (Datagram Transport Layer Security) provides secure, encrypted communication between RADIUS clients and servers while maintaining the UDP transport characteristics of traditional RADIUS. This implementation follows RFC 7360 and enhances RADIUS security without requiring migration to TCP-based transports.

Routing control functions (RCF) is a language that can be used to express route filtering and attribute modification logic in a powerful and programmatic fashion. This document serves as a reference guide for: Routing protocol attributes , Operators for comparing and modifying attributes

Routing control functions (RCF) is a language that can be used to express route filtering and attribute modification logic in a powerful and programmatic fashion. This document serves as a reference guide for Bgp agent points of application:

Routing control functions (RCF) is a language that can be used to express route filtering and attribute modification logic in a powerful and programmatic fashion. This document serves as a reference guide for IpRib agent points of application Configuration of RCF

RSVP-TE, the Resource Reservation Protocol (RSVP) for Traffic Engineering (TE), is used to distribute MPLS labels for steering traffic and reserving bandwidth. The Label Edge Router (LER) feature implements the headend functionality, i.e., RSVP-TE tunnels can originate at an LER which can steer traffic into the tunnel.

RSVP-TE applies the Resource Reservation Protocol (RSVP) for Traffic Engineering (TE), i.e., to distribute MPLS labels for steering traffic and reserving bandwidth.

The send support-bundle feature adds a new CLI command which creates a ZIP file containing a useful set of logs and command outputs, and then writes it to either a local or remote destination specified by a CLI URL. When sending to a remote destination, the ZIP file will be created and streamed to the destination on-the-fly, saving local disk space.

The statuses of the transceiver low-speed pins are not easily readable. This feature provides a way to expose these statuses through a CLI command.

Synchronous Ethernet (SyncE) provides support for frequency synchronization over Ethernet between devices traceable to an external frequency reference, like a primary reference clock, as specified in ITU G.8261.

VLAN tagged MACsec refers to frames that have a VLAN tag between the MAC source address and the MACsec ethertype.  This VLAN tag is unencrypted (in the clear) so that intermediate devices between the MACsec endpoints can forward the MACsec frames based on this unencrypted VLAN tag.

Previously, when both “ipv6 nd proxy prefix connected” and VXLAN is configured for a VLAN interface, and the router received a Neighbor solicitation (NS) with an IPv6 address within the connected prefix of the router, the router replied with the interface physical (or virtual-router if VARP is configured) mac address as long as the NS is received on a local (front-panel) port. This feature extends the behavior to also include the NS received from the VXLAN tunnel.

This feature is used to add VXLAN support for local-proxy-arp, Previously, when both “ip local-proxy-arp” and VXLAN is configured for a VLAN interface, and the router received an ARP request with an IP address within the same subnet as the router, the router replied with the interface physical (or virtual-router if VARP is configured) mac address for requests that are received on a local (front-panel) port. This feature extends the behavior to include the VXLAN tunneled ARP requests.

WRED ( Weighted Random Early Detection ) is one of the congestion management techniques. It works at queue level to drop packets randomly after crossing the given queue threshold even before the queue is full. Without WRED, all newly arriving packets get tail dropped once the queue is full, which creates TCP global synchronization issues. WRED helps to avoid TCP global synchronization.