10-09-2018 06:20 PM - edited 10-09-2018 06:21 PM
Hi,
I've looked and looked, and haven't found a satisfactory answer or same specific situation answered. We have a remote with a primary and backup. The remote advertises 10.10.10.0/24 to COLO 1 via primary and to COLO 2 via backup. COLO 1 and COLO 2 are eBGP peered to each other. So COLO 1 is advertising the preferred route to 10.10.10.0/24 to COLO 2. Should COLO 2 advertise the backup 10.10.10.0/24 learned prefix to COLO 1?
Things I'm already aware of:
-BGP slit horizon is for iBGP only.
-I understand COLO 2 should not advertise the route learned from COLO 1 back to COLO 1. I'm referring to advertising a different path with different attributes and next-hop.
My understanding is BGP shouldn't advertise anything it doesn't have installed in it's routing table. So if COLO 2 has already installed the prefix learned from COLO 1 into the routing table, how could it install and advertise a route to the same prefix to COLO 1 that it learned from the remote's backup path? Sure I'm missing something here. Please enlighten.
Solved! Go to Solution.
10-10-2018 10:36 AM - edited 10-10-2018 02:56 PM
I labbed this up and determined COLO 2 will not advertise the remote's backup path to COLO 1. If COLO 1 and COLO 2 were in same BGP update-group, COLO 2 would advertise the primary path it learns from COLO 1 back to COLO 1, but COLO 1 would not show receiving this advertisement. It will not show up in "sh ip bgp neighbor x.x.x.x received-routes" and thus would not show up in "sh ip bgp x.x.x.x" on COLO 1 as an alternate path. Once connection between COLO 1 and remote goes down, COLO 1 will then receive the alternate path from COLO 2 and install it in the routing table.
Please feel free to continue to discuss.
10-10-2018 10:36 AM - edited 10-10-2018 02:56 PM
I labbed this up and determined COLO 2 will not advertise the remote's backup path to COLO 1. If COLO 1 and COLO 2 were in same BGP update-group, COLO 2 would advertise the primary path it learns from COLO 1 back to COLO 1, but COLO 1 would not show receiving this advertisement. It will not show up in "sh ip bgp neighbor x.x.x.x received-routes" and thus would not show up in "sh ip bgp x.x.x.x" on COLO 1 as an alternate path. Once connection between COLO 1 and remote goes down, COLO 1 will then receive the alternate path from COLO 2 and install it in the routing table.
Please feel free to continue to discuss.
10-10-2018 04:14 PM
Hello,
I guess the NLRI gets dropped because the AS_PATH attribute already contains COLO1 AS.
If you have a lab you should be able to see this with a debug bgp updates.
How are prefixes sent from remote to COLO1 and COLO2 ? Is it eBGP?
ADP
10-10-2018 04:39 PM - edited 10-10-2018 04:57 PM
Correct, loop prevention drops it.
BGP(0): 172.16.1.2 rcv UPDATE about 1.1.1.1/32 -- DENIED due to: AS-PATH contains our own AS;
All peerings are eBGP (remote has a primary and backup router which are iBGP of course).
Note: 10.10.10.0/24 was a made up address I used before creating the lab. In the lab I used loopback 1.1.1.1 to simulate 10.10.10.0/24
10-10-2018 04:58 PM
Ok cool, glad that you manage to see the proper debug log. Actually, unless you have set some policies to change med/local_pref COLO2 should prefer the direct router to the remote backup router as the path lenght is shorter..
Remember to mark the post as solved if you found the answers to your question.
Cheers,
ADP
10-10-2018 05:16 PM
I prepended the remote's backup to simulate the production scenario.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide