• Tag : 4.23.0F

 
 

DSCP support for CPU generated traffic

The differentiated services code point (DSCP) is a 6 bit field in the IP header, which can be used to mark traffic for providing quality of service (QoS). This feature can be used to set the DSCP value individually for various protocols that are used for network management. All protocol specific traffic leaving the switch will be marked with the configured DSCP value. The supported protocols are RADIUS, TACACS, SNMP, SSH and sFlow. IPv4 support for this feature is available since 4.18.1F. IPv6 support for this feature is available since 4.23.0F. Platform compatibility This feature is provided on all platforms....
Continue reading →

Support for UCMP “adjust auto” (multi-agent)

Description Unequal-cost multi-path (UCMP) for BGP is a mechanism for forwarding ECMP route traffic using weights, with which the next hops of those routes are programmed in the FIB. This is done using BGP by disseminating BGP link-bandwidth extended community attribute information with BGP routes, such that the receiver device of all routes programs the next hops in the FIB using the received link-bandwidth values. This feature appends the percentage of interface speed with a route’s received link bandwidth extended community value. The idea is to rebalance the weight ratio of the traffic sent over egress ports, such that we...
Continue reading →

BGP shutdown and reset communication (multi-agent)

Description This feature implements support for RFC8203/BIS so that users can attach the reason of BGP instance or peer session administrative shutdown or hard reset to the BGP Cease Notification sent to the peers. Platform compatibility This feature is platform independent and only available when multi-agent mode is enabled. Configuration Below is a list of all possible configurations under this feature: (config-router-bgp)# shutdown [reason REASON] (config-router-bgp)# neighbor ( addr | peer-group) shutdown [reason REASON] (config-router-bgp)# clear [ip | ipv6] bgp [(neighbor (addr | peer-group)) | * ] [vrf (all | default | VRFNAME)] [reason REASON] Note that attaching ‘reason REASON’...
Continue reading →

Hardware Flow Tracking with IPFIX export

Description Campus hardware flow-tracking allows for extensive and fine grained hardware based flow tracking and management features. It provides the capability of collecting data from packets as per user defined flow profile (defined as match criteria and set of data to be collected from the packet) and shipping it to an external observation node called Collector, using IPFIX flow export protocol. The diagram below shows how switches enabled with hardware flow-tracking can be used to perform flow tracking and flow export in a Campus network. The flow tracking engine as per user defined tracking parameters, track flows traversing through the...
Continue reading →

Ingress/Egress per-port IPv4, IPv6 counters

This feature provides support for per-interface ingress/egress packet/byte counters for both IPv4 and IPv6. Platform compatibility DCS-7280SR DCS-7280CR DCS-7500-R DCS-7300X DCS-7250X DCS-7050X DCS-7060X Please note feature is platform specific, packet versus bytes distinction, and the ability to count routed packets only (as opposed to counting all IPv4/v6 traffic: routed or bridged). Please consult your systems engineer to check if a particular combination is supported. Configuration IPv4, IPv6 ingress counters (counts bridged and routed traffic, supported only on front-panel ports) can be enabled/disabled using the following command: Arista#[ no ] hardware counter feature ip in For IPv4, IPv6 ingress/egress counters that...
Continue reading →

IP Locking + Release Updates

Description IP Locking is an EOS feature configured on an Ethernet Layer 2 port.  When enabled, it ensures that a port will only permit IP and ARP packets with IP source addresses that have been authorized. IP Locking prevents another host on a different interface from claiming ownership of an IP address through ARP spoofing. On an IP Locked Port, ARP probes with 0.0.0.0 as Sender Protocol Address (SPA) will be allowed for duplicate address detection (DAD). Incoming DHCP server response packets are dropped to avoid rogue device(s) acting as DHCP server(s). Incoming DHCP client request packets are allowed for...
Continue reading →

Errdisable Detect Cause for ACL

Description Allows user to use the CLI to configure whether or not ACL failures cause a port to become errdisabled. The default behavior for ACL is to errdisable a port upon ACL failure. Platform compatibility All 7500, 7280, 7020 Configuration The default configuration is to errdisable a port upon ACL failure. To disable errdisabling on failure, run the following command: no errdisable detect cause acl To turn errdisabling for ACLs back on, run the following command: errdisable detect cause acl Show Commands Output When Errdisabling is Enabled for ACLs (config)#show errdisable detect Errdisable Reason Detection Status ------------------------------ ---------------- acl Enabled...
Continue reading →

LSP Ping/Traceroute for MPLS Nexthop Group Tunnels

Description MPLS ping/traceroute utility is extended to support liveness checking of Nexthop Group tunnel endpoint (MPLS Nexthop Group). The feature is also supported on vEOS-lab and cEOS-lab. Platform Compatibility Platform independent. vEOS-lab/cEOS-lab. CLI Command ping mpls tunnel nexthop-group <endpoint> [entry <index>] Example output: rtrmpls1#ping mpls tunnel nexthop-group 100.0.116.1/32 LSP ping to nexthop-group tunnel 100.0.116.1/32 100.0.116.1/32: nexthop-group tunnel index 1 (nexthop-group name: nhg-100) Entry 0 Via 10.0.16.2 Reply from 10.0.108.1: seq=1, time=507.546ms Entry 1 Via 10.0.16.8 Reply from 10.0.113.1: seq=1, time=516.131ms --- nexthop-group tunnel index 1, nexthop-group nhg-100: lspping statistics --- Entry 0 Via 10.0.16.2 1 packets transmitted, 1 received, 0%...
Continue reading →

VLAN-aware bundle Addition/Removal of VLANs from VLAN set

Description In EVPN, when configuring the member VLANs for a VLAN-aware bundle, the existing configuration command only allows the specification of a VLAN range string, which replaces the previously configured VLAN range string.  This enhancement adds new syntax to add or remove additional VLANs from the currently configured VLAN-aware bundle VLAN list. Platform Compatibility Platform independent Configuration The existing configuration CLI for configuring the member VLANs in a VLAN-aware bundle is: vlan <range>   This takes a VLAN range-string and uses it to replace the currently configured VLAN range-string.  The updated CLI syntax is now: vlan [ add | remove...
Continue reading →

DirectFlow Output Nexthop Action

Description DirectFlow is a feature that allows the user to steer traffic by matching on packet headers and/or metadata using the OpenFlow semantics. This allows the user to create rules using matches and actions that are a superset of the OpenFlow 1.0 specification. Unlike OpenFlow, DirectFlow runs alongside existing layer 2/3 forwarding plane capabilities and does not require a controller or any third party integration, allowing the user to create flows from CLI.    The “output nexthop” is a routing action that allows the user to redirect packets matching a DirectFlow rule to a configured next hop. It can be...
Continue reading →

EVPN – MLAG single homed hosts

Description As described in the Multi-VTEP MLAG TOI, singly connected hosts can lead to suboptimal peer-link utilisation. By adding a local VTEP to each MLAG peer, the control plane is able to advertise singly connected hosts as being directly behind a specific local VTEP / MLAG peer. The multi-VTEP MLAG feature has been extended to add EVPN control plane support. VXLAN bridging (EVPN Type-2 and Type-3 routes) and routing (EVPN Type-5 routes and IRB) are supported by this feature. When multi-VTEP MLAG mode is enabled, outgoing EVPN route advertisements will contain a nexthop and router MAC extended community as summarized...
Continue reading →

Power management

Description Power management is a way to limit the total available power to be used for Power over Ethernet (PoE) ports. Without power management, the total amount of power that the power supply units (PSU) are able to provide is used. Power management can be used to create power redundancies. For example, if a system has 2 1050W PSUs, the feature can set the total available power to be 800W for PoE. With this configuration, 1 PSU is sufficient to power the system and the unused PSU acts as a backup source, thus giving the system a 1+1 redundancy. Platform...
Continue reading →

GRE Decapsulation

Description This is an addendum to the “IP in IP decapsulation” document https://eos.arista.com/eos-4-15-0f/ipinip-decapsulation. When GRE decapsulation is configured using decap groups, incoming packets with an outer IP header having IPProto=47(GRE) . Ip destination matching the one configured will be decapsulated, meaning that the outer IP and GRE header will be removed from the packet and all subsequent decisions will be based on the inner IP header. Platform compatibility DCS-7050X DCS-7050X2 DCS-7250X DCS-7300 DCS-7060X DCS-7060X2 DCS-7260X3 CCS-720XP (Starting in EOS 4.22.1F) DCS-7050SX3 (Starting in EOS 4.22.1F) DCS-7010T (Starting in EOS 4.23.0F) Configuration The  GRE decapsulation configuration is similar to IPInIP decapsulation,...
Continue reading →

Egress Filtered Mirroring

Description This article describes the support for Egress Filtered Mirroring. The user can selectively mirror egress packets based on the permit statements in the configured IPv4 ACL. Platform Compatibility DCS-7020 DCS-7280SE DCS-7500E DCS-7280R DCS-7280R2 DCS-7500R DCS-7500R2 Configuration Unlike Ingress Filtered Mirroring, where the ACL is attached to either the Mirroring Session or the Mirroring Source, Egress Filtered Mirroring is configured using Port Security ACLs.   For details on how to use the Mirroring Features, please refer to the following TOI: https://eos.arista.com/advanced-mirroring-features/   These commands configure Ethernet interface 8 as the destination port for the redirect_1 mirroring session, and Ethernet interface...
Continue reading →

Support for the Priority Keyword in DirectFlow

Description DirectFlow is a feature that allows the user to steer traffic by matching on packet headers and/or metadata using the OpenFlow semantics. This allows the user to create rules using matches and actions that are a superset of the OpenFlow 1.0 specification. Unlike OpenFlow, DirectFlow runs alongside existing layer 2/3 forwarding plane capabilities and does not require a controller or any third party integration, allowing the user to create flows from CLI. As of 4.23.0F, there is support for the `priority` keyword, allowing control over which Flow’s actions are applied when multiple Flows satisfy the match conditions. Platform compatibility...
Continue reading →

Sharing of FEC for imported VPN routes in Multi-Agent Mode

Description For MPLS VPN address family in BGP, when the VPN path routes are imported to multiple VRFs,  individual FEC entry in the hardware table is used for each VRF. This feature enables the sharing of the same Forwarding Equivalence Class (FEC) entry across multiple  VRF’s and achieves higher scale in VPN deployments by making optimal use of hardware resources. This feature is available with the multi-agent routing protocol model. In multi-agent mode, Bgp agents support doing in-place FEC change as opposed to updating each route. Platform compatibility This feature is supported on all platforms. Configuration The below configuration in...
Continue reading →

Supporting ‘match ip next-hop’ clause for static routes redistributed into IGPs

Description EOS 4.23.0F adds support for ‘match ip next-hop’ clause for static routes redistributed into IGPs. There was already support for this feature in single agent mode. EOS 4.23.0F adds support for multi-agent mode as well. We can apply ‘match ip next-hop’ route-map clause while redistributing static routes into IGPs to redistribute the static routes whose configured next-hops satisfies the route-map policy. Configuration To configure a static route (config)#ip route 10.20.30.0/24 1.2.3.4 To configure a prefix-list (config)#ip prefix-list prefixListName (config-ip-pfx)#permit 1.2.3.4/32 Here 1.2.3.4 is a configured next-hop for static route 10.20.30.0/24 To configure a route-map (config)#route-map routeMapName (config-route-map-routeMapName)#match ip next-hop...
Continue reading →

Show rib route summary

Description This CLI command will display a short summary of the routes present in the Routing Information Base. Show Commands “show rib route summary” will display a table containing the summary of all the routes in the Routing Information Base for the default VRF on the device. Arista#show rib route summary VRF: default Route Source Number Of Routes -------------------- ---------------- BGP 1 Connected 4 Dynamic policy 0 IS-IS 0 OSPF 0 OSPFv3 0 RIP 0 Route input 2 Static 0 VRF leak 0 There are four further keyword arguments that can be specified: brief ip ipv6 vrf “show rib route...
Continue reading →

Accelerated Software Upgrade support on some 7280R platforms

Description ASU (or Accelerated Software Upgrade) is a feature that will minimize traffic loss when upgrading from one ASU-supported EOS version to a newer ASU-supported EOS version. During the upgrade process, the ASIC is kept active and will continue to forward traffic based on the data plane state. A brief loss of traffic is expected when the configuration from the new EOS image is applied to the ASIC. Note that the first supported version for this feature refers to the first version where the command is available. ASU cannot be performed from an older version to the first supported version....
Continue reading →

MPLS Support on X Series Switches

Description Multiprotocol Label Switching (MPLS) is a networking process that replaces complete network addresses with short path labels for directing data packets to network nodes. The labels identify LSPs (label switched paths) between distant nodes rather than endpoints. MPLS is scalable and protocol-independent. Data packets are assigned labels, which are used to determine packet forwarding destinations without examining the packet. The MPLS implementation supports static MPLS tunneling that is manually configured on each switch or established over a network by an SDN controller. The configuration is specified by a set of rules that filter packets based on matching criteria. Each...
Continue reading →

Follow

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

Join other followers: