The Unified Forwarding Table (UFT) is a group of memories that is shared between Layer2 and Layer3 lookup tables with capabilities for variable partitions. Rather than separate Layer2 and Layer3 lookup tables of fixed size, the UFT may be partitioned to support user-requested combinations of Layer2 and Layer3 lookup tables of varying sizes..

With the 13.0 release, CloudVision Cognitive Unified Edge (CV-CUE) lets you configure Unique PSK (UPSK) for client authentication. UPSKs allow users  to connect to the same SSID using a unique PSK which is user specific. UPSK provides added security as compared to single PSK because single PSKs are easily compromised.

With the 15.0 release, CloudVision Cognitive Unified Edge (CV-CUE) introduces the following enhancements to the Unique-PSK(UPSK) workflow:

Arista currently posts separate EOS images for different CPU architectures: i686 (EOS.swi), x86_64 (EOS64.swi), and aarch64-based (EOSarm.swi, starting with EOS-4.35.0F). The universal SWI (EOSuni.swi) is a single file containing support for all CPU architectures, meant to simplify image management and provisioning. The universal SWI will be posted in addition to the existing architecture-specific SWIs and is not meant to fully replace them.

With the 12.0 release, you can check for available upgrades and upgrade your server to the latest version of CloudVision Cognitive Unified Edge (CV-CUE).  Only a Superuser  can initiate a server upgrade.

CVA 6.x may be upgraded to CVA 7.0 with an upgrade launcher. The launcher is an interactive executable that is run on the CVA system that is to be upgraded, and performs several functions Staging of an appropriate upgrade image for autoinstall

CVA 6.x may be upgraded to CVA 7.1 with an upgrade launcher. The launcher is an interactive executable that is run on the CVA system that is to be upgraded, and performs several functions

With the 16.0 release, you can authenticate edge devices from a centrally managed network access control server using the 802.1X authentication. As a network administrator, you want to authenticate the access points (APs), before the APs connect to the network. To enable the authentication, you need to first configure the uplink port on the AP using CV-CUE.

This feature adds the capability to import as path access-list from a URL, in release 4.20.1F. The file specified by the URL can contain one or more as-path access-list entries. All the entries that are in the file are added to the as-path access-list being configured. This feature gives the advantage of using one EOS CLI command to configure many as-path access-list entries, instead of adding each one of them line by line in the CLI.

TOI 4.20.1F

Role based access control (RBAC) is an approach to regulating access to network resources based on the roles of

Packets which exceed the L2 Maximum Transmission unit (MTU) in EOS are dropped. The value of the L2 MTU is configurable for each Ethernet or Port-channel interface.

This article describes how to customize TCAM ( Ternary Content Addressable Memory ) lookup for each feature which uses TCAM.

User-defined TPIDs allows an arbitrary TPID (Tag Protocol Identifier) to be used with a FlexEncap specification. A TPID is used in Ethernet frames to identify the encapsulation protocol, where standard values like 0x8100 (for IEEE 802.1q VLAN tagging) and 0x88a8 (for IEEE 802.1ad Q-in-Q) are commonly used. However, some network equipment may use non-standard or legacy values such as 0x9100. This feature allows FlexEncap subinterfaces to be configured with an arbitrary TPID to allow interfacing with networking equipment that uses values besides 0x8100 and 0x88a8.

This feature expands Multi Domain EVPN VXLAN to support an Anycast Gateway model as the mechanism for gateway

EOS 4.15.0F added support for a CLI knob to determine whether the L3 forwarding agent (responsible for programming FECs and routes into hardware) would react to BFD status events for an interface to update next-hop programming for FECs programmed in hardware. This required two events, one for the BFD session to transition to an “Up” status and a subsequent transition to a “Down” status. This is identical to how various protocols in EOS (i.e. BGP, IS-IS) leverage BFD for faster down detection, and is useful to allow the L3 forwarding agent to preemptively remove next hops that would later be deprogrammed due to protocol session status state.

Arista’s DCS-7130LBR series of switches are capable of supporting SwitchApp, which is an FPGA-based L2/L3 switch. However, as the switch would then contain two switch ASICs (one traditional switch ASIC, and one FPGA-based switch) physically upon loading the SwitchApp application, there are certain limitations and nuances along with its usage. This document intends to explain some of the details.

This feature enables exchanging IPv4 NLRI using MP BGP over an IPv6 TCP connection.  Additionally, this feature

The vertical navigation bar is an update to the layout of CloudVision. It replaces the existing horizontal header with a vertical navigation menu that lines the left side of the page. This allows for a cleaner horizontal header where key functions of CloudVision sections are highlighted.

Virtual Private LAN Service (VPLS) can be used when one wishes to connect several LANs dispersed across a packet switched network. VPLS can allow the dispersed LANs to act like a single bridged LAN by providing a service to connect the LANs. The service will appear like an Ethernet LAN (in almost all regards). VPLS achieves this by creating a mesh of pseudowires that connect the dispersed LANs, while also processing the traffic that moves through the pseudowires in a similar way to how a L2 service would. For example, MAC address learning, flooding and forwarding functions are applied to the pseudowire traffic in a VPLS. This allows  VPLS to mimic the functionality of an any-to-any L2 service when connecting dispersed LANs.

The Arista Service Node (SN) provides specialized packet processing within the DANZ Monitoring Fabric (DMF), which is not easily accomplished within the CPU on a switch.  The SN provides a packet processing pipeline tied to a physical interface, reading packets and writing results from the same interface.

This article describes the support of a VLAN filter for IP, IPV6 and MAC ACLs on the ingress ports. The users will be able to filter the packets by specifying a VLAN id in the ACL rule. VLAN id specified in the ACL rule is internal broadcast domain VLAN id. 

The Tap Aggregation Traffic Steering feature provides support for filtering data streams received on tap ports and directing flows to tool ports based on user-configurable match rules, using either class maps and policy maps or traffic policies.

 

The VLAN mapping or translation feature provides the ability to map an arbitrary VLAN tag to a particular bridging VLAN on the switch. This mapping can be either bidirectional or applied only in one direction (incoming/outgoing).

This feature is available in the VLAN configuration mode. When a switch receives a packet with unknown destination MAC address on a VLAN, L2 miss happens. The current behavior for L2 miss packets is to flood the packet on all ports of the VLAN. In certain cases, there may be a preference to drop or log L2 miss packets instead of flooding them across the VLAN.

VLAN Pooling is a list of VLAN IDs defined by the Network Administrator. The Access Point (AP) distributes the VLAN IDs from this pool of VLAN to the clients connecting to the SSID.VLAN Pooling offers better scalability and optimized load-balancing of traffic.

As of EOS 4.15.2F, VM Tracer adds support for VMware NSX V. This includes supporting NSX V specific features, improved

Prior to EOS 4.24.1F, per-destination steering into an SR Policy was only supported for IP unicast BGP routes in the default VRF.

VRF redirection often requires matching packets’ source 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.

CloudVision now creates VRF system tags in order to name devices in a VRF. This allows you to identify devices by VRF using the Tag Query Editor, like in Dashboards.

This document describes how to use the new feature, VRRP IPv6 using VRRP IPv4 MAC prefixes. RFC 5798 defines a specific

Traceroute and tracert are widely available diagnostic command-line interface commands for displaying possible routes (paths) and transit delays of packets across an Internet Protocol (IP) network. This enhancement applies to IPv4 and IPv6 overlay. The VTEP overlay ICMPs for “time-to-live expired” (aka TTL-expired) are sourced with the VTEP IP which results in the traceroute output to display the VTEP IPs on the overlay packet’s path from source to destination.

This feature allows the VRRP MAC and IP to be advertised via EVPN MAC-IP routes when VRRP is configured on the VTEP.

When a frame gets bridged from an edge port to a VXLAN core port, it is necessary to encode the QOS fields in the outer

This feature allows an operator to configure a centralized routing topology with an IPv6 VXLAN underlay. This is useful for customers who want to use an anycast (VARP) gateway for routing over an IPv6 control plane. VARP allows multiple switches to simultaneously route packets from a common IP address in an active-active router configuration. Each switch is configured with the virtual IP address and a common virtual MAC address.

This feature makes IGMP Snooping aware of VXLAN endpoints. Without this feature, multicast data traffic is flooded to all the VXLAN endpoints in case of a VXLAN VLAN. This increases the underlay network utilization. It is desirable to forward multicast traffic to only those VXLAN endpoints that are attached to receivers. To identify interested VXLAN endpoints, this feature snoops IGMP reports that are coming from the remote VXLAN endpoints. Note: EVPN control plane is not required when using this feature.

The VXLAN Control Service (VCS) provides a mechanism by which hardware VTEPs share states between each other in order

This feature allows selecting Differentiated Services Code Point (DSCP) and Traffic Class (TC) values for packets at VTEPs along VXLAN encapsulation and decapsulation directions respectively. DSCP is a field in IP Header and TC is a tag associated with a packet within the switch, both influence the Quality of Service the packet receives. This feature can be enabled via configuration as explained later in this document.

Hardware Head End Replication (HW HER) optimizes flooding of inter VTEP broadcast, unknown unicast and broadcast

In EOS 4.18.0F, VXLAN direct routing was introduced on the 7500R and 7280E/R series platforms. VXLAN routing

VXLAN multicast decapsulation enables VTEPs that only support HER (Head End Replication) to terminate multicast

VXLAN is a Layer 2 technology that helps you to create a virtual Layer 2 network (overlay network) on top of a physical

VXLAN ARP and IPv6 Neighbor Discovery (NDP) packet headend replication capability via VxlanSwFwd matches the COPP rate limit for these packets for the supported platforms regardless of the size of the VXLAN flood VTEP list. However, there still remains a case where the handling capacity is limited by CPU: the handling of ARP broadcast and NS multicast that result from Glean traffic (post routing).

With the 12.0 release, CloudVision Cognitive Unified Edge (CV-CUE) supports a new tunnel type —  VXLAN over IPSec. You need to specify a tunnel type when you create an SSID.

VxLAN bridging enables stretching Layer 2 domains across a Layer 3 cloud. VxLAN routing provides the capability to

The 7500 and 7280 switch series platforms have previously supported VXLAN bridging, which enables stretching of

Vxlan routing in multichip systems uses the different modules to do different portions of the packet processing.

MLAG provides Layer2 active/active redundancy. VXLAN is supported over an MLAG setup by having the two switches

This document describes VXLAN routing with overlay VRFs on the DCS 7050X platforms. The feature allows users to

Up until now, the mirroring ACLs on the DCS 7150 series used to support only the security ACL rules. This meant that

Configuration of VXLAN overlay using EVPN allows for extension of Layer 2 (L2) or Layer 3 (L3) networks across