Most BGP implementations I’ve labored with break up the neighbor BGP configuration into two elements:
- International configuration that creates the transport session
- Handle household configuration that prompts the tackle household throughout a configured transport session, and adjustments the parameters that have an effect on BGP updates
AS numbers, supply interfaces, peer IPv4/IPv6 addresses, and passwords clearly belong to the worldwide neighbor configuration.
BGP insurance policies like route maps and prefix lists clearly belong to the tackle household configuration, however what about issues like route reflector shoppers and subsequent hop processing?
One may argue that these parameters belong to the tackle household configuration. In spite of everything, they have an effect on BGP updates inside an tackle household. One may also argue that it doesn’t make sense to have completely different route reflector topologies for particular person tackle households. That may have been the argument that brought on Arista to implement neighbor route-reflector-client and neighbor next-hop-self instructions on the worldwide BGP configuration stage. I’d don’t have any drawback with that if solely they have been applied constantly.
As I described in April 2022, Arista EOS takes next-hop-self a bit too actually – that choice additionally adjustments the following hops on mirrored routes. No drawback, one also can use bgp route-reflector preserve-attributes command to repair it. The “solely” drawback: that command doesn’t work on all tackle households, and there’s no method to repair that.
Listed below are the related elements of the worldwide BGP configuration netlab created after I began testing the leaf-and-spine EVPN topology with Arista EOS:
BGP session topology
Related elements of Arista EOS route reflector configuration created with netlab launch 1.3
router bgp 65000
bgp advertise-inactive
bgp log-neighbor-changes
no bgp default ipv4-unicast
no bgp default ipv6-unicast
router-id 10.0.0.7
bgp cluster-id 10.0.0.7
bgp route-reflector preserve-attributes
!
neighbor 10.0.0.5 remote-as 65000
neighbor 10.0.0.5 description l1
neighbor 10.0.0.5 update-source Loopback0
neighbor 10.0.0.5 next-hop-self
neighbor 10.0.0.5 route-reflector-client
neighbor 10.0.0.5 send-community commonplace prolonged
!
neighbor 10.0.0.6 remote-as 65000
neighbor 10.0.0.6 description l2
neighbor 10.0.0.6 update-source Loopback0
neighbor 10.0.0.6 next-hop-self
neighbor 10.0.0.6 route-reflector-client
neighbor 10.0.0.6 send-community commonplace prolonged
To this point so good. IPv4 works, subsequent hops are right. Now for the EVPN half:
EVPN BGP configuration on Arista EOS route reflector
router bgp 65000
address-family evpn
!
neighbor 10.0.0.5 activate
neighbor 10.0.0.6 activate
neighbor 10.0.0.8 activate
Seems to be easy, proper? The one drawback is it doesn’t work – no routes are mirrored between L1 and L2. I attempted all kinds of issues, and the one method to get EVPN route reflector to work was to take away the neighbor next-hop-self from the IBGP neighbors.
It appears to be like like EVPN BGP AF processing ignores bgp route-reflector preserve-attributes setting, and because the change within the subsequent hop would carry the visitors to the backbone change (which didn’t have the VXLAN interfaces to deal with it), the backbone change determined to not ship the updates.
Curiously, you’ll be able to configure neighbor next-hop-unchanged inside the EVPN tackle household, nevertheless it solely applies to EBGP neighbors (you want that whenever you imagine in constructing EBGP-only information facilities). It doesn’t have an effect on the neighbor next-hop-self world setting.
OK, so I gave up and eliminated all of the neighbor next-hop-self instructions from the worldwide configuration. Hastily, EVPN labored like a allure, however after all the take a look at IBGP+EBGP topology wouldn’t work as a result of the following hops of some routes (EBGP neighbors) wouldn’t be reachable.
In the long run, I used to be compelled to make use of the BGP equal of the Swiss Military knife: a route map that units the following hop (netlab commit), ensuing within the following configuration:
Last Arista EOS BGP IPv4 configuration
route-map next-hop-self-ipv4 allow 10
match route-type exterior
set ip next-hop peer-address
!
route-map next-hop-self-ipv4 allow 20
!
address-family ipv4
!
community 10.0.0.7/32
!
neighbor 10.0.0.5 activate
neighbor 10.0.0.5 route-map next-hop-self-ipv4 out
neighbor 10.0.0.6 activate
neighbor 10.0.0.6 route-map next-hop-self-ipv4 out
Extra Info
- Wish to reproduce my assessments? Set up netlab and use Arista cEOS containers.
- Wish to study extra about EVPN? There’s in all probability no higher supply than EVPN Deep Dive webinar with Dinesh Dutt (the creator of BGP within the Information Middle), Lukas Krattiger (the creator of Constructing Information Facilities with VXLAN BGP EVPN), and Krzysztof Grzegorz Szarkowicz (the creator of MPLS within the SDN Period)
