Tag : 4.22.1F

Description EOS 4.22.1F release adds support for secure In-band connection between CVX and Arista switches. Prior to this release, only Out-of-band connections between CVX and Arista switches supported secure communication.    The executive summary of this change is as follows: Added support for SSL communication in tacc  Added new SSL connection and listener modules in Sysdb and Controllerdb Uses the same configuration as SSL for out-of-band CVX connections. Seamless upgrade paths (see more below) Previously, Arista switches and CVX did not support secure communication over the In-band connections between them and the following was displayed when SSL profiles were in...
Continue reading →

Description Lanz Mirroring feature allows users to automatically mirror traffic queued as a result of congestion to either CPU or a different interface.  Platform compatibility 7150S-64 7150S-52 7150S-24 7050QX-32 7050QX-32S 7050SX-72Q 7050SX-64 7050SX-72 7050SX-96 7050SX-128 7050TX-48 7050TX-64 7050TX-72 7050TX-96 7050TX-128 7050TX-72Q 7060CX-32S 7060CX-32S-ES 7060CX2-32S 7060SX2-48YC6 7050QX2-32S 7050SX2-72Q 7050SX2-128 7050TX2-128 7010T-48 7010T-48-DC Configuration Enabling LANZ Mirroring LANZ mirroring is disabled by default. In order to enable LANZ mirroring, LANZ must be enabled. Enabling LANZ mirroring will also reserve one port mirroring session. Arista(config)#queue-monitor length mirror Arista(config)#no queue-monitor length mirror Arista(config)#default queue-monitor length mirror Selecting Destination Interface When congestion occurs on any...
Continue reading →

Platform Compatibility Multi Agent, Platform independent. Show Commands Related information can be seen under the heading Update Attribute Errors in the output of:  show bgp neighbor Description This feature supports RFC 7606, which  provides improved security and robustness in the processing of errors in the BGP Update messages that are received from peer routers. In earlier releases, the BGP agent would reset the BGP peering session according to RFC 4271 (BGP for IPv4) and RFC 4760 (Multi-protocol BGP) if it detected errors in the BGP Updates received from a given peer. This feature was supported by the BGP implementation in...
Continue reading →

Description This feature makes the PTP agent aware of VLANs, running with a single Best Master Clock Algorithm (BMCA). It allows you to enable PTP on certain VLANs on a trunk port, on which PTP packets will be sent and processed. By default, enabling PTP on a trunk port will follow the previous behaviour, which is to only egress PTP packets VLAN untagged on the native VLAN and process ingress PTP packets regardless of their VLAN tag. With this feature, PTP states are now per-port per-VLAN pair and ingress/egress PTP packets on a trunk port is based on the VLAN...
Continue reading →

Description SSH certificates (as implemented by OpenSSH, introduced in version 5.4) allow for easy management of user authentication and authorization for passwordless logins, as well as host verification. User authentication is achieved through having a certificate authority (CA) that signs user public keys with its private key, while configuring sshd to trust that CA’s public key. User authorization is achieved by signing the user key with specific principals, which define which accounts the user is allowed to login as. Signing the user key with the CA private key generates the user’s certificate, which the user will present when attempting to...
Continue reading →

Description Due to hardware constraints on specific platforms, Ethernet interfaces are grouped together, within which their speeds are restricted depending on additional CLI commands discussed in this document. Each group of Ethernet interfaces is denoted a “speed group”, with configuration and management of the restricted speeds done on each speed group as opposed to each Ethernet interface individually. Each speed group is uniquely identified by the token speed-groupX, where X is composed of numbers and slashes that are vaguely related to Ethernet interfaces, i.e. 5/1.   Speeds of interfaces in a speed group are restricted based on the serdes rates...
Continue reading →

Description The VxLAN VTEP and VNI counters feature allows the device to count VxLAN packets received and sent by the device on a per VTEP and per VNI basis. Specifically, it enables the device to count bytes and packets that are encapsulated and decapsulated as they are passing through. The counters are logically split up in the two VxLAN directions:  “encap” counters count packets coming from the edge, encapsulated on the device and directed to the core, while “decap” counters count packets coming from the core, decapsulated on the device and heading towards the edge. To be able to count...
Continue reading →

Description Power over Ethernet (PoE) is a way of delivering power and data over the same Ethernet wires. There have been multiple IEEE standards for PoE over the years: 802.3af-2003 (PoE) – up to 15 W per port 802.3at-2009 (PoE+) – up to 30 W per port 802.3bt-2018 (4PPoE) – up to 90 W per port (Arista products currently only support up to 60 W per port) Arista’s PoE switches are compliant with the IEEE standards. There exist various other legacy and proprietary PoE standards. EOS is not guaranteed to work with legacy and proprietary PoE standards, but some such...
Continue reading →

Description This is an addendum to this TOI, which adds Accelerated Software Upgrade support for the 7280TR-48C6. All other features/limitations are unchanged. Platform compatibility 7280TR-48C6

Description gNOI (gRPC Network Operations Interface) defines a set of gRPC-based microservices for executing operational commands on network devices. gNOI Traceroute executes the traceroute command on the target and streams back the results. ## Get gNOI repository export GOPATH="${HOME}/go" mkdir -p ${HOME}/go/src/github.com/openconfig cd ${HOME}/go/src/github.com/openconfig git clone https://github.com/openconfig/gnoi.git ## Install grpcurl export PATH=${PATH}:${GOPATH}/bin go get -u github.com/fullstorydev/grpcurl go install github.com/fullstorydev/grpcurl/cmd/grpcurl ## Invoke the gNOI Ping RPC grpcurl -H 'username: admin' \ -d '{"destination": "'${DESTINATION}'"}' \ -import-path ${GOPATH}/src \ -proto github.com/openconfig/gnoi/system/system.proto \ -plaintext \ ${SWITCH_ADDRESS}:6030 gnoi.system.System/Traceroute ## Example RPC to ping www.google.com from switch at address ## 172.30.183.49 with 50 maximum hops...
Continue reading →

Description gNOI (gRPC Network Operations Interface) defines a set of gRPC-based microservices for executing operational commands on network devices. gNOI Ping executes the ping command on the target and streams back the results. ## Get gNOI repository export GOPATH="${HOME}/go" mkdir -p ${HOME}/go/src/github.com/openconfig cd ${HOME}/go/src/github.com/openconfig git clone https://github.com/openconfig/gnoi.git ## Install grpcurl export PATH=${PATH}:${GOPATH}/bin go get -u github.com/fullstorydev/grpcurl go install github.com/fullstorydev/grpcurl/cmd/grpcurl ## Invoke the gNOI Ping RPC grpcurl -H 'username: admin' \ -d '{"destination": "'${DESTINATION}'"}' \ -import-path ${GOPATH}/src \ -proto github.com/openconfig/gnoi/system/system.proto \ -plaintext \ ${SWITCH_ADDRESS}:6030 gnoi.system.System/Ping ## Example RPC to ping www.google.com from switch at address ## 172.30.183.49 10 times and do...
Continue reading →

Description This document focuses on the newly supported LANZ latency reporting feature on DCS-7500R and DCS-7280R. The feature allows you to display the latency associated to each congestion event reported by LANZ, using the show queue-monitor length tx-latency CLI command. This feature is compatible with both LANZ modes (polling and notifying), and available as of 4.22.1F. Platform compatibility Platform Tx-latency support DCS-7500E No DCS-7280E DCS-7500R Yes (as of 4.22.1F) DCS-7280R DCS-7020R No Note that, on a modular system, if only some linecards are compatible, then LANZ will report latencies only for these linecards. Configuration First, LANZ has to be enabled...
Continue reading →

Description Octa is a process which combines OpenConfig and certain TerminAttr functionality, primarily with the intent of servicing gNMI requests for OpenConfig paths and for “EOS native” paths. If Octa is enabled (see Configuration section below), then OpenConfig, in addition to accepting OpenConfig paths in gNMI get/set/subscribe requests, will also support EOS native paths (e.g. Sysdb/Smash paths). gNMI requests received by Octa are interpreted as either OpenConfig or TerminAttr requests, as follows.  gNMI requests containing an origin of “eos_native” are processed as TerminAttr requests.   Requests lacking an origin of eos_native are treated as OpenConfig requests. A gNMI client which supports...
Continue reading →

Description The Multicast Label Distribution Protocol ( RFC 6388 ) is an extension of LDP to support creation of point-to-multipoint (P2MP) LSPs so as to support multicast forwarding in an MPLS network. When EOS is acting as a transit node, EOS will participate in the signalling of P2MP tunnels and in traffic forwarding through the P2MP tunnels replicating as needed. Platform compatibility DCS-7280R/R2 Configuration mLDP must be configured on all EOS duts that intend to participate in P2MP tunnels. All MPLS enabled interfaces will be able to support P2MP tunnels, once mldp is enabled. The following shows the configuration (config)#mpls...
Continue reading →

Description Classification of packets based on COS/Vlan+COS bits in 802.1q header. Platform compatibility DCS-7020R DCS-7020RA DCS-7020SR-24C2 DCS-7020SRG-24C2-F DCS-7280R DCS-7280E DCS-7280R2 DCS-7280SRA DCS-7280SRM-40CX2 DCS-7280TR DCS-7280QR-C36 DCS-7280SRAM-48C6 DCS-7280TRA-48C6 DCS-7280TRA-48C6-M DCS-7500E DCS-7500R DCS-7500R2 DSC-7504 DCS-7508 DCS-7512 DCS-7516 On DCS-7504 and DCS-7508 modular chassis we support L2 Protocol Forwarding only on 7500E,7500R & 7500R2 linecards. TCAM Profile Configuration To support match on cos / vlan + cos bits, we need to apply a TCAM profile that supports matching on cos / vlan + cos bits. hardware tcam profile qos-cos feature acl port ip sequence 45 key size limit 160 key field dscp dst-ip ip-frag...
Continue reading →

Description BGP routing information often contains more than one path to the same destination network. The BGP best-path selection algorithm determines which of these paths should be considered as the best path to that network. If the best BGP path (as chosen by the algorithm) is also chosen as the winning path from among the other non-BGP paths (if any), it will be installed in the RIB and used to forward traffic to that network. The best BGP path will also be the path that is subsequently advertised to any BGP neighbors. BGP best-path steps When comparing any two paths...
Continue reading →

Description BGP routing information often contains more than one path to the same destination network. The BGP best-path selection algorithm determines which of these paths should be considered as the best path to that network. If the best BGP path (as chosen by the algorithm) is also chosen as the winning path from among the other non-BGP paths (if any), it will be installed in the RIB and used to forward traffic to that network. The best BGP path will also be the path that is subsequently advertised to any BGP neighbors. BGP best-path steps When comparing any two paths...
Continue reading →

Description 4.22.1F introduces support for ip address virtual for PIM and IGMP in MLAG and Vxlan. On a VLAN, the same IP address can be configured using ip address virtual on both mlag devices as well as on different VTEPs. Control packets are source NATed by the kernel to a chosen IP address. The source NATing fails for PIM and IGMP. To overcome this, users can configure pim ipv4 local-interface and borrow the IP address to be used on the VLAN.  PIM and IGMP bypass the source NATing in the kernel. The interface configuration pim ipv4 local-interface allows PIM and...
Continue reading →

Description Platform compatibility Hardware forwarding oThis feature introduces hardware forwarding support for IPv4 over IPv4 GRE tunnel interfaces on selected Arista Switches. The GRE tunnel interface acts as a logical interface which performs the GRE encapsulation or decapsulation. f GRE tunnel interface is supported on the below Arista switches: DCS-7050X DCS-7050X2 DCS-7050SX3 DCS-7250X DCS-7300 DCS-7060X DCS-7060X2 DCS-7260X3 Configuration Configuration for creating a GRE tunnel interface: On Local Arista Switch arista1(config)#ip routing arista1(config)#interface Tunnel 10 arista1(config-if-Tu10)#tunnel mode gre arista1(config-if-Tu10)#ip address 192.168.1.1/24 arista1(config-if-Tu10)#tunnel source 10.1.1.1 arista1(config-if-Tu10)#tunnel destination 10.1.1.2 arista1(config-if-Tu10)#tunnel path-mtu-discovery arista1(config-if-Tu10)#tunnel tos 10 arista1(config-if-Tu10)#tunnel ttl 10 On remote Arista Switch: arista2(config)#ip routing...
Continue reading →

Description Segment Routing Traffic Engineering Policy (SR-TE) aka SR Policy makes use of Segment Routing (SR) to allow a headend to steer traffic along any path without maintaining per flow state in every node. A headend steers traffic into an “SR Policy”. EOS 4.21.0F added support for SR Policy for the MPLS dataplane (SR-MPLS) for Type-1 SR Policy segments in single agent routing model. EOS 4.22.1F adds support for SR-TE in multi-agent routing model. For a detailed description of the functional behavior please refer to the “Description” section of EOS 4.21.0F TOI for SR-TE in single agent routing model. Platform...
Continue reading →