BGP Challenge: Merge Autonomous Systems
Here’s a challenge in case you get bored during the Christmas break: merge two networks running BGP (two autonomous systems) without changing anything but the configurations of the routers connecting them (the red BGP session in the diagram). I won’t give you any hints; you can discuss it in the comments or a GitHub discussion.
Hopefully, you won’t have to deal with something similar in real life, but then we know that crazy requirements trump good designs any day of the week.
There's a hint in your topology file.
> Each one has a public AS number.
None of them has a public AS number. They all have a private AS number.
> The only change you can make is a new BGP session between PE2 and PE2.
It should be PE3 there.
To meet your requirements I would configure BGP with something along "neighbor 172.29.42.x local-as 65003 no-prepend" on PE2 respectively "neighbor 172.29.42.x local-as 65000 no-prepend" on PE3 and "neighbor 172.29.42.x next-hop-self" on both PE2 and PE3.
I haven't tested it with your lab tool.
Not sure it would work, it seems that you cannot use local-as with the same value as the AS of the peer:
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13761-39.html
"Local-AS cannot have the local BGP protocol AS number or the AS number of the remote peer."
@Anonymous: thanks a million for the typo report. Hopefully, I fixed everything you mentioned.
As for the "hint in the topology file" -- I had to use that parameter to prevent the automatic configuration of a BGP session between PE2 and PE3. Found a better way to do that.
@chris: You were right (at least for Cisco IOS).
I found a convoluted solution (not sure if it still meets all requirements):
I tested it in my own lab.
I think i got it right ! My only assumption is that the PE/RR peers use next-hop-self knobs, which makes sense at least for PE1 and PE4. An alternative is to advertise the network 172.29.42.0/24 into BGP, which is not forbidden :)
For my lab, i replaced backbone AS by 5000 and 5003 in order to use public AS and it is still OK !
Thanks Ivan for the fun !
x2#sh ip bgp | b Netw Network Next Hop Metric LocPrf Weight Path *> 192.168.100.0 10.1.0.17 0 5003 65100 i *> 192.168.107.0 0.0.0.0 0 32768 i x2#Looks like you lost the customer prefixes (192.168.1.0/24 and 192.168.3.0/24). Have no idea what could cause that as the transit prefixes got across.
Also, did you preserve the next hops of the BGP prefixes across both autonomous systems (the last "at the end of the migration project" bullet)?
Yes, i forgot to configure the customer prefixes. But worst, i do not have the expected next-hops at PE1 and PE4 ! -> Back to study :)
Question: Are we allowed to add static routes or to edit the isis/ospf configuration ?
> Are we allowed to add static routes
I wouldn't (and you don't need them)
> or to edit the isis/ospf configuration
As long as you don't change anything on any other router. However, the real-life answer would probably be " NO!!!"
OK, this time, the lab pass the verifications, and, yes, no static routes and no IGP changes !
next-hop is not modified by the bgp session between PE4 and PE3 :
PE1#sh ip bgp 192.168.3.0 BGP routing table entry for 192.168.3.0/24, version 25 Paths: (1 available, best #1, table default) Advertised to update-groups: 5 Refresh Epoch 1 (5003) 10.0.0.6 (metric 11) from 10.0.0.2 (10.0.0.2) Origin IGP, metric 0, localpref 100, valid, internal, best Community: internet Originator: 10.0.0.3, Cluster list: 10.0.0.2 PE1#and x1/x2 receive exactly 3 prefixes with the correct AS-path :
x1#sh ip bgp | b Netw Network Next Hop Metric LocPrf Weight Path *> 192.168.1.0 10.1.0.1 0 0 5000 i *> 192.168.3.0 10.1.0.1 0 5000 i *> 192.168.100.0 0.0.0.0 0 32768 i *> 192.168.107.0 10.1.0.1 0 5000 65107 i x1#Thanks again Ivan !
I built it with netlab and FRR containers. Here is my solution for configuration: