Re: AS_PATH length and route selection (WAS: Strange BGP announcement)
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 On Wed, Nov 18, 1998 at 02:30:59PM -0800, Sean M. Doran wrote:
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.
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. On Wed, 18 Nov 1998, Sean M. Doran wrote:
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.
participants (3)
-
Ben Black -
Deepak Jain -
Sean M. Doran