• Tag : BGP

 
 

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 →

maintenance mode bgp

Hello. I am trying to set up maintenance mode in order to do the following procedure: Gracefully shut down all eBGP Peers. I have configured the following: maintenance profile bgp ebgp-profile initiator route-map eBGP-gshut inout profile unit ebgp-profile on-boot duration 300 unit ebgp-unit group bgp ebgp-Group profile unit ebgp-profile route-map ebgp-gshut permit 10 set local-preference 0 set community GSHUT additive group bgp ebgp-group neighbor 149.6.155.217 neighbor 213.242.115.13 When I run show maintenance groups, the output is the following: Bgp Group: ebgp-group Origin: User Configured Neighbors: Ipv4 Peers: 149.6.155.217, 213.242.115.13 Bgp Profile: Default Vrf: default Units: ebgp-unit I would expect the...
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 (also known as adjacency or FEC). 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...
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 →

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 →

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 →

Follow

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

Join other followers: