• Tag : 4.22.1F

 
 

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 DCS-7280R3, DCS-7800R3 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 port-Channel 1 lf121(config)#monitor session s1 destination cpu...
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 →

Segment Routing Traffic Engineering Policy (SR-TE)

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 adds support for SR Policy for the MPLS dataplane (SR-MPLS) for Type-1 SR Policy segments with BGP and locally configured policies as sources of SR Policies on Arista’s 7500, 7280 families of switches. SR Policy Overview SR Policy Identification An SR Policy is identified using a 2-tuple of Endpoint – an IPv4 or IPv6 address which...
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 →

RSVP-TE Node Protection

Description RSVP-TE node protection is a Fast-ReRoute feature that provides protection against the failure of nexthop LSR in the protected LSP. It works by creating a bypass LSP to reach next-nexthop LSR avoiding the next LSR. In case of nexthop link or node failure, traffic is automatically rerouted using the bypass LSP. Platform Compatibility RSVP-TE node protection is supported on Arista 7500R, 7280R family of switches. Configuration Support for Fast Reroute (FRR) node protection/NNHOP (RFC 4090) is enabled by setting the Fast Reroute mode to “node-protection” in mpls-rsvp sub-mode. (config)# mpls rsvp (config-mpls-rsvp)# (config-mpls-rsvp)# fast-reroute mode node-protection Show Commands If...
Continue reading →

DSCP support for CPU generated traffic

Description The differentiated services code point (DSCP) is a 6-bit field in the IP header, which can be used to mark traffic for providing quality of service (QOS). This feature adds the support to set the DSCP value individually for NTP, DNS, Syslog, Traceroute, OSPF, and OSPF3 protocols. All protocol specific traffic leaving the switch will be marked with the configured DSCP value. In the case of NTP, DNS, Syslog, and Traceroute, the configured DSCP value will be applicable for both ipv4 and ipv6 traffic. This feature is an extension to DSCP support. Platform compatibility This feature is provided on...
Continue reading →

Support for TI-LFA FRR using IS-IS Segment Routing

Description Topology Independent Fast Reroute, or TI-LFA uses IS-IS SR to build loop-free alternate paths along the post-convergence path. These loop-free alternates provide fast convergence in the range of sub-50 ms.   The PLR ( point of local repair – the router where TI-LFA is configured ) switches to these loop-free alternate backup paths in the event of a link down ( link-protection ) or BFD neighbor down (node protection) event, protecting traffic destined to IS-IS SR node-segments/adjacency segments while the IGP converges and the post-convergence paths are computed.   EOS 4.22.1F added support for TI-LFA backup paths that protect...
Continue reading →

Dot1x – User Should Be Able to Set Access Direction

Summary When passive non-Dot1x speaking devices are connected to Dot1x port and it is expected that they would be authenticated by MAC address. These devices would not actively send packets and only respond to poll requests such as ping, arp and etc., but not Dot1x requests. These devices have ip preconfigured, and the switch would have a routed port and SVI for each of access vlans to route traffic to the connecting host/devices once they are authenticated and assigned with a vlan. With current Dot1x design switch blocks forwarding in both ingress and egress directions, and only sends out Dot1x...
Continue reading →

Follow

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

Join other followers: