• Tag : 4.22.1F

 
 

Simultaneous negotiation of IPv6 unicast and 6PE capabilities in BGP

Support for negotiating and receiving IPv6 unicast and IPv6 labeled-unicast (6PE) updates from a BGP peer. Description Some deployments require IPv6 unicast and 6PE capabilities to be negotiated. An example of one such deployment involves learning routes from a route reflector which itself is getting both 6PE and IPv6 unicast routes. The goal of this feature is to add support for configuring both 6PE and IPv6 unicast on a single peer, which were previously mutually exclusive. Platform compatibility This feature would work on all platforms supporting 6PE. Configuration A new command is now available to configure both 6PE and ipv6-unicast:...
Continue reading →

Chip level next-hop backup failover support

Description This feature allows failover to backup path to occur in constant time per interface going down for features such as RSVP link protection, RSVP node protection, TI-LFA link protection, and BGP PIC. Without this feature enabled, it would take time proportional to the number of paths going over the interface experiencing the link down event to failover to the backup path. With this feature enabled, the failover time would be constant regardless of the number of paths. For example, if a given link has 1000 LSPs going over it that are all protected with a backup next-hop, the convergence...
Continue reading →

Configuration Lock

Description This mechanism allows a session to lock the configuration of the switch to prevent any other session from altering the configuration. The configuration lock is intended to be short-lived and allows a client to make a change without fear of interaction with other clients, eAPI, OpenConfig, CLI scripts, human users, etc. In order to acquire the configuration lock, a privileged user must use configure lock [ REASON ] command. Care must be taken, because if this CLI session cannot acquire the lock then an error will be issued, and the client must handle this error correctly. When the configuration...
Continue reading →

RFC 5549: IPv4 unicast NLRI with IPv6 next-hop support

Description 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). The feature enables: Negotiating Extended Next Hop Encoding capability for IPv4 unicast NLRI advertisements over IPv6 BGP sessions. In multi-agent mode IPv4 iBGP sessions are also supported. Encoding of the next-hop in the UPDATE message that allows determination of the next-hop’s address family. This...
Continue reading →

Route Map Debugging CLI 

Description This document describes a new CLI command to help debug how and why route maps permit and deny paths. The aim of this CLI command is for the user to debug a route map by specifying as input a prefix for which BGP has reachability for, either via a BGP peer or a redistribe source. The path information for this prefix is then used in the evaluation of a route map. The route map can be specified by the user, but if none is specified the route map applied to the peer is used. Any route map configured can...
Continue reading →

Tunnel Preferences and Related Enhancements

Description Configuring the IGP cost for tunnels is a feature that allows influencing the BGP best path selection for routes resolving over MPLS tunnels. It works by overriding the existing preference (which is inherited from the underlying IGP) with the user defined preference. Platform compatibility This feature is supported on all Arista devices. Configuration Tunnel preferences can be statically configured by going under the tunnel-ribs mode, selecting the tunnel rib (system or custom) and setting it for a specific protocol. bgprtr1(config)#tunnel-ribs bgprtr1(config-tunnel-ribs)#tunnel-rib custom2 bgprtr1(config-tunnel-rib-custom2)#source-protocol ldp igp-cost preference 20 Show Commands If IGP preferences for tunnels are configured, ‘show running config’...
Continue reading →

OSPFv2 Multiple Instances Support

Description EOS 4.22.1F added support for multiple OSPFv2 instances to be configured in the default VRF.  This feature provides isolation and allows segregating/dividing the link state database based on interface.  Basic OSPFv2 functionality along with redistribution of OSPFv2 routes (all instances) into BGP and default information originate always is available since 4.22.1F release. Support for graceful restart and BFD with multiple OSPFv2 instances is added in 4.23.1 release. Platform compatibility This feature is supported on all platforms. Configuration The existing OSPFv2 configuration commands remain unchanged and are used for configuring multiple OSPFv2 instances. Each OSPFv2 instance in the default VRF...
Continue reading →

Mirroring to Multiple Destinations

Description This feature adds support for allowing multiple destinations in a single monitor session. Reference TOI for support of advanced mirroring features is available here. Platform compatibility DCS-7280SE, DCS-7500E, DCS-7280R, DCS-7280R2, DCS-7500R, and DCS-7500R2 (as of EOS-4.22.1F) DCS-7280R3 and DCS-7800R3 (as of EOS-4.23.1F) Configuration The following section describes how to configure a monitor session with multiple destinations. lf121(config)#monitor session s1 source ethernet 7 lf121(config)#monitor session s1 destination ethernet 23,24,25 lf121(config)#show monitor session Session s1 ------------------------ Source Ports: Both: Et7 Destination Ports: Et23 : active Et24 : active Et25 : active lf121(config)#monitor session s1 destination ethernet 26 lf121(config)#monitor session s1 destination...
Continue reading →

High Availability for DCI solution on CVX Cluster

Description This solution builds upon the feature developed in previous releases for federating multiple instances of VCS running on CVX node using  BGP-EVPN. However one of the limitations of the DCI solution was that it did not support high availability in the CVX cluster. In case of failure of the leader node in the CVX cluster, the VTEPs would observe a traffic loss.  The high availability for DCI addresses this problem and ensures that there is no traffic loss observed by VTEPs in case of leader failure in CVX cluster. The CVX cluster is composed of an odd number of...
Continue reading →

DHCP Server on EOS

Description Support for DHCPv4 (RFC 2131)  and DHCPv6 Server (RFC 8415) was added to EOS-4.22.1 and EOS-4.23.0 respectively. The feature is based on ISC Kea. The router with DHCP Server enabled acts as a server that allocates and delivers network addresses with desired configuration parameters to its hosts.  Supported DHCP Server features include: Since EOS-4.22.1: DHCPv4 support Configurable on different interfaces: Routed, Vlan, LAG, Sub-interface, and LAG Sub-interface. Configurable lease time for allocated network addresses. Configurable DNS domain. Configurable DNS servers. Configurable subnets with parameters: Default gateway. DNS servers. Ranges. Lease time. Since EOS-4.23.0: DHCPv6 support for all features in...
Continue reading →

MSDP support for multi-agent model

Description The Multicast Source Discovery Protocol (MSDP) provides a mechanism to connect together multiple PIM Sparse-Mode (PIM-SM) domains. Through peering relationships with MSDP-speaking routers in other PIM-SM domains, an MSDP speaker can learn of multicast sources in these domains, and interested receivers in its own can then be delivered multicast data from these over an inter-domain distribution tree. Existing support is in place for MSDP with the ribd routing protocol model. EOS-4.22.1F introduces support for MSDP with the multi-agent routing protocol model. Platform compatibility This feature is platform-independent. SA Messages and RPF-Peer Selection In both the ribd and multi-agent models,...
Continue reading →

Arista Macro Segmentation Service (MSS) integration with Check Point Software Technologies Firewalls

Description This document explains how to configure and deploy Arista MSS with Check Point Software Technologies firewalls (henceforth will be referenced as just Check Point). The feature requires the use of Check Point Management Server, a security management platform by Check Point, which allows central management of Check Point gateway security devices. Platform Compatibility The feature has been tested with the following Management Server and Gateway versions: Management Server Versions Version R80.30 with API version 1.5 (and above). In addition to this Management Server version, Check Point is provided a “hot fix” that provides a “Proxy API” ability which allows...
Continue reading →

Segment Routing Traffic Engineering Policy (SR-TE) multi-agent routing model TOI

Description Segment Routing Traffic Engineering Policy (SR-TE) aka SR Policy makes use of Segment Routing (SR) to allow a headend to steer traffic along any path without maintaining per flow state in every node. A headend steers traffic into an “SR Policy”.    EOS 4.21.0F added support for SR Policy for the MPLS dataplane (SR-MPLS) for Type-1 SR Policy segments in single agent routing model. EOS 4.22.1F adds support for SR-TE in multi-agent routing model.    For a detailed description of the functional behavior please refer to the “Description” section of EOS 4.21.0F TOI for SR-TE in single agent routing...
Continue reading →

ECMP Load Balance Profile Support

Description As of 4.22.1F Load Balance Profiles can be used to explicitly configure ECMP Load Balance parameters. In addition, users can choose from up to 8 hash polynomials instead of the usual 3 for ECMP and LAG (see Limitations). Platform compatibility DCS-7280E DCS-7280R DCS-7280R2 DCS-7280R3 DCS-7020R DCS-7500E DCS-7500R DCS-7500R2 DCS-7500R3 DCS-7800R3 Configuration Load Balance Profile mode This feature extends existing Load Balance Profiles configuration (see https://eos.arista.com/eos-4-15-0f/lag-hashing/ for more information on how to configure load-balance profiles). The user can choose to modify the default profile or create a custom one.  To enter the profile mode issue the following commands. Arista(config)#load-balance policies...
Continue reading →

Support for Nexthop Group as IP Tunnels

Description Nexthop Group tunnels are a tunneling abstraction in EOS. A nexthop group tunnel is comprised of a tunnel endpoint (IP prefix) and a nexthop group name representing the underlying nexthop group that forwards the traffic. If the underlying nexthop group is not configured, the tunnel endpoint will be unreachable until the given nexthop group is configured. Platform Compatibility Platform independent Configuration The nexthop-group tunnel can be configured by the following CLI command under global config mode: ip tunnel <prefix> nexthop-group <nhg-name> To remove a nexthop-group tunnel: no ip tunnel <prefix> nexthop-group Limitations Egress tunnel counter for Nexthop Group tunnel...
Continue reading →

SSU support for L2 EVPN with VXLAN

Description Smart System Upgrade (SSU) aims to minimize traffic loss during a software upgrade. The Smart System Upgrade (SSU) process includes the core functionality of Accelerated Software Upgrade, plus additional optimizations that permit a hitless restart of several features. SSU leverages protocols capable of graceful restart to minimize traffic loss during upgrade. For protocols not capable of graceful restart, SSU generates control plane messages and buffers them in hardware to be slowly released when the control plane is offline. Additionally, under SSU, the forwarding ASIC does not get reset and ports do not flap. Starting EOS 4.22.1F SSU is now...
Continue reading →

Inter-VRF Local Connected Route Leaking

Description This feature allows the leaking of connected routes from one VRF (the source VRF) to another VRF (the destination VRF) on the same router. Connected routes can be leaked using the following methods: BGP based leaking using the appropriate import and export route targets configured on the source and destination VRFs. VrfLeak Agent based leaking using the appropriate subscription policy in the destination VRF. Leaking connected routes differs from leaking other types of routes in that it causes additional routes to be leaked. These additional routes are: Attached routes covered by the connected route being leaked. An attached route...
Continue reading →

BGP per AFI/SAFI Update Wait-for-Convergence

Description BGP update wait-for-convergence feature prevents BGP from programming routes into hardware and advertising routes to other BGP peers until a convergence event is resolved, which can reduce CPU and hardware programming churn. The existing BGP update wait-for-convergence feature can only be configured at BGP instance level (router-bgp) for all address families.  In certain EVPN deployment scenarios, BGP is used for both overlay (EVPN) and underlay (IPv4 Unicast). Overlay EVPN sessions are typically dependent on underlay IPv4 unicast routes, because EVPN sessions can only be established after underlay IPv4 unicast routes are installed. Since “update wait-for-convergence” is enabled at BGP...
Continue reading →

Pseudowire Resolution Over User-defined Tunnel RIBs

Description This feature allows configuring user-defined tunnel RIBs for the resolution of LDP pseudowire endpoints. User-defined tunnel RIBs were introduced in EOS 4.22.0F.   Applications can have different requirements and preferences for the tunnel protocols they use. This necessitates the use of separate tunnel RIBs for specific requirements. Pseudowires, too, can be configured to be resolved over user-defined tunnel RIBs. Platform Compatibility Resolution of LDP pseudowires over user-defined tunnel RIBs is available on all platforms supporting LDP pseudowires. For the full list of supported platforms, please see LDP pseudowires. Configuration The tunnel RIB used by pseudowires is configured by the...
Continue reading →

RSVP-TE Bandwidth Management

Description RSVP-TE Bandwidth management feature allows signaled paths to reserve a specified amount of bandwidth per egress interface on a Label Switching Router (LSR). Platform compatibility 7500R, 7280R family of switches Configuration To enable bandwidth management, first same set of steps should be taken as to enable RSVP-TE:  MPLS should be enabled IP routing should be enabled IS-IS should be enabled Traffic engineering should be enabled The amount of traffic-engineering bandwidth must be specified: (config-te)#interface Ethernet1 (config-if-Et1)#traffic-engineering (config-if-Et1)#traffic-engineering bandwidth [<bandwidth>]   The exact amount of bandwidth available per interface is an optional parameter. If omitted, the 75% of the interface’s...
Continue reading →

Follow

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

Join other followers: