• Tag : 4.23.2F

 
 

Redistribution of ISIS Routes into OSPFv3

Description This document describes the feature that allows redistribution of routes from ISIS to OSPFv3 running on a device. This feature is supported for both IPv4 and IPv6 address families. Platform compatibility This feature is supported on all platforms, both in ribd and multi-agent routing modes. Configuration EOS supports 2 configuration styles for OSPFv3. The command to redistribute ISIS into OSPFv3 in both the configuration styles are captured below. ‘router ospfv3’ configuration style The command is available under the ‘address-family [ipv4 | ipv6]’ sub-modes of the ‘router ospfv3’ config mode. (config-router-ospfv3)#address-family ipv4|ipv6 (config-router-ospfv3-af)#redistribute isis ? level-1 Redistribute IS-IS level-1 routes...
Continue reading →

Configurable Admin Distance for OSPFv3 External Routes

Description Add support for configuring admin distance for OSPFv3 external routes, without this OSPFv3 would always install external routes with a preference of 110. This feature is supported for both IPv4 and IPv6 address families. This feature is supported both in ribd and multi-agent routing modes. Platform compatibility Supported on all platforms. Configuration EOS supports 2 configuration styles for OSPFv3, and the command to configure the admin distance for external routes is available in both these configuration styles, as detailed below. (config-router-ospf3-af)#distance ospf external ? <1-255> Distance value Available under ipv4 and ipv6 `address-family` submodes of `router ospfv3` mode Available...
Continue reading →

Allow resolution over BGP aggregates

Description Adds the ability to revert to previous behavior where BGP and static routes could resolve over BGP aggregates (when the aggregate is the longest-prefix-match (LPM) for the route) and be installed in the FIB. Provided for backward compatibility purposes. Platform compatibility Supported on all platforms. Configuration To enable this backward compatibility, run: (config)# router general (config-router-general)# next-hops resolution bgp aggregates allowed To disable, run: (config)# router general (config-router-general)# no next-hops resolution bgp aggregates allowed

Chip level next-hop backup failover support

Description This feature allows failover to backup path to occur in constant time per interface going down for features such as RSVP link protection, RSVP node protection, TI-LFA link protection, and BGP PIC. Without this feature enabled, it would take time proportional to the number of paths going over the interface experiencing the link down event to failover to the backup path. With this feature enabled, the failover time would be constant regardless of the number of paths. For example, if a given link has 1000 LSPs going over it that are all protected with a backup next-hop, the convergence...
Continue reading →

EVPN Centralized Anycast Gateway

Description In the Centralized Anycast Gateway configuration, the Spines are configured with EVPN-IRB and are used as the IP Default Gateway(DWG), whereas the Top of rack switches perform L2 EVPN Routing. EVPN-IRB  supports both Virtual eXtensible Local Area Network (VXLAN) Bridging and IP Routing on the top of rack (TOR) switch.  In a typical EVPN IRB deployment, the IP Default Gateway(DGW) for a host (or VM) is the IP address configured on the IRB interface (check out the EVPN IRB TOI for more detail).   Platform compatibility DCS-7050X* DCS-7050X2 DCS-7050X3 DCS-7300/DCS-7320 DCS-7300X3 DCS-7260X* (DCS-7260X, DCS-7260X2, DCS-7260X3) DCS-7280R, DCS-7280R2, DCS-7280R3 DCS-7500R, DCS-7500R2,...
Continue reading →

The BGP best-path selection algorithm

Description BGP routing information often contains more than one path to the same destination network. The BGP best-path selection algorithm determines which of these paths should be considered as the best path to that network. If the best BGP path (as chosen by the algorithm) is also chosen as the winning path from among the other non-BGP paths (if any), it will be installed in the RIB and used to forward traffic to that network. The best BGP path will also be the path that is subsequently advertised to any BGP neighbors. BGP best-path steps When comparing any two paths...
Continue reading →

Per Port Tc-To-Cos

Description This feature enables per port TC-To-COS mapping. TC represents Traffic-Class and COS represents Vlan tag PCP bits. While at present there is a global TC-To-COS mapping, in this feature named TC-To-COS profiles can be created which can be applied to the required interfaces. When a Tc-To-Cos profile is applied to an interface then all the packet egressing through this interface will follow the below principles: Cos remarking will happen based on the TC, Dp( Drop precedence ) of the packet. The exact value of the cos will depend on the mapping present in the tc-to-cos profile applied to it....
Continue reading →

Redistribution of leaked routes into BGP

This feature allows routes that were leaked from one VRF (the source VRF) into another VRF (the destination VRF) – using the VrfLeak Agent to be redistributed into BGP for advertising to VRF-lite / Option A BGP peers.  Description As of 4.23.2F we support leaked routes learned (in the source VRF) via the following protocols: Connected Static ISIS OSPF/ OSPFv3 BGP Into the following AFI/SAFI’s within BGP: IPv4 Unicast IPv6 Unicast Platform compatibility This feature is supported on all platforms. Configuration The feature is available when the protocol agent model is multi-agent. The following command puts the system in multi-agent...
Continue reading →

Port ACLs with User-Defined Fields

Description This article describes the support for specifying User-Defined Fields( UDF ) in Port ACLs including IPv4, IPv6, and MAC ACL. The purpose of the User-Defined Fields feature is to permit or deny packets based on custom offset pattern matching.   User-Defined Fields, or UDFs, are defined as part of an access-list filter and are comprised of an offset, length, pattern match and mask. This describes a single portion of any incoming packet to match the provided value upon.   UDFs may also be defined via aliases. Aliases are a way to save a UDF configuration for reuse in multiple...
Continue reading →

Support for new OpenConfig paths

Description 4.23.2F release supports reading and streaming various OpenConfig configuration and state models over gNMI (gRPC Network Management Interface), RESTCONF, and NETCONF transports. A subset of the configuration models may also be modified over these transports, see below. All client transactions that modify device configuration provide the same atomicity guarantees that are provided by sessions in the CLI. Please refer to OpenConfig Configuration Guide for more details on how to configure and use the OpenConfig support in EOS.  Supported OpenConfig paths updates to 4.23.2F Arista Qos: arista/eos/qos/acl/input/cli/cmapType/cmap/match/strValue,read+write Openconfig-qos-interfaces v0.2.2: qos/interfaces/interface/output/queues/queue/state,,augmented,Augment: missing description qos/interfaces/interface/output/queues/queue/state/dropped-octets,read,augmented,Number of octets dropped by the queue due...
Continue reading →

Tap Aggregation Timestamp Keyframes

Description The Tap Aggregation timestamping on the 7500 series supports both timestamping packets in TAI (International Atomic Time) since EOS-4.18.1F, and UTC (Coordinated Universal Time) since EOS-4.22.0F (see Packet Time Stamping on the 7500R/7280R/7500E/7280E). When using the TAI format for timestamping, keyframes can be used to correlate TAI time from the timestamping header to corresponding UTC time.   A keyframe contains ASIC time in TAI format and the equivalent UTC time and it also holds PTP (Precision Time Protocol) information from the switch, like the last synchronization time.   For the Arista switch to be aware of the number of...
Continue reading →

Clear/Set COS for CPU Generated Traffic

Description The CPU CoS mapping feature can only be configured on physical routed interfaces. No other interface types including LAGs, SVIs, sub-interfaces or Tunnel interfaces are supported at this time. When a CPU TC to CoS Map is applied on an interface All outgoing VLAN tagged CPU traffic on that parent interface (including all sub-interfaces) is subjected to the mapping function. This means that the CoS field of the outermost VLAN tag will be computed based on the mapping function. In the case of QinQ sub-interfaces, the inner tag will not be affected at all. Platform compatibility DCS-7020 DCS-7280 series...
Continue reading →

Route Map – Match Interface Support in Multi-Agent

Description This feature adds support for ‘match interface’ clause under route-map config for Bgp policy application in multi-agent model. This feature may be used when a policy to filter routes on the basis of the resolved interface of a route is desired. A route-map can be used at various application points to filter routes based on the policy but ‘match interface’ is supported  only for specific application points. For such applications when a route-map with ‘match interface’ clause is applied, the interface of the resolved nexthop of each route is matched against the interface specified in route-map and the route...
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 →

IPv4 ACL DSCP Mask

Description This article describes the support for specifying DSCP mask in IPv4 access-list. DSCP mask can be used to match multiple DSCP values in a single ACL rule. Platform compatibility DCS-7020R DCS-7280E DCS-7280SE DCS-7280R DCS-7280R2 DCS-7280R3 DCS-7500E DCS-7500R DCS-7500R2 DCS-7500R3 Configuration After a DSCP value is configured in an IPv4 ACL rule, users can configure an optional DSCP mask. A bit set to 1 in the mask indicates to ignore the corresponding value bit. A bit set to 0 in the mask indicates to match exactly the corresponding value bit. switch(config)#ip access-list acl1 switch(config-acl-acl1)#permit ip any any dscp af21 0x0F...
Continue reading →

Client Side Support for MPLS LDP Multipath Traceroute

Description MPLS LDP traceroute utility has now been extended to support multipath traceroute. This allows network administrators to monitor reachability information of all nodes part of a valid ECMP, from a given source to destination prefix, with LDP tunnels established. Platform compatibility Platform Independent. CLI Command traceroute mpls ldp ip <endpoint> multipath [ base ] [ count ] ------------- 5 | | ----- 3 ---- | | | | | (src) 2 --- 4 --- 7 ----- 8 (dst) | | | ----- 6 ----- Let us assume that an IGP (for e.g. OSPF) is running between all nodes in...
Continue reading →

Match Inner VLAN in QoS Policy-Map on 7280E/7280R/7500E/7500R

Description Classification of packets based on inner VLAN value along with VLAN and CoS bits in a double tagged packet. Platform compatibility DCS-7020SR DCS-7020SRG DCS-7020TR DCS-7020TRA DCS-7280CR DCS-7280CR2 DCS-7280CR2A DCS-7280CR2K DCS-7280CR2M DCS-7280SE DCS-7280SR DCS-7280SR2 DCS-7280SR2A DCS-7280SR2K DCS-7280SRA DCS-7280SRAM DCS-7280SRM DCS-7280TR DCS-7280TRA DCS-7280QR DCS-7280QRA DCS-7504* DCS-7508* DCS-7512N* DCS-7516N* * On DCS-7504, DCS-7508, DCS-7512N and DCS-7516N modular chassis series, we support this feature only on 7500E, 7500R and 7500R2 linecards. TCAM Profile Configuration To support this feature, we need to apply a TCAM profile that supports match on VLAN, CoS and inner VLAN at the same time. hardware tcam profile qos-inner-vlan-match feature...
Continue reading →

Forwarding destination prediction byte stream support

Description Forwarding destination prediction enables visibility into how a packet is forwarded through the switch, allowing you to determine which interfaces a packet would egress out of. This feature has been expanded upon with support for packets specified as a byte stream, allowing you to fully specify the packet. Please see the TOI on forwarding destination prediction for more details. Platform compatibility DCS-7020 DCS-7280/R/R2 series DCS-7500/R/R2 series Interactive Mode There are two methods of interacting with the command. The first method is to use an interactive prompt, and the other method is specifying all fields of the packet in a...
Continue reading →

Management SFP port configuration

Description This article describes speed configuration for the management SFP port. Platform compatibility DCS-7300-SUP2 DCS-7300-SUP2-D DCS-7368-SUP DCS-7368-SUP-D DCS-7800-SUP Configuration The user may configure the management SFP port’s speed to either “auto” or “forced 1000full”. The default value is “auto”. switch(config)#interface ma1/2 switch(config-if-Ma1/2)#speed forced 1000full Show Commands The port’s configuration settings can be seen using the following command. switch(config-if-Ma1/2)#show interface ma1/2 status Port Name Status Vlan Duplex Speed Type Flags Encapsulation Ma1/2 connected routed full 1G 1000BASE-T Limitations The speed “forced 1000half” is not supported. Attempts to set the speed to this value will result in a silent failure. The port’s...
Continue reading →

Support for standalone link training

Description When a high speed serial communication link is established, the two ends communicate with each other over a “channel”.  This channel typically consists of traces on a circuit board, a medium over which the link is carried (for example, a copper cable), and connectors which connect the two ends together.  Each element in the channel doesn’t transmit the signal perfectly – they each degrade the signal a little bit so it looks less like it did when it was first transmitted. By the time the signal gets to the destination receiver, it typically looks nothing like the signal that...
Continue reading →

Follow

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

Join other followers: