Tag : EOS-4.20.5F

EOS 4.20.5F introduces support for disabling local interface, when a fault is signaled by the remote peer. The Pseudowire agent will honor Pseudowire Status TLVs (type 0x096A), when received from an LDP peer, notifying that it is not forwarding traffic. On receiving any reason for the remote peer to not forward traffic, the local interface is error disabled with the error reason explained as “pseudowire.” Supported platforms The feature is supported on all platforms supporting LDP Pseudowires. Details RFC4446 defines status codes (a bit mask) for signalling the state of a pseudowire at one end. These are summarized below. 0x00000000...
Continue reading →

Feature Benefits This feature makes sure that on a supervisor switchover, VxLAN bridging forwarding state is not affected. In line with 7500R/7500R2 SSO, VxLAN SSO keeps VxLAN bridging traffic flowing with sub-second loss. Terminology Term Definition VxLAN RFC7348 SSO Stateful Switchover Hitless Restart Minimal packet loss agent restart. Staging Synchronization mechanism used by software agents to track restart progress. VTEP VxLAN Tunnel EndPoint. VTEPs are configured on Arista switches to initiate and terminate VxLAN traffic. Platform Compatibility DCS-7504 DCS-7508 DCS-7504N DCS-7508N DCS-7512N VxLAN Scale Supported The current supported Vxlan scale is supported by this feature. This includes: 4K VNIs 4K...
Continue reading →

IS-IS Counters feature adds support to monitor per interface count of received, transmitted and dropped IS-IS PDUs at the Rib/Isis agent level. The counters start getting incremented once IS-IS is enabled on an interface and persist until IS-IS is disabled on it or the Rib/Isis agent restart. This feature can be used to debug protocol related issues of interconnected neighbors. Platform compatibility IS-IS Counters feature is supported on all EOS platforms. Configuration No additional configuration is necessary to enable this feature. It is enabled by default whenever IS-IS is configured on an interface. Status The counters are displayed using show...
Continue reading →

This TOI describes the features details and any caveats of Stateful Switchover (SSO) support for Sand modular chassis with 7500R (Jericho) and 7500R2 (JerichoPlus) based line cards. Supported Chassis 7504 7508 7504N 7508N 7512N Supported Line cards All Jericho based line card modules with the exception of 7500RM-36CQ-LC and7500R-8CFPX-LC modules. All JerichoPlus based line card modules with the exception of 7500R2M-36CQ-LC module Configuration Command for enabling redundancy protocol sso. redundancy protocol sso Status Following command shows the current status of the system with configured redundancy state. The ‘my state’ refers to the state of the supervisor on which this command...
Continue reading →

Introduction The EOS Event Handler feature provides the ability to specify a condition and an action to be carried out when that condition is detected. It is a flexible and configurable way to automate the reaction to conditions without the need for a system operator to observe and apply the desired actions manually. The multiple interface support is an  extension to the on-intf event handler trigger which provides the ability to specify an interface range or a list of interface ranges in the “trigger on-intf” command in the event-handler config mode. Previously, a single interface is allowed in this command. Platform compatibility The multi-line...
Continue reading →

The SNMP notifications (Trap and Inform messages) that were most recently sent are recorded in a log, as described by NOTIFICATION-LOG-MIB (RFC 3014). If the sending of a notification fails—for example, because a recipient is not reachable—the notification is still included in the log. Supported Platforms This feature is supported on all platforms. Configuration The maximum number of notifications in the log is specified via nlmConfigGlobalEntryLimit. Its value may be set via SNMP or using the CLI, for example: Arista(config)#snmp-server notification log entry limit 1000 The default value of the entry limit is 500 entries. Its value must be between 1...
Continue reading →

Introduction Starting from EOS 4.20.5F, power supply low input voltage warning can be configured via a CLI command. Prior to the feature availability, the low input voltage signal was relied on from the power supply themselves. Some power supplies have warning thresholds and failing thresholds values vary close to each other, and accuracy was lacking when it came to reporting the warning message before a power supply shutdown. This CLI command can be used to set the low input voltage threshold to the value customers require. This command also provides the option to configure the maximum number of fault readings...
Continue reading →

This feature allows the possibility to enable/disable the hardware watchdog. By default the hardware watchdog is enabled if supported. Platform compatibility This feature is supported on all Arista Hardware. Note: vEOS, vEOS vRouter and EOS on whitebox do not contain this feature. Configuration The configuration of the hardware watchdog can be done by using the “hardware system-controller watchdog” command in configuration mode. The following examples show respectively how to disable the hardware watchdog and how to re-enable it: Arista#configure Arista(config)#no hardware system-controller watchdog Arista#configure Arista(config)#hardware system-controller watchdog Status – show command The user can determine the state of the hardware...
Continue reading →

This release adds support for mapping 802.1Q tags to VNIs on a per-port basis through OVSDB when using the Hardware Switch Controller Service on CVX. The OVSDB Hardware VTEP Schema specifies VLAN bindings separately for each port. This implies that these bindings may differ from one port to another. Previously this was not supported. An attempt to map different VLANs to the same VNI or the same VLAN to different VNIs on different interfaces through OVSDB would result in the conflicting mappings being ignored. The feature must be enabled through the CVX CLI and supported by the client switch hardware. In that...
Continue reading →

Introduction These are the release notes and configuration guide for the OpenConfig feature available in the 4.20.5F EOS release. The 4.20.5F release supports reading and streaming various OpenConfig configuration and state models over gNMI (gRPC Network Management Interface), RESTCONF, and NETCONF transports. A subset of the configuration models may also be modified over these transports, see below. All client transactions that modify device configuration provide the same atomicity guarantees that are provided by sessions in the CLI. Platforms Supported All Configuration The following section outlines configuration options for OpenConfig, NETCONF, and RESTCONF transport methods. Native OpenConfig CLI gNMI Transport This...
Continue reading →

This feature adds the ability to filter out Syslog messages based on POSIX extended regular expressions. Messages matching a configured REGEX will be discarded and will not show up in the syslog. Platform compatibility This feature is supported on all platforms. Configuration The following shows how to configure syslog to discard all messages sent by the standby supervisor. Messages that are sent by the standby supervisor are prepended with “[STANDBY]”. First, a named list of regular expressions must be created. This is done through the match list configuration. The following creates a list of regular expressions named “syslogMessageFilter”. In this configuration, the...
Continue reading →

Feature Benefits This feature reduces switch downtime during an upgrade. In lieu with Arista ASU2, Vxlan ASU2 guarantees Vxlan flows with zero packet loss and worst-case 200ms traffic disruption during the upgrade. Terminology Term Definition Vxlan RFC7348 ASU2 Accelerated Software Upgrade Phase 2. Provides hitless upgrade for supported features. Hitless Restart Zero-packet loss agent restart. Staging Synchronization mechanism used by software agents to track restart progress. VTEP Vxlan Tunnel EndPoint. VTEPs are configured on Arista switches to initiate and terminate Vxlan traffic. Platform Compatibility DCS-7050(X) Operation On platforms supporting ASU2, hitless restart is triggered by the same command as before:...
Continue reading →

By default, counters are polled from hardware every 2 seconds. This enhancement allows this period to be configured, allowing for more or less frequent polling of the hardware counters. Decreasing this period will result in counter values being available for consumption more quickly, while increasing it will result in reduced CPU usage. Platform compatibility DCS-7010 DCS-7020 DCS-7050X DCS-7050X2 DCS-7280 DCS-7300 DCS-7500 Configuration Configuration can be done using update interval from within the monitor ethernet counters mode. This mode can be entered from configure mode via monitor counters mode. Entering monitor ethernet counters mode Arista(config)#monitor counters Arista(config-mon-counters)#ethernet interfaces Configuring counter period Arista(config-mon-counters-ethintfs)#update interval 0.5...
Continue reading →

Introduction Prior to this feature, Strata platforms (Please see Platform compatibility) used to support only destinationMac based match on a packet in MY_STATION_TCAM table to decide whether it should be routed or bridged. If dmac of the packet is routerMac and routing is enabled on the VLAN, packet is handled by L3 pipeline and processed. If dmac of the packet is routerMac and routing is not enabled on the VLAN(no SVI configured) the packet is still handled by L3 pipeline and is dropped. This routerMac can be normal bridgeMac, virtualMac( if VARP is enabled) or mlagPeerMac( if mlagPeerMac Gateway feature is enabled)....
Continue reading →

The PHY test pattern CLI can be used to check the quality of the physical layer for an Ethernet interface. This is done by generating a specific test pattern to a peer, and having the peer check the test pattern that is received. Because the test pattern is a well-known sequence of bits, the peer can check that the pattern received matches this well-known sequence; any difference is a bit error introduced by the peculiarities of the physical layer. The test pattern generator is enabled by configuring a specific test pattern on the transmitter side of an interface. The test...
Continue reading →

Identity tagging is an existing Tap Aggregation feature that allows a 802.1Q header to be added to packets sent by tool ports with a configurable identity value. This article describes a feature to enable QinQ identity tagging, allowing two 802.1Q headers to be added. Platform Compatibility PLATFORM INITIAL RELEASE DCS-7280R/7500R EOS-4.20.5F DCS-7280R2/7500R2 EOS-4.20.5F DCS-7280R3/7500R3/7800 EOS-4.24.1F DCS-7020R EOS-4.23.0F Frame Format The first 802.1Q header is called the “outer” header, and the second 802.1Q header the “inner” header. Configuration To enable QinQ identity tagging, a user-defined TCAM profile must be also configured. The following commands configure the user-defined TCAM profile tap-aggregation-user-qinq, based...
Continue reading →

This document provides an Arista specific solution to deliver multicast traffic in a Vxlan environment where L2 subnet has been extended over an L3 cloud. Prior to 4.20.5F, multicast traffic ingressing on a Vxlan VLAN would be flooded to all Vxlan Tunnel Endpoints (VTEPs), which may not be optimal in terms of bandwidth utilization. The solution described below uses PIM in the underlay to build a path between source and receivers. There are two main parts: Injecting the source IP address ( an address in the overlay ) into the underlay, which is needed for RPF checks. All link local...
Continue reading →

This feature allows the DHCP relay agent to insert or modify Converged Cable Access Platform (CCAP) Core IPv6 addresses in the DHCP server response. The CCAP core addresses configured at the relay agent will be included in suboption 61 inside CableLabs’ option17 in the server responses being forwarded to the client. This addition of CCAP core addresses is subject to the following conditions: when the server response already includes CableLabs’ option 17 and suboption 61, the relay agent will overwrite the previous suboption 61 with the configured CCAP core addresses when the server response already includes CableLabs’ option 17 but...
Continue reading →