• Tag : EOS-4.15.0F

 
 

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 →

Tap aggregation manager

The Tap Aggregation Manager (TAM) is a GUI front-end for configuring and monitoring Tap Aggregation features of Arista switches.  Version 2.0, introduced in EOS-4.15.0F, includes several new features and enhancements, and supports new platforms. new tabbed interface design with resizable sidebars enhanced ACL Editor in its own tab enhanced interface visualization and bundling traffic steering configuration via ACLs, Class Maps and Policy Maps support for DCS-7500 series switches IP V6 ACL support new guided Tour to orient first time users Configuration Basic configuration In order to start the TAM, simply enable Command API on the switch: 7150(config)#management api http-commands 7150(config-mgmt-api-http-cmds)#no shutdown TAM...
Continue reading →

IPv4 route scale

IPv4 routes of certain prefix lengths can be optimized for enhanced route scale on 7500E, 7280E, 7500R and 7280R platforms using this feature. This feature is ideally suited to achieve route scale when route distribution has a large number of routes of one or two prefix lengths. Configuration Starting from 4.15.2F release the following configuration command can be used to increase the hardware resources available for the specified prefix lengths. switch#[no] ip hardware fib optimize prefix-length ?   12  Prefix length 12   16  Prefix length 16   20  Prefix length 20   24  Prefix length 24   28  Prefix length...
Continue reading →

Subinterfaces

Subinterfaces are logical L3 interfaces that enable the division of a single Ethernet or Port-channel interface into multiple logical L3 interfaces based on the incoming 802.1q tag.  They are commonly used in the L2/L3 boundary.  They can also be used in the context of VRF-lite, by configuring each subinterface in a different VRF. The following features are supported on subinterfaces. Unicast and multicast routing BGP, OSPF, ISIS, PIM VRF VRRP SNMP VXLAN (see Limitations section for platform limitations) MPLS (see Limitations section for platform limitations) GRE (see Limitations section for platform limitations) Inheriting QOS settings (trust mode and default DSCP)...
Continue reading →

BGP 4-byte ASN

At the beginning of 2014 the the Number Resource Organization announced that the pool of 2-byte BGP AS numbers had nearly been depleted (2-byte Autonomous System (AS) Number Pool Nearing Depletion). This feature has been introduced into the 4.15 code release and adds 4-byte AS number support (RFC6793) into Arista’s EOS BGP implementation. The feature extends the number of supported AS numbers from 65535 to 4294967295. BGP speakers that support 4-byte AS numbers are referred to as NEW BGP speakers, these need to be backward compatible with speakers that only support 2-byte AS numbers, referred to as OLD BGP speakers. NEW BGP...
Continue reading →

Bgp multipath relax

EOS by default selects the prefix for ECMP if the two paths have the same AS-PATH length regardless of the ASN values in the AS-PATH attribute. BGP Multipath relax feature provides the knob to change the default behavior of the EOS. The existing EOS behavior of BGP multipath selection that selects the routes in the same ECMP group even if the AS_PATHs are not same should be in effect only if BGP is configured to  relax the check for AS_PATH comparison via the bgp bestpath as-path multipath-relax command. Configuration Command Syntax :      [no | default] bgp as-path multipath relax ...
Continue reading →

Fair VOQ credit allocation

The 7280E and 7500E series are Virtual Output Queues (VOQs) based multi-chip systems where there is a VOQ for all the egress ports and traffic classes per ingress chip. In some customer setup, the egress port can be oversubscribed for a period of time and for a given traffic class it might not be desirable to be fair between different ingress chips. Consider a switch which has two ingress ports on chip #1 and one ingress port on chip#2. The egress port is on chip #3. Here the ingress ports are unevenly distributed across two different chips. The previous default allocation between VOQs...
Continue reading →

BGP sFlow export

BGP sFlow export is to add BGP route information including source and destination AS path information, local preference, BGP nexthop, etc into sFlow sample packet if the destination IP is based on a BGP route. The BGP meta data is called the extended_gateway structure as per the latest sFlow specification. Once BGP sFlow export is enabled, the routing agent will export BGP route table and AS path information for the sFlow agent. Then sFlow agent will look up the longest matched prefix once it receives a sample packet. If the route is a BGP route, sFlow agent will do further look up  to get all BGP...
Continue reading →

Source ARP with virtual IP

Source ARP with a virtual IP is a new VARP feature. The purpose of this feature is to change the ARP request header’s source IP and source MAC address to the virtual IP and virtual MAC addresses.  This change occurs for all the ARP request packets originating from the router that match a configured virtual subnet. The VARP MAC address is used as the source MAC address, while the virtual IP address is based on the interface on which the packet goes out. This feature is also supported in a VRF context. Following is the example configuration: ip virtual-router mac-address 0011.2233.4455 ip...
Continue reading →

Tap aggregation – stripping VLAN tags using traffic steering

The traffic-steering policies used in tap aggregation mode allow steering traffic from tap to tool ports using ‘set aggregation-group’ action, while the ‘set id-tag’ action tags the traffic with the specified id(in the dot1q format). The new action allows removing the VLAN(dot1q) tags from the steered traffic. VLAN tag removal is already available as the tool port interface mode command ‘switchport tool dot1q remove outer <1-2>’. However this is a bit rigid since all frames going out of the tool port will be stripped of the VLAN tags. Letting a policy specify the removal provides greater flexibility. Configuration As with the other policy...
Continue reading →

VXLAN routing over MLAG

MLAG provides Layer2 active/active redundancy. VXLAN is supported over an MLAG setup by having the two switches implement a single logical VTEP. This means either of the two switches can terminate a single VXLAN tunnel depending on where the packet arrives. VXLAN routing entails routing packets received from a tunnel after decapsulation and/or encapsulating packets into a tunnel after routing. VXLAN bridging is already supported over MLAG. In this release, we have added support for VXLAN routing over MLAG on the 7150 series. While VXLAN bridging enables either of the two switches in the MLAG pair to bridge packets in the overlay,...
Continue reading →

Follow

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

Join other followers: