• Tag : 4.24.2F

 
 

VxLAN VTEP counters on 7020R, 7280R, 7280R2, 7500R, and 7500R2 series

Description 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 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 “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...
Continue reading →

Health monitoring of free buffer counts

Description In rare circumstances, a Single Event Upset may cause an underflow in the free list of buffers of a switch chip. This can cause the chip to stop forwarding packets. Recovery from this state typically requires the affected chip to be reset. This new feature allows customers to take user-defined actions when the count of buffers in use exceeds the buffers configured in the system, with a default being to log to /var/log/messages. Platform compatibility DCS-7020R DCS-7280R DCS-7280R2 DCS-7280R3 DCS-7500R DCS-7500R2 DCS-7500R3 Configuration The HealthMonitorBuffersHandler has been added as a built-in event-handler. No configuration is required to set it...
Continue reading →

Discard unimportable VPN paths

Description In a Service Provider network, a Provider Edge (PE) device learns VPN paths from remote PEs and uses the Route Target extended communities carried by those paths to determine which customer VRF(s) the paths should be imported into (from where they can be subsequently advertised to Customer Edge (CE) devices). In large Service Provider networks, each PE device may learn a significant number of VPN paths even though it might only handle a relatively small number of customer VRFs. As a result, such PE devices are really only interested in a subset of the VPN paths that they receive...
Continue reading →

Route Map – Match Resolved Nexthop Support in Multi-Agent

Description This feature adds support for ‘match ip(v6) resolved-next-hop’ clause under route-map config for BGP policy application in multi-agent model. This feature may be used when a policy to filter routes on the basis of the resolved nexthop of a route is desired. A route map can be used at various application points to filter routes based on the policy but ‘match ip(v6) resolved-next-hop’ is supported only for specific application points. For such applications when a route map with ‘match ip(v6) resolved-next-hop’ clause is applied, the ip address of the resolved nexthop of each route is matched against the ip-prefixes...
Continue reading →

Connected routes for VARP subnets

Description Virtual-ARP (VARP) allows multiple switches to simultaneously route packets from a common IP address in an active-active router configuration by configuring a virtual IP on an interface.  Source ARP with a virtual IP  is an existing feature where a virtual IP address may optionally be configured with a subnet.  When configured, all ARP request packets will use the virtual IP and MAC address in the ARP header for addresses that match a configured virtual subnet.  Prior to this feature, static routes needed to be configured to associate the virtual subnets with the local interfaces on which the virtual IP...
Continue reading →

LDP End-of-LIB

Description LDP End-of-LIB is a signaling enhancement defined in RFC 5919 to allow an LDP speaker to notify a neighbor when it has completed advertising all labels from its Label Information Base (LIB). Although End-of-LIB is a standalone feature, it is useful primarily as an enhancement to other features. In the absence of End-of-LIB some LDP procedures use timer expiration as a heuristic to determine when all of a neighbor’s label bindings have been received. Use of a timer for this purpose is wasteful and potentially error-prone since the timer must be sufficiently large to accommodate known worst case scenarios....
Continue reading →

Flexible Interface Encapsulation (FlexEncap)

Description EOS currently supports the ability to match on a single VLAN tag  (encapsulation dot1q vlan 10)  or a VLAN tag pair (encapsulation dot1q vlan 10 inner 20) to map a packet to an interface. In this case, the encapsulation string is considered consumed by the mapped interface before forwarding, which means that the tags are effectively removed from the incoming packet for the purposes of any downstream forwarding. With the introduction of the FlexEncap feature, more flexibility and use cases are possible within the encapsulation tag string match process while also maintaining the above described encapsulation string match/consume process....
Continue reading →

Support for Traffic Policy on interfaces

Description Access Control Lists (ACL) use packet classification to mark certain packets going through the packet processor pipeline and then take configured action against them. Rules are defined based on various fields of packets and usually TCAM is used to match packets to rules. For example, there can be a rule to match the packet source IP address against a list of IP addresses, and drop the packet if there is a match. This will be expressed in TCAM with multiple entries matching the list of IP addresses. Number of entries are reduced by masking off bits, if possible. TCAM...
Continue reading →

Route-Map As-Path “repeat” option

Description The “set as-path prepend” and “set as-path match all replacement” route-map configuration clauses now have a “repeat” option that allows the entered as-path to be prepended/replaced multiple times. Configuration The new repeat option is a “repeat” keyword after the entered as-path followed by a number between 2 and 64 Examples: set statement: set as-path prepend 10 repeat 2 prepended as-path: 10 10 set statement: set as-path prepend 1 2 3 repeat 4 prepended as-path: 1 2 3 1 2 3 1 2 3 1 2 3 (in this example, auto represents AS 100) set statement: set as-path match all...
Continue reading →

OSPF conditional default-originate

An OSPF router can attract all traffic towards itself from within the OSPF network, by advertising a default route. Often it is desirable to advertise this default route conditionally, for instance, only when there is a connection to an upstream router or when a default route is learnt through other protocols like BGP. OSPF conditional default-originate provides the above functionality. Configuration The below commands are now supported under “router ospf” mode in multi-agent protocol model: Arista(config-router-ospf)#default-information originate [ metric <metric-value> ] [ metric-type <metric-type-1-or-2> ] Arista(config-router-ospf)#default-information originate route-map <route-map-name> [ metric <metric-value> ] [ metric-type <metric-type-1-or-2> ] Arista(config-router-ospf)#area 0 nssa...
Continue reading →

Disable ENTITY-STATE traps for link up/down

Description This feature adds a CLI knob to allow disabling the ENTITY-STATE traps entStateOperEnabled & entStateOperDisabled that are triggered by link up/down events; entStateOperEnabled & entStateOperDisabled traps will still be generated as usual for entities that are not interfaces. Platform compatibility This feature is supported on all platforms. Configuration The entStateOperEnabled & entStateOperDisabled traps from the ENTITY-STATE-MIB are enabled by default. They are grouped under the “entity” category, and may be enabled/disabled like all other traps with the  “[no] snmp-server enable traps” command. To specifically target those entStateOperEnabled & entStateOperDisabled traps that are generated due to interfaces going up or...
Continue reading →

EOS-4.24.2F TOI Index Page

Disable ENTITY-STATE traps for link up/down IS-IS set-attached-bit OSPF conditional default-originate Route-Map As-Path “repeat” option RSVP-TE LSR Advanced Mirroring Features Support for Traffic Policy on interfaces DHCP Server on EOS Flexible Interface Encapsulation (FlexEncap) LDP End-of-LIB BGP Enhanced Route Refresh Connected routes for VARP subnets Support for Non XPN Cipher Suites in MACsec Route Map – Match Resolved Nexthop Support in Multi-Agent Discard unimportable VPN paths Health monitoring of free buffer counts Support for ECMP routes in RIP VxLAN VTEP counters on 7020R, 7280R, 7280R2, 7500R, and 7500R2 series RFC 4364 BGP/MPLS L3 VPN Dynamic CLI Access VLAN Support for...
Continue reading →

Security ACL Filtered Mirroring

Description This article describes the support for Filtered Mirroring using security ACL. The user can selectively mirror packets based on the statement in the configured IPv4, IPv6 or MAC ACL. Platform compatibility DCS-7020 DCS-7280SE DCS-7500E DCS-7280R DCS-7280R2 DCS-7280R3 DCS-7280SR3 DCS-7500R DCS-7500R2 DCS-7500R3 DCS-7800R3 Change Log 4.23.0F – initial release Support for egress IPv4 ACL 4.24.1F Support for egress MAC ACL 4.24.2F Support for ingress IPv4, IPv6 and MAC ACLs 4.26.0F Support for egress IPv6 ACL on R3 Series Configuration Unlike Ingress Filtered Mirroring, where the ACL is attached to a mirror session, Security ACL Filtered Mirroring is configured using port...
Continue reading →

Unidirectional links

Unidirectional links is a feature that configures an Ethernet interface transmit and receive paths to be independent. Specifically, the transmit path can be up or down independent of the receive path being up or down. Feature History Release Update 4.15.2F Initial introduction of unidirectional link support on 100G links on DCS-7280E and DCS-7500E Series 4.24.2F Support of DCS-7280R3, DCS-7500R3 and DCS-7800R3 Series 4.26.2F Support of DCS-7170 Overview 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...
Continue reading →

Follow

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

Join other followers: