• Tag : 4.25.0F

 
 

Deploying EVPN with IPv6 Fabric using RFC5549

Introduction To use IPv6 addresses for VXLAN underlay, there are two different approaches.  The first approach is to make use of IPv6 VXLAN tunnel (i.e. IPV6 tunnel encapsulation) for all VTEPs to VTEPs communication.  This approach is suitable for a Greenfield deployment environment where all the VTEPs are capable of supporting IPV6 VXLAN tunnels. The second approach is to use IPV4 VXLAN Tunnels while using IPv6 addresses in the Data center fabric.  In this approach, all VTEPs advertise the IPV4 VXLAN Tunnels VTEP IP with a IPv6 nexthop using RFC5549.  Because VTEPs to VTEPs are using IPV4 VXLAN Tunnels and...
Continue reading →

MRU Enforcement

Description MRU ( maximum receive unit ) enforcement provides the ability to drop giant frames on the ingress interface. Platform compatibility DCS-7020 DCS-7280R DCS-7280R2 DCS-7280R3 ( Starting in 4.25.1F ) DCS-7500R DCS-7500R2 DCS-7500R3 ( Starting in 4.25.1F ) Change Log 4.25.0F – initial release Support for MRU enforcement on Ethernet, Port-Channel and Sub-interfaces. 4.25.1F Support MRU enforcement on 7280R3 and 7500R3 platforms Support for per-chip MRU drop counter Configuration MRU is configurable per-interface, and can be configured on Ethernet and Port-Channel interfaces. Frames with size greater than the configured MRU value will be dropped on the ingress, and will not...
Continue reading →

Egress ACL counters

This feature provides the capability to count the number of packets hitting rules associated with egress ACLs applied to various interfaces in a switch. Platform compatibility DCS-7020 Series DCS-7280 Series DCS-7500 Series DCS-7800 Series Configuration Counters for each ACL will be shown only if “counters per-entry” is enabled in ACL configuration. Arista(config)#ip access-list acl1 Arista(config-acl-acl1)#counter per-entry Both IPv4 and IPv6 egress ACL counters can be enabled/disabled by user by using the following command: Arista(config)# [no|default] hardware counter feature acl out [ipv4|ipv6] IPv4 egress ACL counters are enabled by default but IPv6 egress ACL counters need explicit configuration. Status Show Commands...
Continue reading →

USB support for ZeroTouch Provisioning

Description This document details how to use the Zero Touch Provisioning ( ZTP ) USB configuration feature. Arista’s Zero Touch Provisioning is used to configure a switch without user intervention. The USB adds another way to provide the bootstrap-name and to verify the authenticity of the file-server. Existing ZTP deployment ZTP deployment requires: A working DHCP Server with option 67 (bootfile-name location) set. A working File Server to download the bootstrap file. A valid bootstrap file USB Deployment By using a USB drive during ZTP, the following features are possible: Specify the location of the bootstrap file instead of using...
Continue reading →

Egress Peer Engineering Using BGP-LU

Description Normally the ingress router in the following diagram has no control over an autonomous system border router’s (ASBR) selection of inter-AS links. The selection of the inter-AS link is determined by the bestpath selection at the ASBR. The Egress Peer Engineering (EPE) feature allows the ingress router to control which inter-AS link the ASBR forwards packets to. Using BGP-LU, EPE is accomplished by (1) the ASBR assigns a distinct MPLS label for each inter-AS link, (2) the ASBR advertises these labels to the ingress router using BGP-LU, (3) the ingress router (under direction from a controller) selects an inter-AS...
Continue reading →

Serving NTP to clients in multiple VRFs

Description The NTP service in EOS may be configured to act as an NTP server for other devices as clients.  Previously, all clients had to be reachable in the same VRF used to reach the NTP server to which EOS is synchronized. (In this document we call it the primary NTP VRF.)  This feature allows us to serve clients reachable in VRFs other than the primary NTP VRF.  This can be achieved by configuring serve all vrf for a specific VRF or by configuring ntp serve on an interface that is in a VRF other than the primary NTP VRF....
Continue reading →

Routing Control Functions

Description Routing control functions (RCF) is a new language that can be used to express BGP route filtering and attribute modification logic in a powerful and programmatic fashion. It supports a new set of workflows to define and apply these functions in EOS. The broader feature set includes: the base RCF language framework support for RCF function application to BGP neighbors support for matching and modifying BGP protocol attributes workflows to define and apply routing control functions CLI commands to provide visibility into operational status As of EOS-4.24.2F release, the following points of application are supported: Point of application Supported...
Continue reading →

Sampled Flow Tracking with IPFIX Export

Description Network administrators require access to flow information that passes through various network elements, for the purpose of analyzing and monitoring their networks. This feature provides access to IP flow information by sampling traffic flows in ingress direction on the interfaces on which it is configured. The samples are then used to create flow records, which are exported to the configured collectors in the IPFIX format. Terminology Flow tracker : Collection of interfaces (observation points) on which samples are collected and flow records are created. It has one or more Exporters. Exporter : Device that sends flow records to one...
Continue reading →

Logical Port Management

Description Logical ports are hardware resources that are required to activate interfaces. Logical ports are organized in pools, which are split between a number of interfaces. The logical port pool to interface mapping is product-specific. Some products may have a smaller number of logical ports than the total number of interfaces due to hardware restrictions. As a result, not all interfaces can be activated and pass traffic at the same time. This document describes the configuration to allocate or release a logical port to or from an interface. This configuration can be used to select a set of interfaces to...
Continue reading →

L2 Protocol Forwarding

Description L2 Protocol Forwarding has been supported since 4.21.0F. The TOI for the support in earlier versions/platforms is as follows: Level of application of L2 Protocol Forwarding profile Supported since TOI Type-5 Pseudowire Port EOS-4.21.0F Link All Ethernet Interfaces EOS-4.22.0F Link From EOS-4.22.0F release onwards, L2 Protocol Forwarding on Ethernet interfaces is supported, in addition to Type-5 PW. Also, selective forwarding of certain L2 Protocol packets ( tagged/untagged/all ) as opposed to forwarding all LACP frames ( both tagged and untagged ) is allowed since EOS-4.22.0F. The protocol list on which L2 Protocol Forwarding is supported has been extended to...
Continue reading →

OSPFv2 and OSPFv3 BFD sessions for adjacencies in any state

Description BFD sessions are only established for OSPFv2 and OSPFv3 adjacencies that are in the FULL state.  In a LAN environment this results in BFD sessions not being established for OSPFv2 and OSPFv3 adjacencies with DR Other neighbors. This feature provides configuration that enables the establishment of BFD sessions for OSPFv2 and OSPFv3 adjacencies that are in any state.  This results in the BFD sessions being established for OSPFv2 and OSPFv3 adjacencies with DR Other neighbors. Platform Compatibility Platform independent Configuration OSPFv2 BFD sessions are enabled for all OSPFv2 adjacencies in an instance when the instance level bfd default configuration...
Continue reading →

GRE Tunneling Support

Description This feature introduces the hardware forwarding support for IPv4 over IPv4, GRE-Tunnel interfaces on Arista Switches. A GRE-Tunnel interface acts as a logical interface which performs the GRE encapsulation or decapsulation. Platform Compatibility Hardware forwarding of the GRE-Tunnel interface is supported on the below Arista switches. Following products support GRE-Tunnel Intfs starting EOS 4.21.1F DCS-7020R Not supported on DCS-7020SRG DCS-7280R DCS-7280R2 DCS-7500R Linecards DCS-7500R2 Linecards Following products support GRE-Tunnel Intfs starting EOS 4.25.0F DCS-7280R3 Not supported on DCS-7280CR3MK DCS-7500R3 Linecards DCS-7800R3 Linecards Configuration Configuration for creating a GRE-Tunnel interface On Local Arista Switch arista1(config)#ip routing arista1(config)#interface Tunnel 10 arista1(config-if-Tu10)#tunnel...
Continue reading →

Consistent Policy Enforcement and Multi-VRF support for Macro-Segmentation Service

Description This document presents Arista Macro-Segmentation Service (MSS) deployment in a network with multiple Virtual Routing and Forwarding (VRF) instances. MSS can ensure more granular segmentation within a VRF, either by attracting a subset of east-west traffic to the firewall or enforcing the security objective at the top-of-rack (TOR) switches. This document also explains the policy enforcement guarantee that MSS provides in the presence of switches with varying hardware resources. Summary of Enhancements This section briefly describes the enhancements made to the current set of MSS features in this release: MSS now can be enabled in a non-default VRF in...
Continue reading →

Route-map match on next-hop for vpnv4/vpnv6 routes

Description This feature adds support to match against nexthop address for VPNV4/V6 routes. This support allows matching against the VPNV4/V6 nexthop address, i.e the remote PE’s address. The feature allows route filtering, setting communities and changing other attributes for the matching paths.  For example, the NO-ADVERTISE community could be set for a matching nexthop (a path received from a certain PE) which can be imported into a VRFs, but it will not be advertised to any CEs. Platform compatibility This feature is supported on all platforms that support MPLS VPN routing (https://eos.arista.com/eos-4-23-2f/rfc-4364-bgp-mpls-l3-vpn/). Configuration The application points for this feature include...
Continue reading →

Support for OSPFv3 dn-bit-ignore

Description This document describes the OSPFv3 feature that allows enabling or disabling the inclusion of LSAs having “Down” (DN) bit set in SPF calculations. The DN Bit is a loop prevention mechanism implemented when OSPF is used as CE – PE IGP protocol. Its usage in OSPFv3 is explained in RFC6565. By default, OSPFv3 honors the DN-bit in type-3, type-5 or type-7 LSAs in non-default VRFs. This means that such LSAs will not be used in SPF calculation, and any routes carried by such LSAs will not be installed in the routing table. This behavior can be changed by using...
Continue reading →

Set TTL for PBRed packets

Description The feature allows modification of the egress TTL of packets routed via PBR, and  to modify the TTL of naked IP/IPv6 packet and the TTL of inner header for a tunneled packet . The TTL action will be effective only when it is configured along with a set nexthop or nexthop-group action, and the nexthop/nexthop-group is resolved, and TCAM profile has the ‘set-ttl-3b’ or ‘set-ttl’ action in the ‘pbr ip’ and ‘pbr ipv6’ features, such as in the “tc-counters” system profile. Supported Platforms: DCS7500R DCS7500R2 DCS7280R DCS7280R2 DCS7280R3 (since EOS-4.25.0) Configuration: Enable tc-counters TCAM profile: (config)#hardware tcam (config-hw-tcam)#system profile...
Continue reading →

Support for deleting link bandwidth extended community without specifying value (“set extcommunity lbw delete”) or with specified AS number (“set extcommunity lbw asn delete”)

Description This feature extends link bandwidth extended community deletion mechanism, which previously always required specifying the exact community value (both BGP AS number and link bandwidth value), to now allow deletion of link bandwidth extended community attribute from path attribute without having to specify exact community value or with just specifying the BGP AS number.  The TOI which describes link bandwidth extended community deletion mechanism as it existed previously can be found here.  Note that this extended support for this mechanism is only supported in the multi-agent routing protocol model. Platform compatibility This feature is platform independent. Configuration The following...
Continue reading →

Support for set large community list

Description 4.25.0F adds support to use large community lists in the ‘set large-community’ route map set clause. This feature allows a large community list to be shared between a number of route maps. Changes to the large community list then affect all route-maps which use this list. This makes applying the same policy change to different inbound and outbound communication easier. Properties of large communities and how to create large community lists will not be covered as those are described here. Platform compatibility This feature is platform independent. Configuration The following commands have been added to route map configuration [no|default]...
Continue reading →

EVPN L3 Gateway

Description This feature adds control plane support for inter-subnet forwarding between EVPN networks. This support is achieved by advertising received EVPN IP Prefix routes (Type-5) with next-hop self. VXLAN and MPLS encapsulation are supported, and the encapsulation type used for advertised routes is dependent on the encapsulation type configured for EVPN peering. The following diagram shows an example topology where an EVPN VXLAN network exchanges Type-5 routes with an EVPN MPLS network.   Within the EVPN VXLAN and EVPN MPLS network, EVPN routes are exchanged as normal. The L3 gateway functionality is achieved by GW1/2 and GW3/4 advertising received type-5...
Continue reading →

CLI error for references to unconfigured policy constructs

Description This feature adds a configuration option which provides a CLI error if a reference is made to an unconfigured policy construct in a route map sequence. It will also provide a CLI error if an attempt is made to delete the configuration for a policy construct which is referenced in an existing route map sequence. The error only takes effect during interactive CLI sessions – i.e. when interacting directly with the CLI, or using a configuration session, or using eAPI configuration. The error does not take effect when loading the configuration at switch startup, or during configuration loading replace....
Continue reading →

Follow

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

Join other followers: