• Tag : 4.23.1F

 
 

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 →

MLDv2 Snooping

Description MLDv2 Snooping optimizes the transmission of multicast packets in Layer 2 by using Layer 3 information contained in MLDv2 and PIM packets. MLDv2 is the protocol used to manage the membership of hosts in multicast groups for IPv6. RFC 3810 talks about MLDv2 functionality. MLDv2 is the IPv6 counter part of IGMPv3.  Platform compatibility DCS-7020R DCS-7280R DCS-7280R2 DCS-7500R DCS-7500R2 Configuration Enable or Disable MLD Snooping MLDv2 snooping can be configured globally and per vlan. A new configuration mode is added for MLD related snooping commands in global config mode. switch(config)#mld snooping switch(config-mld-snooping)#disabled switch(config-mld-snooping)#vlan 1-100 switch(config-mld-snooping)#vlan 101 switch(config-mld-snooping-vlan-101)#disabled Vlans have...
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. IP Locking prevents another host on a different interface from claiming ownership of an IP address through ARP spoofing.   On an IP Locked Port:  ARP probes with 0.0.0.0 as Sender Protocol Address (SPA) will be allowed for duplicate address detection (DAD).  Incoming DHCP server response packets are dropped to avoid rogue device(s) acting as DHCP server(s). Incoming DHCP client request packets are allowed...
Continue reading →

IS-IS Dynamic Flooding

Description The goal of Dynamic Flooding is to allow IS-IS to scale to large, dense topologies such as Leaf-Spine topologies. In such topologies, legacy IS-IS can exhibit a congestive collapse due to the control plane load created by excessively redundant flooding.    The basic idea in Dynamic Flooding is to dynamically compute a restricted topology for flooding (the flooding topology). Since this can be much smaller than the full physical topology, this can reduce the redundancy seen by each node, thereby reducing the control plane load and avoiding a congestive collapse.   To do this, we first select one node...
Continue reading →

VXLAN Bridging & Routing on DCS-7500R3

Description This document describes the support of VxLAN Bridging and Routing on the R3 series of DCS 7280, 7500 and 7800 Arista switches. Platform Compatibility DCS-7280R3 DCS-7280R3 DCS-7500R3 Linecards DCS-7800R3 Linecards Differences with DCS-7500R2 Implementation Following are the notable differences with respect to implementation of VxLAN on the R3 series of switches. There is no need to configure vxlan-routing TCAM profile to enable VxLAN routing on the R3 series switches. The command is still accepted for backward compatibility reasons. Any CPU bound traffic after VxLAN decapsulation (e.g. routing protocol packets) will use the same CoPP queues used by the non...
Continue reading →

Follow

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

Join other followers: