Arista EOS Central - Tag

High Availability for DCI solution on CVX Cluster

Posted on November 14, 2019 by Nitin Singh | 18 Views

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

Posted on November 13, 2019 by Huong Nguyen | 25 Views

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...
Continue reading →

MSDP support for multi-agent model

Posted on November 12, 2019 by Zach | 13 Views

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

Posted on November 12, 2019 by Mihyar Baroudi | 39 Views

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

Posted on November 12, 2019 by Manoharan Sundaramoorthy | 28 Views

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)

Posted on November 11, 2019 by Manoharan Sundaramoorthy | 146 Views

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

Posted on October 24, 2019 by Konrad | 65 Views

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

Posted on October 14, 2019 by Yuanzhi Gao | 58 Views

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

Posted on October 14, 2019 by Narendra C R | 58 Views

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

Posted on October 12, 2019 by Prashant Srinivas | 100 Views

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

Posted on October 11, 2019 by Yaonan Liang Liang | 32 Views

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

Posted on October 11, 2019 by Sharad Birmiwal | 47 Views

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

Posted on October 9, 2019 by Maxim Martynov | 35 Views

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

Posted on October 9, 2019 by Kalash Nainwal | 26 Views

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

Posted on October 7, 2019 by Nikhil Goyal | 19 Views

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

Posted on October 7, 2019 by Sandeep Kopuri Kopuri | 50 Views

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 the labelled traffic while the IGP converges and the post-convergence paths are computed. EOS 4.22.1F adds support for TI-LFA backup paths that protect IS-IS SR labeled traffic...
Continue reading →

Dot1x – User Should Be Able to Set Access Direction

Posted on October 7, 2019 by Jifei Song | 30 Views

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 →

VOQ Delete Logging Using Event-Handler Framework

Posted on October 7, 2019 by Rahul | 12 Views

Description This feature allows customers to take user-defined actions on “VOQ delete” occurrences on Arad/Jericho based platforms. VOQ deletes happen when an active VOQ does not receive any credits and no packets are dequeued from the head of the queue for a fixed period of time (credit watchdog threshold : 500 ms) which leads to the queue entering the “delete state”. All the packets in a VOQ are flushed in this state. With this feature, a user can set the threshold on number of VOQ delete occurrences for an interface within a specified time-window after which the stated action must...
Continue reading →

MPLS VPN Export Without MPLS labels

Posted on October 4, 2019 by Pradeep Goyal | 38 Views

Description RFC4364 supports exporting VRF routes into the VPN table and advertising these VPN routes to peers. Exporting the VRF IPv4/IPv6 Unicast routes as MPLS VPN routes requires MPLS labels to be allocated for each route. MPLS label allocation is supported only on some platforms. On other platforms, where MPLS label allocation is not supported, VRF routes can still be exported as VPN routes without having to allocate MPLS labels, with the support of this feature. These routes are exported with dummy labels ( explicit-null MPLS label ) if this feature is enabled. Platform compatibility This feature is supported on...
Continue reading →

DHCP Relay Across VRF

Posted on October 4, 2019 by Sourav Basu | 55 Views

The EOS DHCP relay agent now supports forwarding of DHCP requests to DHCP servers located in a different VRF to the DHCP client interface VRF. IP Version 4 Enabling VRF support for the DHCP relay agent has a prerequisite that Option 82 (DHCP Relay Agent Information Option ) is enabled. Option 82 is used by the DHCP relay agent to insert client specific information to pass on to the DHCP server. The DHCP relay agent will insert Option 82 information into the DHCP forwarded request when the DHCP server belongs to a network on an interface that belongs to a...
Continue reading →

Tag : 4.22.1F