If you look at the BGP best path algorithm and take a look at all of the attributes that are chosen and examined, you will find that the tie breaker in this particular case for R3 to learn about R1’s loopback from R2 and not from R5 is the “eBGP over iBGP routes” attribute. Take a look at the topology once again:
R3 will learn about 11.11.11.11 from both R2 and R5, but will prefer the route learned via R2 because it was learned from an eBGP peer rather than an iBGP peer. Even within a confederation, BGP routers prefer routes learned from other sub-ASes rather than those learned from within their own sub-AS. All the previous attributes would be equal. So you never get o the “higher router ID” attribute.
Thanks for the answer. That’s what I thought initially. But considering this sentence in the document:
“R5 has two options: it learns about this route from R3 (confed-internal) or R4 (confed-external). The BGP best path selection algorithm has no distinction between confederation external or internal. In this case, the path was chosen based on the lowest router ID.”
I thought that BGP confederation changed that somehow. Would you care to explain why R5 would prefer a prefix from R3 (iBGP) rather than from R4 (eBGP) when you just stated that eBGP is always preferred over iBGP even in BGP confederation?
You’re absolutely correct, my apologies. Indeed, when dealing with confederations, the best path algorithm does not prefer routes learned from BGP peers in another sub-AS over those learned from BGP peers in the same sub-AS.
After thinking about this a little bit more, I realized the the reason R3 doesn’t learn about the loopback of R1 via R5 is because of the iBGP split horizon rule. Note that R5 has learned about the 11.11.11.11/32 network from R3. Thus, it will not re-advertise that route back to R3. So R3 never gets informed about this network from R5, thus it only has the route via R2 in its BGP table. Does that make sense?
