Event Manager Custom bash counters

Introduction The EOS Event Manager feature provides the ability to specify a condition and an action to be carried out when that condition is detected. It is a flexible and configurable way to automate the reaction to conditions without the need for a system operator to observe and apply the desired actions manually. This feature extends the on-counters event handler by providing the ability to create custom counters based on the output of bash commands.   The on-counters Event Handler The on-counters event handler extension to the Event Manager, provides a framework to specify a condition in the form a logical...
Continue reading →

Event Manager TCollector counters

Introduction The EOS Event Manager feature provides the ability to specify a condition and an action to be carried out when that condition is detected. It is a flexible and configurable way to automate the reaction to conditions without the need for a system operator to observe and apply the desired actions manually. The TCollector is an open-source software that is used to gather statistical counters for the Linux system. This feature integrate the TCollector Counters with the Event Manager and provides a new set of the system statistical counters that can be used with the on-counters event handler.   The on-counters Event Handler...
Continue reading →

Event Manager on-logging handler

Introduction The EOS Event Manager feature, introduced in 4.17.0F,  provides the ability to specify a condition and an action to be carried out when that condition is detected. It is a flexible and configurable way to automate the reaction to conditions without the need for a system operator to observe and apply the desired actions manually. The on-logging event handler extension to the Event Manager provides a framework to detect text strings in Syslog messages. When the condition is met, an action specified by the user will be carried out. The regular expression pattern matching is done on the messages in...
Continue reading →

Coherent PHYs and Optics

The 7500E-6CFPX-LC linecard with ACO CFP2 optics provides connectivity over DWDM systems and links. 7500E-6CFPX-LC currently only supports connections to other 7500E-6CFPX-LC linecards. Platform compatibility DCS-7500E Enhancements for Linear CFP2-ACO Configuration Updated grid spacing values Grid spacings of 25, 12.5, and 6.25 GHz are now available for linear optics. Grid-spacings that are a multiple of these values, for example 37.5 GHz, can use a grid spacing that evenly divides it, for example 12.5 GHz. Arista(config)#interface Ethernet 3/1 Arista(config-if-Et3/1)#transceiver channel 50 grid-spacing 12.5 Configuring roll-off factor The roll-off factor is an important parameter for best link performance, with a range of...
Continue reading →

Multichip and CPU LANZ

Introduction LANZ adds support for monitoring congestion on backplane (or fabric) ports on DCS-7304, DCS-7308, DCS-7316, DCS-7250QX, DCS-7260CX and DCS-7320X. In addition to monitoring congestion on backplane (or fabric), LANZ adds support for monitoring congestion on CPU ports on DCS-7050QX, DCS-7050SX, DCS-7050TX, DCS-7260QX and DCS-7060CX. LANZ streaming is also available for fabric and CPU ports. This page will only demonstrate specific commands for fabric and CPU ports, and for generic LANZ commands, refer to the existing documentation for LANZ. Platform compatibility Monitoring of both CPU and backplane (or fabric) ports is supported on the following platforms: DCS-7304 DCS-7308 DCS-7316 DCS-7250QX...
Continue reading →

Allow single lane of 10G on 40G only ports

The 40G-only ports on Trident 2 switches may now be configured as 1 lane of 10G, 1G, or 100M*. This may be achieved using the first lane of a QSFP+ cable or transceiver, the first lane of a QSFP+ to 4xSFP+ “octopus” cable or transceiver, or an SFP+ cable or transceiver inserted into a Mellanox MAM1Q00A-QSA QSFP to SFP adapter (QSA). Platform compatibility DCS-7050QX-32 DCS-7050QX-32S DCS-7050SX-128 DCS-7050TX-128 Limitations The bandwidth scheduler on the forwarding chip will schedule the 40G-only ports as if they were running at 40G regardless of their actual speed. * Some ports on the DCS-7050QX-32 and DCS-7050SX-128 do...
Continue reading →

Support to specify VRF for PBR nexthops

This feature enables the user to configure PBR policy on an interface in the default VRF to match and forward incoming packets to a next-hop in a user defined VRF. Platform compatibility DCS-7010 DCS-7050 DCS-7050X DCS-7250X DCS-7280E DCS-7300 DCS-7500E Configuration To redirect matching incoming packets to a nexthop in a user defined VRF specify the VRF name as part of the PBR action. If multiple nexthops are provided as part of the PBR action to use ECMP, all the nexthops must be in the same VRF. The VRF specified must be configured and the nexthops should be reachable. switch#configure terminal switch(config)#policy-map type...
Continue reading →

ECMP Hash Visibility

ECMP Hash visibility CLI determines the output interface for an ECMP set based on the flow parameters supplied by the user. Ingress interface, source IP address, destination IP address and  IP protocol are the required parameters. L4 source and destination ports and VLAN identifier are optional, but should be specified if the packet has them. 7050(config)# show load-balance destination ingress-interface <interface> { src-ipv4-address <ipv4-address> dst-ipv4-address <ipv4-address> | src-ipv6-addess <ipv6-address> dst-ipv6-address <ipv6-address> } ip-protocol <protocol> [src-l4-port <port#> dst-l4-port <port#>]  [vlan-id <vlan>] Platform compatibility 7050X 7250X 7300 7050 7010 Configuration Example 1: Say, the routes programmed in system are: 7050(config)#show ip route       ...
Continue reading →

IPv6 route support for Nexthop Groups

With this, IPv6 routes can be configured pointing to a static Nexthop-group of 2 types:- Type “ip” : IPv6 packets matching the route will be load balanced across the paths. This works like a regular but static ECMP. Type “ip-in-ip” : Packets matching the route will be encapsulated within an IPv6 tunnel and forwarded. Platform compatibility DCS-7050X DCS-7250X DCS-7300 DCS-7010 Configuration Configure a static Nexthop-Group route and an IP-in-IP Nexthop-Group. Arista(config)#ipv6 route 2001::1/128 nexthop-Group abc-ip Arista(config)#nexthop-group abc-ip type ip Arista(config-nexthop-group-abc)#?  entry           Nexthop Group Entry Index  size            Nexthop Group Entry Size  ttl             Time to Live...
Continue reading →

Per port per VLAN QoS

The per-port-per-VLAN feature allows application of QoS policies for IP, IPv6 and non IP traffic on a per-port-per-VLAN basis. This feature is also supported for port-channels. This feature is not supported for CoPP. Platform compatibility Here is the platform compatibility with EOS version where the feature got introduced. DCS-7010T EOS4.17.0F DCS-7050X EOS4.17.0F DCS-7250X EOS4.18.0F DCS-7300X EOS4.18.0F DCS-7280(E/R) EOS4.18.0F DCS-7500(E/R) EOS4.18.0F Configuration On DCS-7280(E/R) and DCS-7500(E/R), to use this feature, tcam profile needs to be switched to ‘qos’. Arista(config)#hardware tcam profile qos Please refer to EOS configuration guide to configure ACL policing QoS. Once created, policy-maps can be applied on single...
Continue reading →

Policing on LAGs

Ingress policing on front panel ports is supported on DCS-7010X and DCS-7050X since EOS4.14.0F. When ingress policing is applied on a port-channel, it polices the matched traffic from all its member interfaces combined i.e aggregate policing and statistics. If per-interface policer is attached to a port-channel, one set of TCAM entries is created for all its member interfaces and associated port-bitmap is updated i.e aggregate policing performed on all its member interfaces. For example, if per-port policer has to allow 1 Mbps of TFTP traffic on all matched TFTP traffic on interfaces Ethernet1, Ethernet2 and a port-channel with members Ethernet3...
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-7500E DCS-7280SE 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 bytes or kilo bytes or mega bytes. Arista(config)#int ethernet 1 Arista(config-if-Et1)#tx-queue...
Continue reading →

Dual Tag VLAN mapping

Dual Tag VLAN mapping feature defines mapping between (outer VID and inner VID of double tagged packet) and bridging VLAN. At ingress, pair of VIDs is mapped to a bridging VLAN and at egress, the bridging VLAN is mapped to a pair of VIDs. Platform compatibility DCS-7500E DCS-7280E Configuration This is a interface level configuration. Arista(config)#int eth 3/1 Arista(config-if-Et3/1)#switchport vlan mapping <outer-tag> inner <inner-tag> <bridging-vlan> Example Arista(config-if-Et3/1)#switchport vlan mapping 1000 inner 100 200 Ingress(or)Egress only vlan mappings can be configured using 'in'(or)'out' keywords Arista(config-if-Et3/1)#switchport vlan mapping in <outer-tag> inner <inner-tag> <bridging-vlan> Arista(config-if-Et3/1)#switchport vlan mapping out <bridging-vlan> <outer-tag> inner <inner-tag> Example...
Continue reading →

Ingress Traffic Class Counters

The feature enables support for displaying per traffic-class counters on ingress interfaces. The feature is supported on routed-ports and subinterfaces only. Both packet and octet counts are displayed. Platform compatibility DCS-7280E DCS-7500E Configuration The feature is configured as: Arista(config)#hardware counter feature traffic-class in The feature will only be enabled if the ‘tc-counters’  TCAM profile is configured. This profile can be configured as: Arista(config)#hardware tcam profile tc-counters Status Show Commands The currently configured dynamic counter features can be listed using the following show command: Arista#show hardware counter feature Feature Direction Counter Resource ... Traffic-class in 3 The counter resource allocated to the feature...
Continue reading →

Global LAG Hashing Profiles

Users can now define a global LAG hashing profile. The global LAG hashing profile will be applied to all linecards which do not have a specific LAG hashing profile assigned to them. Platform compatibility This feature is available starting in EOS 4.17.0F on 7500E and 7500R systems. Configuration The user selects a LAG hashing profile to be designated global 7500(config)#port-channel load-balance sand profile ? WORD Name of the load-balance profile 7500(config)#port-channel load-balance sand profile myGlobalProfile The ‘default’ profile is a special profile which cannot be deleted and will be set to global if no other profile is selected to be...
Continue reading →

Sub-interface ACLs

This feature enables ACL functionality on subinterfaces. Platform compatibility Product Family Minimum Software Version DCS-7280E 4.17.0F DCS-7500E 4.17.0F DCS-7280R 4.18.0F DCS-7500R 4.18.0F Configuration ACLs on subinterfaces are configured using the following command: Arista(config-if-Et1.1)#ip|ipv6 access-group <acl-name> in|out ACLs on subinterfaces are unconfigured using the following command: Arista(config-if-Et1.1)#no ip|ipv6 access-group in|out Status Show Commands show ip|ipv6 access-lists <acl-name> summary shows the summary of a configured ACL including the subinterface on which the ACL is configured and active. Arista#show ip access-lists acl1 summary IPV4 ACL acl1 Total rules configured: 1 Configured on Ingress: Et5.1 Active on Ingress: Et5.1 Arista#show ipv6 access-lists acl1 summary...
Continue reading →

MacSec EAP-FAST support

Support for Media Access Control Security (MACsec) with static keys was added in EOS-4.15.4. This feature brings support for dynamic Mac Security keys. To derive Mac Security keys dynamically, both peers must be configured for 802.1x authentication. One peer must be configured to be the ‘Authenticator’ and the other peer is the ‘Supplicant’. Upon a successful 802.1X authentication sequence between the peers, keying material is generated by both the authenticator and the supplicant. This keying material is then used to derive Mac Security keys to establish a MACSec Key Agreement (MKA) protocol session. The following diagram depicts a typical Mac...
Continue reading →

Per VLAN MAC Learning

Per VLAN MAC Learning is a feature to enable/disable mac learning per-vlan instead of per-port. Using this feature with VxLAN could provide a poor-man version of Point-to-Point VxLAN Pseudowire services. Platform compatibility DCS-7500E DCS-7280 Configuration By default, MAC learning on a VLAN is enabled. To disable MAC learning on VLAN 10, simply issue no mac address learning command on VLAN config. 7280(config)#vlan 10 7280(config-vlan-10)#no mac address learning To bring the VLAN back to the default mode use mac address learning command. 7280(config-vlan-10)#mac address learning Status To check MAC Learning status on VLANs, issue show mac address-table command. 7280(config)#vlan 10 7280(config-vlan-10)#no...
Continue reading →

MPLS over GRE Encapsulation

MPLS over GRE encapsulation MPLS-over-GRE encapsulation support in EOS 4.17.0 enables tunneling IPv4 packets over MPLS over GRE tunnels. This feature leverages next-hop group support in EOS. With this feature, IPv4 routes may be resolved via MPLS-over-GRE next-hop group to be able to push one MPLS label and then GRE encapsulate the resulting labelled IPv4 packet before sending out of the egress interface. Platform compatibility DCS 7500E DCS 7280SE Configuration nexthop-group group_name type mpls-over-gre size num_entries ttl ttl_value tunnel-source { intf intf | src_ip_addr } entry index push label-stack label tunnel-destination dst_ip_addr Example: switch(config)#nexthop-group nhg1 type mpls-over-gre switch(config-nexthop-group-nhg1)#tunnel-source 11.1.1.1 switch(config-nexthop-group-nhg1)#ttl...
Continue reading →

VRRP IPv6 using VRRP IPv4 MAC prefix

This document describes how to use the new feature, VRRP IPv6 using VRRP IPv4 MAC prefixes. RFC 5798 defines a specific mapping of VRRP Virtual Router Identifier (VRID) to a MAC prefix. For example, a VRRP IPv6 instance would use 00:00:5e:00:02:<VRID> as the virtual MAC address. The new feature would allow to over ride the RFC specification and use VRRP IPv4 virtual MAC address 00:00:5e:00:01:<VRID> prefix for IPv6 VRRP configurations. For example, an IPv6 VRRP group with VRID 10 would have a mac address 00:00:5e:00:02:0a. When the feature is configured via “vrrp ipv6 mac range ipv4“, 00:00:5e:00:01:0a will be used...
Continue reading →