Filtered Mirroring of MPLSoGRE Packets

MPLSoGRE Filtered Mirroring is a specialized version of Mirroring to GRE Tunnel and Filtered Mirroring in which IPv4oMPLSoGRE and IPv6oMPLSoGRE packets entering a GRE tunnel endpoint on which an MPLS lookup is performed may also be be selected for mirroring based on the destination IP address field in the inner IPv4 or IPv6 header. Packets selected for mirroring will have the following header format: The packets described above when forwarded based on either the L2 or outer L3 header destination address will not be subject to mirroring. When mirroring to a GRE tunnel, the payload of the outgoing GRE packet...
Continue reading →

SNMP MIB for nexthop-group counters

Nexthop-groups is an existing feature which allows users to manually configure a set of tunnels with nexthops. Nexthop-group counters provide the ability to count packets and bytes associated with such tunnels. With SNMP MIB support, users can use SNMP to query the nexthop-groups present in the system, and the counters for each entry in a nexthop-group. Platform compatibility DCS-7500E DCS-7280E DCS-7500R DCS-7280R Configuration The SNMP agent can be enabled when the first community is created. Arista(config)#snmp-server community public Nexthop-group entries can be counted only when the nexthop hardware counter feature is configured. 7500R(config)#hardware counter feature nexthop Status 7500R(config)#show snmp mib...
Continue reading →

BFD SSO

BFD Stateful Switchover (SSO) allows for a switchover from an active supervisor to a standby supervisor where BFD sessions do not flap on the router undergoing the SSO, or the router that is the BFD peer. If BGP is configured with a BFD neighbor and with graceful restart, then BGP routes will not flap during SSO. BFD echo mode is required to be configured on the BFD peer. In the below diagram if Router A is supporting SSO then BFD echo mode must be configured on Router B. Note that in may cases where SSO is supported on both routers...
Continue reading →

VXLAN Indirect Routing on 7280E, 7280R and 7500R series

In EOS-4.18.0F, VXLAN direct routing was introduced on the 7500R and 7280E/R series platforms. VXLAN routing provides the capability to route between VXLAN Layer 2 domains. In EOS-4.18.1, support for VXLAN Indirect Routing model is added to the 7500R and 7280E/R series platforms. In the Indirect routing model, the destination host is not directly attached to the VTEP(s) where the default gateway functionality is present. This model is called “indirect” because, in this model,  the packet possibly needs to go through multiple hops in the overlay to reach the final destination. It typically involves running routing protocols in the overlay...
Continue reading →

25/50G support on 7500R, 7280R, 7500R2, 7280R2 Series

In EOS-4.18.1, support for 25G/50G is added on 7500R, 7280R, 7500R2 and 7280R2 series. This feature provides forced 25G/50G speed and IEEE802.3 Clause73 auto-negotation (AN) connectivity. This feature allows configuring 25G Consortium AN mode and/or IEEE802.3by AN mode on 25G interface. Platform compatibility DSC-7500R DCS-7280R DSC-7500R2 DSC-7280R2 Configuration Configure forced 25G/50G  speed Arista(config)#interface ethernet 1 Arista(config-if-Et1)#speed forced 25gfull Arista(config)#interface ethernet49/3 Arista(config-if-Et49/3)#speed forced 50gfull Configure 25G/50G AN speed Arista(config)#interface ethernet 1 Arista(config-if-Et1)#speed auto 25gfull Arista(config)#interface ethernet49/3 Arista(config-if-Et49/3)#speed auto 50gfull Configure 25G AN mode Enable IEEE802.3by AN mode only, Arista(config-if-Et1)#phy media 25gbase-cr negotiation standard ieee Enable 25G Consortium AN mode only, Arista(config-if-Et1)#phy media 25gbase-cr negotiation standard consortium Enable...
Continue reading →

MPLS Push

This feature allows the Arista switch to act as the tunnel head for an MPLS tunnel and is exposed through two mechanisms: 1) Static IP routes having a label associated with each route. 2) NexthopGroup of type MPLS. Each NexthopGroup entry can have a single MPLS label associated with it. Platform compatibility DCS-7050X DCS-7250X DCS-7260X DCS-7300X DCS-7260QX DCS-7060CX DCS-7060CX2 DCS-7260CX DCS-7320X-32C-LC Configuration MPLS push route configuration MPLS push routes are configured similar to static IP routes with the addition of the label parameter. The below example configures an IPv4 static MPLS push route with label 12000. Arista(config)#ip route 10.1.2.0/24 10.0.3.7 label...
Continue reading →

Traffic Steering using User-Defined Fields

This article describes the TAP Aggregation User-Defined Fields feature. The purpose of the User-Defined Fields feature is to provide custom offset pattern matching to be used in TAP Aggregation Traffic Steering. This allows for deeper packet inspection of up to 128 bytes. User-Defined Fields, or UDFs, are defined as part of an access-list filter and are comprised of an offset, length and pattern match. This describes a single portion of any incoming packet to match the provided value upon. Access-list filters containing a UDF are then applied as usual as part of a TAP Aggregation Traffic Steering policy. Platform Compatibility DCS-7280E DCS-7280R DCS-7500E...
Continue reading →

TapAgg truncation

EOS-4.18.1F added truncation capability for Tap Aggregation, which allows tapped traffic to be truncated to a smaller size before being transmitted. It can be used to reduce the amount of traffic received by analysis devices, if only the headers are to be analyzed while the payload of the packets is irrelevant or unwanted for practical or legal reasons. An example could be the analysis of packets in a video streaming network where packets would typically have large payloads that are not necessarily useful for the analyzers. Packet truncation can be configured on tap or tool ports: Truncation configured on a tap port will cause...
Continue reading →

SVI blocking for RACLs

When configuring or modifying a RACL applied to a VLAN interface, the VLAN will be blocked while applying the updated RACL.  This will prevent inconsistent forwarding of traffic to or from the VLAN interface while the RACL is being modified.  As with ACLs applied to ports, the default blocking behavior can be overridden using the hardware access-list update default-result permit command. Platform compatibility 7010T 7050Q 7050S 7050T 7050QX 7050SX 7050TX 7060CX 7060CX2 7250QX 7260CX 7260QX 7304 7308 7316 Configuration This feature is the default behavior for ACL configuration. In order to prevent any traffic from being dropped during RACL configuration...
Continue reading →

SNMP MIB support for “show hardware capacity”

Hardware Table Capacity Monitoring is an existing feature to keep track of the capacity and utilization of various hardware forwarding resources and generate alerts/syslogs when the utilization exceeds a threshold value. With SNMP MIB support, Users can use SNMP server to monitor hardware utilization. Whenever utilization exceeds threshold value, Switch sends SNMP traps in addition to aletes/syslogs. The Main use-case would be for troubleshooting  in overflow situations and avoid overflows altogether by taking corrective actions on high utilization. Platform compatibility DCS-7280E DCS-7500E DCS-7050SX DCS-7050TX DCS-7050QX DCS-7260CX DCS-7260QX Configuration SNMP Configuration EOS supports a growing number of both Arista-specific and standards-based MIBs,...
Continue reading →

Sampled Mirroring

Sampled Mirroring is an extension of the Mirroring feature and sampling is a property of the individual mirroring session: when the session’s sample rate N is specified, a packet eligible for mirroring will have a 1/N chance of being mirrored, that is, 1 packet is mirrored for every N packets. Sampled Mirroring is supported for mirroring sessions where Mirroring ACLs are defined: only the incoming packets matching the ACL are subject to sampling. Sampled Mirroring is supported for mirroring sessions where the destination is set to CPU. The Sampled Mirroring feature described in this document provides support for statistical sampled mirroring [as opposed to random...
Continue reading →

Packet Time Stamping on the 7500R/7280R/7500E/7280E

Time stamping is an important tool for network engineering and performance analysis. EOS-4.18.1F added header time stamping of all packets received on any tap interface in Tap Aggregation mode at line rate. A timestamp is taken on ingress and then inserted as an additional header to packets on egress. Optionally, timestamps may be synchronized to an authoritative source by enabling PTP. However, PTP is not supported on the 7500R and 7280R series in EOS-4.18.1F. Header Format and Placement The timestamp header is a new Ethernet/L2 header consisting of the Arista EtherType (0xD28B), a two-byte protocol subtype of 0x1, a two-byte protocol version of 0x10...
Continue reading →

Overlay IPv6 routing over VXLAN

Overlay IPv6 routing over VXLAN Tunnel is simply routing IPv6 packets in and out of VXLAN Tunnels, similar to VXLAN overlay IPv4 routing. Underlay ( Outer IP Header ) in VXLAN still uses IPv4, and common for both overlay IPv4 and IPv6 . Hence VXLAN configuration remains exactly same for both IPv4 and IPv6 overlay routing support. This feature enables IPv6 networks/hosts get connected through VXLAN Tunnels. Following figure illustrates IPv6 routing followed by VXLAN encapsulation to reach a remote host across the VXLAN tunnel.   Following figure illustrates VXLAN decapsulation and routing of an IPv6 packet. Platform compatibility DCS-7050X DCS-7060X DCS7260X DCS-7050X2 DCS-7250X DCS-7304 / DCS-7308 /...
Continue reading →

LANZ Notifying Mode on 7500R, 7280R series

LANZ adds Notifying Mode support for DCS-7500R and DCS-7280R. Notifying Mode provides more granular congestion monitoring with Start, Update, and Stop events. Notifying Mode on DCS-7500R and DCS-7280R supports congestion monitoring on front-panel and CPU ports. The previous behavior of polling the most congested queue per chip is still available in Polling mode, which is enabled by default on the 7500(E/R) and 7280(E/R) series. This document focuses on the differences with the 7500E and 7280E series. Please refer to the existing documentation for configuring and using Notifying Mode. Platform compatibility Platform Polling Mode support Notifying Mode support LANZ enabled by default Default...
Continue reading →

HSC support for multiple standalone external controllers

External controllers can communicate with HSC (Hardware Switch Controller) running on CVX/EOS using the OVSDB management protocol (RFC 7047) in order to orchestrate a VXLAN L2/L3 overlay network over a physical network of Arista switches. To enable communication with an external controller, its IP address (and, optionally, port number) needs to be configured via the “manager” command in the HSC configuration mode on CVX. Arista# cvx Arista(config-cvx)# service hsc Arista(config-cvx-hsc)#manager <ip> [ port ] Arista(config-cvx-hsc)#no shutdown Prior to EOS 4.18.1F, only a single controller IP was allowed to be configured in the above CLI. If a new controller was configured via...
Continue reading →

EVPN extension to BGP using VXLAN

Ethernet VPN (EVPN) is an extension of the BGP protocol introducing a new address family: L2VPN (address family number 25) / EVPN (subsequent address family number 70). It is used to exchange overlay MAC and IP address reachability information between BGP peers within a tunnel [1]. In EOS 4.18.1F VXLAN tunnel support is introduced [2]. The available features are: Single-homing L2 routes (EVPN type 2 and type 3), with MLAG used as the L2 multi-homing solution. Multi-homing L2 routes (EVPN type 1 and type 2) are received and installed, with up to two all-active remote paths per destination (additional paths...
Continue reading →

DSCP for CPU generated traffic

The differentiated services code point (DSCP) is a 6 bit field in the IP header, which can be used to mark traffic for providing quality of service (QoS). This feature can be used to set the DSCP value individually for various protocols that are used for network management. All protocol specific traffic leaving the switch will be marked with the configured DSCP value. The supported protocols are RADIUS, TACACS, SNMP, SSH and sFlow. Platform compatibility This feature is provided on all platforms. Configuration The following CLI commands can be used in global configuration mode, to configure the DSCP value for...
Continue reading →

Control WRED threshold for non-ECT packets

This feature is an extension to the Explicit Congestion Notification (ECN) functionality for non-ECN-Capable Transport (non-ECT). It allows the user to configure Weighted Random Early Detection (WRED) thresholds for dropping non-ECT packets, which enables non-ECT packets to participate in WRED congestion avoidance independent of the ECT packets. Platform compatibility DSC-7050X DCS-7250X DCS-7300X Configuration The non-ECT thresholds are configured at an interface’s tx-queue level. The drop profile is defined by minimum-threshold, maximum-threshold, and drop-probability. The units for thresholds can be given in segments, bytes, kilobytes or megabytes. Please note that global config level qos random-detect ecn allow non-ect configuration is needed to allow (and not...
Continue reading →

Coherent Modulation Formats and 7500R-8CFPX-LC

The 7500R-8CFPX-LC linecard with ACO CFP2 optics provides connectivity over DWDM systems and links. 7500R-8CFPX-LC currently only supports connections to other 7500R-8CFPX-LC linecards. 7500R-8CFPX-LC when used with Linear CFP2-ACO supports three modulation formats allowing three different combinations of reach and data rate as required by the application. Enhancements for 7500R-8CFPX-LC Modulation Formats Capabilities The show interfaces capabilities command has been enhanced to show the available modulations for coherent interfaces. Arista#show interfaces Ethernet4/1/1-4/2/1 capabilities Ethernet4/1/1  Model:        7500R-8CFPX-LC  Type:         100G-DWDM-E  Speed/Duplex: 100G/full(default)  Flowcontrol:  rx-(off,on),tx-(off)  Error Correction:     Reed-Solomon: 100G  Modulation:   DP-QPSK,8QAM,16QAM(default) Ethernet4/1/2  Model:        7500R-8CFPX-LC  Type:         100G-DWDM-E  Speed/Duplex: 100G/full(default)...
Continue reading →

AS Ranges for Dynamic BGP Peer Groups

BGP neighbors, or peers, are initiated by configuration commands that cause BGP to establish TCP connections with other BGP speakers.  Dynamic neighbors are established by creating a listen range and accepting incoming connections from neighbors within that address range.  Dynamic neighbors must be configured using a dynamic peer group, which defines attributes for all neighbors associated with the listen range.  A BGP listen range has so far allowed exactly 1 remote AS number to be specified for acceptable incoming connections. The AS Ranges for Dynamic Peer Groups feature introduces a flexible means of specifying multiple, allowable remote AS numbers for...
Continue reading →

802.1br-E/VN Tag Stripping

This article describes a Tap Aggregation feature to strip IEEE 802.1BR E-Tag and Cisco VN-Tag headers from all tagged packets received on any tap interface before delivering them to tool interfaces. Untagged packets are unaffected. This feature may be useful for third-party tools and/or packet analyzers which cannot parse these headers. Platform Compatibility DCS-7280E/R series DCS-7500E/R series Configuration By default, Arista switches do not strip BR-E/VN tags from ingress packets. BR-E/VN tag stripping is globally configured for Tap Aggregation. The feature allows a choice of stripping both or either of the tags. To enable BR E-Tag stripping add the following configuration: Arista(config)#tap aggregation Arista(config-tap-agg)#encapsulation dot1br strip To enable...
Continue reading →

VXLAN Routing on 7280E, 7500R and 7280R Platforms

The 7500 and 7280 switch series platforms have previously supported VXLAN bridging, which enables stretching of Layer 2 domains across an Layer 3 IP Cloud. In EOS-4.18.0F, VXLAN routing is introduced on these platforms, which provides the capability to route between these stretched Layer 2 domains. In this release, only IPv4 unicast routing is supported in the overlay. In particular, VXLAN Routing is only supported in the Direct Routing mode, where every host is directly attached in the overlay to every VTEP in the network. This requires all VXLAN SVIs for the overlay subnets to be configured on all VTEPs....
Continue reading →

BGP Convergence Timer Improvements

BGP Convergence Overview To avoid hardware updates and route advertisement churn during switch reload or BGP instance start, BGP enters into convergence state where it will wait for all the peers to join and receive all the routes from all the peers. In this phase BGP also waits for IGP protocols to converge before declaring its convergence, this is required for all IBGP sessions to get Established and also for routes learned over IBGP sessions to get recursively resolved via IGP routes. BGP declares convergence when it has received route updates from all its peers, received EOR (End-Of-RIB) markers from...
Continue reading →

BGP Prefix Independent Convergence Enhancements for IBGP

The BGP Prefix Independent Convergence (PIC Edge) is an existing feature that was first introduced in EOS-4.15.0F. This feature refers to fast re-convergence of traffic destined for BGP prefixes on a network event affecting the best path(s) such that the time taken to switch traffic from the active best path(s) to the next best path (i.e. backup path) is independent of the number of prefixes. The above behavior is achieved by pre-programming the best path and alternate backup path in the forwarding agent in steady state. It is supported for both IPv4 and IPv6 address families for default and non-default VRFs....
Continue reading →

Igmp Snooping Proxy

IGMP Snooping Proxy feature is an optimization over IGMP snooping. When IGMP Snooping Proxy is enabled, the switch gathers IGMP reports from downstream hosts by sending queries periodically and updates its local state. Later, when it receives a query from an upstream router, the switch responds with a report immediately based on its local state. When IGMP Snooping Proxy is not enabled, IGMP Snooping floods the query in the VLAN for the hosts to respond with a report and the reports are flooded to ports that are known to have multicast routers. Enabling IGMP Snooping Proxy prevents a sudden burst...
Continue reading →

DHCP for SVI interfaces

Dynamic Host Configuration Protocol (DHCP) is a feature which can be used to provide an IP address to the interfaces on the switch. DHCP can be used to fetch an IP address dynamically from a DHCP server without the administrator needing to configure the IP address manually. Platform compatibility This feature is provided on all platforms Configuration The following configuration can be used under the interface configuration mode to enable or disable this feature [no|default] ip address dhcp An interface is not configured via DHCP by default DHCP is supported on Ethernet, Port-channel, SVI and management interfaces The following sequence...
Continue reading →

Yum support for downloading extensions

EOS Yum support is a feature that allows yum repositories to be configured and saved in the running-config. This allows users to configure repositories that are persistent across reboots and download packages from the repositories. This feature allows an operator to configure a single yum repository and easily deploy extensions and security hot-fixes across all managed switches. Platform compatibility This feature is provided on all platforms Configuration & Usage The following configuration can be used under the configure mode to configure a Yum repository. Arista(config)#management package Arista(config-mgmt-package)#repository <repository-name> Arista(config-mgmt-package-repository-foo)#type yum Arista(config-mgmt-package-repository-foo)#description Network repo Arista(config-mgmt-package-repository-foo)#url http://url/to/my/repo The following is used to...
Continue reading →

Certificate chain and CRL

This is an addition to the SSL certificate and key management feature added in EOS-4.15.0F. Previously, only certificates directly issued by the trusted CA could be configured in an SSL profile. Certificate chaining allows a trusted CA to issue intermediate certificates that will in turn sign other intermediate CAs or the subject certificate. This hierarchical list of certificate going all the way up to the root CA is called the certificate chain. During the TLS handshake, a client will send its peer the entire certificate chain for verification, and vice-versa. The peer only needs to be configured to trust the...
Continue reading →

Transceiver Performance Monitoring and Enhanced Diagnostics

This feature adds support for viewing the Digital Optical Monitoring (DOM) parameters for the optics that support enhanced diagnostics from the CLI. The show commands described later in this document can be used to view the instantaneous values for various PAM4 parameters like Signal-To-Noise Ratio, Residual Inter Symbol Interference, PAM4 Level Transition Parameters, etc. that such optics support. EOS-4.18.0F also introduces the Performance Monitoring feature wherein EOS collects and maintains certain performance statistics over a user-defined time period. EOS stores data for two intervals, the current interval and the most recently completed interval. When the current interval completes, the data...
Continue reading →

TACACS+ RBAC Support

Role-based access control (RBAC) is an approach to regulating access to network resources based on the roles of individual users. Each user has one or more roles. Each role has its own rules which indicate the allowed and denied commands under specified mode. Commands authorization of a user is performed based on these rules. TACACS+ RBAC allows users to configure roles on TACACS servers and rules on switches, which is a much more scalable solution than local RBAC. Roles can be set and modified on the server side once and applied to all switches who connect to the server, instead...
Continue reading →

DCS-7160: ACL based QoS

ACL based QoS marking and policing is supported on DCS-7160 switches. Currently we support IPv4 ACL based QoS via policy-map configuration. The feature can be configured on front panel ports and port-channel interfaces and will be applied to traffic in ingress direction. Platform compatibility DCS-7160-32CQ DCS-7160-48YC6 Configuration Please refer to EOS configuration guide to configure ACL based QoS marking and policing using QoS service-policies. Sample configuration can be found below, Arista(config)#ip access-list acl1 Arista(config-acl-acl1)#permit ip 10.1.1.1/24 any Arista(config-acl-acl1)#exit Arista(config)#class-map match-any class1 Arista(config-cmap-qos-class1)#match ip access-group acl1 Arista(config-cmap-qos-class1)#exit Arista(config)#policy-map policy1 Arista(config-pmap-qos-policy1)#class class1 Arista(config-pmap-c-qos-policy1-class1)#police cir 100 mbps bc 100 kbytes Arista(config-pmap-c-qos-policy1-class1)#set dscp 20...
Continue reading →

Incoming LACPDU Rate-Limit

Incoming LACPDU Rate-Limit on Arista switches allows for errdisabling of ports experiencing a sustained rate of incoming LACPDUs greater than or equal to 10 packets per second. This feature has been introduced in 4.18.0F. Platform compatibility All models supported by EOS-4.18.0F Configuration Incoming LACPDU Rate-Limit is enabled by default, but can be configured on a global or per-port basis. The per-port config will override the global config unless it is set to default. The feature is either enabled or disabled, and currently does not support a user configurable threshold. Global config for LACPDU Rate-Limit can be disabled using: Arista(config)#no lacp...
Continue reading →

LACP on Loopback Interfaces

LACP on Loopback Interfaces allows for Active Port-Channels on one or more interfaces whose link endpoints terminate on the same switch. This feature has been introduced in 4.18.0F and is applicable in custom scenarios where there is a requirement to connect multiple interfaces, back to back, on the same physical switch and form a bundled port-channel. Previously, such a scenario was only possible using a static lag, however, with this feature we introduce the capability to run LACP on such a port-channel which helps with link down discovery via the propagation of LACP PDUs. Platform compatibility All models supported by...
Continue reading →

Enhance “show ip bgp” commands to display age of paths received

The BGP implementation now provides the ability to display the age of paths received for a given prefix using the following CLI show commands when the ‘detail’ option is used show ip bgp show ip bgp [prefix] show ip bgp neighbors [NEIGHBOR_ADDR] received-routes show ip bgp neighbors[NEIGHBOR_ADDR] routes Example: #show ip bgp 0.0.0.0/0 detail BGP routing table information for VRF default Router identifier 10.254.81.1, local AS number 6001 route status: [a.b.c.d] - Route is queued for advertisement to peer. BGP routing table entry for 0.0.0.0/0 Paths: 3 available 65074 65377 65400 10.254.1.4 from 10.254.1.4 (10.254.80.1) Origin IGP, metric 0, localpref...
Continue reading →

BGP AS path prepend using “last-as” keyword

The “set as-path prepend” clause in route-map configuration mode has been enhanced with the addition of the “last-as” keyword, which will prepend the AS path with the specified number of instances of the last AS number in the AS path. Currently, the command only accepts an explicit list of AS numbers to prepend to the AS path. This list may also include one or more “auto” keywords in place of AS numbers, which are replaced by the peer AS number for inbound routes, and the local AS number for outbound routes. By extending some AS paths, this feature enables customers...
Continue reading →

4-Octet BGP AS Specific Extended Communities

The BGP extended communities support within EOS has been enhanced to include support for 4-octet AS Extended BGP Communities (as per RFC5668). This permits 4-octet AS numbers extended-community values to be used in the same manner as 2-octet AS numbers. BGP Extended communities permit the labelling of BGP routing information, permitting administrators filter and manipulate routes based upon the community values. Each extended communities value includes a type field and a value. For the BGP extended community types ‘Two-Octet Route-target’ and ‘Two-Octet Site-of-origin’ the values specified are a 2-octet AS number and a 4-octet local-admin. Two new BGP Extended Community...
Continue reading →

BFD Support for ISIS IPv6

IPv6 support for BFD in ISIS. BFD provides a faster convergence in scaled deployments where using aggressive times may cause scalability issues. This also addresses scenarios which need sub-second hello timers, which is not supported in EOS. Platform compatibility ISIS IPv6 BFD feature is supported on all platforms. Configuration This feature can be configured in two ways. 1.The following command is available under the config-router-isis mode. Arista(config)#router isis <Isis Process ID> Arista(config-router-isis) address-family ipv6 Arista(config-router-isis-af)#[ no | default ] bfd all-interfaces This enables or disables BFD for all ISIS interfaces for ipv6. It is disabled by default. 2. The following...
Continue reading →

BGP Missing Policy Action

The default policy behavior is to permit/accept all routes when a BGP neighbor or peer group is configured with a route-map which is misconfigured (e.g. the route-map is either empty or referencing a non-existing route-map). This type of misconfiguration can go undetected causing undesirable issues (such as hitting the peer max prefix limit). A route-map is considered “empty” when it is referenced by a neighbor or peer group but not defined by the CLI (or perhaps has been deleted). A route-map is considered “non-empty” once a sequence is defined for the route-map. It need not have any match or set...
Continue reading →

BGP Add-Path TX

Introduction BGP Add-Path TX allows for a BGP speaker to advertise multiple paths (instead of a single best-path) for a prefix towards a peering BGP speaker (RFC7911). EOS implemented the BGP Add-Path receiver (RX) functionality in 4.15.XF and is implementing the advertisement (TX) functionality in 4.18.0F. There can be several options for choosing exactly which paths to advertise for a prefix to an Add-Path capable peer: Advertise the best-path (same as not configuring Add-Path) Advertise the best-path and the backup path Advertise ECMP paths Advertise any arbitrary subset of paths using an “Add-Path route-map” Advertise all paths In the 4.18.0F...
Continue reading →

Directed Broadcast

Directed broadcast is method of transfer to send a packet to recipients in a target subnet. This is done by sending a directed broadcast packet as a standard unicast packet until it reaches a switch connected to the target subnet. Then, the packet is broadcast to reach all recipients in the target subnet. Directed broadcast packets are designated by having a IP destination address that is the broadcast address for the target subnet. When a directed broadcast is received, if the receiving switch is not connected to the target subnet, then packet is forwarded as a normal unicast packet. If...
Continue reading →

ISIS ignore attach bit

The default behavior of a level-1 router running IS-IS is to install a default route to a level-1-2 router present in a different area after it finds the attach-bit set in the incoming LSPs from a level-1-2 router. Sometimes this behavior may not be desired and the user might wish for IS-IS on level-1 router to ignore the attach-bit in the incoming LSPs and skip installing a default route to the level-1-2 router. Platform compatibility ISIS ignore attach bit feature is supported on all platforms. Configuration The following command is available under the config-router-isis-af mode. Arista(config)#router isis <Isis Process ID>...
Continue reading →

BGP Fallback AS

BGP Fallback AS offers the ability for BGP peering relationships be established with either the local-as or the router-as. This assists in deployments where the peer AS is expected to change as it avoids the need for concurrent configuration updates. For example, if a service provider is updating their ASN from <old-ASN> to <new-ASN>, peers must make corresponding changes to their eBGP configuration to accept the new value. This will involve configuration updates on both sides of the peering relationship. If the updates are not co-ordinated, connectivity may be lost. With fallback AS, the service provider can configure their BGP...
Continue reading →

OSPF Max LSA Retransmission Threshold

The OSPF Max LSA Retransmission Threshold feature adds a configurable limit to the number of LSA update retransmissions. OSPF sends LSA updates to its OSPF neighbors in a Link State Update packet. The neighbor acknowledges that it received and accepted the LSA update by sending a LSA Acknowledgment in a Link State Acknowledgement packet. If a LSA acknowledgment is not received in the configured retransmit interval from a neighbor, OSPF retransmits the LSA update to that neighbor. Retransmissions will continue until an acknowledgement is received or the maximum retransmission limit is reached. When the limit is reached for a neighbor,...
Continue reading →

OSPF Non Stop Forwarding

Introduction The OSPF Non Stop Forwarding (NSF) feature adds support for Graceful OSPF Restart (IETF RFC 3623). When OSPF Graceful Restart (GR) is configured, a Smart System Upgrade (SSU), redundancy switchover from active to standby supervisor, or a restart of the OSPF software should be hitless. Neighboring routers continue to forward traffic to the restarting router, and traffic forwarding through the restarting router continues without loss. If GR is successful, router downtime should be completely transparent to network applications. NSF allows the router to retain its hardware routing tables (Forwarding Information Base/FIB) and continue forwarding utilizing those tables while routing...
Continue reading →

Storm Control: Rate limiting unknown unicast packets

  Introduction A traffic storm is a flood of packets entering a network, resulting in excessive traffic and degraded performance. Storm control prevents network disruptions by limiting traffic beyond specified thresholds on individual physical LAN interfaces. Storm control monitors inbound traffic levels over one-second intervals and compares the traffic level with a specified benchmark. The storm-control command configures and enables storm control on the configuration mode physical interface. Unknown unicast storm control is another mode added to the existing storm control command. This mode provides the capability to rate limit unknown unicast traffic to a user configurable value in pps...
Continue reading →

DirectFlow

DirectFlow runs alongside the existing layer 2/3 forwarding plane, enabling a network architecture that incorporates new capabilities, such as TAP aggregation and custom traffic engineering, alongside traditional forwarding models. DirectFlow allows users to define flows that consist of match conditions and actions to perform that are a superset of the OpenFlow 1.0 specification. DirectFlow does not require a controller or any third party integration as flows can be installed via the CLI. Platform compatibility DCS-7010T DCS-7010T-DC DCS-7050S DCS-7050T-36 DCS-7050T-52 DCS-7050T-64 DCS-7050TX DCS-7050SX DCS-7050QX DCS-7260QX-64 DCS-7060CX-32S DCS-7060CX2-32S DCS-7250QX DCS-7260CX DCS-7300X DCS-7320X Configuration Directflow supports flow configuration at different stages of the...
Continue reading →

WRED Support

WRED ( Weighted Random Early Detection ) is one of the congestion management techniques. It works at queue level to drop packets randomly after crossing given queue threshold even before queue is full. Without WRED, all newly arriving packets get tail dropped once the queue is full, which creates TCP global synchronization issue. WRED helps to avoid TCP global synchronization. Platform compatibility DCS-7050X DCS-7300X DCS-7250X Configuration This is configured at interface’s tx-queue level. The drop profile is defined by minimum-threshold, maximum-threshold and drop-probability. The units for thresholds can be given in segments ( 1 segment is equivalent to 208 bytes on T2...
Continue reading →

Aggregate Storm Control per Traffic Class

Introduction Aggregate storm-control with traffic-class option provides the capability to rate limit BUM( Broadcast, Unknown-unicast, Multicast ) traffic to user configurable value in pps( minimum value can go to 1 pps ) per traffic-class across all ports in the system. Platform compatibility DCS-7050QX DCS-7050SX DCS-7050TX DCS-7260QX-64 DCS-7060CX-32S Configuration CLI command to configure aggregate storm-control per traffic-class is Arista(config)#[no] storm-control bum aggregate traffic-class <tc> level pps <rate> ‘bum’ means BUM ( broadcast, unknown-unicast, multicast ) traffic. ‘aggregate’ means all ports. This will create a shared policer instance and attach entries corresponding to traffic-class to it. Sample configuration Arista(config)#storm-control bum aggregate traffic-class...
Continue reading →

Per port Per VLAN Qos range

Classification of traffic for QoS policies on a per-port-per-vlan basis is already supported and corresponding information can be found here – http://eos.arista.com/eos-4-17-0f-toi/per-port-per-vlan-qos/. ‘match vlan’ configuration under a class-map helps in programming that configuration. This enhancement to the ‘match vlan’ is to allow configuration for multiple vlans as a range (single range or comma-separated multiple ranges) instead of just vlan and a mask. This feature only works with QoS-based class-maps. Platform compatibility DCS-7010T DCS-7050X DCS-7250X DCS-7260X DCS-7280E, DCS-7280R DCS-7300X DCS-7320X DCS-7500E, DCS-7500R Configuration Please refer to EOS configuration guide to configure ACL policing QoS and per-port-per-VLAN. Once created, policy-maps can be...
Continue reading →

Policy maps under QoS Profiles

QoS profiles have been applicable on fabric and front panel ports across all platforms from EOS 4.17.0F release onwards with support for all interface level QoS configurations. Support for application of a policy-map under QoS profile has now been added in EOS 4.18.0F. The same policy-map can be applied through QoS profile on one interface and directly attached on another. If two policy-maps are applied on an interface through directly and QoS profile, the one applied directly is given more priority and used. Configuration The command to configure a policy-map under qos profile is – Arista(config)#qos profile <qos-profile name> Arista(config-qos-profile-name)#service-policy...
Continue reading →