• Tag : 4.24.1F

 
 

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 →

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 →

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 Configuration The OSPF ‘tunnel routes’ command is issued in router ospf mode. The command syntax...
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 →

Egress Sflow

Description Egress Sflow sampling feature allows to sample unicast packets based on the egress interface. Platform compatibility The following platforms are supported: 7368 Series (starting in EOS-4.24.1F) DCS-7060DX4-32 Series(starting in EOS-4.24.1F) DCS-7060PX4-32 Series (starting in EOS-4.24.1F) DCS-7050TX3-48C8 Series (starting in EOS-4.25.1F) DCS-7050SX3-48YC8 Series (starting in EOS-4.25.1F) DCS-7050SX3-48C8 Series (starting in EOS-4.25.1F) DCS-7050CX3-32S Series (starting in EOS-4.25.1F) DCS-7050SX3-48YC12 Series (starting in EOS-4.25.1F) DCS-7050CX3M-32S Series (starting in EOS-4.25.1F) 7300X3-32C-LC Series (starting in EOS-4.25.1F) 7300X3-48YC4-LC Series (starting in EOS-4.25.1F) Configuration The CLI “sflow interface egress unmodified enable default” is used to modify the default egress sampling setting. Post execution we can see that...
Continue reading →

Support for TI-LFA FRR using IS-IS Segment Routing

Description Topology Independent Fast Reroute, or TI-LFA, uses IS-IS SR to build loop-free alternate paths along the post-convergence path. These loop-free alternates provide fast convergence in the range of sub-50 ms. The PLR ( point of local repair – the router where TI-LFA is configured ) switches to these loop-free alternate backup paths in the event of a link down ( link-protection ) or BFD neighbor down (node-protection) event, protecting traffic destined to IS-IS SR node segments, adjacency segments, and anycast segments while the IGP converges and the post-convergence paths are computed. Anycast segment protection is restricted to those segments...
Continue reading →

Egress Sflow

Description Egress Sflow sampling feature allows to sample unicast packets based on the egress interface. Platform compatibility The following platforms are supported: 7368 Series (starting in EOS-4.24.1F) DCS-7060DX4-32 Series(starting in EOS-4.24.1F) DCS-7060PX4-32 Series (starting in EOS-4.24.1F) Configuration The CLI “sflow interface egress unmodified enable default” is used to modify the default egress sampling setting. Post execution we can see that each interface output has “(Ingress,Egress,Counter)”. It means that ingress, egress sampling is enabled on this interface. The counters are also enabled. switch (config)#sflow interface egress unmodified enable default glc408(s1)(config)#show sflow interfaces Default ingress sFlow configuration for an interface: Enabled Default...
Continue reading →

Transient Capture Buffer (TCB)

Description TCB provides a mechanism to capture information around a MMU( Memory management unit ) drop event EOS support includes: Configuring the TCB to capture using different match conditions. Capture of the dropped packet and associated details are exposed only using gRPC. Platform compatibility This feature is available only on 7050X3, 7050-SX3 single chip platforms. Configuration The configuration consists of setting up the match criteria for capturing the dropped packet (config)#platform trident mmu drop capture drop Specify the drop type enable Enable drop capture history Specify capture history match Match drop on sample Specify sample rate Drop Type can be...
Continue reading →

Fast Poll Counters

Fast poll counters allow for rapid collection of a basic set of MAC counters on supported platforms at a very high frequency. Description The fast poll counters collect the basic MAC counters for all front panel interfaces at a high frequency. The data may be useful input to load balancing, or other resource reallocation algorithms. Most likely this sort of functionality will be performed by a program running on the switch to avoid delays and variability introduced by transferring the data off the switch. The fast poll counters include the following objects: inUcastPkts inMulticastPkts inBroadcastPkts inOctets outUcastPkts outMulticastPkts outBroadcastPkts outOctets...
Continue reading →

BGP UCMP

Description This feature adds support for BGP UCMP in the multi-agent routing protocol model. The TOI for BGP UCMP in the ribd routing protocol model can be found here. Unequal Cost Multi Path (UCMP) for BGP is a mechanism for forwarding traffic from a device for an ECMP route in the ratio of the weights with which the next hops of that route are programmed in the FIB. This is done for BGP by disseminating BGP link bandwidth extended community attribute information with BGP paths such that the receiver device of all such paths for a route programs next hops...
Continue reading →

IPv6 Underlay Support for VXLAN With EVPN Control Plane

Description Several customers have expressed interest in using IPv6 addresses for VXLAN underlay in their Data Centers (DC). Prior to 4.24.1F, EOS only supported IPv4 addresses for VXLAN underlay, i.e., VTEPs were reachable via IPv4 addresses only. This feature enables a VTEP to send VXLAN Encapsulated packets using IPv6 underlay. The following list describes the capabilities of this feature. The feature is designed for a Greenfield deployment environment, i.e., an environment where all VTEPs communicate using IPv6 underlay only. In such deployments, the VTEPs must be configured with an IPv6 address on the VXLAN source interface. And all VTEP-VTEP VXLAN...
Continue reading →

Accumulated IGP Metric (AIGP)

Description Accumulated IGP Metric (AIGP) is an optional non-transitive BGP attribute used to carry an IGP metric with BGP route advertisements. The AIGP attribute is useful for tie-breaking in BGP bestpath selection so that routing decisions can be made on the basis of shortest path/lowest IGP cost path amongst multiple BGP paths. This is particularly applicable in scenarios where a single administration is subdivided into multiple Autonomous Systems (AS) each with similar routing policies and the same IGP in use such that the IGP metric for a route can be propagated usefully between the ASes so as to let receiving...
Continue reading →

Routing control functions

Description Routing control functions (RCF) is a new language that can be used to express BGP route filtering and attribute modification logic in a powerful and programmatic fashion. It supports a new set of workflows to define and apply these functions in EOS. The broader feature set includes: the base RCF language framework support for RCF function application to BGP neighbors support for matching and modifying BGP protocol attributes workflows to define and apply routing control functions CLI commands to provide visibility into operational status As of EOS-4.24.2F release, the following points of application are supported: Point of application Supported...
Continue reading →

4-way L2 ECMP support for EVPN VXLAN All-Active Multihoming 

Description As of EOS 4.22.0F, EVPN all-active multihoming is supported as a standardized redundancy solution.  Redundancy provides not only better fault tolerance but also a way to load balance unicast traffic for better efficiency.  The EVPN VXLAN 4-way L2 ECMP feature allows a Customer Edge (CE) to perform Equal Cost Multi-Path (ECMP) unicast VXLAN switching to a remote CE that is multihomed to at most four Provider Edges (PE).  This feature overcomes the existing 2-way ECMP limitation by providing up to 4-way ECMP. Platform compatibility Platform Independent. (Subject to any and all platform compatibility limitations listed in EVPN Extension to...
Continue reading →

Support for showing last update timestamp in show rib route 

Description The CLI command “show rib route ip[ipv6]” and its sub-commands (e.g. “show rib route ip bgp”) displays information on routes present in the Routing Information Base table for each of the provided routing protocol (e.g. Bgp, OSPF, ISIS, etc.). Additionally to the existing information, the command will now also display the time since a route was last updated in the routing table when in multi-agent mode. This additional information would allow a network operator to check if and when a route was updated in the routing table to correlate possible network issues caused by routing updates (e.g. traffic now...
Continue reading →

Support for static NAT access-list resource sharing

Description Static NAT rules may optionally include an access-list to filter the packets to be translated Static NAT rules and access-list filters are written to hardware via TCAM tables, by default both are stored in the IFP TCAM The number of IFP TCAM entries required is therefore proportional to the number of NAT rules multiplied by the number of filters in the access-list With this feature enabled, the access-list is written to a different TCAM table, the VFP TCAM, instead of the IFP TCAM The number of IFP TCAM entries now remains constant regardless of access-list size; the number of...
Continue reading →

MLAG Unicast Convergence

On a MLAG chassis, MAC addresses learned on individual peers are synced and appropriate interfaces are mapped to these MAC addresses. In case of unexpected events like reloading of one of the peers in the MLAG chassis or flapping of one or more MLAG interfaces, some loss of traffic may be observed. If a MLAG flaps on one peer, learned MAC addresses may have to be remapped to different interfaces such that the reachability is via the other peer in the MLAG domain. Until the remapping of MAC addresses and host routes complete, some amount of traffic may drop and...
Continue reading →

Optimizing hardware utilization for unused (S,G) routes

Description Current EOS PIM sparse mode implementation installs an (S, G) route in the hardware whenever it receives an (S, G) join from the PIM neighbor. Prior to using this feature, devices could have higher hardware utilization because EOS installs all the routes corresponding to the (S, G) joins. This is especially evident if the devices peers with other autonomous system receivers which are administered by an external source. These receivers can send a large number of (S, G) joins for invalid sources leading to exhaustion of hardware resources. With the support of this feature, PIM sparse mode doesn’t install...
Continue reading →

MPLS static tunnel ECMP

Description EOS version 4.24.1F introduces support for specifying multiple vias to form ECMP in MPLS static tunnels. A new configuration mode for an MPLS static tunnel is introduced, where it is possible to enter one or multiple vias for said tunnel. Platform compatibility This is largely a platform-independent feature and therefore will work on all Arista platforms which meet the following requirements: Running a control plane in multi-agent mode. Using a data plane which supports MPLS forwarding. See section Limitations of MPLS encapsulation TOI: https://eos.arista.com/eos-4-15-0f/mpls-encapsulation/ Configuration For CLI configuration details and legacy (“single line”) MPLS static tunnel configuration, please refer...
Continue reading →

Follow

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

Join other followers: