• Tag : 4.25.1F

 
 

BGP Prefix Origin Validation with  Resource Public Key Infrastructure (RPKI)

Description RPKI provides a mechanism to validate the originating AS of an advertised prefix. EOS support includes: Connecting to RPKI cache server(s) using the RTR protocol and syncing the Route Origin Authorizations (ROA) that have been synced from the global repositories. Validating prefixes received in BGP Update messages either using the ROAs that have been synced, or the Origin Validation State Extended Community attached to the received routes. Using the result of the validation to apply inbound policy in a route map. Platform compatibility This feature is available on all platforms. Configuration Configuration consists of 3 steps: Configuration of an...
Continue reading →

Configurable IGP Preference and Metric for SR-TE Policies

Description Currently, there is a global knob for configuring the preference of all SR-TE policies, that affects the comparison between SR-TE policies and other tunnels.  This feature adds more granular control to set the preference and IGP metric of individual policies. The metric is used as a tie-breaker when picking two policies with the same cost value, otherwise the cost determines the preferred policy.  Platform compatibility This feature is supported on all platforms that support SR-TE policies in multi-agent routing mode. Configuration Below is the hierarchy of policy configurations. The existing configuration of igp-cost was under the segment-routing configuration, meaning...
Continue reading →

Multicast EVPN All-Active Multihoming

Description [L2-EVPN] and  [Multicast EVPN IRB] solutions allow for the delivery of customer BUM (Broadcast, Unknown unicast and Multicast) traffic in a VLAN and L3VPNs respectively using multicast in the underlay network. This document describes the solution to support all-active multihoming for customer multicast traffic as described in [IGMP PROXY] . More information about VXLAN EVPN all-active multihoming may be found in [VXLAN EVPN All-Active Multihoming]. Multicast All-Active Multihoming IGMP PROXY support As described in [IGMP PROXY], in an all-active redundancy mode, IGMP reports from the CE may arrive at any one of the multihomed peers. The multihomed peer which...
Continue reading →

BGP nexthop resolution RIBs

Description This feature adds support for user-configured BGP Nexthop Resolution RIB profiles for various BGP-based services e.g. IP unicast, L3 VPN, EVPN, etc. The feature allows an administrator to customize the next hop resolution semantics of BGP routes with an ordered list, or profile, of resolution RIB domains (i.e., either tunnel or IP domain). This allows EOS to direct specific services over the specified RIB domains, overriding the default behavior. Further, this feature, through the use of user-defined tunnel RIBs, empowers an administrator to further select a subset of tunnelling protocols for specific services. Refer to User-defined tunnel RIBs for...
Continue reading →

Interface Policing on 7280R/R2, 7500R/R2

Description The document describes the support for dedicated and group ingress policing on subinterfaces without using QoS policy-maps to match on the traffic and apply policing. This feature allows for configuring upto 2048 subinterfaces with policers that are dedicated to the traffic flows on respective subinterfaces. As of version 4.26.1F, the feature also allows for configuring upto 1024 subinterfaces with group policers that police traffic flows coming from the respective subinterfaces together. Platform compatibility DCS-7280R series DCS-7280R2 series DCS-7500R linecard series DCS-7500R2 linecard series Configuration TCAM Profile Configuration To support this feature, we need to apply a TCAM profile that...
Continue reading →

IS-IS area proxy

Description IS-IS area proxy allows the creation of more scalable networks. IS-IS already has hierarchical mechanisms for creating topological abstractions. Area proxy improves upon those mechanisms, allowing abstraction with less overhead, resulting in a more scalable network.   In IS-IS today, a Level 1 area can provide transit for Level 2 traffic if the transit topology becomes part of the Level 2 topology. This implies that the Link State information from the transit topology must become part of the Level 2 Link State database that is flooded throughout Level 2. This can become a scalability limitation.   With area proxy,...
Continue reading →

ECN Counters per tx-Queue

Description This feature supports counting ECN-marked packets (ECN = Explicit Congestion Notification) on a per egress port per tx-queue basis.   The feature can be used to gather these packet counts via CLI or SNMP.   There are two cases when an ECN-marked (congestion) packet is counted on the egress port/queue: ECN-marked packet ingresses on a certain port and egresses to a port/queue; i.e., the ECN bit is preserved from ingress to egress. Non ECN-marked ingress packets that are ECN-marked due to congestion. On DCS-7260X, DCS-7250X, DCS-7060X, DCS-7050X, DCS-7010, and DCS-7300X, the packet is also a switch-marked packet (i.e., the...
Continue reading →

Hardware Accelerated sFlow on 7280R3/7500R3/7800R3

Description EOS-4.24.0 adds support for hardware-accelerated sFlow on R3 systems. Without hardware acceleration, all sFlow processing is done in software, which means performance is heavily dependent on the capabilities of the host CPU. Aggressive sampling rates also decrease the amount of processing time available for other EOS applications. With hardware acceleration, all sFlow processing is done on the switch ASIC itself, with little involvement from the CPU. Hence, it’s possible to support higher sampling rate without compromising CPU performance. Note that this is different from DCS-7280R2 and DCS-7500R2 systems, where a separate accelerator chip is used to provide hardware acceleration....
Continue reading →

BGP Prefix Origin Validation with Resource Public Key Infrastructure (RPKI)

Description RPKI provides a mechanism to validate the originating AS of an advertised prefix. EOS support includes: Connecting to RPKI cache server(s) using the RTR protocol and syncing the Route Origin Authorizations (ROA) that have been synced from the global repositories. Validating prefixes received in BGP Update messages either using the ROAs that have been synced, or the Origin Validation State Extended Community attached to the received routes. Using the result of the validation to apply inbound policy in a route map. Platform Compatibility This feature is available on all platforms. Configuration Configuration consists of 3 steps: Configuration of an...
Continue reading →

MAC Address Configurability on Routed Interfaces

Description For various peering applications, there is a need to support the assignment of a MAC address on routed interfaces. This feature adds the support for MAC address configurability on the following types of routed interfaces: Ethernet interfaces  Sub-interfaces on ethernet interfaces Port-channel interfaces Subinterfaces on port-channels VLAN interfaces This feature enables the following capabilities: A fully specified unicast MAC address can be configured, i.e., the new MAC address may not be from Arista’s allocated OUI space or derivative from the device’s base or system MAC address. A single MAC address can be assigned to multiple interfaces on a device....
Continue reading →

LDP Pseudowire

Description The LDP pseudowire feature provides support for emulating Ethernet connections over a Multiprotocol Label Switching (MPLS) network using the extension of the MPLS Label Distribution Protocol (LDP) specified in RFC4447. The patch panel configuration mode allows “patching” a local interface “connector” to an LDP pseudowire “connector” terminating on the local switch. The LDP pseudowire itself is defined under the pseudowires configuration mode, under the mpls ldp configuration mode. This feature also supports locally patching traffic between two interfaces or subinterfaces and is again configured under the patch panel configuration mode. Both these features support tagged (type 4) and raw...
Continue reading →

Macro-Segmentation Service deployment in a Brownfield Environment

Description This document presents how Arista Macro-Segmentation Service (MSS) can be deployed in a brownfield environment with a mix of non-Arista switches. This solution targets a VXLAN based network where both Arista and non-Arista Virtual Tunnel Endpoints (VTEPs) share the overlay reachability using the EVPN control plane.The following figure depicts such setup: In order to enable security enforcement with MSS, the user can put the resources that they would want to protect behind Arista VTEPs and express the security objectives using firewall policies. Moreover, this feature allows the user to enable MSS in a multiple datacenter (DC) environment where a...
Continue reading →

Spanning tree network super root

Description Arista MLAG supports STP for Layer-2 loop detection. In fact, most customers enable STP in their MLAG(s) to ensure no downstream Layer-2 loops due to mis-cabling or mis-configuration. Pre 4.25.1F EVPN All-Active multihoming mechanism did not support STP downstream because of the following reasons: Unlike MLAG, EVPN multihoming peers run STP independently. Hence, all EVPN multihoming PEs send BPDUs independently on port-channel links. STP BPDUs will have Bridge ID derived from the local system MAC address, so the BPDUs generated by each multihoming PE are different.  Hence, the downstream multihomed switch/server receives different BPDUs from different PEs, so STP...
Continue reading →

OSPF routes over GRE tunnels

Description This feature introduces the support for OSPF routes over GRE tunnels under default as well as non-default VRFs. The feature is disabled by default. 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) 7368 (Starting in EOS 4.23.1F) vEOS router DPDK mode (MODE=sfe in /mnt/flash/veos-config) Starting 4.24.1F DCS-7020 Not supported on DCS-7020SRG DCS-7280R DCS-7280R2 DCS-7500R Linecards DCS-7500R2 Linecards Starting 4.25.1F DCS-7280R3 Not supported on DCS-7280CR3MK DCS-7500R3 Linecards DCS-7800R3 Linecards Starting 4.25.2F OSPFV3 over GRE Not supported on DCS-7250X, DCS7010T, DCS-7280 Configuration The OSPF ‘tunnel...
Continue reading →

DHCP relay all subnets

Description EOS DHCP relay agent forwards all the DHCP requests from the clients using the primary IP address of the interface as the ‘giaddr’ in the relayed/forwarded requests even when there are secondary IP addresses configured on the interface and there are multiple IP address pools from secondary IP subnets with available addresses on the server. DHCP Relay All Subnets feature supports forwarding requests with secondary IP addresses in the gateway address ‘giaddr’ field. This allows the DHCP server to offer addresses to client requests with gateway addresses from secondary IP subnets configured on the interface. While All Subnets is...
Continue reading →

MRU Enforcement

Description MRU (maximum receive unit) enforcement provides the ability to drop frames that exceed a configured threshold on the ingress interface. Platform compatibility DCS-7020 DCS-7280R DCS-7280R2 DCS-7280R3 (Starting in 4.25.1F) DCS-7500R DCS-7500R2 DCS-7500R3 (Starting in 4.25.1F) Change Log 4.25.0F – initial release Support for MRU enforcement on Ethernet, Port-Channel and Sub-interfaces. 4.25.1F Support MRU enforcement on 7280R3 and 7500R3 platforms Support for per-chip MRU drop counter Configuration MRU is configurable per-interface, and can be configured on Ethernet and Port-Channel interfaces. Frames with size greater than the configured MRU value will be dropped on the ingress, and will not be forwarded...
Continue reading →

Support for IPv4 uRPF

Description IPv4 Unicast Reverse Path Forwarding (uRPF) can help limit malicious IPv4 traffic on a network. uRPF works by enabling the router to verify reachability (routing) of the source IP address (SIP) in the packet being forwarded. If the SIP is determined to not be a valid address, the packet is dropped. Two modes are supported: loose mode strict with allow-default mode. In the strict with allow-default mode, the packet must be received on the same L3 interface that the router would use to route the return packet. The packets can also come in on the interface through which the...
Continue reading →

Egress traffic-policing support for L3 subinterface

Description Egress traffic-policing can be applied on L3 Ethernet subinterfaces for outbound traffic. Platform Compatibility 7050SX3  7050TX3  7050CX3  720XP   Configuration arista(config)#class-map type qos match-any c1 arista(config-cmap-qos-c1)#match ip/ipv6 access-group abc < matching ACL to be rate-limited> arista(config)#policy-map type quality-of-service p1 arista(config-pmap-quality-of-service-p1)#class c1 arista(config-pmap-c-quality-of-service-p1-c1)#police rate X mbps burst-size Y bytes arista(config)#interface ethernet 1.1 arista(config-if-Et1.1)#service-policy output p1 Show Commands  The following command displays the subinterfaces to which the egress policy is attached arista(config)#show policy-map p1 summary Service-policy output: p1 Hardware programming status: Successful Number of class maps: 2 Configured on: Ethernet1.1 Active on: Ethernet1.1 Inactive on: arista(config)#show policy-map p1 Service-policy output: p1 Hardware...
Continue reading →

Setting metric on static routes and EOS SDK support

Description This feature introduces a metric for static routes so that the user can configure both administrative distance and metric for a static route. Administrative distance precedes metric when comparing configured routes. Lower metric route will win among routes with the same administrative distance. Winning routes will be programmed to hardware and shown in “show ip route”. It can be configured by CLI or through EosSdk. One use case of static route metric is to impact BGP best path selection. Route Arbitration case 1 — route with lower admin distance wins ip route 10.0.0.0/8 192.168.1.1 10 metric 100   (win)...
Continue reading →

Single Event Upset (SEU) handling on 7280/7500 Series

Description All electronic devices are subject to interference from cosmic radiation. Arista products use a combination of hardware and software to automatically detect and correct the results of this interference. For instance, many chip memories contain parity or Error Correcting Code (ECC) bits.   An SEU is a random, uncontrollable event, and cannot be stopped. However, continuous SEUs on a particular device may indicate a hardware or software fault, and Arista Support will help in making that determination. Platform Compatibility DCS-7020R DCS-7280R DCS-7280R2 DCS-7280R3 DCS-7500R DCS-7500R2 DCS-7500R3 DCS-7800R3 Configuration No configuration is required to enable SEU handling.   To change...
Continue reading →

Follow

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

Join other followers: