• Tag : 4.17.0F

 
 

RFC 3107 – BGP Labeled Unicast and Recursive route resolution of IPV4 BGP Routes using tunnels

The BGP labeled-unicast (LU) RFC is used to advertise BGP routes with a stack of MPLS labels, thereby allowing distribution of MPLS tunnel paths through BGP.  The BGP peers that have negotiated labeled unicast capability can carry one or more labels as part of the network layer reachability information (NLRI) in the route advertisement. Recursive route resolution of IPv4 BGP routes using tunnels allows for BGP route nexthops to be resolved through tunnel paths received from BGP or other protocols. Platform Compatibility DCS-7500R series DCS-7500E series Configuration The following configuration commands have been added to supported this functionality. Configuration for labeled-unicast capability The following command submode...
Continue reading →

Shared ACL based QoS on SVIs

ACL based QoS programmed on SVIs can share hardware resources starting from EOS-4.17.0F. This results in a more efficient utilization of the system resources and is particularly useful for environments with a few, potentially large, QoS policy-maps applied to multiple SVIs. For more information on ACL based QoS support on SVIs, refer to ACL based Qos on SVIs. Platform compatibility DCS-7010 DCS-7050X DCS-7250X DCS-7300X Configuration By default, the sharing of ACLs is disabled. The CLI command used to enable it is: 7050(config)#hardware access-list qos resource sharing vlan in The CLI command to disable it is: 7050(config)#no hardware access-list qos resource sharing vlan in Status Show Commands...
Continue reading →

NAT Peer State Synchronization

Introduction NAT Peer State Synchronization feature provides redundancy and resiliency for Dynamic NAT across pair of devices in attempt to mitigate the risk of single NAT device failure. Both devices in redundant pair are active. Both of them track new sessions and create or delete NAT entries dynamically. Essentially, an active NAT entry is maintained on both devices irrespective of who created it. Platform compatibility NAT Peer State Synchronization is supported on the following platforms: DCS-7150 Configuration The following requirements must be ensured before enabling NAT Peer State Synchronization on devices in redundant pair Both devices in redundant pair must...
Continue reading →

Support for bandwidth percentage

The guaranteed bandwidth feature ensures minimum bandwidth for outgoing lower priority traffic from a specific queue of an egress interface to prevent starvation from high-priority traffic. The guaranteed bandwidth percentage is an extension to this existing feature wherein guaranteed bandwidth can now be configured in percentage in addition to the absolute value in kbps or pps. This percentage is applied to the port speed of the egress interface. Operators may now have the flexibility to express bandwidth in percent rather than in explicit digits, which automatically adjusts based on the configured speed of the interface. As an example, if the required guaranteed bandwidth on a 40G...
Continue reading →

Bug Alerts

Bug-Alerts is a service that runs on Arista CloudVisionTM eXchange (CVX) that provides customers with information on known, resolved bugs that are impacting Arista switches. The feature collects switch properties such as EOS version, hardware platform, configuration and operating conditions of all connected switches. It uses these switch properties and a local database of known bugs to determine the list of impacting bugs for each switch. This information is then displayed via show commands on CVX. The complete Bug-Alerts feature consists of the following components: CVX components AlertBase – This is the database of known and resolved bugs in Arista...
Continue reading →

Show command for fabric interfaces

The show command ‘show qos interface fabric’ was introduced for DCS-7250QX and DCS-7300X series starting EOS-4.15.2F release, which just displayed the Qos profile applied on the fabric interface. This command has now been modified to display detailed information about configured/operational values of interface Qos configurations, as is shown by the command – ‘show qos interfaces <intfName>’ for front panel ports. Variants of the command have also been added to display information of fabric ports across all chips and to display ECN thresholds for ECN configuration on the ports. Platform compatibility DCS-7250X DCS-7300X Configuration All configurations on the fabric port is through...
Continue reading →

MLAG heartbeat timeout enhancement

In an MLAG setup, periodic TCP/UDP heartbeats are sent over peer-link to ensure IP connectivity between peers. Prior to EOS-4.17.0F release, a heartbeat timeout on MLAG primary/secondary causes MLAG state to become inactive and leads to spanning-tree topology changes, LACP port-channel link-flaps etc. From EOS-4.17.0F onwards, a heartbeat timeout on MLAG primary/secondary doesn’t cause MLAG state change, instead MLAG will remain in same state and also remain active. Status CLI command “show mlag detail” captures statistics related to heartbeat timeout events. Configured heartbeat interval : 4000 ms Effective heartbeat interval : 4000 ms Heartbeat timeout : 60000 ms Last heartbeat...
Continue reading →

BFD Enhancements

As of EOS-4.17.0F, BFD support has been enhanced with support for configuring BFD within VRFs, improved scalability and cleanly disabling BFD sessions. This latter enhancement, referred to as AdminDown support, makes it possible to disable BFD configurations without the remote peer interpreting the BFD state change as a session failure. In most instances this non-disruptive BFD disablement is performed automatically upon changing the BFD configuration. Situations which would still be disruptive are cases where the interface which the BFD session is operating over is disabled or reconfigured to be incompatible with BFD. Examples include, the switchport or no vlan 1234...
Continue reading →

VxLAN VTEP counters

The VxLAN VTEP counters feature allows the device to count VxLAN packets received and sent by the device on a per VTEP basis. Specifically, it enables the device to count bytes and packets  that are getting encapsulated and decapsulated as they are passing through. The counters are logically split up in the two VxLAN directions:  “encap” counters count packets coming from the edge, encapsulated on the device and directed to the core, while “decap” counters count packets coming from the core, decapsulated on the device and heading towards the edge. To be able to count VxLAN packets the device has to support VxLAN and have a VxLAN interface...
Continue reading →

MapReduce Tracer support for MR2

MapReduce Tracer is an existing feature that monitors MapReduce nodes that are directly connected to Arista switches. In 4.17.0F release, support has been added to monitor nodes running YARN version (MapReduce version 2) of Hadoop. The following versions of Hadoop distributions have been tested: Apache 2.6.0 Cloudera CDH 5.4.0 HortonWorks HDP 2.2.4.2 Configuration When the cluster is running YARN version of Hadoop, the following cluster information needs to be configured in MapReduce Tracer feature configuration mode. Arista(config)#monitor hadoop Arista(config-monitor-hadoop)#cluster CL1 Arista(config-monitor-hadoop-CL1)#resource-manager 1.1.1.1 port 8088 This configures 1.1.1.1 and 8088 as the IP address and port of the server where YARN...
Continue reading →

QoS Profiles

QoS profiles are a collection of interface level QoS configuration commands, that are used as an alternate means of input to the traditional CLI. They help in reducing clutter in the running configuration. A possible use-case would be when there are common QoS configuration statements that need to be applied or modified on multiple interfaces. Introduced first for the DCS-7250QX and DCS-7300X series with the EOS-4.15.2F release, they have been improved upon in this release. Previously, they were applicable only on the fabric interface and supported priority flow control, tx-queue ECN, WRED and guaranteedBandwidth configurations. Now they are also applicable...
Continue reading →

L3 Interface Ingress Counters

L3 interface ingress counters can be used to count routable traffic coming into the box on sub-interfaces and vlan interfaces with L3 address (IPv4 and/or IPv6 address) configured. Such traffic will get accounted irrespective of routing decision. L3 interface counters are not supported on routed ports. Platform compatibility DCS-7050X DCS-7250X DCS-7300X series Configuration L3 interface ingress counters for subinterfaces can be enabled using the following configuration: 7050(config)#[no] hardware counter feature subinterface in L3 interface ingress counters for vlan-interfaces can be enabled using the following configuration: 7050(config)#[no] hardware counter feature vlan-interface in Note that L3 interface ingress counters are not enabled...
Continue reading →

IS-IS Segment Routing

Description Segment Routing Segment Routing provides mechanism to define end-to-end paths within a topology by encoding paths as sequences of sub-paths or instructions. These sub-paths or instructions are referred to as “segments”. IS-IS Segment Routing (henceforth referred to as IS-IS SR) provides means to advertise such segments through IS-IS protocol as per the guidelines in IETF draft : draft-previdi-isis-segment-routing-extensions. IS-IS SR feature provides knobs to configure various types of segments which are distributed as part of IS-IS LSPs (Link State PDUs) and may get instantiated as LFIB (Label Forwarding Information Base) entries in the MPLS data-plane of IS-IS SR supporting...
Continue reading →

LDP

The Label Distribution Protocol (LDP) is a protocol in the Multiprotocol Label Switching (MPLS) context that allows label switch routers (LSRs) to exchange label mapping information. It is a distributed protocol without a central controller. Instead, each LSR generates local label mappings for Forward Equivalence Classes (FECs) and propagates this information to adjacent LSRs which it maintains LDP sessions with. LDP is supported starting from EOS 4.17.0F on the 7500E and 7280E series. Configuration For CLI configuration details, please refer to EOS Config Guide. The LDP protocol is enabled in the mpls ldp configuration section. Arista(config)#mpls ldp Arista(config-mpls-ldp)#no shutdown By...
Continue reading →

RFC 5838 support for OSPFv3

EOS-4.17.0F adds support for IPv4 address family in OSPFv3 (multiple address family support) based on RFC5838. OSPFv3 instances are now associated with either IPv4 or IPv6 address family and the respective routes are advertised. This feature enables configuring and managing networks using the same IGP for both IPv4 and IPv6 routing. A single OSPFv3 instance is supported per address family per VRF. This implies that address family and VRF can uniquely identify an OSPFv3 instance. OSPFv3 IPv4 packets use IPv6 as the underlying transport, hence IPv6 needs to be enabled both in the VRF as well as on the interface, even if only IPv4 routing...
Continue reading →

OSPFv3 BFD

EOS-4.17.0F adds support for BFD in OSPFv3. BFD provides a faster convergence in scaled deployments where using aggressive times may cause scalability issues. This also addresses scenarios which need sub-second hello timers , which is not supported in EOS. Platform compatibility OSPFv3 BFD feature is supported on all platforms. Configuration This feature can be configured in two ways. The following command is available under the config-router-ospf3 mode. Arista(config)#ipv6 router ospf <Ospf Process ID> Arista(config-router-ospf3)#[ no | default ] bfd all-interfaces This enables or disables BFD for all OSPFv3 interfaces. It is disabled by default. The following command is available under...
Continue reading →

RFC 5549: IPv4 unicast NLRI with IPv6 next-hop support

Extended Next Hop Encoding Capability This feature provides support for advertising IPv4 unicast Network Layer Reachability Information (NLRI) with IPv6 next-hops over IPv6 peering sessions described as the Extended Next Hop Encoding capability in RFC5549. Extended Next Hop Encoding capability can be supported for IPv4 unicast, IPv4 Labeled Unicast, and IPv4 VPN address and sub-address families (1/1, 1/4, 1/128 respectively). The feature enables: negotiating Extended Next Hop Encoding capability for IPv4 unicast NLRI advertisements over IPv6 BGP sessions, and encoding of the next-hop in the UPDATE message that allows determination of the next-hop’s address family. This feature is available with...
Continue reading →

IPv4 Addressless Forwarding on IPv6 addressed Interfaces for BGP RFC5549 support

This feature enables dataplane forwarding of IPv4 traffic on interfaces that are not IPv4 address enabled, but only configured with an IPv6 address. This capability is required to forward IPv4 unicast traffic based on IPv4 NLRI (routes) learnt from BGP peers where the NLRI information is received with IPv6 Next-hops (RFC 5549 – extended next-hop encoding). IPv4 Addresses are typically not configured on peering interfaces that exchange such routes. Unless this feature is enabled, IPv4 packets received on interfaces without IPv4 addressing will be dropped. Platform compatibility This feature is provided on all platforms. But the feature does not need...
Continue reading →

Maximum number of accepted-routes in BGP

Currently, the ‘maximum-routes’ knob allows one to set an upper bound on the number of routes that can be received from a neighbor. The ‘maximum-accepted-routes’ feature provides the ability to set an upper bound on the number of routes that can be accepted from a neighbor after filtering. When the limitation is exceeded, the peer session will be put into Idle state indefinitely. The session can be reactivated by issuing one of the ‘clear ip bgp neighbor’ commands or by configuring the bgp idle restart interval (see Reference section below). Platform compatibility This feature is provided on all platforms. Configuration...
Continue reading →

eBGP IP next-hop unchanged

The eBgp “ip next-hop unchanged” feature allows a router to send routes to its eBgp peers without changing their next-hops to its own peering address. By default a Bgp router, as defined in RFC 4271, changes the next-hop attribute of a route to its own address before sending it out to its eBgp peer. The router uses third party address as next-hop when the eBgp peers are within the same subnet as the source of the prefixes. Users may need further flexibility for multihop eBgp peer other than the above cases. If the command proposed by this feature is configured,...
Continue reading →

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: