Multicast-Only Fast Reroute

Introduction Multicast-Only Fast Reroute (MoFRR) is a feature based on Pim sparse-mode (Pimsm) 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 Pimsm 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. Configuration 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 trees towards...
Continue reading →

DHCPv6 Prefix Delegation

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

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 →

BGP redistribution of static routes pointing to Nexthop Groups

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

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.0F 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 the receiving interface using...
Continue reading →

BGP Monitoring Protocol

Introduction BGP Monitoring Protocol (BMP) [1] allows a monitoring station to connect to a router and collect all of the BGP announcements received from the router’s BGP peers. The announcements are sent to the station in the form of BMP Route Monitoring messages formed from path information in the router’s BGP Adj-Rib-In tables. A BMP speaker may choose to send either pre-policy routes, post-policy routes, or both. BMP is unidirectional: Messages are sent from the router to the monitoring station. No messages are ever sent from the monitoring station to the router. The information sent to a monitoring station is controlled by the router’s...
Continue reading →

MP BGP for v4 multicast

Introduction The feature MP-BGP v4 Multicast provides a way to populate the MRIB (Multicast Routing Information Base).  MRIB is an alternate routing table used in PIM’s RPF (Reverse Path Forwarding) lookup.  Up until now, there was only one way to populate the routes in the MRIB.  Users can add a static route into the MRIB via the ip mroute command.  With BGP support for multicast SAFI in EOS 4.20.0F, users can advertise multicast static routes and connected routes to other PIM routers.  These routes learned via BGP are stored in the MRIB. Additionally, users should be aware that the RPF lookup algorithm...
Continue reading →

OSPFv3 Flood Pacing

EOS-4.20.0F adds OSPFv3 flood pacing support that allows configuring the minimum interval between the transmission of consecutive LS update packets. This feature prevents the draining of the flood queue at once generating multiple LS update packets. Flood pacing helps mitigate high CPU or socket buffer utilization issues observed when a large number of LSAs get flooded at once. Increasing the flood pacing interval will help reduce LSA flooding in scenarios where the LSDB is being updated frequently. It should be noted that in case of large OSPF LSDBs, increasing the flood pacing interval to a larger than requried value will lead to convergence delays....
Continue reading →

RFC 7606: BGP enhanced error handling

This feature supports RFC 7606 to provide improved security and robustness in the processing of errors in the BGP Update messages that are received from peer routers. In the earlier releases, the Rib 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 will provide the following new functionality:   Treat-as-withdraw: In certain scenarios, the malformed BGP Update will be treated in such a way that all contained routes have been withdrawn by the peer instead of being installed in...
Continue reading →

UCMP for LU over v4/v6

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. This feature enables deriving and using link-bandwidth attribute for BGP LU paths which further enables applying weighted nexthop sets for BGP LU routes installed in IP FIB and for IP routes resolving over LU tunnel routes. As part of UCMP support for BGP LU routes, the following functionality has been added: IP routes resolving over BGP LU routes should be able to inherit the link-bandwidth information from the resolving BGP LU route (if the...
Continue reading →

IS-IS Graceful Restart

IS-IS Graceful Restart adds support for Restart Signaling for IS-IS, IETF RFC 5306. When IS-IS is used as the IGP, the following EOS features require NSF and support for the graceful restart from IS-IS: ASU2 – Software upgrades. SSO – Planned SSO initiated by an operator for maintenance or Unplanned SSO due to failures on the active supervisor. RIB agent restart due to software failures. With IS-IS Graceful Restart (GR) configured, a redundancy switchover from active to standby supervisor or ASU2 or restart of the IS-IS software (the RIB Agent) should, if the GR completes successfully, be a hitless event.  Which means that neighbor routers continue to...
Continue reading →

URL based import of AS path access lists

This feature adds the capability to import as path access-list from a URL, in release 4.20.0F.  The file specified by the URL can contain one or more as-path access-list entries. All the entries that are in the file are added to the as-path access-list being configured. This feature gives the advantage of using one EOS CLI command to configure many as-path access-list entries, instead of adding each one of them line by line in the CLI.   Platform compatibility This is a platform independent feature.   Configuration [no] ip as-path access-list list_name source URL duplicate DUPLICATE_HANDLING Parameters list_name         the name...
Continue reading →

BGP Aggregate Address Advertise-only

The aggregate address advertise-only feature adds the capability of NOT installing the Null0 route in the FIB/kernel for an aggregate route while still advertising it to BGP peers. By default, BGP aggregates are installed as a drop/Null0 route which will blackhole destinations in the aggregate prefix’s range that don’t have a more specific route. With this feature enabled, the drop/Null0 route is not installed thereby allowing a covering route (say the default route) to route such traffic. Configuration The CLI option will appear under the “aggregate-address” command in router-bgp mode.  The full syntax of the CLI is given below with...
Continue reading →

BGP route-map match on route type

Introduction This feature adds support for a ‘match route-type’ route-map match clause in release 4.20.0F. This clause allows filtering routes based on the peer from which the route was learned. Specifically, the user can match on ‘external’, ‘internal’, ‘local’, or ‘confederation-external’ which match on EBGP, IBGP, locally originating (e.g. aggregate), or confed-EBGP routes, respectively. This clause has a wide range of potential use cases. One use case is to add specific communities to all externally (EBGP) routes prior to propagating them into a customer’s network. Configuration In order to configure this feature, the following command is configured in the route-map...
Continue reading →

Expanded VRRP, VARP, and MLAG Peer Gateway Virtual MAC Capabilities on the 7500R, 7280R, 7500R2, 7280R2, 7020R Series

EOS-4.20.0F introduces expanded VRRP, VARP and MLAG Peer Gateway virtual MAC capabilities on the 7500R, 7280R, 7500R2, 7280R2, and 7020R series because of improved hardware capabilities. The highlights are: Simultaneous support for VRRP, VARP and MLAG Peer Gateway. VARP and MLAG Peer Gateway take priority over VRRP Support for IPv4 and IPv6 Dual Stack VRRP Platform Compatibility DCS-7500R/R2 series DCS-7280R/R2 series DCS-7020R series Configuration For detailed VRRP, VARP, and MLAG Peer Gateway configuration information and examples please refer to links in the Resources section. Hardware oversubscription on the 7500R, 7280R, 7500R2, 7280R2, and 7020R series is defined as exceeding 16 virtual...
Continue reading →

Tap aggregation – traffic steering on MPLS labels

This article describes the Tap Aggregation Traffic Steering on MPLS Labels feature. The purpose of this feature is to allow steering of MPLS packets based on their labels. A packet is considered an MPLS packet when the first header is Ethernet with Ethertype=0x8847 (MPLS). Platform compatibility DCS-7280E DCS-7280R DCS-7500E DCS-7500R DCS-7280R2 Configuration TCAM profile This feature requires the tap-aggregation-extended TCAM profile. The profile should be specified when enabling Tap Aggregation, for example: 7500(config)#tap aggregation 7500(config-tap-agg)#mode exclusive profile tap-aggregation-extended MPLS labels rules MPLS labels rules are specified in the MAC access-list rules for MPLS-type packets. The rules can match on any of the MPLS...
Continue reading →

Connectivity Monitor

Connectivity Monitor is an EOS feature that allows users to monitor their network resources from their Arista switches. The resources being monitored may or may not be Arista devices. Connectivity monitoring is unidirectional in nature and uses simple tools like ICMP ping and HTTP Get requests to determine connectivity to any network reachable device   Supported Platforms This feature is supported on all platforms Configuration Connectivity Monitor is configured under the monitor-connectivity submode: Arista(s1)(config)# monitor connectivity Arista(s1)(config-mon-connectivity)#? interval Configure connectivity probe interval host Configure host parameters shutdown Shutdown connectivity monitoring Host is used to configure the end points being monitored....
Continue reading →

EAPI configurable in multiple VRFs

This feature allows eAPI to run in multiple non-default VRFs on the same physical router. In this way, users can configure Arista switch through eAPI from both default and management VRF. Platform compatibility This feature works in all platform. Configuration To run eAPI in more than one VRFs, from “management api http-commands” mode, you can enter each VRF mode by command “vrf <vrfName>”. In this submode, you can enable or disable eAPI running in each VRF, including the default VRF, by typing “[no|default] shutdown”. If no VRF is configured and eAPI is enabled then it will run in default VRF. Note: for backward compatibility,...
Continue reading →

Config Checkpoint

  Config checkpoint mechanism provides a shortcut to copy the current running-config into a file stored in checkpoint directory. Checkpoint can be made specifically by the user or it will be generated automatically before session commit or configure replace. Checkpoint allows user to preserve a series of snapshots of running-config in the flash and reload later. It can be used as a backup to rollback to previous config, or it can be saved as a configuration template to be operated multiple time in the future. Platform compatibility Config checkpoint works on all EOS platforms. Configuration To make a checkpoint: Arista#configure...
Continue reading →

LANZ on 7160 series

  Introduction LANZ on 7160S-32CQ,  7160-48YC6 and  7160-48TC6 adds support for monitoring congestion on front panel ports with Start, Update and Stop congestion events. This feature is supported on 7160 from EOS version 4.20.0 onwards. Platform compatibility 7160S-32CQ 7160-48YC6 7160-48TC6 Configuration LANZ can be enabled on the switch with the following command: 7160(config)#queue-monitor length This enables LANZ on all front panel ports with the default high and low threshold values. LANZ can be disabled on interface Ethernet1 with the following command: 7160(config-if-Et1)#no queue-monitor length 7160 uses a default high threshold of 450 pages and low threshold of 128 pages: 7160(config-if-Et2)#default queue-monitor length thresholds...
Continue reading →