• Tag : EOS-4.20.5F

 
 

DHCP relay in VXLAN EVPN (Anycast usecase)

In VXLAN EVPN deployments, a distributed anycast address is often used as the gateway address for end devices connected to the Vxlan Tunnel End Points (VTEPs). Similarly, in MLAG configurations in a VXLAN environment, ip address virtual could be used on both MLAG peers. A DHCP Relay agent running on such switches needs to forwards DHCP requests originating from end devices to the DHCP Server. In such deployments, the DHCP Relay Agent will not be able to use the anycast address or the virtual IP address to communicate with the server. In order to enable the server to uniquely identify...
Continue reading →

Agent Snapshot Core CLI Command

EOS’s architecture is built around the notion of agents. While the CLI show commands offer great insights into the operational status of the switch, their output can become voluminous in highly scaled route environments affecting the operational stability of the switch. The agent <agent> snapshot core CLI command quickly and safely creates a core snapshot file that can be exported off the switch to provide the same operational status information without affecting switch stability. Platform compatibility This feature is platform independent. Configuration The agent CLI command has new parameter snapshot. The new snapshot parameter has a new parameter core. These...
Continue reading →

Set BGP Multi-Exit-Discriminator for IGP Routes

This feature allows for setting BGP path attribute Multi-Exit-Discriminator for IGP routes advertised by BGP. This feature supports OSPF, OSPFv3 and ISIS as IGP. By default, no MED value is set on exported routes. To set MED value, configure a route map using the command ‘set metric’ and apply it. This route map can be applied as an outbound route map or when redistributing routes from IGP into BGP. This command only sets the BGP MED on BGP routes which are redistributed from IGP and has no effect otherwise. Platform compatibility This feature is platform independent. Configuration The following example...
Continue reading →

Override IGP cost of BGP next hop

One of the steps in the BGP best path selection algorithm compares the IGP cost of the BGP next hop, preferring the path with the lower cost. This step can be skipped by setting the CLI configuration bgp bestpath skip next-hop igp-cost. However, this configuration has global scope. To enable skipping the IGP cost comparison on a per prefix basis, a new route map set statement, set next-hop igp-metric, is introduced. This new route map statement overrides the IGP cost value being used in BGP best path selection. Overriding the IGP costs of different BGP paths to the same value effectively renders...
Continue reading →

Common Encryption Key for internal storage of neighbor passwords

Introduction This feature will provide a common encryption key to be used across all protocols to encrypt the neighbor password data for BGP, OSPFv2, BMP, ISIS, OSPFv3 and FHRP/VRRP for secure internal storage in the configuration. Prior to this feature, each protocol used its own algorithm based on neighbor IP or peer group to derive the password encryption key value. An unintended consequence of this original method is that the user cannot copy the encrypted password from one part of the configuration to another as the key to decrypt the passwords cannot be derived by all neighbors outside the original...
Continue reading →

Respect ‘set community’ clause order between route-map sequences

Introduction NOTE: The entire contents of this TOI apply equally to standard communities as well as extended communities. For brevity, the term “community” is used to mean either one. This feature adds support for “sequential” processing of route-map ‘set ext/community’ clauses. This feature is enabled via a configuration knob and there is no change in behavior without enabling this knob. The default route-map processing behavior can be summarized as “add then delete”. ip community-list expanded cl1 permit 1:.* route-map RMAP permit 5 set community 1:10 1:20 route-map RMAP permit 10 set community community-list cl1 delete route-map RMAP permit 15 set...
Continue reading →

BGP Community Matching With Community Instances

Community Instances offer a method of selecting BGP routes based on count of communities in the communities path attribute as an alternative to complex community-list regular expressions. Operation BGP community matching with community instances clause allows administrators to specify the number of standard community entries in a communities path attribute of a route to match.   Syntax [(no|default)] match [invert-result] community instances (>=|<=|=) <0-1024> [(no|default)] match [invert-result] community instances <= <0-1024> and >= <0-1024> [(no|default)] match [invert-result] community instances >= <0-1024> and <= <0-1024> “=” matches exactly the specified number of standard communities instances in the communities path attribute of...
Continue reading →

Inverting match result for communities and extcommunities in route maps

The route map feature ‘invert-result’ has been added to the ‘match community’ and ‘match extcommunity’ statements which permits or denies routes when provided communities or extended communities are missing. Configuration Arista(config)#route-map <route-map name> permit 10 Arista(config-route-map-name)#match invert-result community <community-list-name> or Arista(config)#route-map <route-map name> permit 10 Arista(config-route-map-name)#match invert-result extcommunity <extcommunity-list-name> Example In this example, the route-map will match any community except 100:300. Arista(config)#ip community-list standard clist permit 100:300 Arista(config)#route-map foo permit 10 Arista(config-route-map-foo)#match invert-result community clist The below configuration will prepend the as-path with “1000” if the path does not have both 100:1 AND 100:2. Arista(config)#ip community-list standard BAR permit 100:1 100:2...
Continue reading →

IS-IS Traffic Engineering

Introduction Traffic Engineering (TE) provides a mechanism to network administrators to control the path that a data packet takes, bypassing the standard routing model which uses routes along the shortest path. Traffic engineered paths are generally computed on the head-end routers of the topology based on various constraints (e.g. minimum bandwidth, affinity) configured for those paths and attributes (e.g available bandwidth, color) received from devices in the network topology. IS-IS Traffic Engineering (IS-IS TE) feature extends IS-IS protocol in EOS to carry TE attributes as part of its Link State Protocol Data Units (LSPs).  Note that IS-IS in EOS only...
Continue reading →

Vlan Mapping – 7160 series switches

VLAN mapping feature provides the ability to map an arbitrary VLAN tag to a particular bridging VLAN on the switch. This mapping can be either bidirectional or applied only in one direction(incoming/outgoing). The mapping is applied on a trunk port and multiple mappings can co-exist under each trunk port. Release 4.20.5F introduces VLAN mapping support on 7160 series switches. Additional details about VLAN mapping are available here:   VLAN mapping

MLAG Unicast Convergence

Feature Update: Please note that this feature has been updated and enhanced in EOS-4.24.1F MLAG Unicast Convergence provides the ability to fast redirect traffic through the other peer, in the event of local peer reloading or local peer’s MLAG interface(s) flapping. As of release 4.20.5F, this feature is now available on 7160 series switches. Here is a link to earlier TOI on Mlag Unicast Convergence: https://eos.arista.com/eos-4-18-0f/mlag-unicast-convergence/

Tap aggregation – user-defined TCAM profiles

This article describes user-defined TCAM (Ternary Content-Addressable Memory) profiles usage in Tap Aggregation. TCAM is a specialized hardware consists of tables that determine the traffic steering behaviour within the switch. The TCAM content is set according to policy ACLs, aggregation groups, and so on. We refer to the structure of the TCAM tables as a TCAM profile. Different TCAM profiles enable a different set of features. The user may use of the supplied TCAM profiles, or customize a TCAM profile to enable new capabilities that are not available in the supplied profiles. We refer to the customized TCAM profiles as...
Continue reading →

Lag Hashing Key Shift

Introduced in EOS-4.20.5, LAG hashing key shift controls how many bits we shift the LAG load balance key. Platform compatibility DCS-7280E DCS-7280R DCS-7280R2 DCS-7020R DCS-7500E DCS-7500R DCS-7500R2 Configuration The command to configure the LAG key shift is in the load balance profile (see https://eos.arista.com/eos-4-15-0f/lag-hashing/ for more information on how to configure load-balance profiles) 7500(config)#load-balance policies 7500(config-load-balance-policies)#load-balance sand profile p1 7500(config-sand-load-balance-profile-p1)# The key shift command is specific to LAGs 7500(config-sand-load-balance-profile-p1)#? fields Configure which headers/fields are used in the port-channel and ECMP hash packet-type Configure port-channel and ECMP hashing behavior specific to a packet type port-channel Configure port channel specific hash settings...
Continue reading →

LAG hashing on Ingress Interface

Introduced in EOS-4.20.5F, LAG ingress interface hashing controls whether the ingress interface is used in the LAG hashing calculation. Platform compatibility DCS-7280E DCS-7280R DCS-7280R2 DCS-7020R DCS-7500E DCS-7500R DCS-7500R2 Configuration The command to configure hashing on ingress interface is in the load balance profile (see https://eos.arista.com/eos-4-15-0f/lag-hashing/ for more information on how to configure load-balance profiles) 7500(config)#load-balance policies 7500(config-load-balance-policies)#load-balance sand profile p1 7500(config-sand-load-balance-profile-p1)# The ingress interface command is specific to LAGs 7500(config-sand-load-balance-profile-p1)#? fields Configure which headers/fields are used in the port-channel and ECMP hash packet-type Configure port-channel and ECMP hashing behavior specific to a packet type port-channel Configure port channel specific hash...
Continue reading →

Two Rate Three Color Marker (TrTCM)

Two rate three color marker (TrTCM) meters incoming packet streams based on two traffic rates: Peak information rate (PIR) and Committed information rate (CIR), and their associated burst sizes. Any stream of packets coming in at a rate lower than CIR is marked green, packets coming in at a rate higher than CIR but lower than PIR are marked yellow, while traffic chipping in higher than peak rate is marked red. Red packets are always dropped. TrTCM is used for ingress policing. Platform compatibility DCS-7060X DCS-7060X2 DCS-7260X Configuration 7060X(config)#policy-map type qos PMAP1 7060X(config-pmap-qos-PMAP1)#class CLASS1 7060X(config-pmap-c-qos-PMAP1-CLASS1)#police rate <rate> [<rateUnit>] burst-size <size>...
Continue reading →

LANZ configurable global thresholds for Ethernet ports

LANZ adds support for configuring global thresholds for Ethernet ports on DCS-7020, DCS-7050TX, DCS-7050X2, DCS-7060X, DCS-7060X2, DCS-7150, DCS-7250X, DCS-7260X, DCS-7280E, DCS-7280R, DCS-7280R2, DCS-7280SR, DCS-7280TR, DCS-7300X, DCS-7500E, DCS-7500R, and DCS-7500R2. This page will only demonstrate specific commands to configure global thresholds for Ethernet ports. For details about generic LANZ commands, refer to the existing documentation. LANZ configurable global thresholds are supported in both Notifying and Polling mode. For details about these modes, refer to the existing documentation. Platform compatibility DCS-7020 DCS-7050TX DCS-7050X2 DCS-7060X DCS-7060X2 DCS-7150 DCS-7250X DCS-7260X DCS-7280E DCS-7280R DCS-7280R2 DCS-7280SR DCS-7280TR DCS-7300X DCS-7500E DCS-7500R DCS-7500R2 Configuration The following command can...
Continue reading →

Ingress per-port IPv4, IPv6 counters

This feature provides support for per-interface ingress packet and byte counters for both IPv4 and IPv6. Platform compatibility DCS-7280SR DCS-7280CR DCS-7500-R Configuration IPv4, IPv6 ingress counters can be enabled/disabled using the following command: Arista#[ no ] hardware counter feature ip in Status Show command to display IPv4, IPv6 packets, octets Arista# show interfaces counters ip Port IPv4InOctets IPv4InPkts IPv6InOctets IPv6InPkts Et1/1 0 0 0 0 Et1/2 0 0 0 0 Et1/3 0 0 0 0 Et1/4 0 0 0 0 ... The command to clear IPv4, IPv6 counters is: Arista# clear counters   Syslog Messages When the feature is configured...
Continue reading →

Port-Channel Min-links Enhancement

Prior to EOS-4.20.5, port-channel min-links feature evaluated minimum-links in the following scenarios: The configuration of min-links on a port-channel interface. When a port-channel is brought up with min-links configuration. Addition or removal of port-channel member interfaces due to configuration or member interface status change. For LACP enabled port-channels, EOS did not re-evaluate min-links on LACP protocol Collecting and/or Distributing state changes. If an interface cannot be programmed as part of the port-channel, it was possible that the port-channel remained link-up with fewer number of active interfaces than the configured min-links. Enhanced min-links support has been introduced in EOS-4.20.5 which addresses...
Continue reading →

Management Tech-Support Policy

Introduction The management tech-support policy provides the capability to efficiently manage the output of “show tech-support” by allowing for the exclusion of specified commands from the “show tech-support” output. This capability could be used for example in a large scale BGP network where it may be desirable to exclude the large amount of BGP information from the “show tech-support” output. Configuration Configure show tech-support exclude policy Follow these steps to confgure the tech-support policy to exclude commands from the show tech-support output. Enter configuration mode. Arista#configure Enter management tech-support mode. Arista(config)#manangement tech-support Enter policy show tech-support mode. Arista(config-mgmt-tech-support)#policy show tech-support...
Continue reading →

802.1x Mac Based Authentication

MAC Based Authentication is a facility which allows a set of MAC addresses to be programmed into the RADIUS server. Such MAC addresses (MAC Based Authentication supplicants) do not have to speak 802.1X and may still be allowed access to the network. The authenticator identifies devices which do not support 802.1X and uses the MAC address of these devices as username/password in its RADIUS request packets. Depending on the MAC Based Authentication setting on the server, the server then decides whether to authenticate the supplicant or not. This is also different from 802.1x in the sense that every supplicant trying...
Continue reading →

Follow

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

Join other followers: