• Tag : TOI

 
 

TapAgg support on MACsec linecards

Introduction Media Access Control Security (MACsec) is an industry standard security technology that provides secure communication for all traffic on Ethernet links. As of EOS 4.20.5F for Arista 7500 lines of switches, users of the tap aggregation features can benefit from using MacSec on tap/tool ports on MacSec capable line cards. Users can use MACsec to secure the communications between their tap/tool ports and ports from other switches which may not necessary be a TapAgg equipment. Enabling MACsec on a port puts it into an “unauthorized” state. Then the interface will not be forwarding any traffic until the MACsec peers successfully complete the MACsec Key Agreement (MKA) procedures. Once...
Continue reading →

Uniform Tx/Rx DOM Thresholds

EOS-4.20.6F adds support for customizing SFP+ and QSFP+ transceiver transmit and receive DOM thresholds. There are three sources of DOM thresholds available:   DOM threshold values that are hard-coded in each transceiver. These values are hard-coded by the transceiver manufacturer, and may vary based on manufacturer part number or serial number. In other words, transceivers with the same Arista part number could have different DOM threshold values. By default, Arista EOS uses the hard-coded values as the default DOM threshold values for each transceiver. An Arista provided DOM threshold file, which can be used to enable uniform thresholds per Arista...
Continue reading →

EVPN Centralized Anycast Gateway

EVPN Centralized Anycast Gateway Description EVPN IRB interface supports both L2 switching and L3 Vxlan Routing on the same 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).  To have the closest TOR to always perform both Vxlan bridging as well as Vxlan Routing, always configure the IRB interfaces as the DGW on all the TORs. This model is commonly known as “distributed Vxlan Routing with EVPN”.  This model is supported in EVPN since...
Continue reading →

Support for PBR in any VRF

This feature enables the user to configure PBR policy on an interface in any VRF, to match and forward incoming packets to next-hop in any VRF. If “vrf” keyword is not specified in the “set nexthop” configuration, the packets will be PBR forwarded in the VRF associated with the incoming interface. Platform compatibility DCS-7010 DCS-7050 DCS-7050X DCS-7060 DCS-7260 DCS-7160 DCS-7250X DCS-7280E DCS-7280R DCS-7300 DCS-7500E DCS-7500R Configuration To redirect matching incoming packets within ingress VRF, the specification of VRF as part of “set nexthop” is not necessary switch#configure terminal switch(config)#policy-map type pbr policy1 switch(config-pmap-pbr-policy1)#class class1 switch(config-pmap-c-pbr-policy1-class1)#set nexthop 11.11.0.1 switch(config-pmap-c-pbr-policy1-class1)#exit switch(config-pmap-pbr-policy1)#exit switch(config)#int...
Continue reading →

Cloud High Availability

Cloud HA feature provides active-active redundancy between two vEOS router instances running in Cloud such as AWS and Azure. Typical deployments will instantiate a pair of vEOS instances in different fault domains/Availability zones of a logical network ( e.g AWS Virtual Private Network( VPC) or Azure Virtual Network ) within a Cloud Provider’s network. The vEOS instances will be used to route traffic to/from cloud hosted VM instances in partitioned subnets which are logically deployed behind each of the vEOS router. The Cloud HA feature allows the vEOS router to back-up each other in case of either peer failure or...
Continue reading →

TAP Aggregation – FCS error handling

In TAP Aggregation mode, when receiving a packet whose Frame Check Sequence (FCS) is corrupted, the default behavior on the 7280E/R/R2 and 7500E/R/R2 series is to replace the bad FCS with the correct value and forward it. Configuration options are available to control the FCS error behaviour, such as to discard errors. Platform compatibility DCS-7280E/R/R2 series DCS-7500E/R/R2 series Configuration A global TAP Aggregation command is used to configure the behavior regarding the FCS errors. To discard the packets with a corrupted FCS: Arista(config-tap-agg)#mac fcs-error discard To revert to the default behavior, i.e. to replace the corrupted FCS with the correct...
Continue reading →

Stateful Switchover on DCS-7300x

Stateful switchover is a redundancy mode available on systems with 2 supervisor cards. One supervisor card is active and performs all the normal operations. The other card is in standby and is inactive. In the event of a failure of the active supervisor, the standby supervisor takes over and becomes active, preserving the configuration and with minimal traffic loss (up to 1s). The previously active supervisor is rebooted in standby mode if still present/functional.   Platform compatibility DCS-7304 and DCS-7308 Configuration To activate stateful switchover, issue the following commands on the system: Arista(s1)(config)#redundancy Arista(s1)(config-redundancy)#protocol sso Note: both supervisors must have the same...
Continue reading →

IP Packet length matching in Ingress Security ACLs

Similar to L4 ports, ACL rules can be configured to filter ingress packets based on their IP length (present in the IPv4 header). The match criteria consist of lookups on the IP length field. The supported range operators are as follows: any – all lengths eq length1, length2 … lengthn – A list of lengths. Max list size of 10 numbers gt length – The set of lengths with numbers larger than the listed length lt length – The set of lengths with numbers smaller than the listed length range length1 length2 – The set of lengths whose numbers are...
Continue reading →

Remove ARP from L3 when MAC L2 port is down

This feature removes an ARP entry when the physical port, on which the ARP entry’s MAC address is learned, goes down. This feature applies only to dynamic ARP entries, not static ARP entries. In addition, if the physical port, which is down, is a member of a LAG, ARP entries are not removed if the LAG remains up (due to other members still being up). ARP entries will be removed if the LAG interface goes down. Platform compatibility This feature is platform independent. Configuration This feature is configurable on a per L3 interface basis. By default, it is disabled. The following example...
Continue reading →

Asset Tagging

EOS release 4.20.5F adds asset tagging support that aids hardware identification by the use of user-supplied strings. Platform compatibility Asset tagging is currently supported only on fixed systems. Configuration Asset tags are configured via the CLI or eAPI using the following command: [ no | default ] hardware asset-tag <hardware> <tag> On a fixed system, <hardware> can be either ‘switch’ or ‘powersupply <1-2>’, depending on the power supplies present. For example, Arista# hardware asset-tag switch Floor3RU4 The current configuration can be viewed with the ‘show’ command: Arista# show hardware asset-tagComponent           Serial Number       Asset Tag ...
Continue reading →

Block Untagged Frames on Dot1Q-Tunnel Port

Introduction “Block Untagged Frames on Dot1Q-Tunnel port” is a new feature that has been added in this release. When this feature is activated, it can block any incoming untagged frame on Dot1Q Tunnel port. Ethernet frames carrying :  No Dot1Q tag (Untagged) or Dot1Q tag with VLAN Id equal to zero or Dot1Q tag carrying Tpid different than the one configured on Dot1Q tunnel port will be treated as Untagged frames, which will prevent them to flow through the VLAN of the Dot1Q-Tunnel port. This feature is applicable on the ingress direction and is supported at Ethernet interface and LAG level; This means that behavior applied to a Dot1Q-Tunnel port...
Continue reading →

EVPN IRB with Vxlan Underlay

EVPN Integrated Routing and Bridging (IRB) with VXLAN In the traditional data center design, inter-subnet forwarding is provided by a centralised router, where traffic traverses across the network to a centralised routing node and back again to its final destination. In a large multi-tenant data center environment this operational model can lead to inefficient use of bandwidth and sub-optimal forwarding. To provide a more optimal forwarding model and avoid traffic tromboning, the EVPN inter-subnet draft (draft-sajassi-l2vpn-evpn-inter-subnet-forwarding) proposes integrating the routing and bridging (IRB) functionality directly onto the VTEP, thereby allowing the routing operation to occur as close to the end...
Continue reading →

TAP Aggregation – TCAM Profile Selection

This article describes a new TAP Aggregation TCAM profile and a corresponding enhancement to the TAP Aggregation mode command. The new TCAM profile is “tap-aggregation-default” and is used to support the standard TAP Aggregation features. Previously, the base TCAM profile natively supported TAP Aggregation, however to achieve better resource utilization, the TAP Aggregation TCAM features were moved into this new profile. To facilitate automatic usage of “tap-aggregation-default”, the TAP Aggregation mode command now supports applying an overlay TCAM profile. If no profile is selected, the default is chosen automatically (see Configuration).   Supported Platforms DCS-7280E, DCS-7280R DCS-7500E, DCS-7500R Configuration (config)#...
Continue reading →

MLAG Dual Primary Detection

Under certain failure scenarios, MLAG peers might end up in a “dual-primary” state (also known as “split-brain” or “active-active”), where both peers are functioning properly but the connectivity between them is down (typically when the peer link is down). In this state, each peer will run layer-2 protocols such as Spanning Tree Protocol independently. Depending on the topology, this may cause loops in the network. IGMP snooping might also be affected. The Dual Primary Detection feature allows using the management port as a separate out-of-band connection between the two peers in addition to the peer link. Once configured, the MLAG...
Continue reading →

Bidirectional PIM on DCS-7020R, DCS-7280E/R/R2, DCS-7500E/R/R2

Bidirectional PIM has information on Bidirectional Protocol Independent Mulicast (PIM). Additional information applicable to DCS-7020R, DCS-7280E/R/R2 and DCS-7500E/R/R2 is documented here. Platform compatibility DCS-7020R DCS-7280E DCS-7280R DCS-7280R2 DCS-7500E DCS-7500R DCS-7500R2 Limitations “Bidirectional PIM” is incompatible with “Dot1x MAB” and “Drop Mac” features. When more than one feature is configured, “Bidirectionl PIM” gets priority followed by “Dot1x MAB” followed by “Drop Mac”. If “Bidirection PIM” is enabled on platforms using Arista Algomatch, ACLs are not supported on routed multicast traffic including sparse-mode PIM

Match MPLS in QoS class-maps

Classification of MPLS packets based on traffic-class bits in MPLS header for QoS Policy-Maps. Platform compatibility DCS-7020R DCS-7280R DCS-7280R2 DCS-7500 DCS-7500R2 Configuration 7500(config)#hardware tcam 7500(config-hw-tcam)#system profile qos 7500(config-hw-tcam)#exit 7500(config)#class-map type qos match-any class1 7500(config-cmap-qos-class1)#match mpls traffic-class ? $      end of range <0-7>  Match packets by Mpls Traffic Class value 7500(config-cmap-qos-class1)#match mpls traffic-class 4 7500(config-cmap-qos-class1)#exit 7500(config)#policy-map type qos policy1 7500(config-pmap-qos-policy1)#class class1 7500(config-pmap-c-qos-policy1-class1)#set traffic-class 3 7500(config-pmap-c-qos-policy1-class1)#exit 7500(config-pmap-qos-policy1)#exit 7500(config)#interface ethernet 3 7500(config-if-Et3)#service-policy input policy1 7500(config-if-Et3)#exit Status 7500(config)#show class-map class1   Class-map: class1 (match-any)     Match: mpls traffic-class 4 7500(config)#show policy-map policy1 Service-policy input: policy1   Hardware programming status: Successful   Class-map: class1 (match-any)...
Continue reading →

ARP converted Host Routes injection into BGP

This features enables ARPs learnt on an SVI interface to be converted into Host routes which can further be redistributed into BGP protocol to take part in the route selection decision process and to get advertised to the peers. These Host routes are not installed into the hardware and are only being generated for advertisement purpose. This feature works for both static and dynamic ARPs. ARP will be converted to Host route, if the feature is enabled using the CLI (as described in the next section), and corresponding MAC address exists in the MAC table Host route will be deleted,...
Continue reading →

PIM Static Source Discovery

Introduction PIM Static Source Discovery (PIM-SM SSD) is a feature implemented as part of PIM-SM. Familiarity with setting up and configuring PIM-SM ( Sparse Mode ) and PIM-SSM ( Source Specific Multicast ) is assumed. PIM-SSM is used to deliver multicast packets from a specific source address requested by a multicast receiver. PIM-SSM bring several benefits over PIM-SM. It does not rely on the designation of a rendezvous point (RP) to establish a RP tree and then switch to Shortest-Path Tree to source. Instead, PIM-SSM builds Shortest-Path Tree to source directly since source is always known in advance. However, PIM-SSM...
Continue reading →

BFD for Static Routes

BFD for static routes enables monitoring of directly connected next-hop reachability using a BFD session. This is achieved by associating the next-hop of the static route with a static BFD neighbor configuration. The static route is either installed or removed based on the status of the underlying BFD session. A static route whose next-hop is configured to be tracked by BFD is referred to as a ‘BFD tracked static route’ in the context of this document. This feature is supported for both IPv4 and IPv6 static routes. Platform compatibility BFD for Static Routes feature is supported on all platforms. Configuration The existing...
Continue reading →

Resilient ECMP

Overview Equal Cost Multi-path (ECMP) provides the ability to load-share traffic across multiple next-hops. When a next-hop fails or is deleted all flows are affected. This is due to the nature of the load-balancing algorithm which re-calculates a new hash for the flows based on the remaining active next-hops. Resilient ECMP keeps the total number of next-hops same by replacing the deleted next-hop with one or more of the remaining active next-hops and maintain the order of next-hops in the ECMP groupset. This feature is currently supported on the 7050, 7160, 7280, 73xx, 75xx platforms Benefits When a next-hop fails,...
Continue reading →