• Tag : 4.23.1F

 
 

BGP nexthop resolution RIBs

Description This feature adds support for user-configured BGP Nexthop Resolution RIB profiles for various BGP-based services e.g. IP unicast, L3 VPN, EVPN, etc. The feature allows an administrator to customize the next hop resolution semantics of BGP routes with an ordered list, or profile, of resolution RIB domains (i.e., either tunnel or IP domain). This allows EOS to direct specific services over the specified RIB domains, overriding the default behavior. Further, this feature, through the use of user-defined tunnel RIBs, empowers an administrator to further select a subset of tunnelling protocols for specific services. Refer to User-defined tunnel RIBs for...
Continue reading →

OSPF routes over GRE tunnels

Description This feature introduces the support for OSPF routes over GRE tunnels under default as well as non-default VRFs. The feature is disabled by default. Platform compatibility DCS-7050X DCS-7050X2 DCS-7250X DCS-7300 DCS-7060X DCS-7060X2 DCS-7260X3 CCS-720XP (Starting in EOS 4.22.1F) DCS-7050SX3 (Starting in EOS 4.22.1F) DCS-7010T (Starting in EOS 4.23.0F) 7368 (Starting in EOS 4.23.1F) vEOS router DPDK mode (MODE=sfe in /mnt/flash/veos-config) Starting 4.24.1F DCS-7020 Not supported on DCS-7020SRG DCS-7280R DCS-7280R2 DCS-7500R Linecards DCS-7500R2 Linecards Starting 4.25.1F DCS-7280R3 Not supported on DCS-7280CR3MK DCS-7500R3 Linecards DCS-7800R3 Linecards Starting 4.25.2F OSPFV3 over GRE Not supported on DCS-7250X, DCS7010T, DCS-7280 Configuration The OSPF ‘tunnel...
Continue reading →

IP Locking + Release Updates

Description IP Locking is an EOS feature configured on an Ethernet Layer 2 port.  When enabled, it ensures that a port will only permit IP and ARP packets with IP source addresses that have been authorized. As of EOS-4.25.0F release update, IP locking can run in two modes – IPv4 Locking (which will be referred to as IP Locking) and IPv6 Locking, which can be configured using the commands mentioned in the below sections. IP Locking prevents another host on a different interface from claiming ownership of an IP address through ARP spoofing. IPv6 Locking extends this behavior to IPv6...
Continue reading →

MLAG Dual Primary Detection and Release Updates

Description When the MLAG peer-link goes down, the secondary peer assumes the primary peer is down/dead, and takes over the primary role. It is possible that when peer-link is down, the primary isn’t actually down/dead and both MLAG peers think they are the primary. This is called “dual-primary” condition/state. In this state, each peer will run Layer-2 protocols such as Spanning Tree Protocol independently. Depending on the topology, this can cause loops in the network. This can also impact the IGMP snooping feature. The Dual Primary Detection feature uses the management interface as an out-of-band connection between the two peers...
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, and anycast segments while the IGP converges and the post-convergence paths are computed. Anycast segment protection is restricted to those segments...
Continue reading →

Two rate three color marker (TrTCM)

Description Two rate three-color marker (TrTCM) meters an incoming packet stream and marks the packets based on two rates, PIR (Peak Information Rate) and CIR (Committed Information Rate), and their associated burst-sizes. Any stream of packets below the CIR is marked as GREEN. Packets coming in at a rate higher than PIR are marked as RED and are always dropped unless it’s threshold values are changed. All other packets with rates between CIR and PIR are marked as YELLOW. Information about TrTCM can be found here. Platform Compatibility DCS-7500R, DCS-7500R2, DCS-7500E (EOS 4.23.1F) DCS-7280R, DCS-7280R2, DCS-7280E (EOS 4.23.1F) DCS-7020 (EOS...
Continue reading →

Support for configuring color extended communities

Description EOS 4.23.1F introduces the ability to configure the color extended community in route-map set clauses and in an extcommunity-list for inbound and outbound policy application. As outlined in the IETF Segment Routing Policy Architecture draft, the color extended community is used for per-destination steering into Segment-Routing Traffic-Engineered (SR-TE) policies. If the next-hop and color of a BGP route match a particular policy (composed of an endpoint and color), any traffic bound to the destination can be steered according to the policy instead of forwarded via an IGP path or tunnel. Details on per-destination IP steering in EOS can be...
Continue reading →

Hardware flow tracking with IPFIX export

Description Arista campus switches allow extensive and fine grained hardware based flow tracking and management features. They provide the capability to collect and export flow telemetry to an external observation node (collector), using IPFIX protocol. The below diagram shows how hardware flow tracking engine can be used to perform flow tracking and flow export in a campus network. It can track flows traversing through the given set of interfaces in a switch and send the collected flow information to a collector. The hardware flow tracking engine allows flow tracking and metering functions on upto 32K concurrent flows. Flows are tracked...
Continue reading →

BGP logical OR of multiple community lists in the same match command

Description In the multi-agent routing protocol model, the Bgp agent now supports matching community lists with a logical OR via the route map “match community or-results <community-list-1> <community-list-2>” command (same applies for extended and large communities with “match extcommunity” and “match large-community”). Without this new “or-results”, the default is to compute the logical AND of all provided community lists. Before this new feature one would need to merge existing community lists into one to do a logical OR: Issue: ip community-list COMMLIST1 permit 1:1 ip community-list COMMLIST2 permit 2:2 ! No way to match "COMMLIST1" or "COMMLIST2" in a singe...
Continue reading →

VCS to EVPN hitless migration

Description This feature enables support for migrating from only using VCS as the control plane to only using EVPN as a control plane in a hitless manner with respect to L2 reachability information. Platform compatibility Platform Independent (Subject to any and all platform compatibility limitations of both VCS and EVPN) Configuration Assume that initially only VCS is configured as the control plane.  The step-by-step migration process is as follows: Check VCS L2 reachability information in L2Rib: Use the following show commands to verify that L2 reachability information is in L2Rib’s input and output: show l2Rib input vxlan-control-service show l2rib input...
Continue reading →

MLAG Dual Primary Detection and Release Updates

Description When the MLAG peer-link goes down, the secondary peer assumes the primary peer is down/dead, and takes over the primary role. It is possible that when peer-link is down, the primary isn’t actually down/dead and both MLAG peers think they are the primary. This is called “dual-primary” condition/state. In this state, each peer will run Layer-2 protocols such as Spanning Tree Protocol independently. Depending on the topology, this can cause loops in the network. This can also impact the IGMP snooping feature. The Dual Primary Detection feature uses the management interface as an out-of-band connection between the two peers...
Continue reading →

“Show Interfaces Interactions” CLI Command

Description The ‘show interfaces interactions’ command aims to provide users a resource that explains various relationships between ethernet interfaces. It describes interactions in which a configuration on an interface causes another set of interfaces to become inactive or have reduced capabilities. Examples include a primary interface consuming subordinate interfaces to service a four-lane speed or platform restrictions that require four interfaces of a port to operate at the same speed. Platform Compatibility With the EOS-4.21.3F release, the command is supported on the following products: 7280QR-C72 7280QRA-C36S With the EOS-4.23.1F release, the command is supported on the following products: 7060DX4-32 7060PX4-32...
Continue reading →

Support for BGP flowspec + Release Updates

Description EOS 4.21.3F introduces support for BGP Flowspec, as defined in RFC5575 and RFC7674. The typical use case is to filter or redirect DDoS traffic on edge routers. BGP Flowspec rules are disseminated using a new BGP address family. The rules include both matching criteria used to match traffic, and actions to perform on the matching traffic. The rules are programmed into TCAM resources and applied on the ingress ports for which flowspec is enabled. Release Updates EOS 4.22.0 Enhancements Added support for redirect over MPLS or GRE Tunnels Added support for traffic-rate action EOS 4.22.1 Enhancements Added support for...
Continue reading →

gRIBI (gRPC Routing Information Base Interface)

Description gRIBI (gRPC Routing Information Base Interface) defines an interface through which OpenConfig AFT (Abstract Forwarding Table) entries can be injected from an external client to a network element. The gRIBI interface is defined in the gRIBI github repo – which defines a simple API for adding, updating, and removing routing entries. These RIB entries are described using a protobuf translated version of the OpenConfig AFT model. For a number of use cases in modern IP networks, the ability to inject routing entries from an external source is advantageous. (Source: https://github.com/openconfig/gribi/blob/master/doc/motivation.md) Use Case The primary use case supported is, steering...
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 →

7500 Series Fabric Capacity Monitor

Description Enough fabric capacity is needed to sustain line rate traffic of front panel ports of each switch element (FAP). Fabric capacity depends on number of fabric (SerDes) links that are operational and the effective bit rate of SerDes. Operational front panel ports capacity depends on number of operational front panel ports and their speed. Sand fabric capacity monitor, monitors the fabric capacity and front panel ports capacity. It allows the customer to configure a fabric threshold as a % of front panel ports capacity to monitor. When fabric capacity goes below or above configured threshold a system log message...
Continue reading →

Static inter-VRF route support

Description This feature adds support for static inter-VRF routes. This enables configuration of routes to destinations in one ingress VRF with an ability to specify a next-hop in a different egress VRF through a static configuration. Such static inter-VRF routes can be configured in default and non-default VRFs. A different egress VRF is achieved by “tagging” the “next-hop” or “forwarding via” with a reference to an egress VRF (different from the source VRF) in which that next-hop should be evaluated. Static inter-VRF routes with ECMP next-hop sets in the same egress VRF or heterogenous egress VRFs can be specified This...
Continue reading →

Two rate three color marker (TrTCM)

Description 4.23.1F introduces support for the TrTCM feature on the platforms listed below. The TOI describing the feature support on earlier versions/platforms is available here and here. Two rate three color marker (TrTCM) meters an incoming packet stream and marks the packets based on two rates, PIR (Peak Information Rate) and CIR (Committed Information Rate) and their associated burst-sizes. Any stream of packets below the CIR is marked as GREEN. Packets coming in at a rate higher than PIR are marked as RED and are always dropped. All other packets with rates between CIR and PIR are marked as YELLOW....
Continue reading →

PHY test pattern CLI

The PHY test pattern CLI can be used to check the quality of the physical layer for an Ethernet interface. This is done by generating a specific test pattern to a peer, and having the peer check the test pattern that is received, and vice versa. Because the test pattern is a well-known sequence of bits, the peer can check that the pattern received matches this well-known sequence; any difference is a bit error introduced by the peculiarities of the physical layer. Quality of the link could be determined based on the acceptable bit errors, as published by the hardware...
Continue reading →

Ingress/Egress per-port IPv4, IPv6 counters

This feature provides support for per-interface ingress/egress packet/byte counters for both IPv4 and IPv6. Platform compatibility DCS-7280SR DCS-7280CR DCS-7500-R DCS-7300X DCS-7250X DCS-7050X DCS-7060X Please note feature is platform specific, packet versus bytes distinction, and the ability to count routed packets only (as opposed to counting all IPv4/v6 traffic: routed or bridged). Please consult your systems engineer to check if a particular combination is supported. Configuration IPv4, IPv6 ingress counters (counts bridged and routed traffic, supported only on front-panel ports) can be enabled/disabled using the following command: Arista#[ no ] hardware counter feature ip in For IPv4, IPv6 ingress/egress counters that...
Continue reading →

Follow

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

Join other followers: