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 that selectively cause packets to take paths different from the paths decided by routing protocols. Platform compatibility DCS-7050X DCS-7300X DCS-7250X 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 of a PBR policy sets a nexthop for...
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. Platform compatibility DCS-7500E DCS-7280 Configuration Configure the counter feature to enable nexthop counters Arista(config)#hardware counter feature nexthop   Status Show Commands Display the status of nexthop group counters in the system Arista#show hardware counter feature Feature Direction Counter Resource acl in 2 nexthop n/a 3 Arista# Display nexthop group counters Arista#show nexthop-group nhg1 Id 5 Type mpls Size...
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 Supported on the following platforms starting 4.15.2F DCS-7280E series DCS-7500E series Supported on the...
Continue reading →

Switches within the Arista 7050X Series utilize a forwarding chip that goes under the name Trident2. Trident2 is a Switch-on-Chip (SoC) single-chip with support for up to 1280Gbps of forwarding capacity (oversubscribed mode) that is provided by either 32x40G or up to 96x10G+8x40G, or up to 960Gbps (linerate mode). Since some Arista 7050X Series switches provide front-panel ports that use a subset of the capacity available on the SoC, the remaining capacity of the SoC is exposed as “UnconnectedEthernet (Ue)” interfaces to rest of the system. The purpose of exposing these internal ports in this manner is to make them available for...
Continue reading →

Some data-plane features on some switch platforms may require packets to be recirculated through the switch chip in order to implement configured features and functionality. VXLAN Routing on Arista 7050X Series (single-chip T2) is one such feature. Recirc-Channel interfaces are a logical grouping of Ethernet and UnconnectedEthernet interfaces for use in recirculating the packet to provide features that require recirculation.  Each Recirc-Channel is tied to one specific feature. In this release, the only feature to be used in conjunction with Recirc-Channel interfaces is VXLAN Routing on Arista 7050X series devices. Platform compatibility DCS-7050X series Configuration The configuration for Recirc-Channel interfaces...
Continue reading →

This feature enables detection of egress queues that are unable to transmit packets for prolonged periods of time due to receiving continuous PFC pause frames. On detection of such a stuck tx-queue this feature will error-disable the respective port with a err-disable reason of “stuck-queue”. Error-disabling a port in such a case may re-route the traffic via different port to the destination if possible. Platform compatibility DCS-7050x Series Configuration This feature can be enabled by the following command Arista(config)# priority-flow-control pause watchdog default timeout < 3-60 seconds >  This will start monitoring all the egress queues which have guaranteed bandwidth enabled and for the priorities...
Continue reading →

OpenStack has a concept of shared tenant networks which let the admin can create a network which can be shared by all the tenants managed by the admin. A shared network is created as a regular tenant network which means that a segment id is associated with it. Whenever any tenant attaches a VM to this shared network, the VLAN required for that shared network is provisioned on the switch interface connected to the compute node hosting the tenant VM. In order to support the shared tenant networks, new internal CLI commands were added so that the ML2 driver can...
Continue reading →

The active-active neutron controller support in CVX enables the deployment of highly available neutron service with multiple active neutron controllers. For the neutron service to be highly available multiple active instances of the server are deployed so that if any instance fails, the work load is distributed among the remaining instances without any downtime. The details on configuring the HA support in neutron can be found in the OpenStack documentation. The Arista ML2 driver interfaces with CVX and sends the virtual network information to it. CVX looks at this virtual network information and the topology to configure the required VLAN...
Continue reading →

The following are new enhancements in DirectFlow and/or OpenFlow that have been added in EOS-4.15.1F Action TTL decrement in an OpenFlow flow OpenFlow 1.3 Group support on DCS-7010 series Clearing flow counters  Action output next hop for DirectFlow Action TTL Decrement in an OpenFlow flow Support for OFPAT_DEC_NW_TTL has been added for flows. This action is supported on DCS-7050, DCS-7050X and DCS-7010 series of switches. This action can be used in conjunction with OFPAT_OUTPUT, OFPAT_POP_VLAN and OFPAT_SET_FIELD actions. a7050(config)#show openflow flows Flow flow00000000000000000001: priority: 100 cookie: 0 (0x0) match: destination Ethernet address: 00:cc:cc:cc:cc:cc/ff:ff:ff:ff:ff:ff Ethernet type: IPv4 actions: decrement TTL output interfaces:...
Continue reading →

Arista switches provide several mirroring features. Filtered mirroring to CPU adds a special destination to the mirroring features that allows the mirrored traffic to be sent to the switch supervisor. The traffic can then be monitored and analyzed locally without the need of a remote port analyzer. One use case of this feature is for debugging and troubleshooting purpose. As for other mirroring features: it can be configured to mirror RX traffic, TX traffic or both up to 14 mirroring profiles can be used simultaneously In addition mirroring to CPU uses the control plane protection to limit the rate of...
Continue reading →

Fallback PBR policy enables an alternate policy to be active when PBR policy attached to an interface is being modified. Configuring Fallback PBR policy is similar to configuring normal PBR policy except that the keyword fallback is specified when the fallback policy is attached to an interface. An interface can have one fallback PBR policy in addition to the PBR policy attached. If a fallback policy is attached to an interface that has no other PBR policy attached the fallback policy will be active. Platform compatibility DCS-7500E DCS-7280 Configuration To configure fallback PBR policy on an interface create policy of type pbr using...
Continue reading →

Introduction LANZ on DCS-7280SE and DCS-7500E adds support for monitoring congestion on front panel ports at a more granular level with Start, Update, and Stop congestion events. These events are available while using Notifying mode. The previous behavior of polling the most congested queue per ASIC is still available in the default Polling mode. LANZ Streaming is now available on DCS-7280SE and DCS-7500E. Platform compatibility DCS-7280SE DCS-7500E Configuration Enabling Notifying mode Arista(config)# queue-monitor length notifying This enables Notifying mode. The default is Polling mode. In a mixed system with both DCS-7500 and DCS-7500E linecards configuring Notifying mode results in Notifying mode on DCS-7500E cards...
Continue reading →

Arista switches enable high precision time distribution directly in the data path using IEEE1588 Precision Time Protocol (PTP). This document provides information about new platforms those now support PTP. Platform compatibility The following platforms now support IEEE1588 Boundary and Transparent clock mode of operation. DCS-7050QX-32S DCS-7050SX-128 DCS-7050TX-64 DCS-7050TX-128 DCS-7250QX-64 Please visit EOS Feature Support page for list of platforms those already support PTP. Configuration EOS System Configuration Guide Precision Time Protocol (PTP) section provides necessary configuration details. Status EOS System Configuration Guide Precision Time Protocol (PTP) section provides various show commands useful for verifying the current operational state of PTP....
Continue reading →

EOS supports different scheduling policies which dictate the way packets at different transmit queues leave the egress port. Currently EOS supports Strict Priority (SP) and Weighted Round Robin(WRR). Default scheduling policy is Strict Priority. Weighted Round Robin scheduling allows packets at different transmit queues to be serviced in round-robin manner in accordance to the weights assigned to those transmit queues. Users will be able to configure the set of queues to participate in WRR scheduling and will also be able configure the weights for those queues. At any given point, EOS allows some transmit queues to participate in SP and some to participate in WRR, the condition being the scheduling policy has...
Continue reading →

The 7250X and 7300 series use an optimized internal CLOS design with multiple port ASICs interconnected via Fabric ASICs in an efficient non-blocking two-tier design. Starting EOS 4.15.2F, EOS allows configuring QoS on fabric ASICs on these platforms. Configuring QoS on the fabric ASICs in addition to front panel ports empowers users to have end-to-end control on these platforms. By default, queues are configured as strict priority on 7250X and 7300X series. The following configuration options are now supported on fabric interfaces: Guaranteed Bandwidth: In order to prevent queue starvation on fabric ports EOS supports minimum bandwidth configuration on per queue basis across all fabric...
Continue reading →

IP Source Guard (IPSG) is a security feature that can help prevent IP spoofing attacks. It filters inbound IP packets based on their source MAC and IP addresses. IPSG is supported in hardware. When IPSG is enabled on a Layer 2 port, every IP packet received on this port is verified. The packet is permitted if its source MAC and IP addresses match any of the user-configured IP-MAC binding entries on the receiving vlan and port. The packet is dropped immediately if no match is found. Platform compatibility DCS-7010 DCS-7050 DCS-7050X DCS-7250X DCS-7300X Configuration IPSG is only applied to Layer 2 ports. To enable...
Continue reading →

By default,  inner IP header of a GRE packet is used for LAG hashing. With this feature, LAGs can hash GRE traffic across ports based on the outer IP header. Platform compatibility DCS-7050X DCS-7300X DCS-7250QX Configuration Using outer IP header of GRE packets for LAG hashing can be enabled based on different GRE tunnel types ( IPv4 over IPv4 GRE tunnel, IPv6 over IPv4 GRE tunnel, IPv4 over IPv6 GRE tunnel and IPv6 over IPv6 GRE tunnel).  To enable GRE LAG hashing based on outer IP header for one or more GRE tunnel types, use the following command in global configure mode:...
Continue reading →

Introduction When a user configures IPv6 ACLs, by default, the system automatically  includes two additional rules :- a default drop rule and a permit all ICMP  types rule. This feature provides the user ability to override the default behavior from permitting ALL IPv6 ICMP types to ONLY permitting IPv6 ICMP neighbor discovery types. Caveats The configuration ONLY applies to IPv6 ACL rules configured  after applying the command “hardware access-list ipv6 implicit-permit icmpv6 neighbor-discovery”. All IPv6 ACLs configured and programmed prior  to applying the command will remain unaffected. Platform compatibility DSC-7050S DCS-7050T DCS-7050Q DCS-7010T DCS-7304 DCS-7316 DCS-7250 Configuration The following example...
Continue reading →

With this feature, IP packets matching a static Nexthop-Group route can be encapsulated within an IP-in-IP tunnel and forwarded. Platform compatibility DCS-7050 DCS-7050X DCS-7250X DCS-7300 DCS-7010T Configuration Configure a static Nexthop-Group route and an IP-in-IP Nexthop-Group. Arista(config)#ip route 124.0.0.1/32 nexthop-group abc Arista(config)#nexthop-group abc type ip-in-ip Arista(config-nexthop-group-abc)#size <1-1024> Arista(config-nexthop-group-abc)#tunnel-source 1.1.1.1 Arista(config-nexthop-group-abc)#entry 0 tunnel-destination 1.1.1.2 Arista(config-nexthop-group-abc)#entry <0-size> tunnel-destination 10.1.1.1 Arista(config-nexthop-group-abc)#ttl <1-64> Status Show Commands show nexthop-group shows all the information about Nexthop-Groups configuration show platform trident l3 software tunnel encap shows the list of tunnels configured in the system Arista(config)#show nexthop-group abc Id          1 Type        ipInIp Size       2 Ttl        ...
Continue reading →

In an MLAG setup, routing on a switch (MLAG peer) is possible using its own bridge/system MAC, VARP MAC or VRRP MAC. When a peer receives an IP packet with destination MAC set to one of the aforementioned MACs, the packet gets routed if the hardware has enough information to route the packet. The following behavior was observed if the destination MAC is peer’s bridge MAC – the packet is L2 bridged on the peer-link and the routing takes place on the peer. This behavior to use the peer-link to bridge the L3 traffic to the peer is undesirable if heavy routable traffic...
Continue reading →

VXLAN multicast decapsulation enables VTEPs that only support HER (Head End Replication) to terminate multicast encapsulated BUM(Broadcast/Unknown/Multicast) packets from remote VTEPs that do not support HER. Platform compatibility DCS-7050X DCS-7250X DCS-7300X Configuration The feature is enabled by using the below CLI under interface Vxlan: Arista(config-if-Vx1)#vxlan multicast-group decap 230.1.1.1 The above command can take more than one multicast group. To disable the feature use the ‘no’ option under interface VXLAN and specify the groups that need to be disabled: Arista(config-if-Vx1)#no vxlan multicast-group decap 230.1.1.1 Status Use the following show command to verify that the multicast group is configured for decapsulation in...
Continue reading →

Leaf Smart System Upgrade (SSU) provides the ability to upgrade the EOS image with minimal traffic disruption. Platform compatibility DCS-7050X (excluding DCS-7050SX-72, DCS-7050SX-96, DCS-7050TX-72 and DCS-7050TX-96) Configuration BGP Graceful Restart For hitless restart of BGP and MP-BGP, BGP graceful restart must be enabled on the switch using the graceful-restart command in BGP configuration mode. The default restart time value (300 seconds) is appropriate for most configurations. Arista(config)#router bgp 64496 Arista(config-router-bgp)#graceful-restart BGP peers (receiving speakers) must support graceful restart helper. Switches running EOS 4.13.0 and greater have this mode configured by default. Prepare the switch Prior to starting a Leaf Smart System Upgrade (SSU):...
Continue reading →

This feature makes ARP and ND packets use a higher priority output queue when software forwarded on the switch. Doing so avoids possible drops in the switching hardware when competing with data plane packets during traffic congestion. Without this feature it is sometimes possible for Bgp sessions to get drops due to dropped ARP and ND packets. Platform compatibility DCS-7500E DCS-7250X DCS-7300X DCS-7010X DCS-7050X Configuration This feature is configured in by default and cannot be disabled.

This feature detects whether a given EOS image is MLAG ISSU compatible with the currently running version on a switch. If the given new image is found to be incompatible then all EOS versions which are potentially compatible to both the given EOS image and the currently running image are listed. Also this adds support to generate additional Mlag ISSU compatibility warnings while reloading the switch or  while issuing ‘show mlag issu warning’ command. All the EOS images has an Mlag ISSU Compatibility matrix published as part of the Release Notes. This matrix shows which images are compatible to a...
Continue reading →

This feature enables user to modify QoS parameters for SVI traffic (L3 VLAN) based on ACL classification. The QoS actions will be applicable only to routed traffic flowing through the members of the corresponding VLAN. This feature is only supported on ingress traffic. The user can configure the following QoS actions : Outgoing COS re-write Outgoing DSCP re-write Selection of traffic-class Policing Platform compatibility DCS-7500E DCS-7280E DCS-7010 DCS-7050 DCS-7050X DCS-7250X DCS-7300X Configuration Please refer to EOS configuration guide to configure ACL based QoS. Once the policy-map is created it can be configured on SVI as shown below, switch(config)#interface vlan 10...
Continue reading →

Maintenance mode is a framework to allow for the easy removal of elements of a switch or the entire switch from service with minimal configuration. The reasons for taking the switch out of the network could be many, including an EOS image upgrade, replacement of hardware, or recabling. The maintenance mode operation also allows the switch or switch elements to rejoin the network gracefully after all maintenance operations are performed. As this operation removes a switch or switch elements from service, the network must support the necessary network-level redundancy to either minimize or avoid loss of traffic. Maintenance mode operation Traffic flow pattern between TOR and Core...
Continue reading →

This feature allows routing traffic across two Vrf domains on the same switch using an external loopback cable connecting ports in different Vrf domains. If a packet received in Vrf1 is forwarded to the interconnect port (either by static route or by default route), the packet is received back in Vrf2 on the same switch. This packet is then forwarded using Vrf2 routing table. Platform compatibility DCS-7300X (TBD: Trident based platforms) DCS-7250X (TBD: Trident based platforms) DCS-7500E Configuration There are no new CLI for configuring or enabling this feature. Here is the example configuration for the topology shown below: An interconnect...
Continue reading →

BGP additional paths is an enhancement that allows a BGP router to advertise and receive multiple distinct paths for the same prefix over the same session. This results in increased path diversity in the network and has a number of important benefits such as fast traffic restoration and efficient link usage through multipathing. Additional paths IETF standard allows for advertisement of multiple paths without new paths implicitly replacing any previous paths. Each path is identified by path identifier in addition to the address prefix. In this release, support has been introduced to only receive additional paths. The ability to send...
Continue reading →

The BGP idle restart interval feature allows an idle BGP peer session to automatically restart after a configurable time interval. Platform compatibility This feature is supported on all platforms. Configuration The following configuration can be used under the BGP configuration mode to enable idle restart interval. [no|default] neighbor <neighbor-id> idle-restart-timer <restart-interval> restart-interval:  <60-4294967295> restart interval in seconds Example This example configures maximum-routes of neighbor 1.0.0.2 to be 5000 and restart-interval to be 100. With this configuration, a connection attempt will be made automatically 100 seconds after the neighbor 192.168.10.10 goes to Idle state due to reach 5000 maximum-routes. neighbor 1.0.0.2 idle-restart-timer...
Continue reading →

Nexthop Groups is a feature that allows users to manually configure a set of nexthops by specifying their nexthop addresses and associated encapsulation information. Each Nexthop Group is referred to by a unique name and can support a single tunnel type like GRE, MPLS, etc… Static routes that directly point to Nexthop Groups can be configured. Any traffic destined to such static routes will then be forwarded via the nexthops specified in the corresponding Nexthop Group. This feature provides ability to recursively resolve Static and BGP routes over Nexthop Groups. There is not configuration changes required as part of this...
Continue reading →

This feature enables configuring static IPv4 routes that specify the next-hop by using an IPv6 address instead of an IPv4 address. IMPORTANT:  This is not intended to be a customer-used feature in this release, but is rather the first part of a follow-on feature in a subsequent release.  As such, the feature-specific CLIs are currently hidden.  This TOI exists to document the feature “just in case”. Platform compatibility This feature is supported on all platforms. Configuration To configure the feature, simply specify an IPv6 address instead of an IPv4 address when creating a static route in configuration mode. Arista(config)#ip route 10.0.0.0/8 a::1...
Continue reading →

In the 4.15.2 release the following enhancements and changes have been made to the BGP bestpath selection configuration. Platform compatibility The changes and enhancements are applicable for all platforms. Configuration The following BGP tie-break configuration CLI commands have been replaced with new CLI commands under the bgp bestpath command hierarchy for consistency. Arista(config-router-bgp)#bgp tie-break-on-router-id has been replaced with Arista(config-router-bgp)#bgp bestpath tie-break router-id If a route is received with an originator ID attribute, the originator ID value will be used as the router ID for router ID comparison. Arista(config-router-bgp)#bgp tie-break-on-cluster-list-length has been replaced with Arista(config-router-bgp)#bgp bestpath tie-break cluster-list-length In addition, the...
Continue reading →

BGP sFlow export is to add BGP route information in sFlow sample packet is the destination IP matches a BGP route. Prior to and including EOS release 4.15.0F, if the route is an ECMP route, the actual path cannot be determined. In this case, the BGP next-hop is arbitrarily set to 0 and AS path information is exported as best effort. As of EOS-4.15.2F software release, DCS-7500E and DCS-7280E platforms are able to provide the actual real-time egress port information to the sFlow agent thus the agent is able to use it to find the actual ECMP path and provide...
Continue reading →

The BGP selective route download feature allows learning and advertising BGP prefixes without installing them in the hardware. The filtering for installation in hardware is through the route-map semantics and filtered out routes are flagged as inactive in the RIB (Routing Information Base). With the feature enabled, BGP is no longer constrained by the platform’s hardware limit and can relay much larger number of prefixes to its peers. The route-map is applied only for BGP learned paths and not on locally originating routes (e.g. BGP aggregates) or redistributed routes. BGP routes filtered out by selective route download are not used...
Continue reading →

  VxLAN bridging enables stretching Layer 2 domains across a Layer 3 cloud. VxLAN routing provides the capability to route between these Layer 2 domains. On the 7050X, 7060CX, and 7260QX series, VxLAN routing is achieved by recirculating the packet multiple times through the ASIC. The routing action (which involves a L2 header rewrite), the VxLAN tunnel decapsulation action, and the VxLAN tunnel encapsulation action each requires a pass through the ASIC. The recirculation is achieved by MAC loopback on dedicated loopback interfaces. Platform compatibility The platforms with the EOS version where the feature was introduced: DCS-7050X series EOS-4.15.2F DCS-7060CX...
Continue reading →

BGP Non Stop Forwarding ( NSF ) aims to minimize the traffic loss when the the following scenarios occur Switchover to Standby Supervisor because of maintenance or software failure viz Kernel hang. Software Upgrades. BGP NSF uses Graceful Restart procedures as defined in the RFC 4724 to support Non Stop Forwarding. It enables the node going down because of software upgrades or switchovers to recover its state with the help from its peers. BGP exchanges the support of this capability with its peers. During the graceful restart the switch forwarding state is preserved and it continues to send traffic on the...
Continue reading →

This feature enables exchanging IPv4 NLRI using MP-BGP over an IPv6 TCP connection.  Additionally, this feature adds a new configuration keyword, “auto-local-addr” which instructs the router to automatically determine what address to use as the next hop on these NLRIs, instead of requiring manual configuration. Platform compatibility The feature is supported on all platforms. Configuration All commands listed here are used in BGP configuration mode, either for the default VRF or for a non-default VRF. To enable IPv4 NLRIs over an IPv6 connection, an IPv6 neighbor must be activated in the IPv4 address family. This can be done explicitly on a...
Continue reading →

PIM VRF feature adds VRF support to these existing multicast protocols: PIM-SM, PIM-BSR, IGMP and MSDP. Interface specific commands related to these protocols (example: ‘ip pim sparse-mode’) remain the same as before. By default, all interfaces belong to default VRF till the ‘vrf forwarding <vrf name>’ command is executed. More on ‘vrf forwarding’ command application to an interface can be found elsewhere in this manual. With VRF support, there are some significant changes to the manner in which the commands related to these protocols are applied to VRF. The configuration section explains this in more detail with examples. To maintain...
Continue reading →