I had an issue at work with a DS3 mysteriously bouncing. We never saw the circuit actually drop (nor any errors) but the BGP peering would sporadically drop. After one of the engineers “solved” the problem by having AT&T set their BGP timers to match ours (see this QoD for an explanation of why that did not work) the issue came to me. I suggested that we disable bgp fast-external-fallover and see if that at least kept the peering nailed up. That worked! We later found out that the site had taken a lightning strike a couple of weeks ago. We had a vendor meet with Cisco, AT&T, the cabling vendor, and the LEC the next day. MAGICALLY the issue “cleared while testing” once the LEC looked at the circuit. 
Anyhoo…by default bgp fast-external-fallover is enabled. This is generally a good thing as it will bring down a BGP peering if a directly connected link goes down. No need to wait out your 3 keepalives. In our case, their was some sporadic issue that “blinked” out the circuit (I suspect a punch-drunk repeater or some CO equipment) very briefly. Our router would then bring down the BGP peering and then re-establish it. By configuring ‘no bgp fast-external-fallover’ under the BGP process, we were able to keep the BGP peering up.
Usage Guidelines
The bgp fast-external-fallover command is used to disable or enable fast external fallover for BGP peering sessions with directly connected external peers. The session is immediately reset if link goes down. Only directly connected peering sessions are supported.
If BGP fast external fallover is disabled, the BGP routing process will wait until the default hold timer expires (3 keepalives) to reset the peering session. BGP fast external fallover can also be configured on a per-interface basis using the ip bgp fast-external-fallover interface configuration command.
