Devang and Danny,

Thanks. What about my first question: when a leased line goes down between the two peer the does (customer and ISP), does the ISP BGP peer immediately notify other peers that the route is unavailable or does it wait for the holdtimer to expire?

thanks,

Arana

Yes it will has to wait till the holdtimer expire as BGP peer by default not sending the notification of tearing down a BGP session... but you can configure to detect the fast tearing dwon of session...

Hi,

actually there are several mechanisms and timers involved.

If the link doen event can not be detected, the BGP holdtime determines when the neighbor is missing.

Otherwise the link down event will immediately lead to a neighbor down event.

There is another timer involved, before sending the update. When an internal neighbor was sent an update, for the next 5 seconds no other update will be sent. As this usually is a route reflector, it might take another 5 seconds to reach all other BGP speakers in the ISP AS.

For external BGP the update timer is 30 sec by default, so it might take a couple of minutes to be propagated through the internet.

Hope this helps!

Regards, Martin

Hi Martin,

Let me try to see if I got the correct understanding.

- If the link down event can be detected (which is my situation) it will immediate see this as neighbour down and will immediately send out an update to its RR. This means that they do not wait for the holdtime to expire.

- The RR will then take anohter 5 sec to send out updates to their clients.

- Then the ABR does not send the update immediately to another AS when if receives the route withdraw information for the RR. It actually waits for 30sec update interval to send the updates.

So if the ABR's update timer is due at 20s (say default is 30s and 10s has already passed)to another AS. The total time will be 5s+20s = 25s to the next AS. So the propogation to the rest of the rest of the internet will be few minutes.

Thanks,

Arana

Hi Arana,

You got it right, except for the fact, that usually there are two internal BGP sessions involved, one to the RR and one from the RR to the ABR, which could prolong the update propagation further.

Besides, an exact upper limit could only be given, if the timer values in the ISP network would be known. Those timers are all configurable and might have been adjusted to smaller values for faster convergence or larger values to lower CPU load.

Another point to consider: the behaviour after link down detection is also configurable (fast-external-fallover). If it is turned off, to avoid a loss of the BGP session in case there is only a short line flap the holdtime has to expire.

One last aspect for now: in case you have provider assigned IP addresses your network is likely part of an aggregate route announced to the internet by the ISP. Then there would be no external update through ABRs required.

You can check the exitence of your network in the internet by telneting to a Route server and use "show ip bgp ".

Route servers can be found f.e. at

http://www.traceroute.org following the link "Route Servers".

Hope this helps!

Regards, Martin

Hi Martin,

Thank you for the verificatin and additional insight. As always very greatful to have you in these discussions.

Today this set up is using dual link to a single service provider using a private AS/Public IP given by the ISP. So I probably will not able to see the changes on the route servers, but certainly this is a great tool when it gets its own AS.

Hi Mohamed,

Thanks. Today I am only taking default route for this set up on both links so the timer is 15/45. When we start taking full routes we will use the default.

Thanks,

Arana