• Tag : 4.22.0F

 
 

Support for Action Output Interface in DirectFlow

Description DirectFlow is a feature that allows the user to steer traffic by matching on packet headers and/or metadata using the OpenFlow semantics. This allows the user to create rules using matches and actions that are a superset of the OpenFlow 1.0 specification. Unlike OpenFlow, DirectFlow runs alongside existing layer 2/3 forwarding plane capabilities and does not require a controller or any third party integration, allowing the user to create flows from CLI. As of 4.22.0F, there is support to redirect matching traffic to a single Ethernet or LAG interface through the action ‘output interface’. Platform compatibility This TOI covers...
Continue reading →

EVPN S-IRB in Default VRF (Type-2 & Type-5 routes)

Description This feature provides a mechanism to export default VRF routes into EVPN and advertise them as EVPN type-5 IP Prefix routes. Using Host route Injection (HRI), the /32 routes will be advertised as EVPN type-2 mac-ip routes. Platform compatibility DCS-7020R DCS-7260X/7260X3 DCS-7050/7050X/7050X2 DCS-7060X/7060X2 DCS-7160 DCS-7250 DCS-7500R/7500R2/7500E DCS-7300X/DCS-7320X Topology Note: Both SVI 10 & 20 Subnets are present on VTEP1 whereas in VTEP2 there is no SVI 20 only has SVI 10. SVI 10 is in non-default (vrf core) VRF. SVI 20 is in default VRF (which we are interested in this doc) Configuration Step 1) Configure the VNI for...
Continue reading →

TAP Aggregation – Traffic Steering to Match Inner Header Fields

Description Traffic steering is an existing Tap Aggregation feature that supports redirection of traffic based on configurable policy map rules. This article describes an extension to Tap Aggregation TCAM profiles that allows matching the inner header fields (either IPv4 or IPv6 inner fields) of encapsulated traffic.   The following convention is adopted when describing an encapsulated traffic: <inner-protocol>-over-<outer-protocol>. For example, the IPv4-over-IPv6 packet indicates that the inner fields belong to IPv4 protocol and the outer fields belong to IPv6 protocol. Platform compatibility DCS-7280R/R2 series DCS-7500R/R2 series Supported packet types and inner header fields The types of traffic for which inner...
Continue reading →

IPSec Tunnels on EOS

Intro IPv4 traffic can be encrypted and carried over IPSec tunnels originating or terminating on EOS dut. A list of applicable standards pertaining to IPSec protocol is provided in RFC6071. Platform Compatibility IPSec feature for EOS is supported only on DCS-7020SRG-24C2. Configuration Overview and configuration of IPSec tunnel interfaces on EOS/vEOS platforms is documented in VEOS IPSec Support. See EOS-specific limitations for IPSec configuration below. TCAM Profile for IPSec must be configured for platform A TCAM profile must be defined in CLI which includes the IPSec feature. This profile must be specified as the active system profile. Example: hardware tcam...
Continue reading →

ISIS-SR Multiple Adj-SIDs

Description This feature allows a user to configure multiple static adjacency SIDs for an IS-IS adjacency. This feature is an extension to ISIS-SR Global Adj-SIDs and ISIS-SR Static Adj-SIDs. Multiple Adjacency SIDs is supported for both global as well as local adjacency segments. This feature is currently supported for P2P interfaces. Platform compatibility Supported on all platforms where IS-IS and MPLS are supported. This feature is available in both the ribd and the multi-agent routing models. Configuration Multiple static adjacency SIDs can be configured at the interface configuration level with the command: [no|default] adjacency-segment <ipv4/ipv6> p2p multiple index global Arista(config-if-Et1)#adjacency-segment...
Continue reading →

Transceiver tuning CLI commands 

Description This feature provides the capability to configure transceiver SERDES electrical tuning parameters. The ability to change the tuning of equalization, amplitude, emphasis from the EOS CLI command may help to improve or fix marginal links due to variability in transceiver modules. Platform compatibility This feature is platform independent. Configuration Transceiver tuning is configured under the primary interface configuration mode only. The primary interface is the first or only interface of a given multi-lane port. Syntax The following command can configure one or multiple electrical tuning parameters on one or multiple lanes. transceiver electrical lane <lane(s)> <[rx-output-amplitude <value>] [tx-input-equalization <value>]...
Continue reading →

User-defined tunnel RIBs 

Description EOS generates a single system-defined tunnel RIB for next hop resolution. When tunnels to the same destination address are learned from multiple protocols, a fixed preference that is associated with each protocol is used to determine the winning tunnel. This feature allows the creation of user-defined tunnel RIBs with: control over which protocols may contribute to the tunnel RIB the ability to override the preference for all tunnels from a protocol in order to achieve non-default ordering of tunnels the option to use it in a context where the system-defined tunnel RIB does not suffice Platform compatibility Resolution of...
Continue reading →

BGP Labeled Unicast / Segment Routing support in multi-agent mode

Description This feature implements RFC3107 that allows carrying a label stack with BGP route updates, using multi-protocol BGP. It also implements segment routing extensions that allow accepting and carrying the transitive segment-index (SID) attribute in LU route updates. This implementation is for multi-agent mode. BGP LU for ribd mode is supported since 4.17.0F, see details in the following location: https://eos.arista.com/eos-4-17-0f/bgplu/ The following BGP LU features are supported: Basic IPv4 and IPv6 BGP LU, both receiving LU updates and originating/re-advertising LU routes to other peers iBGP and eBGP peering for LU peers Using ISIS-SR (or other MPLS tunnels) as the underlay...
Continue reading →

Support for new OpenConfig paths

Description 4.22.0F 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. Please refer to OpenConfig TOI for more details on how to configure and use the OpenConfig support in EOS. Supported OpenConfig paths updates to 4.22.0F Arista Mlag arista/eos/mlag/config/domain-id,read+write arista/eos/mlag/config/dual-primary-action,read+write arista/eos/mlag/config/dual-primary-detection-delay,read+write arista/eos/mlag/config/enabled,read+write arista/eos/mlag/config/heartbeat-interval,read+write arista/eos/mlag/config/lacp-standby,read+write arista/eos/mlag/config/local-intf,read+write arista/eos/mlag/config/peer-address,read+write arista/eos/mlag/config/peer-link-intf,read+write arista/eos/mlag/config/reload-delay,read+write arista/eos/mlag/config/reload-delay-mlag-configured,read arista/eos/mlag/config/reload-delay-non-mlag,read+write arista/eos/mlag/config/heartbeat-peer-address/address,read+write arista/eos/mlag/config/heartbeat-peer-address/vrf,read+write Arista Qos...
Continue reading →

802.1X on Arista switches

Overview 802.1X is an IEEE standard protocol that prevents unauthorised devices from gaining access to the network. 802.1X defines three device roles, Supplicant (client), Authenticator (switch) Authentication server (RADIUS) Before authentication can succeed, switchport is in unauthorized mode and blocks all traffic but, after authentication has succeeded, normal data can then flow through the switchport. Description 802.1X port security controls who can send traffic through and receive traffic from the individual switch ports. A supplicant needs to authenticate itself using EAPoL packets with the switch before it gains full access to the port. Arista switches act as an authenticator, passing...
Continue reading →

BGP VPN and Inter-VRF Local Route Leaking Support for default VRF

Description This feature extends the BGP Layer 3 VPN Import/Export and VRF Route Leaking functionality to “default” VRF. Currently, these functionalities are only supported for non-default VRF. Please refer to this TOI for more details on the support for non-default VRF. EOS supports the following two types of VPN configurations and this feature is applicable for both. RFC 4364 BGP/MPLS L3 VPN (TOI Link) BGP L3 EVPN (TOI Link) This feature is available when configuring BGP in the multi-agent routing protocol model. Platform Compatibility DCS-7250 DCS-7050TX/SX/QX DCS-7060X DCS-7280R DCS-7500R Configuration Configuring BGP VPN in default VRF is similar to how it is...
Continue reading →

Secure boot

Description Secure boot is an anti tamper mechanism. It verifies the cryptographic signature embedded in an EOS SWI image to validate its authenticity. Upon startup, with the feature turned on, the Aboot bootloader is going to verify the signature against the Arista root certificate. This certificate is burnt into the switch at manufacturing time. Certificates used by Arista to sign SWIs are derived from this secure boot root certificate, allowing it to verify any image coming from Arista. If the verification is successful, the switch proceeds as usual and boots the trusted image. On the contrary, if the verification fails,...
Continue reading →

Tap Aggregation and Mirror to GRE Timestamping in UTC Time Scale

Description Previously, Tap Aggregation and Mirror to GRE timestamping only supported timestamping packets in International Atomic Time ( TAI ). This release introduces a new feature on the Sand platform to allow for timestamping packets in UTC. UTC only differs from TAI by being behind by 37 leap seconds than TAI. Additional leap seconds will then be added or subtracted by the International Earth Rotation and Reference Systems Service ( IERS ) when needed. Generally, the PTP grandmaster propagates the leap second information downstream to all its slaves. For the Arista switch to know the number of leap seconds, this...
Continue reading →

Prefix-length support for IPv6 attached-host routes

Description This feature supports generation of non-host routes for the IPv6 neighbor entries learnt on an SVI interface. These non-host routes can further be redistributed into BGP protocol to take part in the route selection decision process and to get advertised to the peers. These routes are not installed into the hardware and are only being generated for advertisement purpose. This feature works for both static and dynamic neighbors. Neighbor generated routes are also referred to as ‘attached-host’ routes in the context of this document even though the routes are non necessarily host routes ( /128 ). A neighbor will...
Continue reading →

4 Byte ASDOT Notation Support

Description This feature allows a user to configure Autonomous System Number (ASN) in Asdot notation and get the ASN in output of Bgp show commands either in Asplain or Asdot notation depending on a knob. ASN is a 32 bit integer value ranging from 0 to 4294967295. According to RFC-5396, there can be following formats for representing AS numbers: Asplain Represents AS number as a decimal integer. Range: 0 – 4294967295 Example: ASN: 42949672950 => Asplain: 4294967290 Asdot+ Represents all AS numbers using a notation of two integer values joined by a period character: <high order 16-bit value in decimal>.<low...
Continue reading →

EVPN VXLAN All-Active Multihoming

Description Ethernet VPN (EVPN) networks normally require some measure of redundancy to reduce or eliminate the impact of outages and maintenance. RFC7432 [1] describes four types of route to be exchanged through EVPN, with a built-in multihoming mechanism for redundancy. Prior to EOS 4.22.0F, MLAG is available as a redundancy option for EVPN with VXLAN, but not multihoming. EVPN multihoming is a multi-vendor standards-based redundancy solution that does not require a dedicated peer link and allows for more flexible configurations than MLAG, supporting peering on a per interface level rather than a per device level. It also supports a mass...
Continue reading →

Selective honoring for Rx PFC Pause Frames

Description This document discusses the approach taken to fulfill requirements on selective honoring of Priority Flow Control frames being received on Strata platforms. Currently, these platforms support the processing of ingressing PFC frames across priorities 0 to 7, with no option available to honor only a subset of these priorities. The current ask seeks to support such an option. Additionally, honoring only a subset of these priorities is also a requirement to support the forward PFC Watchdog action. Platform compatibility 7050s 7300s 7260s 7320s Configuration The following CLIs (additions bolded) would be added in the global scope: ld102(config)#priority-flow-control ?  ...
Continue reading →

Drop Threshold per Color per TxQueue

Description This feature can be divided into 3 parts – Enable support for different threshold per Color per TX queue – We already have different thresholds that can be set in hardware per Traffic-Class per Color.  This feature extends that by deriving the traffic class from the tx queue using tc-to-txqueue mapping and setting the threshold per color ( drop precedence ) per tx queue. Ability to map a given DSCP value to TX queue + color ( red, yellow, green ) – A qos policy-map is used on a per-interface to achieve this. The class-map has a match criteria that...
Continue reading →

EVPN VxLAN IPV6 Overlay

Description Starting with EOS release 4.22.0F, the EVPN VXLAN L3 Gateway using EVPN IRB supports routing traffic from IPV6 host to another IPV6 host on a stretched Vxlan VLAN. This TOI explains the EOS configuration and show commands. Platform compatibility Platform Supporting ND Proxy and ND Suppression DCS-7280R/7280R2 DCS-7050CX3-32S-F DCS-7050SX3-48YC12-F ( Starting in 4.22.1F ) DCS-7050SX3-48YC8 ( Starting in 4.22.1F ) DCS-7050/7050X/7050X2 ( Starting in 4.22.1F ) DCS-7260X/7260X3 ( Starting in 4.22.1F ) DCS-7060X/7060X2 ( Starting in 4.21.1F ) DCS-7250 ( Starting in 4.22.1F ) DCS-7300/DCS-7320 ( Starting in 4.22.1F ) Platform Compatibility (No ND Proxy, No ND Suppression) DCS-7020R...
Continue reading →

Interface Profiles

Description In a typical switch deployment, multiple ports can have the same configuration, such as description and access VLAN. With the interface profile feature, a user can define a set of ethernet configurations in an “interface profile.” Then, the profile can be applied to one or more ethernet interfaces, so that all the commands defined in the profile will be configured on the interface. Additionally, modifying a profile will automatically update the configurations of the interfaces that use the profile. Platform compatibility All platforms support this feature. Configuration The following shows how to configure an interface profile and an interface...
Continue reading →

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: