CVX VXLAN Hardware Head-End-Replication (HER) configurable list

This feature allows adding third party VTEPs to  a common L2 domain comprising of Arista and non-Arista switches (hardware VTEPs). This CLI can be used to configure, and add VTEP IP addresses of non-Arista switches to the BUM (Broadcast, Unknown-host, Multicast) VTEP flood list for any VNI. Note that CVX already supports collecting flood lists from all the connected vteps, collating them, and redistributing that information to all the connected Arista VTEPs. However, if there are non-Arista/third party VTEPs in a network topology, there is no way for CVX or Arista switches to know about their existence in automated way. The...
Continue reading →

LAG hardware-only

LAGs are allocated hardware resources on transition from one member (software LAG) to two members (hardware LAG) and deallocated hardware resources on transition from two member to one member. This allocation/deallocation causes some traffic disruption. Starting with EOS4.15.4F, the option to configure all LAGs to use hardware resources is supported on the 7500E platform. Configuring LAGs as ‘hardware-only’ results in one member LAGs being hardware LAGs. Therefore, the hardware resource allocation/deallocation traffic disruption occurs on first member addition or deletion (LAG initialization) rather than the second member addition or deletion. Configuration To configure hardware-only LAGs use the following command: 7500(config)#platform...
Continue reading →

Unicast RPF (uRPF )+ Egress IPv4 RACLs

This feature provides a configuration option to disable egress IPv4 RACL sharing allowing for uRPF to be configured. The RACL sharing feature, enabled by default, optimizes hardware resources by sharing TCAM entries for common RACLs that are applied to multiple SVIs. This feature is not compatible with uRPF. Configuration of uRPF and RACLs in non-shared mode is permitted. Platform compatibility DCS-7280E DCS-7500E Configuration IPv4 egress RACL optimization is configured by default to allow for more efficient TCAM utilization and greater scalability. uRPF cannot be configured in this shared mode. To enable uRPF IPv4 RACL sharing must be disabled. Status Show...
Continue reading →

7500E-6CFPX-LC and optics

The 7500E-6CFPX-LC linecard with ACO CFP2 optics provides connectivity over DWDM systems and links. 7500E-6CFPX-LC currently only supports connections to other 7500E-6CFPX-LC linecards. Platform compatibility DCS-7500E Configuration In the best scenario, the linecard can be inserted into a 7500E system, the ACO CFP2 optics inserted, the fiber connected, and links come up. More likely configuration is needed to achieve link up and the best performance. Wavelength/frequency configuration Both sides of a link need to transmit and receive light at the same wavelength/frequency. For ease of use, instead of configuring the wavelength directly, a channel number and optional grid spacing is...
Continue reading →

Media Access Control Security (MACsec)

Media Access Control Security (MACsec) is an industry standard encryption mechanism to protect all traffic flowing on Ethernet links. Mac Security is described in IEEE 802.1X and IEEE 802.1AE standards. Platform compatibility As of EOS-4.15.4, Mac Security is only supported on DCS-7500E with the 7500E-6CFPX-LC linecard. Configuration Following command is used to enter Mac Security mode on a switch. Arista(config)#mac security In order for Mac Security to function correctly, a valid Mac Security license must be configured on a switch. Mac Security licenses are tied to a switch. Every switch running Mac Security will require a separate license of its...
Continue reading →

Delay based ECN

Introduction Delay based ECN on DCS-7280SE and DCS-7500E adds support for measuring the queueing delay that an IPv4 unicast routed packet experiences. If the delay is greater than a configurable threshold, congestion is indicated by marking ECN bits. One important use case is when WRED based ECN is not good enough, for e.g. when congestion in high priority queue ( Traffic Class ) can cause delay for the packets in uncongested lower priority queue but not mark ECN bits of packets out of this lower priority queue, because WRED based ECN works solely based on the queue length. WRED based...
Continue reading →

VXLAN Routing on Multi-Chip Systems

VxLAN Routing Vxlan routing in multichip systems uses the different modules to do different portions of the packet processing. This is done to avoid having to configure any of the front-panel chips in loopback mode for recirculation. This also means that every vxlan-routed packet is sent to the fabric chip even if the ingress and egress ports are in the same chip. Differences with VXLAN Routing in multichip models: decapsulation for vxlan packets always happens in the ingress chip; layer 3 lookup and forwarding happens in the fabric chip for packets that need encapsulation, or in the egress chip for packets...
Continue reading →

VXLAN – QoS mapping form Overlay to Underlay

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 header appropriately. This feature is used to mark COS and DSCP values in the outer-VLAN-header and outer-IP-header respectively. The Traffic Class (TC) is derived based on the trust mode of the ingress port, the default COS and DSCP configurations on the ingress port, COS and DSCP values of the ingress frame, ingress frame type and any QOS policy applied. This TC is used to derive the COS and DSCP values in the encapsulated frame. The...
Continue reading →

Maintenance mode with sub-interfaces

Maintenance mode with sub-interfaces is an extension to the maintenance mode feature released in EOS-4-15-2F. With this feature, sub-interfaces are implicitly put into/brought out of maintenance when respective parent interfaces/linecards/system are put into/brought out of maintenance. Traffic flowing through sub-interfaces is steered away from the interfaces on maintenance, provided alternate paths are available for traffic. As this operation removes the interface and inherited sub-interfaces from service, the network must support network-level redundancy to minimize or avoid traffic loss. Traffic rate monitoring: Rate monitoring for sub-interfaces is not supported. However respective/corresponding parent interfaces are monitored, which include the aggregate values for...
Continue reading →

Configurable BGP remote port

This BGP knob allows users to configure BGP TCP remote port on a per-peer or per-peer-group basis. Previously, port 179 was used as both connect and listen ports for the BGP instance. There is already a CLI knob to configure BGP listen port which is a BGP instance-wide setting. The current feature adds the ability to configure the TCP active connect/remote port, per-peer or per-peer-group. Configuration Under config-router-bgp mode, the following is the format for configuring remote port for a peer or peer-group [no|default] neighbor <peer/peer-group> transport remote-port <connect port #> Default value for the remote port is 179. Examples:...
Continue reading →

BGP UCMP

Unequal Cost Multi Path (UCMP) for BGP is a mechanism for forwarding traffic from a device for an ECMP route in the ratio of the weights with which the next hops of that route are programmed in the FIB. This is done for BGP by disseminating BGP link-bandwidth extended community attribute information with BGP paths such that the receiver device of all such paths for a route programs next hops for that route in the FIB in the ratio of the received link-bandwidth values. Configuration The following configuration commands have been added as part of this feature support Enabling UCMP...
Continue reading →

CVX High-Availability

Introduction CVX High Availability (HA) provides CVX Controller redundancy by having multiple CVX controllers running in a cluster configuration. A CVX Controller can fail because of a hardware or a software fault. EOS agents are designed to be software fault tolerant – a crashed agent will restart and resume gracefully from its saved state in Sysdb. Hardware failures though can not be handled when there is only one instance of the Controller running. CVX HA fills this gap by providing support for handling hardware failures by running multiple Controllers, each on its own dedicated hardware, working together as one system....
Continue reading →

Arista EOS 4.15.4F Release – Transfer of Information

Arista Platform Independent Features CVX HA CVX VXLAN Hardware Head-End-Replication (HER) configurable list BGP UCMP Configurable BGP remote port Maintenance mode with sub-interfaces Arista 7050X Specific Features VXLAN – QoS mapping from Overlay to Underlay Arista 7250X/7300X Specific Features VXLAN Routing VXLAN – QoS mapping from Overlay to Underlay Arista 7500E/7280E Specific Features Delay based ECN MacSec 7500E-6CFPX-LC and optics uRPF + Egress RACLs LAG hardware-only