• Tag : 4.25.0F

 
 

Support for in-band traffic in a management VRF without routed SVI or physical interfaces

Description A Management VRF instance allows network operators to separate their management traffic from the rest of the production or services traffic. Previously, if there was a requirement to access the management VRF over an in-band interface (without the provision of an out-of-band management port) then an assignment of a dedicated routed SVI or physical port to that VRF would be required. This enhancement removes the need to configure a routed in-band interface in a management VRF or when IP control packets in a non-management VRF is exchanged over routes which point to special forwarding adjacencies like nexthop-groups or tunnels...
Continue reading →

Support for shared shaper across multiple subinterfaces

Description As of EOS-4.25.0F, sub-interfaces can be grouped into logical units called scheduling groups, which are shaped as a single unit. Each scheduling group may be assigned a scheduling policy which defines a shape rate in kbps and optionally a guaranteed bandwidth, also in kbps. The guaranteed bandwidth is used for oversubscription scenarios; that is, if the sum of the shape rates of all scheduling groups and sub-interfaces that are not part of groups for a parent interface exceeds the available bandwidth. Each sub-interface within that scheduling group may have its own independent shape rate. The shape rates are applied...
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 →

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 frames that exceed a configured threshold 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 be forwarded...
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. The following points of application are supported: Point of application Supported since Inbound BGP neighbor...
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 →

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 →

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 OSPFv2 and OSPFv3 dn-bit-ignore

Description This document describes the OSPFv2 and 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. OSPFv2 only honors the DN-bit in type-3 LSAs in non-default VRFs. With EOS-4.25.0F, OSPFv2 will also honor the DN-bit in type-5 and type-7 LSAs in non-default VRFs. This means that the type-3/5/7 LSAs with DN-bit set will not be used in SPF calculation and any routes carried by such LSAs will not be installed in...
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 →

Follow

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

Join other followers: