Tag : EOS-4.15.2F

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 →