• Tag : BGP

 
 

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 →

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.1F release, the following points of application are supported: Inbound BGP neighbor...
Continue reading →

BGP best paths and best ECMP paths counters

Description It is often useful to know on a per AFI/SAFI basis, the number of paths that have been selected from a peer as best paths. For example, we may have configured a policy to ensure that paths from a particular peer are most preferred, and it would be useful to have a quick way of confirming this. Similarly, we may need to divert traffic away from a peer, and we may use a policy to reduce the preference of paths received from the peer to accomplish this. This feature provides an easy way to know the number of paths/prefixes...
Continue reading →

Simultaneous negotiation of IPv6 unicast and 6PE capabilities in BGP

Support for negotiating and receiving IPv6 unicast and IPv6 labeled-unicast (6PE) updates from a BGP peer. Description Some deployments require IPv6 unicast and 6PE capabilities to be negotiated. An example of one such deployment involves learning routes from a route reflector which itself is getting both 6PE and IPv6 unicast routes. The goal of this feature is to add support for configuring both 6PE and IPv6 unicast on a single peer, which were previously mutually exclusive. Platform compatibility This feature would work on all platforms supporting 6PE. Configuration A new command is now available to configure both 6PE and ipv6-unicast:...
Continue reading →

The BGP Best-Path Selection Algorithm

Description BGP routing information often contains more than one path to the same destination network. The BGP best-path selection algorithm determines which of these paths should be considered as the best path to that network. The best BGP path (as chosen by the algorithm) is then used as follows: If it is also chosen as the RIB winner (i.e. the winning path from among any other non-BGP paths), it will be installed in the RIB and used to forward traffic to that network. With the multi-agent routing protocol model since EOS-4.23.2, RIB installation can be skipped by using the “bgp...
Continue reading →

EVPN MPLS Virtual Private Wire Service (VPWS)

Description EVPN MPLS VPWS (RFC 8214) provides the ability to forward customer traffic to / from a given attachment circuit (AC) without any MAC lookup / learning.  The basic advantage of VPWS over an L2 EVPN is the reduced control plane signalling due to not exchanging MAC address information.  In contrast to LDP pseudowires, EVPN MPLS VPWS uses BGP for signalling.  Port based and VLAN based services are supported. VLAN Based Service Port Based Service Platform compatibility DCS-7280R DCS-7280R2 DCS-7500R DCS-7500R2 Configuration VPWS configuration is made up of two main components on each participating router.  The first is the patch...
Continue reading →

Support to Restrict the Number of Bgp Ecmp Next Hops in Multi-Agent Protocol Model

Description In the ribd routing protocol model, the “maximum-paths … ecmp …” command allows restricting the number of BGP paths and the number of vias in the ECMP FEC respectively. In the multi-agent protocol model, a “maximum-paths” value of greater than 1 enabled the formation of ECMP. However, the number of BGP paths or the number of vias in the FEC were not constrained by the configured value. With the 4.24.0F EOS release, the multi-agent protocol model supports restricting the number of BGP paths and ECMP FEC size based on the BGP configuration. Platform Compatibility Supported on all platforms. Configuration...
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 →

Standalone BGP Origin Validation with RPKI

The Border Gateway Protocol (BGP) is the primary routing protocol used between the tens of thousands of different networks that make up the global Internet. Unfortunately, the original conception of BGP presumed a fundamental level of trust between all of the participating networks, which has repeatedly permitted both major and minor outages across the Internet due to networks accepting incorrect routing information. Either deliberately or accidentally, networks are able to advertise more specific prefix routing information for address space controlled by other networks to their peers over BGP, which causes that traffic to flow through their network instead of to...
Continue reading →

BGP Send-Community Global Setting

Description This change adds a global toggle to BGP communities that allow for community sharing to be enabled/disabled for all BGP neighbors. Prior to this change, community sharing for bgp peers had to be enabled on a per peer or per peer-group basis.  A flattened state of the send-community is computed and applied to each peer. This flattened state is a function of the send-community state at a peer level (for that peer), peer-group level (for a group containing that peer) and global level. This flattened state prioritizes at the peer level over the peer-group level over the global level....
Continue reading →

Allow resolution over BGP aggregates

Description Adds the ability to revert to previous behavior where BGP and static routes could resolve over BGP aggregates (when the aggregate is the longest-prefix-match (LPM) for the route) and be installed in the FIB. Provided for backward compatibility purposes. Platform compatibility Supported on all platforms. Configuration To enable this backward compatibility, run: (config)# router general (config-router-general)# next-hops resolution bgp aggregates allowed To disable, run: (config)# router general (config-router-general)# no next-hops resolution bgp aggregates allowed

Configurations and Optimizations for Internet Edge Routing

Introduction For many years, network deployments for enterprise Internet edge environments have consisted of dedicated routing platforms and a switching or aggregation layer to distribute this to various network zones.  With the advances in merchant silicon forwarding engines and the software expertise put into Arista’s Extensible Operating System (EOS), we can now fully replace this legacy architecture with a collapsed routing and switching layer using Arista R Series platforms.  Arista R Series platforms allow for holding a full copy of the Internet routing table for both IPv4 and IPv6 in hardware (the Forwarding Information Base, or FIB) with plenty of...
Continue reading →

The BGP best-path selection algorithm

Description BGP routing information often contains more than one path to the same destination network. The BGP best-path selection algorithm determines which of these paths should be considered as the best path to that network. If the best BGP path (as chosen by the algorithm) is also chosen as the winning path from among the other non-BGP paths (if any), it will be installed in the RIB and used to forward traffic to that network. The best BGP path will also be the path that is subsequently advertised to any BGP neighbors. BGP best-path steps When comparing any two paths...
Continue reading →

Redistribution of leaked routes into BGP

This feature allows routes that were leaked from one VRF (the source VRF) into another VRF (the destination VRF) – using the VrfLeak Agent to be redistributed into BGP for advertising to VRF-lite / Option A BGP peers.  Description As of 4.23.2F we support leaked routes learned (in the source VRF) via the following protocols: Connected Static ISIS OSPF/ OSPFv3 BGP Into the following AFI/SAFI’s within BGP: IPv4 Unicast IPv6 Unicast Platform compatibility This feature is supported on all platforms. Configuration The feature is available when the protocol agent model is multi-agent. The following command puts the system in multi-agent...
Continue reading →

BGP In-place Adjacency Replace (IAR)

Introduction A typical BGP router has a large number of routes compared to the number of nexthops. Under certain circumstances, mostly in highly symmetric CLOS networks, when all routes in RIB move from “Adjacency A” → “Adjacency B” as a result of a single (or a series of near simultaneous) events – we update “Adjacency A” “in-place” to refer to “Adjacency B” contents – thereby avoiding the need to change every route to refer to a new Adjacency. This operation of identifying and updating adjacency in-place is called – Inplace Adjacency Replace (IAR). The goal of IAR operation is to...
Continue reading →

Route Map – Match Interface Support in Multi-Agent

Description This feature adds support for ‘match interface’ clause under route-map config for Bgp policy application in multi-agent model. This feature may be used when a policy to filter routes on the basis of the resolved interface of a route is desired. A route-map can be used at various application points to filter routes based on the policy but ‘match interface’ is supported  only for specific application points. For such applications when a route-map with ‘match interface’ clause is applied, the interface of the resolved nexthop of each route is matched against the interface specified in route-map and the route...
Continue reading →

RFC 4364 BGP/MPLS L3 VPN

Description This feature allows a Service Provider (SP) or an Enterprise to provide the service of interconnecting geographically dispersed customer sites. Such a service can be provided to multiple customers over the common network backbone infrastructure of the Service Provider, while:   Maintaining privacy of each customer Allowing for overlapping IP addresses amongst customers Having constrained route distribution – i.e. only those routers in the Service Provider’s network that need the customer routes, have them. And the above is achieved through the extensions to BGP as defined in RFC 4364 for IPv4 and RFC 4659 for IPv6 and the use...
Continue reading →

RFC 5549: IPv4 unicast NLRI with IPv6 next-hop support

Description This feature provides support for advertising IPv4 unicast Network Layer Reachability Information (NLRI) with IPv6 next-hops over IPv6 peering sessions described as the Extended Next Hop Encoding capability in RFC5549. Extended Next Hop Encoding capability can be supported for IPv4 unicast, IPv4 Labeled Unicast, and IPv4 VPN address and sub-address families (1/1, 1/4, 1/128 respectively). The feature enables: Negotiating Extended Next Hop Encoding capability for IPv4 unicast NLRI advertisements over IPv6 BGP sessions. In multi-agent mode IPv4 iBGP sessions are also supported. Encoding of the next-hop in the UPDATE message that allows determination of the next-hop’s address family. This...
Continue reading →

Migrating from legacy DC design to EVPN VXLAN Fabric

Introduction This document is intended to provide a reference of steps and sequence followed for:  (1) migrating a legacy 3-tier L2 network to EVPN based VXLAN environment using Leaf & Spine design (2) migrating an L2 Leaf & Spine network with VXLAN using CVX as the control plane to EVPN based control plane (3) migrating an L2 Leaf & Spine network with VXLAN using static VXLAN as the control plane to EVPN based control plane. Scope The key objective of this report is to migrate a Layer 2 datacenter to EVPN based VXLAN using Leaf & Spine (L3LS) solution for...
Continue reading →

Per Address Family BGP Missing Policy Action for Multi-agent Model

Description Prior to EOS-4.23.2F, BGP missing policy action configuration is a global BGP configuration that, when set to deny, will deny/reject import (and/or export) of all routes when route-map is missing or misconfigured and it only applies to IPv4 Unicast and IPv6 Unicast address family. Now for multi-agent routing protocol model (single-agent model remains unchanged), the missing policy action can be applied to all address families by specifying “address-family all” in the existing missing policy configuration. With “address-family all” enabled, missing-policy config will apply to all AFs. Note that “address-family all” applies a “loose” behavior that misconfigured route map in...
Continue reading →

Follow

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

Join other followers: