Ben Black wrote:
The key to this is that the administrative preference in question has domain
scope. Assuming you are correctly implementing iBGP, whether with a full
mesh, reflectors, or confederations, and assuming consistent announcements
from external route originators, then you can't make a loop because the
same policy is in effect for all the routers in the AS.
You will not form a *persistent* loop or black-hole. However,
as there is invariably some degree of propagation delay among iBGP
speakers, particularly in a large network, there can be short-lived
loops or black-holes when converging upon routing changes.
Sean.
Absolutely, there will be transient loops created in common situations
as the network converges. However, this problem is not a flaw in BGP, per
se. At least, not any moreso than other common protocols which suffer
from the same issue.
Without using some sort of (probably complex) global, distributed
synchronization mechanism to guarantee a consistent, loop-free topology,
I suspect transient failures from loops and blackholes during convergence
are soemthing we will just have to live with.
I believe the question regarding the use, or lack thereof, of the AS_PATH
length in tie breaking was whether persistent loops would be created. I
still think the answer is "No".
Ben
Best guess approximation? Say not more than 1 minute per router (* N
router hops between 1 edge of network and the other?) typically more like
10 seconds on moderately loaded routers/links? Assuming you aren't
re-establishing each iBGP session from scratch and only receiving an
update from 1 connection (peer or customer)?
Does that sound reasonable?
-Deepak.