• Tag : 4.22.0F

 
 

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 →

TOI 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 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 withdrawal mechanism...
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 TOI

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 Platform Compatibility (No ND Proxy, No ND Suppression) DCS-7020R DCS-7260X/7260X3 DCS-7050/7050X/7050X2 DCS-7060X/7060X2 DCS-7160 DCS-7250 DCS-7500R/7500R2/7500E DCS-7300X/DCS-7320X Configuration Enable IPv6 Routing First, enable global IPv6 unicast routing.  Then enable IPv6 unicast routing for each VRF. hs482(config)#ipv6 unicast-routing hs482(config)#ipv6 unicast-routing vrf tenant-c Virtual Router MAC (config-t)#ip virtual-router mac-address <mac> IPV6 SVI If...
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 →

BGP replace remote-as

Description The replace remote AS feature allows a provider edge (PE) router to change the autonomous system (AS) number used by a customer edge (CE) device, on an external BGP (EBGP) session. Enterprises, which are geographically distributed, are connected via providers. As a best practice, these enterprises use same BGP AS across multiple sites. This will cause the local AS number to be carried in AS_PATH via external BGP sessions, as illustrated in the diagram below. BGP, by default, does not accept routes with an AS path attribute that contains the local AS number to prevent routing loops. In the...
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 →

OSPFv2 Traffic Engineering

Description OSPF supports all of RFC3630 and parts of RFC4203. When configured, OSPF generates the following information in traffic engineering LSAs: Router Address TLV Link TLV Link type Link ID Local interface IP address Remote interface IP address Traffic engineering metric Maximum bandwidth Maximum reservable bandwidth Unreserved bandwidth Administrative group Shared Risk Link Group Platform compatibility This feature is supported on all platforms. Configuration To configure OSPF traffic engineering, first enter the traffic engineering mode: router ospf <id>    traffic-engineering By default, traffic engineering is not enabled in any area. To enable OSPF traffic engineering in all areas: router ospf...
Continue reading →

MLAG MaintenanceMode

Description The objective of Maintenance Mode on MLAG is to gracefully drain away the traffic (L2 and BGP) flowing through a switch that is part of the MLAG pair while the switch is put into maintenance and to gracefully add it back into the network and attract traffic again, once the switch is out of maintenance. Platform compatibility Compatible with all platforms. Configuration Maintenance Mode on a device in an MLAG Domain can only be configured for System Unit which consists of all the BGP neighbors and the interfaces. Following steps are putting device into maintenance mode: Setting mlag and non-mlag...
Continue reading →

L2 Protocol Forwarding

Description L2 Protocol Forwarding is supported on platforms listed below. The TOI for the support in earlier versions/platforms is available here. From this release onwards, we start supporting L2 Protocol Forwarding on Ethernet interfaces in addition of Type-5 PW. We also allow selective forwarding of certain L2 Protocol packets ( tagged/untagged/all ) as opposed to forwarding all LACP frames ( both tagged and untagged ) in the previous version. The protocol list on which we support L2 Protocol Forwarding has been extended to PAUSE, LACP, LLDP, MACSEC, STP. In this version we have also introduced two new interfaces level “show...
Continue reading →

Interface Reflector

Description Many a times it helps to make sure the service, that is going to be provided to a customer, is really going to work as expected and within SLA constraints. The Interface Reflector feature allows performing certain actions (such as source/destination MAC address swap) on bridged packets that are reflected back from the interface. It is useful to test properties and SLAs before deploying the service for a customer. Actions available are: Swap source and destination MAC addresses Actions can be applied to packets going in the following forwarding directions of a reflector interface: Out (egressing the interface) Platform...
Continue reading →

ACL Counters per Chip

Description ACL counters can be displayed on a per chip basis by passing an additional option in the ACL show command. The output of the new command contains the chip name, followed by all of the ACL rules. Each rule will have a count next to it (if non-zero), indicating the number of times the rule was hit on that particular chip. The chips listed in the output are all of the chips on which the ACL is configured. Platform compatibility All 7500, 7280, 7020 Configuration ACL counters per chip are turned on as long as the ACL meets the...
Continue reading →

Sampled Flow Tracking with IPFIX export

Description Network administrators require access to flow information that passes through various network elements, for the purpose of analyzing and monitoring their networks. This feature provides access to IP flow information by sampling traffic flows in ingress direction on the interfaces on which it is configured. The samples are then used to create flow records, which are exported to the configured collectors in the IPFIX format. Terminology Flow tracker : Collection of interfaces (observation points) on which samples are collected and flow records are created. It has one or more Exporters. Exporter : Device that sends flow records to one or...
Continue reading →

Follow

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

Join other followers: