Routing control functions (RCF) is a new language, a different way of policy definition and application in a programmatic fashion (https://www.arista.com/en/support/toi/eos-4-27-2f/15102-routing-control-functions-language-and-configuration). EOS Application Programmable Interface (eAPI) is another means whereby commands are sent to the switch (i.e. aside from the switch’s command-line interface - CLI which has been the norm), which can be executed through various methods like web interface, shell or a program/script.

The document captures the default preference value (between and 255) for routes from various supported protocols.

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.

For network monitoring and troubleshooting flow related issues, it is desirable to know the path, latency, queue and congestion information for flows at different times. The inband telemetry feature(INT), based on Inband Flow Analyzer RFC draft -IFA 2.0 and IFA 1.0(on some platforms) , is used to gather per flow telemetry information like path, per hop latency and congestion. INT is supported for both IPv4 and IPv6 traffic.

IPv6 routes of certain prefix lengths can be optimized for enhanced route scale on R3. This TOI explains the usage of these optimizations.

EOS 4.26.2F EOS 4.29.2F

Multicast EVPN IRB solution allows for the delivery of customer BUM (Broadcast, Unknown unicast and Multicast)

RADIUS over TLS provides secure and reliable transport for RADIUS clients. RADIUS over TLS allows RADIUS

AAA Radius Dot1x EOS 4.26.2F EOS 4.29.1F

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. The VRF fallback feature is an extension of these policies which allows users to optionally specify a “fallback” VRF for each VRF. The behavior is such that if the FIB lookup fails in a match rule’s selected VRF, another lookup will be attempted in the configured fallback VRF. Additionally, the fallback VRF itself can have yet another fallback VRF, such that if the lookup in the VRF and fallback VRF fail, the fallback-of-the-fallback VRF will be looked up (see the Configuration section for an example of this).