Deep packet inspection – SCTP support

Stream Control Transmission Protocol ( 132 ) is a transport layer protocol, much like TCP. After the IP header, a SCTP packet has the following fields: source port, destination port, tag and checksum. Starting EOS 4.15.0F, deep packet inspection on Arista DCS 7150 allows for filtering of SCTP traffic via ACLs, by matching on source port, destination port and payload. Configuration The feature can be configures using following set of CLI commands: Arista(config)#tap aggregation Arista(config-tap-agg)#mode exclusive Arista(config)#ip access-list <acl name> Arista(config-acl)#permit/deny sctp <srcIp> <sport> <dstIp> <dport> payload [ { offset <value> pattern <value> mask<value> }+] switch(config-acl)#permit/deny sctp <srcIp> <dstIp> [ userl4 pattern < value>...
Continue reading →

OSPF distribute lists

OSPF distribute-list is a policy construct to filter out routes received from OSPF LSAs so that they will not be installed on the router even though the routes are resolved and are installable. The filtering is performed after SPF calculation and only on routes from received LSAs, not on self-originated LSAs. This feature does not affect the OSPF protocol behavior of the router. LSAs are exchanged, e.g. flooded, even if the routes are not installed locally on the router. The purpose of this feature is to have added control over what received routes to install. For example, one can prevent...
Continue reading →

Static NAT and twice NAT counters

Packet counters for Static and Twice NAT connections are now supported on the DCS-7150 series. This is a debug feature. Enable this feature to start counting packets translated by Static NAT rules in hardware. This can be used to troubleshoot Static NAT translation failures. Configuration The CLI command “ip nat translation counters” can be used to enable this feature globally. “no ip nat translation counters” will disable the feature. Once enabled, all rules currently programmed in hardware and new rules configured after this command will get policers for counting packets. Status Show Commands The CLI commands “show ip nat translation hardware detail”...
Continue reading →

Tap aggregation – traffic steering show/clear commands

This TOI briefs the commands related to the traffic steering policies used in Tap Aggregation. These commands display the configured traffic-steering policy-maps, class-maps, the interfaces they are applied to, and the counters for each rule of the policy (presented in acl-counter format). The policy rule counters can be cleared using the corresponding clear commands.   CLI commands Presented below are the command formats along with the sample output: show class-map type tapagg [class-name] This command displays all/named tap aggregation class-maps. The output lists a mapping between a class-map and access-list(s). Each class-map could be mapping to multiple access-lists, but all of the access-lists...
Continue reading →

Static ARP inspection

Static ARP inspection is a security feature that verifies the source IP and the source MAC addresses of each received ARP packet payload based on user configured IP-MAC bindings. Static ARP inspection is enabled on a per-VLAN basis. When it is enabled on a VLAN, the switch intercepts ARP packets, both requests and responses, on all interfaces belonging to this VLAN, and verifies that each intercepted packet has a valid IP-MAC address binding in its ARP payload. On user-configured trusted interfaces, all received ARP packets are considered valid. After being inspected, ARP packets that have valid IP-MAC bindings are forwarded...
Continue reading →

Dynamic and symmetric LAG hashing

Starting with EOS4.15.0F, dynamic and symmetric LAG hashing policies are supported on the 7500E platform. Dynamic LAG hashing enables high link utilization and highly even distribution among LAG members by employing a randomized hashing algorithm. Symmetric LAG hashing allows the two flows of a bidirectional communication link, even when the two flows enter the switch on different ingress ports, to be hashed to the same member of a LAG on egress. Dynamic and symmetric LAG hashing policies are enabled via named Port-channel load-balancing profiles. LAG load-balancing policies can be provisioned on per linecard basis using these profiles. Configuration To configure...
Continue reading →

Egress ACL deny logging

Egress ACL deny logging on Arista DCS-7280E, DCS-7500 and DCS-7500E series switches allows the logging of the frames matching deny rules in egress ACLs. This behavior can be enabled by using the log keyword when configuring an ACL deny rule. Frames matching those ACL rules are sent to the control plane, where a syslog entry of the frame header is being generated. This feature can be used to troubleshoot egress ACL related issues. Configuration When configuring an ip access-list, a log keyword can be associated with a deny rule: lf123(config)##ip access-list test1 lf123(config-acl-test1)#permit ip 10.30.10.0/24 host 10.20.10.1 lf123(config-acl-test1)#deny ip host 10.10.10.1 host 10.20.10.1 log lf123(config-acl-test1)#permit ip...
Continue reading →

IP in IP decapsulation

With this feature, Arista 7050 and 7050X series of switches can now decapsulate IP in IP tunneled packets. When IP in IP decapsulation is configured, incoming packets with an outer IP header having IpProto=4 (IP in IP) and IpDest matching the one configured will be decapsulated, meaning that the outer IP header will be removed from the packet and all subsequent forwarding decisions will be based on the inner IP header. For a detailed description of IP in IP tunneling, please refer to RFC2003. Configuration The IP in IP decapsulation feature is enabled by configuring a decap group with type IpIp...
Continue reading →

MPLS encapsulation

EOS 4.15.0F adds support for MPLS encapsulation of IP packets in EOS. The functionality is exposed through two mechanism(s): 1) We can have static IP routes which have a label associated with it, all IP packets hitting this route will get encapsulated with the MPLS label specified and sent out. This is supported for both V4 and V6 static IP routes 2) We can also program a NexthopGroup of type MPLS. Each NexthopGroup entry can have up to 4 MPLS label(s) associated with it. Traffic hitting this NexthopGroup will get ECMP load balanced across all the NexthopGroup entries and will get...
Continue reading →

Hardware switch controller MLAG integration

The Hardware Switch Controller (HSC) provides an integration point between the SDN controllers (NSX or Nuage) and VXLAN Controller Service (VCS).  The SDN controller will interact with the HSC agent through OVSDB (Open vSwitch Database). The HSC agent, in turn, will translate information between OVSDB and VCS. The HSC agent publishes the inventory of physical switches and physical ports to the SDN controller. The SDN controller in turn would read this inventory and update the physical ports’ VLAN bindings in order to bind a VLAN to a logical switch. In a MLAG deployment where two physical switches publish MLAG ports....
Continue reading →

IPv6 vrf support

This feature adds the support for IPv6 unicast in a VRF context in EOS. This entails static routing and dynamic routing capabilities with OSPFv3 and BGP within a vrf . This allows IPv6 unicast routing to function in a non default VRF context. Following are some of the salient points regarding this feature No ipv6 route leaking support across VRFs static and dynamic ipv6 neighbor support  per VRF static ipv6 route support per VRF IPv6 ECMP support in a VRF context IPv6 dynamic routing supported with OSPFv3 and BGP in a VRF context Routed ports, SVIs, Loopback interfaces and Management interfaces...
Continue reading →

IPv4 VRRP VRF support

As of EOS 4.15.0F, VRRP is supported in a VRF context. Virtual IP addresses can be reused in different VRF contexts, but still follow the same rules within the each VRF. Configuration To enable VRRP in a VRF, the user must do the following steps: Configure VRF: Switch(config)#vrf definition foobar Switch(config-vrf-foobar)#rd 100:10 Enable global and VRF routing: Switch(config)#ip routing Switch(config)#ip routing vrf foobar Add a Vlan into the VRF and add a physical IP address: Switch(config)#interface Vlan10 Switch(config-if-Vl10)#vrf forwarding foobar Switch(config-if-Vl10)#ip address 10.0.0.1/24 Finally, configure VRRP normally: Switch(config-if-Vl10)#vrrp 1 ip 10.0.0.2 Switch(config-if-Vl10)#vrrp 1 ?                  ...
Continue reading →

SSL certificate and key management

This is an infrastructure that provides management of SSL certificates, keys and profiles. Only RSA keys are supported. 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. A user can manage certificates, keys and also multiple SSL profiles. A SSL profile is a configuration which includes certificate, key and trusted CA certificates used in SSL/TLS communication. A SSL profile configuration can be attached to another EOS configuration which supports SSL/TLS communication. Individual EOS features that use this infrastructure will document the details of...
Continue reading →

LANZ

Introduction LANZ on DCS-7280SE and DCS-7500E adds support for monitoring congestion on front panel ports at a more granular level with Start, Update, and Stop congestion events. These events are available while using Notifying mode. The previous behavior of polling the most congested queue per ASIC is still available in the default Polling mode. LANZ Streaming is now available on DCS-7280SE and DCS-7500E. Platform compatibility DCS-7280SE DCS-7500E Configuration Enabling Notifying mode Arista(config)# queue-monitor length notifying This enables Notifying mode. The default is Polling mode. In a mixed system with both DCS-7500 and DCS-7500E linecards configuring Notifying mode results in Notifying...
Continue reading →

MPLS label swap and pop

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 virtual links (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. Arista switches utilize MPLS to improve efficiency and control from servers through data centers and to the WAN. The MPLS implementation supports static MPLS tunneling that is manually configured on each switch or established over a network by an SDN controller. The...
Continue reading →

Egress IPv4/IPv6 ACLs for IPoMPLS packets after MPLS pop

IPv4/IPv6 over MPLS packets are now eligible for ACLs at egress stage by default. The feature is applicable only to IPv4/IPv6 over MPLS packets that are MPLS label popped ( i.e if the label is Bottom of Stack ). The user can override this behavior if required and disable egress ACLs for certain MPLS labels by explicit configuration. Configuration No special configuration is needed to enable egress ACLs on IPv4/IPv6 over MPLS packets. There is however configuration to skip egress ACLs on a per label basis. The command to disable egress ACLs for a label is as follows switch(config)#[no] mpls...
Continue reading →

RACL divergence

RACL divergence enables the optimization of the utilization of hardware resources by installing ACLs only on the hardware components corresponding to the member interfaces belonging to the SVIs on which the ACL is applied. This can save a lot of hardware resources and enables RACLs to scale to larger configurations. Deployments where multiple large RACLs are applied on SVIs with member interfaces corresponding to mutually exclusive forwarding ASICs, will benefit from this feature. Terminology RACL : any access-Lists (ACL) applied to an Switched Virtual Interface (SVI). Ingress traffic : any traffic entering a VLAN is said to ingress the SVI corresponding to the VLAN Egress...
Continue reading →

IPv6 egress RACL sharing

IPv6 egress ACLs applied to routed interfaces across the same chip on the DCS-7500E and the DCS-7280E series can be shared starting EOS-4.15.0F. In addition to that, IPv6 egress ACLs can match on the DSCP value, starting with the same release. This result in a more efficient utilization of the system resources and it is particularly useful for environments with a few, potentially large, IPv6 Egress ACLs applied across multiple routed interfaces. Configuration By default, the sharing of ACLs is disabled. The CLI command used to enable it is: 7500(config)#hardware access-list resource sharing vlan ipv6 out The CLI command to disable it is: 7500(config)#no hardware access-list resource sharing vlan...
Continue reading →

Static multicast MACs

A number of L4-7 appliances use the same MAC address to load balance services across two or more appliances that form the cluster. A typical example are firewalls. As a result, a switch must be able to learn the same MAC address on several ports. With this feature, the user can now configure the static multicast MAC destination address with multiple destination ports. Configuration The command to configure static multicast MAC  address with multiple destination ports is as follows: Arista(config)#mac address-table static <MAC-address> vlan <VLAN-id> interface <destination-ports> Example : Arista(config)#mac address-table static 0100.1234.1234 vlan 3 interface et3/1,et3/4 Status 7500# show...
Continue reading →

Ingress replication to LAGs

On DCS-7048, DCS-7280E, DCS-7500 and DCS-7500E, prior to EOS 4.14.5, multicast traffic using ingress replication would load balance the traffic over lags on a per-multicast group basis. The software would pin a multicast flow to a port in the lag based on the vlan and the multicast MAC address of the flow. This meant that software would resolve the lag for a multicast-group, and program the resolved port into the hardware for multicast traffic destined to that group. This would result in two problems: The load balancing of traffic over ports may not be even. If there is more traffic...
Continue reading →

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 and 7280SE 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 →

BGP advertise inactive

EOS BGP implementation normally considers only active routes in RIB for advertisement to its peers. In certain deployments, IGP protocol like OSPF may carry same set of prefixes as BGP. In addition, routes from OSPF and BGP may be mutually redistributed. As a result, when local BGP process advertises these prefixes to its neighbors, it would always choose OSPF routes over corresponding BGP routes (admin distance of OSPF is better than that of BGP). In event of OSPF route being lost, OSPF process running on these BGP peers will detect the loss of forwarding path. However, there is no alternate path available locally on...
Continue reading →

PBR/ACL counter selection

Prior to EOS-14.15.0F, if a single packet hit both a PBR and an ACL rule, then only the hardware counters corresponding to the PBR will increment. Starting in EOS-4.15.0F, it is possible to configure EOS such that the hardware counters corresponding to the ACL will be incremented instead. Configuration The CLI command to enable this behavior is: 7500E(config)#[no|default] platform arad tcam counters feature {pbr|acl} The default behavior is to increment the PBF counters. If counters for one of the feature are enabled, then the counters for the other feature will be automatically disabled in all cases. For example, if ACL counters are enabled,...
Continue reading →

VLAN mapping

VLAN mapping feature provides  the ability to map an arbitrary incoming VLAN tag to a particular bridging VLAN on the switch. The mapping is applied on a trunk port and multiple such mappings can exist under each trunk port. This particular feature enables the use of VLAN mapping on 7280/7500E series switches. Configuration switchport vlan mapping [in | out] vlan_tag_on_wire dest_vlan no switchport vlan mapping [in | out] vlan_tag_on_wire dest_vlan default switchport vlan mapping vlan_tag_on_wire dest_vlan Example: interface Ethernet3 switchport mode trunk switchport vlan mapping 10 100 switchport vlan mapping in 11 200 switchport vlan mapping out 300 12 Status Arista#show...
Continue reading →

IPv6 ACLs

IPv6 access-lists can be used to filter IPv6 network traffic. Starting EOS 4.15.0F release, we have added support for IPv6 ACLs for DCS-7150 series. This feature will available for the following interfaces: Ethernet port ( ingress and egress ) Port-Channel ( ingress and egress ) SVI ( ingress only) Additionally, support is also added for IPv6 ACL based TapAgg traffic steering. Please check Tap Aggregation Traffic Steering TOI for information on the same. Configuration The following example creates an IPv6 ACL and adds the rules in ACL configuration mode. switch(config)#ipv6 access-list test1 switch(config-ipv6-acl-test1)#permit ipv6 2001::1/120 any switch(config-ipv6-acl-test1)#deny ipv6 any 3001::3/64 log...
Continue reading →

OSPFv3 authentication

This feature adds authentication support for OSPFv3. Unlike OSPFv2, OSPFv3 does not have authentication fields in the packet header. It requires IPv6 Authentication Header (AH) and IPv6 Encapsulating Security Payload (ESP) to provide integrity, authentication or confidentiality. To configure authentication, Security Association needs to be configured from the cli which has two parameters: Security Policy Index (SPI) and a secret key. These parameters are used to compute an Integrity Check Value (ICV), which is used to authenticate peers. For the OSPFv3 to work between a set of peers with authentication enabled, SA parameters must be same for all of them. OSPFv3 packets received over an interface...
Continue reading →

MSTP PVST inter-operation

While migrating from PVST to MSTP, or vice-verse, the network engineer may choose not to run MSTP throughout the network. A possible scenario would be to deploy MSTP in certain regions and PVST in others based on their respective merits or other extenuating factors. This feature facilitates such scenarios by allowing protocol level interaction between MSTP and PVST i.e., PVST BPDUs are consumed and transmitted by MSTP at the border. The functionality is self-contained within MSTP and is designed to work with any PVST implementation. The inter-operation can be viewed as bi-directional BPDU translation occurring at MSTP PVST border ports...
Continue reading →

Routing with an MLAG peer’s system MAC

In an MLAG setup, routing on a switch (MLAG peer) is possible using its own bridge/system MAC, VARP MAC or VRRP MAC. When a peer receives an IP packet with destination MAC set to one of the aforementioned MACs, the packet gets routed if the hardware has enough information to route the packet. Before EOS 4.15.0F, the following behavior was observed if the destination MAC is peer’s bridge MAC – the packet is L2 bridged on the peer-link and the routing takes place on the peer. This behavior to use the peer-link to bridge the L3 traffic to the peer is...
Continue reading →

IPv6 VRF management features

EOS-4.15.0F is introducing support of IPv6 management capabilities inside a VRF. This means existing management capabilities available in the default VRF, are now available in any VRF defined by user through IPv6. You can find below description and example for this new feature. SSH/Telnet (Secure shell) In an interface with a VRF context and an IPv6 address configured, it supports ssh/telnet related features. Tacacs+ (Terminal Access Controller Access Control System) With a VRF configured, an IPv6 host can be specified as the Tacacs+ server as well as the source interface of an interface configured with a VRF and IPv6 address. SNMP (Simple Network Messaging...
Continue reading →

VXLAN Control Service

The VXLAN Control Service (VCS) provides a mechanism by which hardware VTEPs share states between each other in order to establish VXLAN tunnels without the need for a multicast control plane. This particular feature enables the use of a VCS client on 7280/7500E series switches. Configuration The following configuration is necessary on each switch that needs to connect to the VXLAN Control Service running on CVX: fm202(config)#management cvx fm202(config-mgmt-cvx)#server host 172.27.6.248 fm202(config-mgmt-cvx)#no shutdown The IP address above is the management IP address of the CVX controller or the IP address that CVX is listening on for client connections. Next step...
Continue reading →

Policy-based routing

Policy Based Routing (PBR) is a feature that is applied on routable ports, to preferentially route packets.  This is based on a policy, and overrides normal routing decision.  This feature has been introduced on DCS-7150 Series of switches. On 7150 series of switches, same policy applied on many interfaces does not occupy extra TCAM space.  Also, changing interface membership does not affect traffic flow.  Different policies applied on interfaces are programmed together in TCAM. Configuration The following is an example of a basic configuration. switch(config)#ip access-list PermitAnyAcl switch(config-acl-PermitAnyAcl)#statistics per-entry switch(config-acl-PermitAnyAcl)#10 permit ip any any switch(config)#class-map type pbr match-any PermitAnyClass switch(config-cmap)#10 match...
Continue reading →