• Tag : BGP

 
 

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 →

Support for BGP Peer Flap Damping

Description This document describes the Bgp Peer Flap Damping feature which allows session damping for peers with bfd enabled. BGP takes a long time to detect failures such as failing links due to longer keepalive/hello time-out values. It takes advantage of detecting link failures faster by receiving notification through BFD. This is very useful until we are faced with a link flapping scenario, as it will cause BGP sessions to establish and break down over and over, causing unnecessary traffic loss and churn.  This feature allows delaying establishment of BGP sessions during BFD flapping, which ends up reducing traffic loss...
Continue reading →

RFC 6368 – iBGP as PE-CE Protocol for BGP/MPLS L3 VPNs

Description This is an extension to BGP MPLS VPNs that allows us to use iBGP as the PE-CE protocol. This feature also provides a way to isolate the customer’s network BGP attributes from the SP backbone’s attributes, by saving them into a special attribute called ATTR_SET, code 128. This separation introduces a “route server” model that allows the customer’s BGP path attributes to be stored in the SP backbone along with the VPN-IPv4/v6 paths.   This feature is enabled by configuring the AS number of the PE’s VRF to match the CE’s AS number. This will cause the exported paths...
Continue reading →

Route-Target Membership

Description In a Service Provider (SP) network, a Provider Edge (PE) device learns virtual private network (VPN) paths from remote PEs and uses the Route Target (RT) extended communities carried by those paths to determine which customer Virtual Routing and Forwarding (VRF) the paths should be imported into (from where they can be subsequently advertised to Customer Edge (CE) devices).   In large SP networks, each PE device may learn a significant number of VPN paths even though they might only handle a relatively small number of customer VRFs. In BGP VPN deployments (EVPN, MPLS VPN IPv4 and MPLS VPN...
Continue reading →

Scrubbing large BGP communities

Hi there, I was wondering how to best scrub large BGP communities that match a certain regex. I’ve tried the following: ip large-community-list regexp INFORMATIONAL permit 65000:101:.+ ! route-map SCRUB-COMMUNITIES permit 10 set large-community large-community-list INFORMATIONAL delete But it appears that when running `config-sanity`, it hints the route-map is incorrect: router(config)#show route-map config-sanity route-map SCRUB-COMMUNITIES permit 10

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, RFC 4659 for IPv6 and the use of VPN...
Continue reading →

Arista BGP Redistribute Static Default Route

Hi, I am trying to confirm the mechanism for redistributing a static default route under bgp. In Cisco, in order to redistribute a static default route, “default-information originate” command is required. From what I have seen in the lab, it seems to be that Arsita does not require this command, to redistribute a static default route under bgp. Also, if possible I want to find out the ways in which default routes can be originated in bgp on Arista. I wanted to confirm this behavior in Arista please. Thanks and regards, Abid Ghufran

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 →

Support for deleting link bandwidth extended community without specifying value (“set extcommunity lbw delete”) or with specified AS number (“set extcommunity lbw asn delete”)

Description This feature extends link bandwidth extended community deletion mechanism, which previously always required specifying the exact community value (both BGP AS number and link bandwidth value), to now allow deletion of link bandwidth extended community attribute from path attribute without having to specify exact community value or with just specifying the BGP AS number.  The TOI which describes link bandwidth extended community deletion mechanism as it existed previously can be found here.  Note that this extended support for this mechanism is only supported in the multi-agent routing protocol model. Platform compatibility This feature is platform independent. Configuration The following...
Continue reading →

BGP Override Graceful Restart Time

Description The BGP graceful restart mechanism has a limitation that the graceful restart time cannot exceed 4095 seconds as per the IETF standard (RFC 4724). On a restarting speaker, Arista’s CLI configuration currently allows only up to 3600 seconds. There are scenarios where this limitation poses a challenge in certain customer deployments, and a need is felt for increasing the restart time to a very high value. This feature provides a way of configuring the restart time to be considered by a graceful restart helper, overriding the value sent by the peer in the graceful restart capability. Using this feature,...
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 →

BGP Link State (BGP-LS) Producer for IS-IS LSDB

Description The BGP-LS extension (RFC7752/to be obsoleted by draft-ietf-idr-rfc7752bis) allows IGP (OSPF/IS-IS) link state database information to be injected into BGP. This is typically used in deployments where some external component, (like a controller or Path Computation Engine) can do centralized path computations by learning the entire IGP topology through BGP-LS. The controller can then communicate the computed paths based on the BGP-LS updates to the head end device in the network. The mechanism used by the controller to communicate the computed TE paths is outside the scope of this document. Using BGP-LS instead of an IGP peering with the...
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 DCS-7800R3 DCS-7500R3 DCS-7280R3 Configuration VPWS configuration is made up of two main components on each participating router.  The first...
Continue reading →

L3VPN

Hello, We have a BGP peer with a Cisco device, i need to deploy a L3VPN scenario, the configurations seems very straight forward but for some reason we’re not able to ping from a VRF. We have all the routes coming from our BGP peer to that VRF and we have our Loopback IP add announced to our BGP Peer. When i try to ping it shows the following error ARISTAPPASBR01#ping vrf MGMT 192.168.222.151 source 192.168.222.168 PING 192.168.222.151 (192.168.222.151) from 192.168.222.168 : 72(100) bytes of data. ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg:...
Continue reading →

Discard unimportable VPN paths

Description In a Service Provider network, a Provider Edge (PE) device learns VPN paths from remote PEs and uses the Route Target extended communities carried by those paths to determine which customer VRF(s) the paths should be imported into (from where they can be subsequently advertised to Customer Edge (CE) devices). In large Service Provider networks, each PE device may learn a significant number of VPN paths even though it might only handle a relatively small number of customer VRFs. As a result, such PE devices are really only interested in a subset of the VPN paths that they receive...
Continue reading →

Route Map – Match Resolved Nexthop Support in Multi-Agent

Description This feature adds support for ‘match ip(v6) resolved-next-hop’ 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 nexthop of a route is desired. A route map can be used at various application points to filter routes based on the policy but ‘match ip(v6) resolved-next-hop’ is supported only for specific application points. For such applications when a route map with ‘match ip(v6) resolved-next-hop’ clause is applied, the ip address of the resolved nexthop of each route is matched against the ip-prefixes...
Continue reading →

BGP Enhanced Route Refresh

Description This feature adds support for “Enhanced Route Refresh” capability (RFC7313). An enhanced route refresh is, like a Route Refresh, a complete re-advertisement of the Adj-RIB-Out to a peer (subject to route policies), with additional demarcations added at the beginning and at the end of the Route Refresh. When an initial demarcation (Begin-of-Route-Refresh) is received, all the routes in the AdjRibin are marked as ‘stale’. As soon as an update is received for a route, the ‘stale’ flag is cleared. When eventually the demarcation of the end (End-of-Route-Refresh) is received, the routes that are still marked as ‘stale’ are deleted....
Continue reading →

EVPN route type 5 imported

Hi, We are configuring L3 VPN service using EVPN route type 5. I can see the route in the bgp table of the VRF but in the route table, the destination of the learned prefix is null0. Can someone explain why and how to fix it? I am running vEOS 4.24.0F in our lab. Here is the output of the bgp table in the VRF: AT1-R1#show ip bgp 10.37.4.0/23 vrf CORE BGP routing table information for VRF CORE Router identifier 10.32.25.2, local AS number 65032 BGP routing table entry for 10.37.4.0/23 Paths: 1 available 65037 65370 2.2.2.3 from 1.1.1.103 (2.2.2.3),...
Continue reading →

EVPN route type 5 imported

Hi, We are configuring L3 VPN service using EVPN route type 5. I can see the route in the bgp table of the VRF but in the route table, the destination of the learned prefix is null0. Can someone explain why and how to fix it? I am running vEOS 4.24.0F in our lab. Here is the output of the bgp table in the VRF: AT1-R1#show ip bgp 10.37.4.0/23 vrf CORE BGP routing table information for VRF CORE Router identifier 10.32.25.2, local AS number 65032 BGP routing table entry for 10.37.4.0/23 Paths: 1 available 65037 65370 2.2.2.3 from 1.1.1.103 (2.2.2.3),...
Continue reading →

Follow

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

Join other followers: