eBGP: advertise same prefix from different path to eBGP neighor that I am learning prefix from already?

[Larry Sullivan]

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. 

[Larry Sullivan · Accepted solution]

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.

[ADP_89]

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

[Larry Sullivan]

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

[ADP_89]

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

[Larry Sullivan]

I prepended the remote's backup to simulate the production scenario.