Multi-homed clients and BGP timers

Fri May 22 23:37:39 UTC 2009

On May 22, 2009, at 5:15 PM, Steve Bertrand wrote:

>>
>> neighbor xxx.xx.xx.x timers 30 60
>>
>> Make sure that this is communicated to your peer as well so that  
>> their timer setting are reflected the same.
>
> Thankfully at this point, we manage all CPE of any clients who peer  
> with
> us, and so far, the clients advertise our own space back to us. I'll  
> go
> back to looking at adequate timer settings for my environment.
>
> All it takes is a quick phone call to the client IT people to inform
> them that a change will be made, and when they prefer I do it (in the
> event something goes south). Also thankfully, I'm within a quick
> walk/drive to these sites, which I've found to be a comfort during the
> last year while I've walked the BGP learning curve (one of my  
> clients in
> particular leaves me with quite a few resources (fibre connections,
> hardware) for me to *test* with between site-and-PoP ;)

Of course, given that the lowest BGP holdtime is selected
when the session is being established, you don't really need
to change the CPE side, all you need to do is make the
change on the network side and reset the session.  And it's
typically a good idea to set the keepalive interval to a
higher frequency when employing lower holdtimes such that
transient keepalive loss (or updates, which act as implicit
keepalives) don't cause any unnecessary instability.

Also, there are usually global values you can set for all
BGP neighbors in most implementations, as well as the per-peer
configuration illustrated above.  The former requires less
configuration bits if you're comfortable with setting the
values globally.

If you want to converge a little fast than BGP holdtimes here
and the fiber link is directly between the routers, you might
look at something akin to Cisco's "bgp fast-external-fallover",
which immediately resets the session if the link layer is
reset or lost.

> While I'm at it, I've got another couple of questions:
>
> - whatever technique you might recommend to reduce the convergence
> throughout the network, can the same principles be applied to iBGP  
> as well?

Depending on your definition of convergence, yes.  If you're
referring to update advertisements as opposed to session or
router failures, though, MRAI tweaks and/or less iBGP hierarchy
might be the way to go.  Then again, there are lots of side
effects with these as well..

> - if I need to down core2, what is the quickest and easiest way to
> ensure that all gear connected to the cores will *quickly* switch to
> preferring core1?

Use your IGP mechanisms akin to IS-IS overload bit or OSPF
stub router (max metric) advertisement.

-danny