Losing BGP due to 1 errored second

[admin_2]

On a DS3 link I am seeing an occasional errored second on the physical layer due to 50 or 60 ms switches in the transport network. These errors cause the BGP to go down and takes several minutes to re-converge. What this means is I am experiencing a several minute outage due to a transport switch which I believe should not have such a dramatic consequence. Why would a single errored second cause the loss of BGP? and Is it possible to configure BGP in such a way as to be more tolerant of switches in the transport network? Thanks.

[ruwhite]

There are a couple of possibilities...

First, is the interface failing? If so, then BGP might be seeing the interface failure, and taking the peer reachable through that interface down. Is this an eBGP peer, or an iBGP peer? If it's an iBGP peer, the session shouldn't be failing until the hold timer expires for the peer--unless the peer is directly connected, and the interface fails. If it's an eBGP peer, we shouldn't be using fast fallover, and dropping the peering session if the interface fails, unless you have fast fallover configured.

If the interface isn't failing, make certain you have log-neighbor changes configured, and see what the log messages say about why the peer is failing. It could be a mangled packet causing one of the two peers to think the other one has sent out some bad information, which could reset the session on a notification message.

Could you tell us if the interface is failing or not, if the peers are eBGP or iBGP, and finally, turn on neighbor logging and tell us what you see there?

:-)

Russ.W

[kschafer]

If the physical DS3 interface is failing, all the BGP routes learned via that interface will be withdrawn immediately.

From your description of what you are experiencing, it sounds like the interface itself is flapping between UP/DOWN.

= K