Yesterday, on a conference call with the ops guys at work, I learned something new about BGP. This is noteworthy for someone who has a personal ASN that's almost old enough to drink, and certainly won't be news to Avi or anyone else who's written an actual BGP implementation, but still a little eye-opener to me.

The nugget of truth was that when explicitly configuring BGP timers (i.e. not going with the standard 30/90), unlike OSPF (or I think ISIS) the numbers on opposite ends of the peer don't have to match. There's actually a negotiation phase and the lower (faster) timer configuration will win.

Wes points out that one ought to configure a minimum so as to guard against over-enthusiastic customers who are looking for a fast-failover substitute for the most unfortunately named protocol in the world. Over-fast timers can result in the session dropping whenever a CPU gets a little busy particularly if your PE is old stuff with a weak control plane. A few peers configured this way can result in a death spiral where things can never come back up all the way.

As my late friend Randy used to say, "sometimes a teacher, always a student".

Update 20141031: The difference between theory and practice is that in theory they're the same thing whilst in practice they're not. You want the timer configs on both ends to match or you'll be writing TMs and MOPs to fix the mess. Trust me on this.