• Tag : EOS-4.15.0F

 
 

Storm control in packets-per-second

The existing storm control interface configuration mode CLI commands have been extended to support the new configuration option Packets per second (pps) on the following platforms: 7050X 7050QX 7300X Configuration The existing percentage parameter command limits the broadcast/multicast traffic to a specified percentage of the link-speed as mentioned in the command. Following is the example command. Arista(config-if-Et1)# storm-control broadcast level 50 The above command can be replaced with ‘pps’ followed by the allowed number of packets per second. So, instead of limiting broadcast traffic to 50% of the link-speed, the command below will limit the broadcast traffic to 5000 packets per...
Continue reading →

OpenFlow forwarding mode flow-and-normal

A new forwarding pipeline is being introduced in EOS-4.15.0F which allows the traffic entering the switch to be processed in a “normal” manner if it does not match a configured flow. It can be seen as an amalgamation of the “OpenFlow” process pipeline and “Normal” pipeline. Unlike OpenFlow, traffic is subjected to ingress and egress VLAN checks, STP state for a port and ingress features such as port ACLs can override the flow actions. It must be noted that this is different than the OpenFlow hybrid mode since flow-and-normal mode does not allow packets to go from OpenFlow pipeline to...
Continue reading →

BGP prefix independent convergence

BGP Prefix Independent Convergence (PIC Edge) refers to fast re-convergence of traffic destined for BGP prefixes on a network event affecting the best path(s) such that the time taken to switch traffic from the active best path(s) to the next best path (i.e. backup path) is independent of the number of prefixes. The above behavior is achieved by pre-programming the best path and alternate backup path in the forwarding agent in steady state.  It is supported for both IPv4 and IPv6 address families for default and non-default VRFs. BGP PIC Edge is supported only when the best path is a single-hop...
Continue reading →

BGP IPv6 VRF

IPv6 BGP peers and IPv6 prefixes for non-default VRFs are supported starting EOS-4.15.0F. All CLI commands available in the address-family IPv6 submode of the default VRF are also supported for non-default VRFs. Configuration IPv6 BGP VRF configuration is performed in the VRF submode of the router-bgp configuration mode. For example, the following commands activate IPv6 address-family support for the IPv6 neighbor  fd7a:2433:8c01::1 in the red VRF: Arista(config)#router bgp 1 Arista(config-router-bgp)#vrf red Arista(config-router-bgp-vrf-red)#router-id 1.1.1.1 Arista(config-router-bgp-vrf-red)#neighbor fd7a:2433:8c01::1 remote-as 16 Arisya(config-router-bgp-vrf-red)#address-family ipv6 Arista(config-router-bgp-vrf-red-af)#neighbor fd7a:2433:8c01::1 activate Status show ipv6 bgp vrf <vrf-name> displays BGP IPv6 routing table entries for a given VRF: Arista(config)#show ipv6...
Continue reading →

Redistribution of IS-IS routes into BGP and BGP routes into IS-IS

This feature allows to advertise routes learnt via BGP into IS-IS network or IS-IS routes into BGP network. It also allows to selectively advertise some routes and modify route attributes before advertising using route-maps. Configuration Switch(config)#router isis 1 Switch(config-router-isis)#address-family ipv4 Switch(config-router-isis-af)#redistribute bgp route-map bgp-to-isis-v4 Switch(config)#router bgp 1 Switch(config-router-bgp)#address-family ipv4 Switch(config-router-bgp-af)#redistribute isis level-1 route-map isis-to-bgp-v4 Alternatively same commands are available in router isis mode and router bgp where if configured it will apply to both IPv4 and IPv6 routes. Switch(config)#router isis 1 Switch(config-router-isis)#redistribute bgp route-map bgp-to-isis Switch(config)#router bgp 1 Switch(config-router-bgp)#redistribute isis level-1 route-map isis-to-bgp Note these commands cannot be configured in...
Continue reading →

Supporting GSHUT community in BGP

This feature adds support for standard BGP GSHUT (0xFFFF0000) community. GSHUT community is the community used in BGP for graceful shutdown. With this support, the BGP speaker sets the local preference of the incoming BGP advertisement to 0 if the advertisement is received with attributes containing GSHUT community. It also enables setting the GSHUT community and matching on GSHUT community using route-maps. Configuration No explicit configuration is required to enable processing GSHUT community. The following configuration creates a route-map entry that sets the community to GSHUT: Arista(config)#route-map map1 Arista(config-route-map-map1)#set community GSHUT Arista(config)#exit Arista(config)# The following configuration creates a route-map entry that...
Continue reading →

AS prepend in BGP policy using “auto” keyword

The "set as-path prepend" clause in the config-route-map mode is enhanced to accept the "auto" keyword. The "auto" keyword is designed to take the value of either the BGP local or peer AS number depending on the directionality of the route-map. In the case of neighbor inbound route-map, the "auto" takes the value of peer AS number and for outbound route-maps, it takes the value of local AS number. The "auto" keyword has no significance in all other cases and will be ignored. The as-path sequence of “set as-path prepend” can accept more than one “auto” similar to any other...
Continue reading →

Disable IEEE reserved frame trapping

IEEE802.1D-2004, Section 7.12.6 specifies destination MAC addresses that are normally trapped (not forwarded) by the a switch. Starting in version 4.15.0F, EOS allows for frame trapping to be disabled for specific addresses (except STP BPDUs and pause frames). Configuration This feature is currently supported on: DCS-7150 DCS-7010 DCS-7050 DCS-7250 DCS-7300 The CLI configuration is available from the global configuration mode: Arista(config)#mac address-table reserved forward <MAC address or range> By default, all reserved addresses are trapped.  MAC address values specified with this configuration will be forwarded instead.  The possible values for <MAC address or range> depend on the specific platform as shown...
Continue reading →

Tap aggregation hybrid mode

  As of 4.15.0F, tap aggregation can be configured in conjunction with other switching and routing features.  This functionality is referred to as hybrid mode.  Hybrid mode is supported on the 7500E series and allows certain line cards to be designated for Tap Aggregation, while permitting others to continue operating as usual. Please see Limitations for unsupported use cases.   Configuration Hybrid mode Tap Aggregation is configured as follows. switch(config)#tap aggregation switch(config-tap-agg)#[no|default] mode mixed module linecard <range> The range can be used to specify one or more linecards to use for Tap Aggregation.  For example, the following would enable Tap Aggregation on linecards...
Continue reading →

DirectFlow/OpenFlow enhancements

The following new enhancements to DirectFlow and/or OpenFlow are added in EOS-4.15.0F: DirectFlow redirect to CPU DirectFlow non-persistent flows DirectFlow/OpenFlow MAC/VLAN rewrite DirectFlow redirect to CPU DirectFlow now supports inserting a flow entry that matches on some specified criteria and redirects matching traffic to the switch CPU. This is useful for cases where the user has a custom agent running on EOS and wants to trap specific traffic and send to the agent. Configuration As part of a flow definition, the user can configure action output interface cpu to redirect traffic matching this flow entry to the CPU. For example: Arista(config)#directflow Arista(config-directflow)#flow...
Continue reading →

PTP enhancements

  This document describes the enhancements to Arista’s IEEE-1588 PTP implementation introduced in EOS-4.15.0F. Arista – 7150 PTP boundary mode is now supported on 40G interfaces. Transparent clock mode is not supported on 40G interfaces. Arista – all platforms that support PTP specify that an interface may only operate in master mode – this will prevent an unexpected topology inversion due to losing connectivity with the grandmaster.   Configuration Configuration of PTP boundary mode on 40G interfaces works exactly the same as on interfaces with other speeds: From interface configuration mode: switch(config-if-<intf>)#ptp enable From global config mode: switch(config)#ptp mode boundary The...
Continue reading →

CLI to reserve BST slices for multicast routes

In order to use the BST(Binary Search Tree) resources more efficiently for multicast, we are introducing a new CLI command to reserve space in the BST for multicast routes. Using this CLI command, the user can specify the number of multicast routes he would like to program in the BST. The software internally translates this to the number of BST partitions required and then earmarks the same for multicast routes. Configuration The following CLI configuration commands are introduced: 1. platform fm6000 bst reserved mroutes <1-15345> 2. no platform fm6000 bst reserved mroutes 3. default platform fm6000 bst reserved mroutes The...
Continue reading →

Configurable IPv6 link-local address

An IPv6 link-local address for an interface is generated automatically using the modified EUI-64 scheme. All IPv6 enabled interfaces are required to have at least one link-local address, with a special prefix starting with “fe80::/10”. In this release, we provide the functionality to manually configure the link-local address of a given interface from the CLI using the ‘link-local’ keyword. Since, Link-local addresses are local to a segment it is possible for multiple interfaces on different subnets to have the same link-local address. This feature allows the network engineer to assign addresses according to a given scheme, and further helps in troubleshooting issues by isolating interfaces...
Continue reading →

CVX secure out-of-band connection

This feature adds support for securing out-of-band connection between CVX server and CVX clients by SSL/TLS transport protocol. SSL/TLS is an application-layer protocol that provides secure transport between client and server through a combination of authentication, encryption and data integrity. SSL/TLS uses certificates and private-public key pairs to provide this security. We will use the term SSL to mean SSL/TLS. By default CVX server and CVX clients communicate over insecure transport. i.e., there is no authentication and encryption between CVX server and CVX clients. This opens up possibility of security risks such as communicating with untrusted CVX server and CVX clients, someone eavesdropping CVX server/client communication etc. This feature can be used to secure...
Continue reading →

ACL-based policing

Ingress policing provides the ability to monitor the data rates for a particular class of traffic and perform action when traffic exceeds user-configured values. This allows user to control ingress bandwidth based on packet classification.  Ingress policing is done by policing meter which marks incoming traffic and performs actions based on the results of policing meters.  On 7500E, 7280SE and 7020TR we support single rate two color mode. Configuration Two parameters needs to be configured in single rate two color mode, namely metering rate and the burst size. The command used is: switch#configure terminal switch(config)#policy-map [type qos] policy-name switch(config-pmap)#class { class-name...
Continue reading →

DHCP relay across VRF

The EOS DHCP relay agent now supports forwarding of DHCP requests to DHCP servers located in a different VRF to the DHCP client interface VRF. Enabling VRF support for the DHCP relay agent has a prerequisite that Option 82 (DHCP Relay Agent Information Option ) is enabled. Option 82 is used by the DHCP relay agent to insert client specific information to pass on to the DHCP server. The DHCP relay agent will insert Option 82 information into the DHCP forwarded request when the DHCP server belongs to a network on an interface that belongs to a different VRF than the...
Continue reading →

sFlow output interface

On 7500E, sFlow output interface feature enables sFlow to use the hardware provided output interface and avoiding software simulation. The below configuration is needed only for releases before 4.15.2F. From 4.15.2F Sflow agent always uses hardware provided output interface to report in the samples. Configuration To enable this feature, sFlow extended switch header, and extended router header need to be disabled and sFlow output interface has to be enabled. sFlow extended switch header, and extended router header have to be disabled since deriving the extension headers using 7500E provided information is not supported yet. sFlow output interface is enabled by default. Arista(config)#no sflow extension switch...
Continue reading →

Config sessions

In EOS 4.15.0F release, we have introduced the configuration sessions feature. Configuration sessions allow the user to issue configuration CLIs that do not take effect immediately. Instead, they are saved in a session with the given name. The session can be entered, modified and exited at any time without affecting the running configuration of the system. When the session is committed, the configuration that was modified in the session is copied into running configuration. The session can also be aborted or removed to remove the session completely and free up memory used by the session. Config Sessions can be used to...
Continue reading →

Permit during ACL update for security ACLs

  Permitting traffic during ACL updates has been available for traffic steering in tap aggregation mode since EOS 4.14.0F. In EOS 4.15.0F, this feature is extended for security ACLs in regular switch mode. By default, the feature is disabled. If there is any change in the ACL configuration, the traffic flow to all Ethernet ports is stopped until the ACLs have been successfully applied and the system in a stable state once again. As a result, a considerable number of packets could be dropped on all ports and features like routing or dynamic NAT can be affected (in this window of time)....
Continue reading →

Switchover on Sysdb restart

For modular systems operating under the SSO redundancy policy, if  the system database agent (Sysdb) on the active supervisor restarts, the system will trigger a switchover and the standby supervisor will take over to become the new active. The system will go through a hitless transition. Status If Sysdb restarts, leading to a switchover event, the previously active supervisor will reload and the following command can be used to display the reload cause: Arista#show reload cause Reload Cause 1: ------------------- Stateful switchover requested due to Sysdb failure. Reload Time: Reload occurred at Mon Mar 23 14:48:08 2015 PDT Syslog Messages The following...
Continue reading →

Follow

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

Join other followers: