Tag : EOS-4.15.2F

Arista switches use the hashing algorithm to load balance traffic among LAG (Link Aggregation Group) members and among L3 ECMP (equal cost multipath) paths. In case of IP/IPV6 traffic, the hashing algorithm may include (if so configured for LAG) the typical IP packet fields such as source/destination IP address(es) as well as source/destination port(s) for UDP/TCP traffic. In order to improve traffic distribution for IPV4/IPV6 traffic, IPV4/TTL and IPV6/HopLimit fields have been added to the hashing algorithm for both LAG and ECMP starting EOS release 4.15.2F for the supported platforms listed below. Platform compatibility DCS-7300X series DCS-7050X series DCS-7250QX Configuration A new CLI for setting the TTL/Hop...
Continue reading →

Starting EOS release 4.15.2F, the ability to re-number front-panel ports of 7050QX-32S is supported.   1) By default, 7050QX-32S front panel ports are numbered in the following way:   SFPs : 1 – 4 QSFPs: 5/1 – 36   2) Following configuration/show CLI commands have been introduced to change/view port numbering:   boot port numbering qsfp dense              Above command, after user chooses to proceed, will erase startup-config, reboot the switch,            and upon reboot, after the switch comes out of ZTP mode, the ports will be numbered like this:      ...
Continue reading →

Configurable TPID enables TPID to be configured per switchport (default TPID on switchport is 0x8100) on supported platforms starting 4.15.2F. Packet is considered tagged (both from ingress and egress point of view) on an interface if and only if TPID on the packet matches the TPID configured on the interface. Terminology As per IEEE 802.1q, standard TPID (Tag Protocol IDentifier) is 0x8100. IEEE 802.1ad standardizes 0x88a8 as the outer TPID for QinQ frames. Another commonly used (but not standardized by IEEE) outer TPID for QinQ frames is 0x9100. TPID overlays the ethertype/length field in an ethernet frame and is also referred to as ‘dot1q...
Continue reading →

Starting 4.15.2F, this feature provides a capability to use a 100G link as a unidirectional link. There are 3 unidirectional link modes: send-only, receive-only, and send-receive. In send-only mode, the interface can only send packets but cannot receive any packet. In receive-only mode, the interface can only receive packets but cannot send any packet. In send-receive mode, the interface can both send and receive packets. However, the interface sends packets to one partner interface but receives packets from a completely different partner interface. In unidirectional link modes, any protocol that requires two-ways interactions on the link will not work properly....
Continue reading →

As of EOS-4.15.2F, VM Tracer adds support for VMware NSX-V. This includes supporting NSX-V specific features, improved integration of NSX-V and VMware vShield Manager within core VM Tracer commands, and improved consistency of CAPI models provided by VM Tracer. EOS-4.15.2F also adds the ability to filter some output using a user-provided VM MAC address. Status show vmtracer vm The show vmtracer vm and show vmtracer vm detail command can be used to display VM interfaces accessible to VmTracer-enabled switch interfaces. It is possible to filter on either VM name or VNic MAC address which produces output in the detailed format produced by show vmtracer vm detail....
Continue reading →

Bidirectional Protocol Independent Multicast (PIM) allows routers to build trees to deliver multicast traffic from sources to receivers. It is a variant of sparse-mode PIM that efficiently addresses the use case where receivers for a  multicast group are also sources for that group. While sparse-mode PIM builds shared trees and source specific trees, bidirectional PIM only builds shared trees. A shared tree for a multicast group is rooted at the Rendezvous Point (RP) for that group. The RP for a bidirectional group is an IP address, which may or may not be real, but is reachable via all routers in the multicast...
Continue reading →

Static multicast feature brings in capability to statically configure multicast routes on any Arista platform running this release of software. This feature must be viewed independently of PIM-SM and PIM-BIDIR protocols which are dynamic variants of programming multicast routes. The feature has been designed to co-exist with these protocols. While the feature is designed to co-exist with dynamic protocols, the selection method for routes are to be kept in mind before programming static routes in order to get predictable results. Static multicast routes competes with the routes provided by PIM-SM and PIM-BIDIR mainly because this static variant, allows the operator...
Continue reading →

Policy Based Routing (PBR) provides the flexibility of routing according to custom defined policies in a way that goes beyond traditional routing protocol concerns. By using policy-based routing, customers can implement policies which can selectively cause packets to take paths different from the paths decided by routing protocols. Platform compatibility DCS-7050X DCS-7300X DCS-7250X DCS-7160 Configuration Arista supports a CLI model where a QoS-style policymap/classmap will be used for the PBR feature. In addition to matching on regular ACL, the PBR policymap can also include a ‘raw match’ statement that looks like a single entry of an ACL. The action part...
Continue reading →

In previous releases of EOS, Stub area and NSSA area types were supported for OSPFv3, but without support of the “no-summary” parameter. This new release of EOS is adding support of the “no-summary” option for both of them. As a reminder, Normal area – accepts intra-area, inter-area and external routes. The backbone is a normal area. Stub area – does not receive route advertisements external to the AS. Stub area routing is based on a default route; external destinations are reachable through a default inter-area route. Inter-area-prefix LSAs are imported into Stub areas. Not-so-stubby-area (NSSA) – may import external routes from an ASBR and propagate...
Continue reading →

Up until now, the mirroring ACLs on the DCS-7150 series used to support only the security ACL rules. This meant that fields beyond the layer-4 header couldn’t be matched in these ACLs. Recent releases have added support for deep-inspection rules in ACLs, but they were reserved for the TapAgg mode. This feature allows VxLAN deep-inspection rules to be specified in the mirroring ACLs, when the switch is operating in normal mode. Platform compatibility DCS-7150S Configuration The following are a few example VxLAN rules that can be specified in mirroring ACLs. The command itself is the same as the VxLAN deep-inspection rule...
Continue reading →

As of EOS-4.15.2F, the support for the tuning of tunable DWDM 10G SFP+ transceivers (10GBASE-DWDM) is added. The following features are supported: Tune the transceiver wavelength/frequency by channel number Show the wavelengths/frequencies supported by the transceiver Show the current wavelength/frequency settings of the transceiver Configuration To tune the transceiver wavelength/frequency by channel number: Arista (config-if) # [ no | default ] transceiver channel <channel_number> [ grid-spacing <spacing> ] Syntax Descripiton: channel channel number. The default channel is 39 (50GHz-spacing grid) which corresponds to a frequency of 193,100 GHz and a wavelength of 1552.52 nm. grid-spacing (Optional) grid-spacing mode. The channel numbering...
Continue reading →

This feature optimizes the utilization of hardware resources by sharing tcam entries for a group of SVIs on which an Ipv4 Egress Router ACL is applied. The entries will be shared for all SVIs per chip. This can save a lot of hardware resources and enables RACLs to scale to larger configurations. Deployments where Ipv4 egress RACLs are applied on multiple SVIs with member interfaces on same forwarding ASIC, will benefit from this feature. For example, a trunk port carrying multiple vlans and and an egress RACL applied on all vlans will occupy lesser tcam space irrespective of number of vlans. Platform...
Continue reading →

The nexthop group feature allow users to manually configure a set of tunnels. Nexthop group counters provide the ability to count packets and bytes associated with each tunnel nexthop, irrespective of the number of times it appears in one or more nexthop groups. In other words, if a nexthop group entry shares a tunnel resource with another entry, they will also share the same counter. In 4.20 and later, if sharing counters is not desired, per-entry nexthop group counters can be configured within each nexthop group at the cost of additional tunnel resources. Supported platforms DCS-7500 DCS-7280 Configuration Configure the counter feature to...
Continue reading →

Nexthop groups in EOS currently only support IPv4 entries and only IPv4 routes can point to nexthop groups. This feature relaxes both these constraints wherein we can have IPv6 entries in the nexthop group and have IPv6 routes pointing to nexthop groups. This constraint is only removed for MPLS nexthop groups on the 7500E and 7280 series. For a given nexthop group, the address family for the entries within it cannot be mixed, i.e. all entries are either of IPv4 address family or of IPv6 address family. Similar to IPv4 entries, the IPv6 entries will get recursively resolved to an immediate...
Continue reading →

Secondary private VLAN trunk ports are introduced in the EOS-4.15.2F release. This feature can be enabled via a new command under interface configuration mode (for details please refer to section “Configuration command” below). Please note that this command is only applicable to trunk ports. When configured, this feature allows the extension of a secondary VLAN (both isolated and community) through a non-private VLAN aware switch. When private VLAN mapping is configured on a trunk port, egress mappings are added on the trunk port for all (primary VLAN id, secondary VLAN id) pairs. Since we can only allow for one such mapping for a given primary VLAN id, if there are multiple secondary VLANs configured...
Continue reading →

MLAG currently checks for basic MLAG configuration to be consistent (e.g. domain-id) before formation with the peer. However, there are many other configuration parameters that need to be consistent on both peers for proper behavior and these parameters are not checked in an automatic fashion. This feature detects configuration inconsistencies on an active MLAG pair to make the MLAG configuration process easier and more user friendly. The MLAG agent currently mounts the peer state in order to synchronize operation between the 2 switches that act as the MLAG pair. A new mount point is added to share configuration entitites for...
Continue reading →

Forward Error Correction (FEC) is required with some QSFP100 media to achieve error free operation of the link when running at 100Gbps. This is accomplished by encoding additional parity check bits into the transmitted data at the PHY PCS level. On reception parity is checked and used to correct errors in the received data, if possible, or mark errors which are not correctable.  The process is defined in IEEE 802.3by Clause 91 Reed-Solomon FEC (RS-FEC). Per IEEE802.3 the following media specify the use RS-FEC. 100GBASE-CR4 100GBASE-SR4 100GBASE-AR4 The default behavior of EOS is to enable FEC on media for which the...
Continue reading →

Introduction This article describes changes to the platform command ‘show platform fm6000 agileports’. Earlier this command was ‘show platform fm6000 agileport map’ which displayed only the mapping between the agile port and the subsumed interfaces. The command did not list information about the agile port configuration or interface status. This information is now available in the output of the ‘show platform fm6000 agileports’ command. eAPI support for this command is available. Platform compatibility DCS-7150S Configuration In order to view the updated output of the platform command, consider the following configuration where Ethernet1 is configured as an Agile port using the interface command...
Continue reading →

Introduction This article describes the addition of a show command to display the mapping between tap and tool ports on a per tap/tool port basis. The command displays the active tap/tool ports by default but offers a ‘configured’ keyword option to view configured tap/tool ports. The output lists the tap agg policy map or class map that is used to map a tap port to a tool port. The output list is sorted first on the tap port, then on the policy/class name, then the group name and lastly on the tool port name. Platform compatibility DCS-7150S DCS-7280SE DCS-7500E Show...
Continue reading →

Hardware Table Capacity Monitoring is a new 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. Users can keep track of the current usage statistics using a single show command, and also configure thresholds on a per-resource basis, to be notified about any high-utilization upfront, before reaching any resource limits. 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-7160-32CQ DCS-7160-48YC6 DCS-7160-48TC6 Configuration The concept of threshold is used...
Continue reading →