• Author : Navneet Sinha

 
 

Bug Alerts

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 →

MLAG heartbeat timeout enhancement

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 →

MapReduce Tracer support for MR2

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 →

IS-IS Segment Routing

Description Segment Routing 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. 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 MPLS data-plane of IS-IS SR supporting...
Continue reading →

LDP

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 →

RFC 5838 support for OSPFv3

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 →

OSPFv3 BFD

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 →

IPv4 Addressless Forwarding on IPv6 addressed Interfaces for BGP RFC5549 support

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 →

BGP Policy config enhancements

The 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. Platform compatibility This feature is available on all platforms. Configuration CLI A route-map can be made to refer another route-map by configuring the other (referred) route-map as sub-route-map. route-map referring_map_name [permit|deny][sequence_number] [ match condition ] [ no|default ] sub-route-map referred_map_name [ set condition ] “no” or “default” variant of command will un-configure the sub-route-map. While configuring sub-route-map care must be taken to avoid cycles, which will result in...
Continue reading →

Maximum number of accepted-routes in BGP

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 →

CLI command to explain BGP best path selection

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

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 →

IS-IS over GRE tunnels

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 →

Follow

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

Join other followers: