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