Tag : 4.20.1F

EOS release 4.20.5F adds asset tagging support that aids hardware identification by the use of user-supplied strings. Platform compatibility Fixed systems since release 4.20.5F.Modular systems since release 4.22.0F. Configuration Asset tags are configured via the CLI or eAPI using the following command: [ no | default ] hardware asset-tag <hardware> <tag> On a fixed system, <hardware> can be either switch or powersupply <1-2>, depending on the power supplies present. On a modular system, it can be chassis, or powersupply, supervisor, fabric, or linecard, followed by a slot number. For example, Arista# hardware asset-tag switch Floor3RU4 The current configuration can be viewed...
Continue reading →

Bidirectional PIM has information on Bidirectional Protocol Independent Mulicast (PIM). Additional information applicable to DCS-7020R, DCS-7280E/R/R2 and DCS-7500E/R/R2 is documented here. Platform compatibility DCS-7020R DCS-7280E DCS-7280R DCS-7280R2 DCS-7500E DCS-7500R DCS-7500R2 Limitations “Bidirectional PIM” is incompatible with “Dot1x MAB” and “Drop Mac” features. When more than one feature is configured, “Bidirectionl PIM” gets priority followed by “Dot1x MAB” followed by “Drop Mac”. If “Bidirection PIM” is enabled on platforms using Arista Algomatch, ACLs are not supported on routed multicast traffic including sparse-mode PIM

Classification of MPLS packets based on traffic-class bits in MPLS header for QoS Policy-Maps. Platform compatibility DCS-7020R DCS-7280R DCS-7280R2 DCS-7500 DCS-7500R2 Configuration 7500(config)#hardware tcam 7500(config-hw-tcam)#system profile qos 7500(config-hw-tcam)#exit 7500(config)#class-map type qos match-any class1 7500(config-cmap-qos-class1)#match mpls traffic-class ? $      end of range <0-7>  Match packets by Mpls Traffic Class value 7500(config-cmap-qos-class1)#match mpls traffic-class 4 7500(config-cmap-qos-class1)#exit 7500(config)#policy-map type qos policy1 7500(config-pmap-qos-policy1)#class class1 7500(config-pmap-c-qos-policy1-class1)#set traffic-class 3 7500(config-pmap-c-qos-policy1-class1)#exit 7500(config-pmap-qos-policy1)#exit 7500(config)#interface ethernet 3 7500(config-if-Et3)#service-policy input policy1 7500(config-if-Et3)#exit Status 7500(config)#show class-map class1   Class-map: class1 (match-any)     Match: mpls traffic-class 4 7500(config)#show policy-map policy1 Service-policy input: policy1   Hardware programming status: Successful   Class-map: class1 (match-any)...
Continue reading →

This features enables ARPs learnt on an SVI interface to be converted into Host routes which can further be redistributed into BGP protocol to take part in the route selection decision process and to get advertised to the peers. These Host routes are not installed into the hardware and are only being generated for advertisement purpose. This feature works for both static and dynamic ARPs. ARP will be converted to Host route, if the feature is enabled using the CLI (as described in the next section), and corresponding MAC address exists in the MAC table Host route will be deleted,...
Continue reading →

Introduction PIM Static Source Discovery (PIM-SM SSD) is a feature implemented as part of PIM-SM. Familiarity with setting up and configuring PIM-SM ( Sparse Mode ) and PIM-SSM ( Source Specific Multicast ) is assumed. PIM-SSM is used to deliver multicast packets from a specific source address requested by a multicast receiver. PIM-SSM bring several benefits over PIM-SM. It does not rely on the designation of a rendezvous point (RP) to establish a RP tree and then switch to Shortest-Path Tree to source. Instead, PIM-SSM builds Shortest-Path Tree to source directly since source is always known in advance. However, PIM-SSM...
Continue reading →

BFD for static routes enables monitoring of directly connected next-hop reachability using a BFD session. This is achieved by associating the next-hop of the static route with a static BFD neighbor configuration. The static route is either installed or removed based on the status of the underlying BFD session. A static route whose next-hop is configured to be tracked by BFD is referred to as a ‘BFD tracked static route’ in the context of this document. This feature is supported for both IPv4 and IPv6 static routes. Platform compatibility BFD for Static Routes feature is supported on all platforms. Configuration The existing...
Continue reading →

Overview Equal Cost Multi-path (ECMP) provides the ability to load-share traffic across multiple next-hops. When a next-hop fails or is deleted all flows are affected. This is due to the nature of the load-balancing algorithm which re-calculates a new hash for the flows based on the remaining active next-hops. Resilient ECMP keeps the total number of next-hops same by replacing the deleted next-hop with one or more of the remaining active next-hops and maintain the order of next-hops in the ECMP groupset. This feature is currently supported on the 7050, 7160, 7280, 73xx, 75xx platforms Benefits When a next-hop fails,...
Continue reading →

Introduction Link Fault Signalling (LFS) is a mechanism by which remote link faults are asserted over a link experiencing problems. Link fault signalling operates between the remote Reconciliation Sublayer (remote RS) and the local Reconciliation Sublayer (local RS). Faults detected between the remote RS and the local RS are treated by the local RS as Local Faults. Configuring LFS parameters is supported on compatible Arista switches from version EOS 4.20.1F onwards. Starting 4.20.5F LFS is also supported on DCS-7050X, DCS-7250X, DCS-7060X, DCS-7260X, DCS-7300, DCS-7320 As part of this feature FCS and Symbol errors are monitored on an interface and if they...
Continue reading →

Connectivity Fault Management (CFM) is used in Virtual Bridged Local Area Networks for detecting, isolating, and reporting connectivity faults. Please refer IEEE 802.1ag standard for more details. This document introduces to the concept of Default Maintenance Intermediate Point and how to configure it on a switch for monitoring connectivity between various Maintenance Points within a Maintenance Domain. This feature is supported from EOS-4.20.1F onwards. Platform compatibility DCS-7020R DCS-7280R DCS-7280R2 DCS-7500R DCS-7500R2 Abbreviations MD Maintenance Domain MDL Maintenance Domain Level MP Maintenance Point MEP Maintenance End Point MIP Maintenance Intermediate Point CCM Continuity Check Message LTM Linktrace Message LTR Linktrace Reply...
Continue reading →

Current Behavior Overview Filtered Mirroring allows certain packets to be selected for mirroring, rather than all packets ingressing or egressing a particular port. Platform Compatibility DCS-7010T, DCS-7050X, DCS-7060X, DCS-7250X, DCS-7260X, DCS-7300X, DCS-7280E, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R, DCS-7500R2, and DCS-7020 are supported. Configuration Note: To use this feature on the DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R and DCS-7500R2 series, a platform configuration may be required to enable the mirroring ACL profile. See the platform-specific section for instructions. Filtered mirroring is configured by creating an IPv4, IPv6 or MAC access-list and then attaching it to a monitor session. For example: Arista(config)#ip access-list acl1...
Continue reading →

Introduction Hierarchical Forwarding Equivalence Class (HFEC) changes a FEC from a single flat level to a multi-level FEC resolution. On 7280R/7500R onwards, two level HFEC is supported: the 1st level FEC points to tunnel next hops and the 2nd level FEC points to direct next hops for each of the tunnel’s next hops. HFEC has below benefits: Supports larger ECMP since only the 1st level tunnel FEC is exposed to RIB, the 2nd level interface FEC is hidden to RIB. Achieves faster convergence since tunnel FEC and interface FEC at each level can be independently updated. Supported Platforms: 7280QR-C72 7280QRA-C36S...
Continue reading →

EVPN Integrated Routing and Bridging (IRB) with VXLAN In the traditional data center design, inter-subnet forwarding is provided by a centralised router, where traffic traverses across the network to a centralised routing node and back again to its final destination. In a large multi-tenant data center environment this operational model can lead to inefficient use of bandwidth and sub-optimal forwarding.   To provide a more optimal forwarding model and avoid traffic tromboning, the EVPN inter-subnet draft (draft-sajassi-l2vpn-evpn-inter-subnet-forwarding) proposes integrating the routing and bridging (IRB) functionality directly onto the VTEP, thereby allowing the routing operation to occur as close to the...
Continue reading →

This feature is available when configuring BGP in the multi-agent routing protocol model. Ethernet VPN (EVPN) is an extension of the BGP protocol introducing a new address family: L2VPN (address family number 25) / EVPN (subsequent address family number 70). It is used to exchange overlay MAC and IP address reachability information between BGP peers [1]. EVPN supports the exchange of layer 3 IPv4 and IPv6 overlay routes through the extensions described in [2] (type 5 EVPN routes). An IP VRF is used on a Provider Edge (PE) router for each layer 3 overlay. VRF IPv4 and IPv6 routes are...
Continue reading →

The IPv6 Neighbor Discovery protocol performs Neighbor Unreachability Detection (NUD) in order to determine if two way communication with a neighboring node has failed. A neighbor is considered reachable if packets sent recently by the node have been confirmed as received by the neighbor. This can happen through a higher layer protocol such as TCP or by explicitly probing the neighbor via a Neighbor Solicitation. In normal operation, EOS will only perform NUD within a randomized range of 80-100% of the IPv6 Neighbor Cache expiry timeout. With this enhancement, EOS will perform NUD using a configured reachable time value. Platform...
Continue reading →

  Introduction These are the release notes and configuration guide for the OpenConfig feature available in the 4.20.1F EOS release. The 4.20.1F 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...
Continue reading →

Introduction Multicast-Only Fast Reroute (MoFRR) is a feature based on PIM sparse-mode (PIM-SM) protocol to minimize packet loss in a network upon link or node failures [1]. Instead of building one reverse path forwarding tree (RPF) towards RP or the source, MoFRR allows PIM-SM to build a secondary RPF tree. Upon link failure of the primary path, packet forwarding is immediately switched to the secondary path to achieve faster convergence. Feature Summary MoFRR can be enabled for a set of multicast group prefix addresses using access-control list. Once enabled, if there is an ECMP route towards the source, two RPF...
Continue reading →

DHCPv6 Prefix Delegation support enables a DHCP relay agent to program routes for addresses assigned by a DHCP server. The assigned prefixes could either be DHCPv6 IA_PD prefix delegation addresses, or DHCPv6 IA_NA global /128 addresses. The routes added for the assigned prefixes can also be redistributed into BGP. Configuration DHCP routes are not programmed by default. To enable the addition of DHCP routes, the following command must be entered in the config-if mode for the interface with ipv6 dhcp relay destination <server-ip> configured: Arista(config-if-Vl100)# ipv6 dhcp relay install routes To disable the addition of DHCP routes and to remove...
Continue reading →

Multi-hop BFD  allows for liveness detection between systems whose path may consist of multiple hops. With an existing multi-hop iBGP or eBGP session between peers whose IP addresses fall in different subnets, a multi-hop BFD session between the peers can be configured to monitor their Layer 3 connectivity. One use case is when there is a multi-hop iBGP or eBGP session between loopback addresses, multi-hop BFD can be configured between the loopback addresses.   Another use case is when there is a multi-hop iBGP or eBGP session between peer addresses belonging to interfaces that are multiple hops away, multi-hop BFD...
Continue reading →

Overview Nexthop Groups allow users to manually configure a set of nexthops by specifying their nexthop addresses and associated encapsulation information. Each Nexthop Group is referred to by a unique name and can support a single tunnel type like GRE, MPLS, etc. Static routes that directly point to Nexthop Groups can be configured. Any traffic destined to such static routes will then be forwarded via the nexthops specified in the corresponding Nexthop Group. With BGP static route redistribution, static routes pointing to nexthop groups can be redistributed along with the regular static routes pointing to nexthops. Route-maps can be applied to...
Continue reading →

IPv6 Router Advertisement Consistency Logging, when enabled, allows for notification through syslogging of incoming router advertisement inconsistencies compared to internal configuration. Detected inconsistencies may indicate that one or more routers are misconfigured, and could warrant further investigation. Consistency requirements are defined in RFC 4861 Section 6.2.7. Platform compatibility All models supported by EOS-4.20.1F Configuration IPv6 Router Advertisement Consistency Logging is disabled by default. The feature can be enabled using: Arista(config)#ipv6 nd ra consistency-check default The feature can be disabled using: Arista(config)#no ipv6 nd ra consistency-check default In order to check prefix information for consistency, the prefix must be configured on...
Continue reading →