The 7500E-6CFPX-LC linecard with ACO CFP2 optics provides connectivity over DWDM systems and links. 7500E-6CFPX-LC currently only supports connections to other 7500E-6CFPX-LC linecards. Platform compatibility DCS-7500E Enhancements for Linear CFP2-ACO Configuration Updated grid spacing values Grid spacings of 25, 12.5, and 6.25 GHz are now available for linear optics. Grid-spacings that are a multiple of these values, for example 37.5 GHz, can use a grid spacing that evenly divides it, for example 12.5 GHz. Arista(config)#interface Ethernet 3/1 Arista(config-if-Et3/1)#transceiver channel 50 grid-spacing 12.5 Configuring roll-off factor The roll-off factor is an important parameter for best link performance, with a range of...
Continue reading →

Introduction LANZ adds support for monitoring congestion on backplane (or fabric) ports on DCS-7304, DCS-7308, DCS-7316, DCS-7250QX, DCS-7260CX and DCS-7320X. In addition to monitoring congestion on backplane (or fabric), LANZ adds support for monitoring congestion on CPU ports on DCS-7050QX, DCS-7050SX, DCS-7050TX, DCS-7260QX and DCS-7060CX. LANZ streaming is also available for fabric and CPU ports. This page will only demonstrate specific commands for fabric and CPU ports, and for generic LANZ commands, refer to the existing documentation for LANZ. Platform compatibility Monitoring of both CPU and backplane (or fabric) ports is supported on the following platforms: DCS-7304 DCS-7308 DCS-7316 DCS-7250QX...
Continue reading →

The 40G-only ports on Trident 2 switches may now be configured as 1 lane of 10G, 1G, or 100M*. This may be achieved using the first lane of a QSFP+ cable or transceiver, the first lane of a QSFP+ to 4xSFP+ “octopus” cable or transceiver, or an SFP+ cable or transceiver inserted into a Mellanox MAM1Q00A-QSA QSFP to SFP adapter (QSA). Platform compatibility DCS-7050QX-32 DCS-7050QX-32S DCS-7050SX-128 DCS-7050TX-128 Limitations The bandwidth scheduler on the forwarding chip will schedule the 40G-only ports as if they were running at 40G regardless of their actual speed. * Some ports on the DCS-7050QX-32 and DCS-7050SX-128 do...
Continue reading →

This feature enables the user to configure PBR policy on an interface in the default VRF to match and forward incoming packets to a next-hop in a user defined VRF. Platform compatibility DCS-7010 DCS-7050 DCS-7050X DCS-7250X DCS-7280E DCS-7300 DCS-7500E Configuration To redirect matching incoming packets to a nexthop in a user defined VRF specify the VRF name as part of the PBR action. If multiple nexthops are provided as part of the PBR action to use ECMP, all the nexthops must be in the same VRF. The VRF specified must be configured and the nexthops should be reachable. switch#configure terminal switch(config)#policy-map type...
Continue reading →

ECMP Hash visibility CLI determines the output interface for an ECMP set based on the flow parameters supplied by the user. Ingress interface, source IP address, destination IP address and  IP protocol are the required parameters. L4 source and destination ports and VLAN identifier are optional, but should be specified if the packet has them. 7050(config)# show load-balance destination ingress-interface <interface> { src-ipv4-address <ipv4-address> dst-ipv4-address <ipv4-address> | src-ipv6-addess <ipv6-address> dst-ipv6-address <ipv6-address> } ip-protocol <protocol> [src-l4-port <port#> dst-l4-port <port#>]  [vlan-id <vlan>] Platform compatibility 7050X 7250X 7300 7050 7010 Configuration Example 1: Say, the routes programmed in system are: 7050(config)#show ip route       ...
Continue reading →

With this, IPv6 routes can be configured pointing to a static Nexthop-group of 2 types:- Type “ip” : IPv6 packets matching the route will be load balanced across the paths. This works like a regular but static ECMP. Type “ip-in-ip” : Packets matching the route will be encapsulated within an IPv6 tunnel and forwarded. Platform compatibility DCS-7050X DCS-7250X DCS-7300 DCS-7010 Configuration Configure a static Nexthop-Group route and an IP-in-IP Nexthop-Group. Arista(config)#ipv6 route 2001::1/128 nexthop-Group abc-ip Arista(config)#nexthop-group abc-ip type ip Arista(config-nexthop-group-abc)#?  entry           Nexthop Group Entry Index  size            Nexthop Group Entry Size  ttl             Time to Live...
Continue reading →

The per-port-per-VLAN feature allows application of QoS policies for IP, IPv6 and non IP traffic on a per-port-per-VLAN basis. This feature is also supported for port-channels. This feature is not supported for CoPP. Platform compatibility Here is the platform compatibility with EOS version where the feature got introduced. DCS-7010T EOS4.17.0F DCS-7050X EOS4.17.0F DCS-7250X EOS4.18.0F DCS-7300X EOS4.18.0F DCS-7280(E/R) EOS4.18.0F DCS-7500(E/R) EOS4.18.0F Configuration On DCS-7280(E/R) and DCS-7500(E/R), to use this feature, tcam profile needs to be switched to ‘qos’. Arista(config)#hardware tcam profile qos Please refer to EOS configuration guide to configure ACL policing QoS. Once created, policy-maps can be applied on single...
Continue reading →

Ingress policing on front panel ports is supported on DCS-7010X and DCS-7050X since EOS4.14.0F. When ingress policing is applied on a port-channel, it polices the matched traffic from all its member interfaces combined i.e aggregate policing and statistics. If per-interface policer is attached to a port-channel, one set of TCAM entries is created for all its member interfaces and associated port-bitmap is updated i.e aggregate policing performed on all its member interfaces. For example, if per-port policer has to allow 1 Mbps of TFTP traffic on all matched TFTP traffic on interfaces Ethernet1, Ethernet2 and a port-channel with members Ethernet3...
Continue reading →

WRED ( Weighted Random Early Detection ) is one of the congestion management techniques. It works at queue level to drop packets randomly after crossing given queue threshold even before queue is full. Without WRED, all newly arriving packets get tail dropped once the queue is full, which creates TCP global synchronization issue. WRED helps to avoid TCP global synchronization. Platform compatibility DCS-7500E DCS-7280SE Configuration This is configured at interface’s tx-queue level. The drop profile is defined by minimum-threshold, maximum-threshold and drop-probability. The units for thresholds can be given in bytes or kilo bytes or mega bytes. Arista(config)#int ethernet 1 Arista(config-if-Et1)#tx-queue...
Continue reading →

Dual Tag VLAN mapping feature defines mapping between (outer VID and inner VID of double tagged packet) and bridging VLAN. At ingress, pair of VIDs is mapped to a bridging VLAN and at egress, the bridging VLAN is mapped to a pair of VIDs. Platform compatibility DCS-7500E DCS-7280E Configuration This is a interface level configuration. Arista(config)#int eth 3/1 Arista(config-if-Et3/1)#switchport vlan mapping <outer-tag> inner <inner-tag> <bridging-vlan> Example Arista(config-if-Et3/1)#switchport vlan mapping 1000 inner 100 200 Ingress(or)Egress only vlan mappings can be configured using 'in'(or)'out' keywords Arista(config-if-Et3/1)#switchport vlan mapping in <outer-tag> inner <inner-tag> <bridging-vlan> Arista(config-if-Et3/1)#switchport vlan mapping out <bridging-vlan> <outer-tag> inner <inner-tag> Example...
Continue reading →

The feature enables support for displaying per traffic-class counters on ingress interfaces. The feature is supported on routed-ports and subinterfaces only. Both packet and octet counts are displayed. Platform compatibility DCS-7280E DCS-7500E Configuration The feature is configured as: Arista(config)#hardware counter feature traffic-class in The feature will only be enabled if the ‘tc-counters’  TCAM profile is configured. This profile can be configured as: Arista(config)#hardware tcam profile tc-counters Status Show Commands The currently configured dynamic counter features can be listed using the following show command: Arista#show hardware counter feature Feature Direction Counter Resource ... Traffic-class in 3 The counter resource allocated to the feature...
Continue reading →

Users can now define a global LAG hashing profile. The global LAG hashing profile will be applied to all linecards which do not have a specific LAG hashing profile assigned to them. Platform compatibility This feature is available starting in EOS 4.17.0F on 7500E and 7500R systems. Configuration The user selects a LAG hashing profile to be designated global 7500(config)#port-channel load-balance sand profile ? WORD Name of the load-balance profile 7500(config)#port-channel load-balance sand profile myGlobalProfile The ‘default’ profile is a special profile which cannot be deleted and will be set to global if no other profile is selected to be...
Continue reading →

This feature enables ACL functionality on subinterfaces. Platform compatibility Product Family Minimum Software Version DCS-7280E 4.17.0F DCS-7500E 4.17.0F DCS-7280R 4.18.0F DCS-7500R 4.18.0F Configuration ACLs on subinterfaces are configured using the following command: Arista(config-if-Et1.1)#ip|ipv6 access-group <acl-name> in|out ACLs on subinterfaces are unconfigured using the following command: Arista(config-if-Et1.1)#no ip|ipv6 access-group in|out Status Show Commands show ip|ipv6 access-lists <acl-name> summary shows the summary of a configured ACL including the subinterface on which the ACL is configured and active. Arista#show ip access-lists acl1 summary IPV4 ACL acl1 Total rules configured: 1 Configured on Ingress: Et5.1 Active on Ingress: Et5.1 Arista#show ipv6 access-lists acl1 summary...
Continue reading →

Support for Media Access Control Security (MACsec) with static keys was added in EOS-4.15.4. This feature brings support for dynamic Mac Security keys. To derive Mac Security keys dynamically, both peers must be configured for 802.1x authentication. One peer must be configured to be the ‘Authenticator’ and the other peer is the ‘Supplicant’. Upon a successful 802.1X authentication sequence between the peers, keying material is generated by both the authenticator and the supplicant. This keying material is then used to derive Mac Security keys to establish a MACSec Key Agreement (MKA) protocol session. The following diagram depicts a typical Mac...
Continue reading →

Per VLAN MAC Learning is a feature to enable/disable mac learning per-vlan instead of per-port. Using this feature with VxLAN could provide a poor-man version of Point-to-Point VxLAN Pseudowire services. Platform compatibility DCS-7500E DCS-7280 Configuration By default, MAC learning on a VLAN is enabled. To disable MAC learning on VLAN 10, simply issue no mac address learning command on VLAN config. 7280(config)#vlan 10 7280(config-vlan-10)#no mac address learning To bring the VLAN back to the default mode use mac address learning command. 7280(config-vlan-10)#mac address learning Status To check MAC Learning status on VLANs, issue show mac address-table command. 7280(config)#vlan 10 7280(config-vlan-10)#no...
Continue reading →

MPLS over GRE encapsulation MPLS-over-GRE encapsulation support in EOS 4.17.0 enables tunneling IPv4 packets over MPLS over GRE tunnels. This feature leverages next-hop group support in EOS. With this feature, IPv4 routes may be resolved via MPLS-over-GRE next-hop group to be able to push one MPLS label and then GRE encapsulate the resulting labelled IPv4 packet before sending out of the egress interface. Platform compatibility DCS 7500E DCS 7280SE Configuration nexthop-group group_name type mpls-over-gre size num_entries ttl ttl_value tunnel-source { intf intf | src_ip_addr } entry index push label-stack label tunnel-destination dst_ip_addr Example: switch(config)#nexthop-group nhg1 type mpls-over-gre switch(config-nexthop-group-nhg1)#tunnel-source 11.1.1.1 switch(config-nexthop-group-nhg1)#ttl...
Continue reading →

This document describes how to use the new feature, VRRP IPv6 using VRRP IPv4 MAC prefixes. RFC 5798 defines a specific mapping of VRRP Virtual Router Identifier (VRID) to a MAC prefix. For example, a VRRP IPv6 instance would use 00:00:5e:00:02:<VRID> as the virtual MAC address. The new feature would allow to over ride the RFC specification and use VRRP IPv4 virtual MAC address 00:00:5e:00:01:<VRID> prefix for IPv6 VRRP configurations. For example, an IPv6 VRRP group with VRID 10 would have a mac address 00:00:5e:00:02:0a. When the feature is configured via “vrrp ipv6 mac range ipv4“, 00:00:5e:00:01:0a will be used...
Continue reading →

Nexthop-group match in PBR policy enables the user to match incoming packets being routed to a specified nexthop-group and provide alternate action in the PBR policy to override the routing decision provided by the FIB route. Specifying the nexthop-group in the PBR policy helps improve the scale since this eliminates the need to add rules to match each destination IP. The default TCAM hardware profile doesn’t support matching nexthop-group. User needs to select TCAM hardware profile pbr-match-nexthop-group to enable this feature as shown below. Platform compatibility DCS-7500E DCS-7280E Configuration Selecting TCAM hardware profile switch(config)# hardware tcam profile pbr-match-nexthop-group Example 1...
Continue reading →

The BGP labeled-unicast (LU) RFC is used to advertise BGP routes with a stack of MPLS labels, thereby allowing distribution of MPLS tunnel paths through BGP.  The BGP peers that have negotiated labeled unicast capability can carry one or more labels as part of the network layer reachability information (NLRI) in the route advertisement. Recursive route resolution of IPv4 BGP routes using tunnels allows for BGP route nexthops to be resolved through tunnel paths received from BGP or other protocols. Platform Compatibility DCS-7500R series DCS-7500E series Configuration The following configuration commands have been added to supported this functionality. Configuration for labeled-unicast capability The following command submode...
Continue reading →

ACL based QoS programmed on SVIs can share hardware resources starting from EOS-4.17.0F. This results in a more efficient utilization of the system resources and is particularly useful for environments with a few, potentially large, QoS policy-maps applied to multiple SVIs. For more information on ACL based QoS support on SVIs, refer to ACL based Qos on SVIs. Platform compatibility DCS-7010 DCS-7050X DCS-7250X DCS-7300X Configuration By default, the sharing of ACLs is disabled. The CLI command used to enable it is: 7050(config)#hardware access-list qos resource sharing vlan in The CLI command to disable it is: 7050(config)#no hardware access-list qos resource sharing vlan in Status Show Commands...
Continue reading →

Introduction NAT Peer State Synchronization feature provides redundancy and resiliency for Dynamic NAT across pair of devices in attempt to mitigate the risk of single NAT device failure. Both devices in redundant pair are active. Both of them track new sessions and create or delete NAT entries dynamically. Essentially, an active NAT entry is maintained on both devices irrespective of who created it. Platform compatibility NAT Peer State Synchronization is supported on the following platforms: DCS-7150 Configuration The following requirements must be ensured before enabling NAT Peer State Synchronization on devices in redundant pair Both devices in redundant pair must...
Continue reading →

The guaranteed bandwidth feature ensures minimum bandwidth for outgoing lower priority traffic from a specific queue of an egress interface to prevent starvation from high-priority traffic. The guaranteed bandwidth percentage is an extension to this existing feature wherein guaranteed bandwidth can now be configured in percentage in addition to the absolute value in kbps or pps. This percentage is applied to the port speed of the egress interface. Operators may now have the flexibility to express bandwidth in percent rather than in explicit digits, which automatically adjusts based on the configured speed of the interface. As an example, if the required guaranteed bandwidth on a 40G...
Continue reading →

Bug-Alerts is a service that runs on Arista CloudVisionTM eXchange (CVX) that provides customers with information on known, resolved bugs that are impacting Arista switches. The feature collects switch properties such as EOS version, hardware platform, configuration and operating conditions of all connected switches. It uses these switch properties and a local database of known bugs to determine the list of impacting bugs for each switch. This information is then displayed via show commands on CVX. The complete Bug-Alerts feature consists of the following components: CVX components AlertBase – This is the database of known and resolved bugs in Arista...
Continue reading →

The show command ‘show qos interface fabric’ was introduced for DCS-7250QX and DCS-7300X series starting EOS-4.15.2F release, which just displayed the Qos profile applied on the fabric interface. This command has now been modified to display detailed information about configured/operational values of interface Qos configurations, as is shown by the command – ‘show qos interfaces <intfName>’ for front panel ports. Variants of the command have also been added to display information of fabric ports across all chips and to display ECN thresholds for ECN configuration on the ports. Platform compatibility DCS-7250X DCS-7300X Configuration All configurations on the fabric port is through...
Continue reading →

In an MLAG setup, periodic TCP/UDP heartbeats are sent over peer-link to ensure IP connectivity between peers. Prior to EOS-4.17.0F release, a heartbeat timeout on MLAG primary/secondary causes MLAG state to become inactive and leads to spanning-tree topology changes, LACP port-channel link-flaps etc. From EOS-4.17.0F onwards, a heartbeat timeout on MLAG primary/secondary doesn’t cause MLAG state change, instead MLAG will remain in same state and also remain active. Status CLI command “show mlag detail” captures statistics related to heartbeat timeout events. Configured heartbeat interval : 4000 ms Effective heartbeat interval : 4000 ms Heartbeat timeout : 60000 ms Last heartbeat...
Continue reading →

As of EOS-4.17.0F, BFD support has been enhanced with support for configuring BFD within VRFs, improved scalability and cleanly disabling BFD sessions. This latter enhancement, referred to as AdminDown support, makes it possible to disable BFD configurations without the remote peer interpreting the BFD state change as a session failure. In most instances this non-disruptive BFD disablement is performed automatically upon changing the BFD configuration. Situations which would still be disruptive are cases where the interface which the BFD session is operating over is disabled or reconfigured to be incompatible with BFD. Examples include, the switchport or no vlan 1234...
Continue reading →

The VxLAN VTEP counters feature allows the device to count VxLAN packets received and sent by the device on a per VTEP basis. Specifically, it enables the device to count bytes and packets  that are getting 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 VxLAN packets the device has to support VxLAN and have a VxLAN interface...
Continue reading →

MapReduce Tracer is an existing feature that monitors MapReduce nodes that are directly connected to Arista switches. In 4.17.0F release, support has been added to monitor nodes running YARN version (MapReduce version 2) of Hadoop. The following versions of Hadoop distributions have been tested: Apache 2.6.0 Cloudera CDH 5.4.0 HortonWorks HDP 2.2.4.2 Configuration When the cluster is running YARN version of Hadoop, the following cluster information needs to be configured in MapReduce Tracer feature configuration mode. Arista(config)#monitor hadoop Arista(config-monitor-hadoop)#cluster CL1 Arista(config-monitor-hadoop-CL1)#resource-manager 1.1.1.1 port 8088 This configures 1.1.1.1 and 8088 as the IP address and port of the server where YARN...
Continue reading →

QoS profiles are a collection of interface level QoS configuration commands, that are used as an alternate means of input to the traditional CLI. They help in reducing clutter in the running configuration. A possible use-case would be when there are common QoS configuration statements that need to be applied or modified on multiple interfaces. Introduced first for the DCS-7250QX and DCS-7300X series with the EOS-4.15.2F release, they have been improved upon in this release. Previously, they were applicable only on the fabric interface and supported priority flow control, tx-queue ECN, WRED and guaranteedBandwidth configurations. Now they are also applicable...
Continue reading →

L3 interface ingress counters can be used to count routable traffic coming into the box on sub-interfaces and vlan interfaces with L3 address (IPv4 and/or IPv6 address) configured. Such traffic will get accounted irrespective of routing decision. L3 interface counters are not supported on routed ports. Platform compatibility DCS-7050X DCS-7250X DCS-7300X series Configuration L3 interface ingress counters for subinterfaces can be enabled using the following configuration: 7050(config)#[no] hardware counter feature subinterface in L3 interface ingress counters for vlan-interfaces can be enabled using the following configuration: 7050(config)#[no] hardware counter feature vlan-interface in Note that L3 interface ingress counters are not enabled by default on the...
Continue reading →

Segment Routing provides mechanism to define end-to-end paths within a topology by encoding paths as sequences of sub-paths or instructions. These sub-paths or instructions are referred to as “segments”. IS-IS Segment Routing (henceforth referred to as IS-IS SR) provides means to advertise such segments through IS-IS protocol as per the guidelines in IETF draft : draft-previdi-isis-segment-routing-extensions. This feature is supported in EOS from release 4.17.0. IS-IS SR feature provides knobs to configure various types of segments which are distributed as part of IS-IS LSPs (Link State PDUs) and may get instantiated as LFIB (Label Forwarding Information Base) entries in the...
Continue reading →

The Label Distribution Protocol (LDP) is a protocol in the Multiprotocol Label Switching (MPLS) context that allows label switch routers (LSRs) to exchange label mapping information. It is a distributed protocol without a central controller. Instead, each LSR generates local label mappings for Forward Equivalence Classes (FECs) and propagates this information to adjacent LSRs which it maintains LDP sessions with. LDP is supported starting from EOS 4.17.0F on the 7500E and 7280E series. Configuration For CLI configuration details, please refer to EOS Config Guide. The LDP protocol is enabled in the mpls ldp configuration section. Arista(config)#mpls ldp Arista(config-mpls-ldp)#no shutdown By...
Continue reading →

EOS-4.17.0F adds support for IPv4 address family in OSPFv3 (multiple address family support) based on RFC5838. OSPFv3 instances are now associated with either IPv4 or IPv6 address family and the respective routes are advertised. This feature enables configuring and managing networks using the same IGP for both IPv4 and IPv6 routing. A single OSPFv3 instance is supported per address family per VRF. This implies that address family and VRF can uniquely identify an OSPFv3 instance. OSPFv3 IPv4 packets use IPv6 as the underlying transport, hence IPv6 needs to be enabled both in the VRF as well as on the interface, even if only IPv4 routing...
Continue reading →

EOS-4.17.0F adds support for BFD in OSPFv3. BFD provides a faster convergence in scaled deployments where using aggressive times may cause scalability issues. This also addresses scenarios which need sub-second hello timers , which is not supported in EOS. Platform compatibility OSPFv3 BFD feature is supported on all platforms. Configuration This feature can be configured in two ways. The following command is available under the config-router-ospf3 mode. Arista(config)#ipv6 router ospf <Ospf Process ID> Arista(config-router-ospf3)#[ no | default ] bfd all-interfaces This enables or disables BFD for all OSPFv3 interfaces. It is disabled by default. The following command is available under...
Continue reading →

This feature provides support for advertising IPv4 unicast Network Layer Reachability Information (NLRI) with IPv6 next-hops over IPv6 peering sessions described as the Extended Next Hop Encoding capability in RFC5549. Extended Next Hop Encoding capability can be supported for IPv4 unicast, IPv4 Labeled Unicast, and IPv4 VPN address and sub-address families (1/1, 1/4, 1/128 respectively). In this release, the feature enables negotiating Extended Next Hop Encoding capability for IPv4 unicast NLRI advertisements over IPv6 BGP sessions, and encoding of the next-hop in the UPDATE message that allows determination of the next-hop’s address family. Platform compatibility This feature is provided on...
Continue reading →

This feature enables dataplane forwarding of IPv4 traffic on interfaces that are not IPv4 address enabled, but only configured with an IPv6 address. This capability is required to forward IPv4 unicast traffic based on IPv4 NLRI (routes) learnt from BGP peers where the NLRI information is received with IPv6 Next-hops (RFC 5549 – extended next-hop encoding). IPv4 Addresses are typically not configured on peering interfaces that exchange such routes. Unless this feature is enabled, IPv4 packets received on interfaces without IPv4 addressing will be dropped. Platform compatibility This feature is provided on all platforms. But the feature does not need...
Continue reading →

Currently, the ‘maximum-routes’ knob allows one to set an upper bound on the number of routes that can be received from a neighbor. The ‘maximum-accepted-routes’ feature provides the ability to set an upper bound on the number of routes that can be accepted from a neighbor after filtering. When the limitation is exceeded, the peer session will be put into Idle state indefinitely. The session can be reactivated by issuing one of the ‘clear ip bgp neighbor’ commands or by configuring the bgp idle restart interval (see Reference section below). Platform compatibility This feature is provided on all platforms. Configuration...
Continue reading →

The eBgp “ip next-hop unchanged” feature allows a router to send routes to its eBgp peers without changing their next-hops to its own peering address. By default a Bgp router, as defined in RFC 4271, changes the next-hop attribute of a route to its own address before sending it out to its eBgp peer. The router uses third party address as next-hop when the eBgp peers are within the same subnet as the source of the prefixes. Users may need further flexibility for multihop eBgp peer other than the above cases. If the command proposed by this feature is configured,...
Continue reading →

The eBgp “ip next-hop unchanged” feature allows a router to send routes to its eBgp peers without changing their next-hops to its own peering address. By default a Bgp router, as defined in RFC 4271, changes the next-hop attribute of a route to its own address before sending it out to its eBgp peer. The router uses third party address as next-hop when the eBgp peers are within the same subnet as the source of the prefixes. Users may need further flexibility for multihop eBgp peer other than the above cases. If the command proposed by this feature is configured,...
Continue reading →

This feature provides the ability to track the reason why a BGP path is excluded from the BGP best path selection process. For a given prefix, the show command output indicates how the winning best path was determined by adding a reason next to every losing path. Please refer to the full BGP best path selection process document for more details. BGP best path selection process Platform compatibility This feature is provided on all platforms. Status Show Commands The explanation for the BGP best path selection process decision can be found within the output of show ip bgp <prefix> detail...
Continue reading →

IS-IS adjacency-uptime describes the uptime or downtime of neighbors since the last state change. Status show isis neighbor detail can be used to know the adjacency uptime of neighbors. The output shown below states that the neighbor router is in the UP state for 15 mins and 40 seconds. Arista1#show isis neighbor detail Instance VRF System Id Type Interface SNPA State Hold time Circuit Id 1 default 1720.1600.2002 L1 Ethernet1 2:1:0:2:0:0 UP 7 1720.1600.2002.04 Area Address(es): 49.0001 SNPA: 2:1:0:2:0:0 Advertised Hold Time: 9 State Changed: 00:15:40 ago LAN Priority: 64 IPv4 Interface Address: 10.1.2.4 IPv6 Interface Address: none Interface name:...
Continue reading →

This feature enables an Arista switch to run the IS-IS routing protocol over a tunnel interface to another IS-IS neighbor when the switch and neighbor are separated by one or more IP networks.  Because IS-IS is not an IP protocol, GRE is used as the tunnel encapsulation service since GRE packets can handled by IP networks.  A GRE tunnel can also be used to avoid creating IS-IS state on transit networks between two IS-IS neighbors. Two tunnels are required in order to provide a virtual bidirectional link between separated IS-IS neighbors A and B. One tunnel originates at neighbor A...
Continue reading →

Arista Platform Independent Features IS-IS over GRE tunnels IS-IS adjacency uptime CLI command to explain BGP best-path eBGP IP next-hop unchanged Maximum number of accepted routes in BGP BGP Policy config enhancements IPv4 Addressless Forwarding on IPv6 addressed Interfaces for BGP RFC5549 support RFC 5549 support for BGP OSPFv3 BFD RFC 5838 support for OSPFv3 (AF support) LDP IS-IS Segment Routing QoS Profiles MapReduce tracer support for MR2 BFD enhancements MLAG heartbeat timeout enhancements Port-Channel member-status logging CloudVision eXchange Bug Alerts Arista 7010/7050X/7250X/7300X Specific Features L3 interface ingress counters VxLAN VTEP counters Classification based on DSCP + ECN Show command for...
Continue reading →