Tag :: EOS 4.35.1F

The 400GBASE ZRP (also known as ZR+) is a transceiver that follows the OpenZR+ MSA (Multi Source Agreement)

This TOI supplements the Ingress Traffic Policy applied on ingress port interfaces. Please refer to that document for a description of Traffic Policies and field-sets. This TOI explains the Traffic Policies as applied in the ingress direction on VLAN interfaces. For Traffic Policies on the egress direction of VLAN interfaces, see the Egress Traffic Policy TOI.

802.1X is an IEEE standard protocol that prevents unauthorized devices from gaining access to the network. We support dot1x protocol standard 802.1X-2004 (version=2)

This feature allows a user to adjust the MTU of radius requests for 802.1x supplicants. Currently this feature only adjusts the MTU size of radius requests for supplicants undergoing EAP TLS authentication.  This can be useful in scenarios where hops between the switch and RADIUS doesn’t support IP MTU discovery and the switch ends up sending Access Requests based on the interface MTU size which get dropped at such hops. With this feature, a user has the flexibility to experiment and choose a MTU setting that works for such a topology forcing the Dot1x agent to send the Access Requests with the configured MTU.

Accumulated IGP Metric (AIGP) is an optional non-transitive BGP attribute used to carry an IGP metric with BGP route advertisements. The AIGP attribute is useful for tie-breaking in BGP bestpath selection so that routing decisions can be made on the basis of shortest path/lowest IGP cost path amongst multiple BGP paths. This is particularly applicable in scenarios where a single administration is subdivided into multiple Autonomous Systems (AS) each with similar routing policies and the same IGP in use such that the IGP metric for a route can be propagated usefully between the ASes so as to let receiving BGP speakers make routing decisions based on the cumulative IGP cost of the route. 

The AGM for ECMP feature allows monitoring the number of packets and bytes going through each member of the configured ECMP group on the system, with a high time resolution.

The EOS-4.35.1F release introduces IGMP Snooping Accelerated Software Upgrade (ASU) support. This enhancement guarantees sub second disruption to multicast forwarding services during software upgrades by ensuring IGMP Snooping remains fully operational and preserving its learned state without interruption. This is essential for highly sensitive environments like IPTV and financial institutions. ​​

In an EVPN network, unique route targets are assigned to each VLAN (or a VLAN bundle). For an IRB (Integrated Routing and Bridging) configuration, unique route targets are assigned for each L3-VRF as well.These route targets are statically configured for each VLAN (or a VLAN bundle) and each L3-VRF as well. Starting with 4.35.1F, such route targets for L3-VRFs can now be auto-derived from the corresponding VNI numbers.

The current workflow for installing extensions involves multiple manual steps: copying, installing, and setting to install at boot, and on dual supervisor systems these steps have to be repeated in a peer supervisor CLI session. This feature introduces new CLI commands automating this process, improving EOS extension management for both dual supervisor and fixed system devices, and easing set up of EOS devices at scale. They are modeled to resemble existing install source commands and should behave similarly for EOS extensions. Both commands are available in enable mode.

ACL based traffic management often requires matching packets’ destination addresses against one or more sets of IP prefixes. This can become difficult to manage when the prefix sets need to be consistently maintained on several devices and either change too frequently or are very large. When the prefixes for the prefix sets are learned by BGP, this feature provides an alternative to maintaining unwieldy sets of statically configured IP prefixes. Instead the prefix sets are populated by BGP based on the BGP communities that are assigned to learned prefixes. BGP can manage IP prefix field sets for use with Traffic Policies.

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.

Creating Traffic Policies that regulate control plane traffic from BGP peers by writing the list of BGP peer addresses statically in a field-set is error prone and difficult to update. Selecting only internal or external peers requires additional care. This feature automatically populates a field-set with IPv4 or IPv6 prefixes corresponding to iBGP or eBGP peers. This can be used instead of “protocol neighbors bgp” (see "Support for CPU traffic policy" ) where only a particular peer type is needed, or to replace complicated manual field-set updates.

A device's classification as a phone or non-phone is determined by the switch through three mechanisms: advertisement via LLDP packets, explicit MAC address classification via CLI commands, or classification as a phone through the DeviceType VSA from a AAA server during authentication. This feature enables the port to be flapped (portflap) when the device's classification transitions from phone to non-phone or vice versa. This functionality applies to classification changes for both MBA and EAPOL supplicants. 

Class Based Forwarding (CBF) is a means for steering IP traffic into specific tunnels based on either the ingress DSCP values or based on “classes”, which are derived from fields in the ingress packet headers and policies provisioned on the router. CBF may be used with SR-TE Policy or RSVP-TE colored tunnels. 4.35.1F adds support for CBF with flex-algo colored tunnels.

Arista’s CCS-710XP series of ethernet switches consist of CCS-710XP-12TH-2S SKU. CCS-710XP-12TH-2S is a 12 port 1000BASE-T PoE & 2-port SFP+ fanless switch device rich with networking features suited for campus deployments.

Class based forwarding (CBF) is a means for steering network traffic into colored tunnels based on one or more fields of the ingress traffic. Rephrased, CBF is forwarding of traffic based on “classes” which are derived from fields in the ingress packet headers and policies provisioned on the router.

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”. Class Based Forwarding (CBF) for SR-TE is a means for steering IP traffic into an SR Policy based on the ingress DSCP values. This mechanism is described in the section on Per-Flow Steering in the Segment Routing Policy Architecture Internet draft.

Class Based Forwarding (CBF) is a means for steering IP traffic into colored tunnels based on the ingress DSCP values. CBF may be used with SR-TE Policy, RSVP-TE or Flex-Algo colored tunnels.

Class Based Forwarding (CBF) is a way of steering IP traffic into specific tunnels based on the ingress DSCP values. Arista already supports class based forwarding today, and the details about the existing support can be found in this CBF TOI. CBF is implemented in the hardware using an override model. As always, forwarding for an ingress IP packet begins with a lookup in the L3 FIB, which returns a default Forwarding Equivalence Class (FEC) to use. If CBF is enabled, an additional lookup is made in order to determine whether traffic associated with that default FEC and with the ingress packet’s DSCP should be steered into an SR Policy tunnel/RSVP-TE/Flex-Algo tunnel. In network deployments where unique (gateway) endpoints are large, the default FEC combinations generated by controller based on these endpoints can be a lot, and the existing approach with the override model using hardware’s TCAM resource doesn’t scale well, given that this resource is limited in nature. To overcome these scale issues, we have developed an alternative approach for CBF that is based on VRF Selection Policy.

Cluster Load Balancing for Spine is a feature designed to ensure optimal load balancing of flows used as part of GPU based cluster communication in a network that uses multiple links to connect a TOR router to a Spine router.. When this feature is enabled on a Spine, it monitors RoCE traffic coming from a TOR and applies optimal load balancing when forwarding the traffic to the next TOR router hosting the destination GPU server.

Connectivity Monitor is an EOS feature that allows users to monitor their network resources from their Arista switches. The resources being monitored may or may not be Arista devices. Connectivity monitoring is unidirectional in nature.

The feature adds cross-VRF support for dynamic prefix-list.

Dynamic prefix-list policy construct is similar to the traditional IP and IPv6 prefix-list, except that they have an additional state associated. This state associated with the dynamic prefix-lists, is determined on the basis of the route entries in FIB, and hence as and when the FIB changes, the state also changes dynamically. This state determines the dynamic prefix-list behavior, when used in route-map/RCF match clauses or route injection.

This feature allows the user to define a custom COS To Traffic-Class (TC) profile and apply it to an interface.

This feature allows the user to define a custom DSCP-To-TC map and apply it to an interface.

The feature allows to create a custom (i.e. named) TC, DP to DSCP mapping profile that can be applied on an interface.

This feature allows the user to define custom EXP To Traffic-Class (TC) maps that can be associated with individual interfaces to classify packets based on EXP bits (MPLS priority bits) of the outer MPLS header.

This feature allows defining custom TC-To-CoS mapping profiles that can be attached to the interfaces.

This document describes how to prefix syslog messages with a custom string value. Previously, syslog messages were constrained to being prefixed with either the device’s hostname, IPv4 address or fully qualified domain name. This can be controlled with the command “logging format hostname ( fqdn | ipv4 )”. Support has now been added for prefixing the syslog messages with a custom comment. This provides users with greater freedom when deciding the format of their syslog messages including those which are sent to syslog servers.

This feature supports an alternative L3 EVPN gateway mechanism using multi-domain L3 VRF instead. A multi-domain IP VRF allows configuring not only the local domain route distinguisher (RD) and route targets (RT), but also the remote domain route distinguisher and route targets on a DCI gateway.

The above figure depicts a typical wireless network deployment. In the above deployment, the traffic from wireless networks are encapsulated into VXLAN tunnels by the AP (Access Point) VTEPs and terminated at the aggregation switches. When a host on the wireless network transmits a DHCP request broadcast packet, the AP encapsulates it in a VXLAN tunnel and sends it to the aggregation switch.

The DHCP relay feature, forwards DHCP packets between a client and the DHCP server when the server is not in the same broadcast domain as the client. The DHCP relay should be configured on the gateway interface (SVI/ L3 interface) for the clients.

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.

EOS supports the DHCP Relay feature, which relays DHCP Requests/Responses between DHCP clients and DHCP servers in different subnets. However, the DHCP server does not have visibility of where the request originated from and can only make IP address allocation decisions based on the client MAC address alone (client MAC address is included in the DHCP packet as part of the payload). To remedy that, DHCP Option-82 was formalized to allow relay agents to include Remote ID and Circuit ID so that DHCP servers can apply a more intelligent allocation policy.

This feature supports counting ECN-marked packets (ECN = Explicit Congestion Notification) on a per egress port per tx-queue basis. The feature can be used to gather these packet counts via CLI or SNMP.

EOS-4.35.1F adds support for egress IPv4/IPv6/MAC PACL. So, by default, egress IPv4/IPv6 ACL enabled on default profile and for MAC ACL to enable, it is required to add its support directly to the current tcam profile or create a new tcam profile based on the default profile and disable egress IPv4 and IPv6 ACL features.

Multiple dynamic counter features may be enabled simultaneously, primarily configured using the ‘[no] hardware counter feature [feature]’ CLI commands. Compatibility of these features has been enhanced to allow for greater flexibility in simultaneously enabled counter features. Changes in counter feature compatibility across EOS releases is detailed below.

As Ethernet technologies made their way into the Metropolitan Area Networks (MAN) and the Wide Area Networks (WAN), from the conventional enterprise level usage, they are now widely being used by service providers to provide end-to-end connectivity to customers. Such service provider networks are typically spread across large geographical areas. Additionally, the service providers themselves may be relying on certain internet backbone providers, referred to as “operators”, to provide connectivity in case the geographical area to be covered is too huge. This mode of operation makes the task of Operations, Administration and Maintenance (OAM) of such networks to be far more challenging, and the ability of service providers to respond to such network faults swiftly directly impacts their competitiveness.

In the Centralized Anycast Gateway configuration, the Spines are configured with EVPN-IRB and are used as the IP Default Gateway(DWG), whereas the Top of rack switches perform L2 EVPN Routing.

In EVPN, an overlay index is a field in type-5 IP Prefix routes that indicates that they should resolve indirectly rather than using resolution information contained in the type-5 route itself. Depending on the type of overlay index, this resolution information may come from type-1 auto discovery or type-2 MAC+IP routes. For this feature the gateway IP address field of the type-5 NLRI is used as the overlay index, which matches the target IPv4 / IPv6 address in the type-2 NLRI. Other types of overlay index are described in RFC9136, but these are currently unsupported.

gNPSI is an OpenConfig protocol designed to act as a proxy between the sFlow agent and interested gRPC clients. The gNPSI server receives datagrams from sFlow, repackages the datagrams in the protobuf message format and forwards these messages onto any subscribed gRPC clients. The protobuf used for this feature is available at the link above.

This feature introduces hardware forwarding support for IPv4-over-IPv4 GRE tunnel interfaces on selected Arista Switches. The GRE tunnel interface acts as a logical interface which performs the GRE encapsulation or decapsulation.

This feature optimizes the utilization of hardware resources by sharing the hardware resources between different VLAN interfaces when they have the same ACL attached in the ingress direction. This is particularly useful for larger deployments where the ACL is applied to multiple VLANs and with the RACL sharing capability, lesser hardware resources are used irrespective of the number of VLANs.

With this feature, IPv4 or IPv6 packets matching a static nexthop-group route can be encapsulated within an IP-in-IP tunnel and forwarded

The IS-IS BFD Damping feature allows IS-IS to delay adjacency establishment on a link that experiences frequent BFD flaps.

Link State IGPs such as IS-IS depend upon having a consistent LSDB across all the Intermediate Systems (ISs or nodes) in the network in order to provide correct forwarding of data packets. When topology change occurs due to various network events, new/updated LSPs are propagated network-wide. The speed of propagation is key for a faster network convergence.

IS-IS LSP out-delay is a feature implemented to mitigate transient micro-loops that can occur during topology changes in an IS-IS network.When a topology change occurs (e.g., a link state or metric change), different routers in the network receive and process the updated Link State PDUs (LSPs) at slightly different times. This can lead to a transient state where some routers have updated their Forwarding Information Base (FIB) based on new LSPs, while others have not, causing traffic to be incorrectly forwarded and forming micro-loops.

This document describes two features that allow dynamic metric change for IS-IS based on interface speed.

Normally, a switch traps L2 protocol frames to the CPU. However, certain use-cases may require these frames to be forwarded or dropped. In cases where the L2 protocol frames are forwarded (eg: Pseudowire), we may require the frames to be trapped to the CPU or dropped. The L2 Protocol Forwarding feature provides a mechanism to control the behavior of L2 protocol frames received on a port or subinterface.

L2 support for CloudEOS and AWE is added.

NAT peer state synchronization feature provides redundancy and resiliency for dynamic NAT across a pair of devices in an attempt to mitigate the risk of single NAT device failure. The main motivation is that since the NAT state is shared between two switches, the failure of one switch can be tolerated since the other switch will retain the translations.