Tag : 4.21.3F

Description ContainerTracer provides a composite view of the physical network topology and Kubernetes. Kubernetes and CVX must be installed before configuring ContainerTracer.  It is expected that all Kubernetes nodes exist in the physical topology known to CVX (show network physical-topology hosts). Configuration Creating Kubernetes ContainerTracer Role ContainerTracer requires a Kubernetes service account that has read permissions for Nodes and Pods.  It is recommended that a least privilege read-only user be created within Kubernetes.  The user and role can be created with the sample Kubernetes config below: File: containertracer_user.yml --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata:   name: containertracer-view rules:   -...
Continue reading →

Description This document explains how to configure and deploy Arista MSS with Fortinet FortiGate firewalls (also called FortiGate: Next Generation Firewall or NGFW). The feature requires use of FortiManager, a security management platform by Fortinet, which allows central management of Fortinet Network Security devices, such as FortiGate firewalls. Platform Compatibility The feature has been tested with the following FortiManager and FortiGate versions: FortiManager Versions FortiManager 5.6.2 and 6.0.1 (and above) FortiGate Versions FortiGate 5.6.3, 5.6.4 and 6.0.0 build 5056 (Interim) (and above) FortiGate Hardware Types Arista MSS has been designed to provide security integration with data center class firewalls. FG100E and...
Continue reading →

Description Many Layer 2 VXLAN deployments span more than one physical data center (DC) location. Typically, each DC has several (10’s to 100’s) VTEPs. Each VTEP typically connects a number of servers/hosts. When using VCS, each VTEP also connects to a network controller (CVX), and shares with it the L2 reachability information about its locally attached hosts. VXLAN control service (VCS), running on the CVX is used to distribute L2 reachability information (MAC-VTEP bindings) amongst all the VTEPs. This is used to orchestrate a L2 overlay network in the DC. Typically, each DC functions as a separate island with its...
Continue reading →

Description Link to old TOI: https://eos.arista.com/eos-4-15-0f/7500e-ipv4-route-scale/ The following additional commands are available in the 4.21.3F release. Configuration Starting from release 4.21.3F, the following command can be used to disable prefix optimization on the specified VRF(s) to provide more flexibility. switch(conf)#ip hardware fib optimize disable-vrf ?   WORD  VRF name Example : Disable prefix optimization on the default VRF. switch(config)#ip hardware fib optimize disable-vrf default ! Please restart layer 3 forwarding agent to ensure that the disable-vrf option change takes effect Example : Disable prefix optimization on VRFs named vrf1 and vrf2. switch(config)#ip hardware fib optimize disable-vrf vrf1 vrf2 ! Please...
Continue reading →

Description This feature provides total ingress MPLS packet and byte counters received per interface. Platform compatibility DCS-7280E/R/R2 DCS-7500E/R/R2 Configuration Ingress MPLS per-interface counter feature can be enabled/disabled using the following command: Arista(config)#[ no ] hardware counter feature mpls interface in Status Show command to display ingress MPLS packets, octets per-interface: Arista# show mpls interfaces counters Interface                 MPLSInOctets     MPLSInPkts Et1/1                       0               0               Et1/2      ...
Continue reading →

Description FIB compression allows us to program routes into the hardware more efficiently. Routes are programmed in the route table of ASIC in switches to do L3 packet forwarding, and the ASIC route table is a precious HW resource. It would be preferable to many users  if the switch can install more routes. FIB compression introduces optimizations that can make use of HW resources more efficiently, and achieve the same result of a larger HW route table size. This feature is especially helpful when there are only a few distinct adjacencies on the switch, and more routes than HW route table can install to...
Continue reading →

Description “MLAG Domain Shared Router MAC” is a new mechanism to introduce a new router MAC to be used for MLAG TOR Leaf pairs.  The user can have either explicitly configured MAC address of their choice or use the system generated MLAG system-id for this purpose.   When the MLAG shared MAC is set as the MLAG system ID value, the new shared MAC has the following properties: Unlike the bridge MAC which is different on each peer, this MLAG Domain shared router MAC has the same exact value on MLAG peers forming the same MLAG domain. This new shared...
Continue reading →

Description This is an addendum to the “IP in IP decapsulation” document https://eos.arista.com/eos-4-15-0f/ipinip-decapsulation. The Decap Group counters feature allows the device to count packets and octets that are decapsulated at the termination of the Decap Group. Platform compatibility DCS-7500E DCS-7280E DCS-7500R DCS-7280R DCS-7500R2 DCS-7280R2 Configuration The decap group counter feature can be configured with the command: switch(config)# [ no | default ] hardware counter feature decap-group Show Commands The counter features that are enabled can be displayed using the command:    switch# show hardware counter feature    Feature             Direction         Counter...
Continue reading →

Description The GRE tunnel interface ACL feature introduces the support for ACL configuration under GRE tunnel interfaces.  The configured ACL rules will be applied to the inner packet header after the GRE header decapsulation. Platform compatibility GRE tunnel interface ACL  is supported on the below Arista switches DCS-7020R DCS-7020RA DCS-7280R DCS-7280RA DCS-7500R DCS-7500RA The GRE tunnel interface ACL on DCS-7500R  is supported only if all the Linecards are -R cards. The feature is supported only on DUTs running with access list mechanism as TCAM. Configuration Configuration for setting the access-list mechanism The below command will be required to set the...
Continue reading →

Description The route-map subroutine (referred from here on as sub-route-map) configuration simplifies routing policies by sharing common policy across route-maps. Common functionality of route-maps configured as inbound/outbound BGP policies can be extracted into a separate route-map and reused using sub-route-map. EOS 4.21.3F introduces support for route-map subroutines in the multi-agent routing protocol model. The behaviour in the multi-agent routing protocol model is identical to that in the ribd routing protocol model as described in EOS-4-17-0f  Platform compatibility This feature is available on all platforms. Configuration CLI A route-map can be made to refer another route-map: route-map  map_name [ permit | deny...
Continue reading →

Description BGP Large Communities, as defined in RFC8092, is now supported within EOS. Both standard (4 octets) and extended (8 octets) BGP communities are unsuitable for 4-octet ASN values due to length restrictions. Large Communities (12 octets)  are a set of values each consisting of a 4-octet ASN value plus two 4-octet local-administrator defined values. Large communities are an optional transitive attribute of variable length. There are no predefined large-community types or values. Large communities may be configured alongside standard and extended communities within route-maps using additional configuration commands. This feature is available with the multi-agent routing protocol model and...
Continue reading →

Arista 7280R Series 40G/100G systems Multi-Speed Port Configuration Existing:  7280QR-C72 Port Layout ** NOTE: As of EOS release 4.19.0F, breakout mode is not supported on any ports between 11-26 (inclusive) and ports between 47-62 (inclusive), and these ports can only run at 1x40GbE or 1x100GbE. Changes to:  7280QR-C72 Port Layout ** NOTE: Breakout mode(4x10G) requires EOS 4.21.3F or later for ports 11,13,15,17,19,21,23,25, 47,49,51,53,55,57,59,61. ** NOTE: When running EOS 4.21.2F or older, these ports can only run at 1x40GbE or 1x100GbE. 2x50G and 4x25G breakout modes are not supported at this time on any EOS release. Existing:  7280QRA-C36S Port Layout **...
Continue reading →

Introduction Explicit Congestion Notification (ECN) is an extension to the Internet Protocol and to the Transmission Control Protocol which allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that is only used when both endpoints support it and are willing to use it. ECN operates over an active queue management algorithm. Congestion in ECN is determined by comparing the avg. queue size with thresholds. The average queue size depends on the previous average as well as the current size of the queue and is calculated using the following formula: avg_queue_size = (old_avg * (1-2^(-weight))) +...
Continue reading →

Starting from EOS-4.21.3F, license for feature BRCM-STRATA-SCHW-TP, which stands for Broadcom Strata Single Chip Hardware Third Party, is required to deploy cEOS/EOS on White Box. Following is an illustration of how cEOS/EOS White Box license is enforced, Details Expiry Warning Log In case of less than 30 days but more than 24 hours to expiration, following log is generated, %LICENSE-4-ABOUT_TO_EXPIRE: License for feature BRCM-STRATA-SCHW-TP expires in <n> days in case of less than 24 hours to expiration, %LICENSE-4-ABOUT_TO_EXPIRE: License for feature BRCM-STRATA-SCHW-TP expires today Soft Enforcement In case of license expiration, following syslog message is generated within grace period, %LICENSE-4-EXPIRED: License...
Continue reading →

Description Explicit Congestion Notification (ECN) is an IP and TCP extension that facilitates end-to-end network congestion notification without dropping packets. ECN recognizes early congestion and sets flags that signal affected hosts. The ECN field in the IP header (bits 6 and 7 in the IPv4 TOS or IPv6 traffic class octet) advertises ECN capabilities: 00 – Non ECN-capable transport, non-ECT 01 – ECN-capable transport, ECT(1) 10 – ECN-capable transport, ECT(0) 11 – Congestion encountered, CE Support has been added to match ECN bits in both Mirroring and Security ACLs (IPv4 and IPv6). This will allow these ACLs to distinguish between...
Continue reading →

Description This feature enables support for hardware-accelerated sFlow while running in Tap Aggregation exclusive mode. This article will describe how to setup accelerated sFlow, for more information please view the hardware-accelerated sFlow article. Platform Compatibility Fixed platforms 7280SR2A-48YC6 7280CR2-60 7280CR2A-60 7280CR2K-60 7280CR2-30 7280CR2A-30 7280SRAM-48C6 7280SR2K-48C6 Modular platforms 7500R2A-36CQ-LC 7500R2AK-36CQ-LC 7500R2AM-36CQ-LC 7500R2AK-48YCQ-LC Configuration Follow the standard configuration for Tap Aggregation (using exclusive mode). To configure accelerated sFlow, configure the following: (config)# ip routing (config)# sflow run (config)# sflow hardware acceleration (config)# sflow destination 10.0.0.10 (config)# sflow hardware acceleration sample 1024 To verify accelerated sFlow is functional, run the show command: (config)# show...
Continue reading →

Description This feature implements RFC 5310 that allows IS-IS PDUs to be authenticated using following secure hash algorithms (SHA): SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512. The feature is supported in both default and non-default vrf. Unlike the existing authentication scheme based on MD5 and ClearText, with this feature two IS-IS nodes can be configured with different SHA algorithm and secret-key and can still exchange IS-IS PDUs. A IS node has to be configured with one or more key-id mapping that maps a integer to a security association. Security association consists of the secret-key and algorithm to be used. The IS...
Continue reading →

If a network uses deep packet inspection for its ECMP, RFC7432 recommends deployments to use a control word in L2 EVPN MPLS encapsulated packets in the data plane to ensure frame ordering. For interoperability purposes, if there are edge devices in the topology which doesn't support control word, the control word can be optionally disabled. Platform compatibility DCS-7500R DCS-7280R DCS-7500R2 DCS-7280R2 Configuration Disable the Control Word: switch(config)#mpls evpn switch(config-mpls-evpn)#no label-stack control-word switch(config-mpls-evpn)#exit Enable the Control Word: switch(config)#mpls evpn switch(config-mpls-evpn)#label-stack control-word switch(config-mpls-evpn)#exit By default the Control Word knob is enabled. Show commands In case Control Word is disabled we can see...
Continue reading →

Description Neighbor default-originate feature is used to advertise a default route to the neighbor ( peer or peer-group ) even when a default route is not present in the BGP RIB. If a default route is present in the BGP RIB, this route will be advertised to the neighbor. When a default route is not present in the BGP RIB, one will be artificially generated and advertised to the neighbor for which this feature is configured. This artificially generated default route will not be installed in the BGP RIB. The default-route ( existing in BGP RIB or artificially generated )...
Continue reading →