Bridging the gap between CCIE RS and SP

February 1, 2010

BGP fast-external-fallover – Common confusion

Filed under: CCIE, CCIE SP — 21500 @ 1:01 pm

Most will know the feature and what it does, but to recap the process level command:

R5(config-router)#bgp fast-external-fallover

R5(config-router)#no bgp fast-external-fallover

This feature will enable fast fallover in the event of a link failure for all neighbors peers. In layman terms shutdown the bgp neighbor as soon as the interface reset is detected and not wait for the holddown timer to expire.

Then the interface command:

R5(config-if)#ip bgp fast-external-fallover permit

R5(config-if)#ip bgp fast-external-fallover deny

This is used to overwrite the process level command. Therefore if the feature is enabled under the bgp process, which is on by default, and a specific client interface is flapping frequently, the interface level command can be used to keep the client peer from flapping due to the fast-fallover and prevent upstream peers from dampening the client routes. Fast-fallover is important in multihomed scenarios where it is useful to shut the neighbor as soon as possible in order to avoid packet drops.

But the real reason for this post is that I have seen this a couple of times configured in both (RS) INE and (SP) IPX workbooks with the incorrect interface level command:

R5(config-if)#no ip bgp fast-external-fallover

This will have no effect, except removing previous fast-fallover config. Beware of this common confusion between the two syntaxes. The correct interface level configuration is to use permit or deny.

1 Comment »

  1. Very true. Good Article.
    Another command often confused with the above commands is the per-neighbor fast peering option:
    router bgp {asn}
    neighbor {IP} fall-over [bfd | route-map]

    Good luck for monday.

    Comment by ruhann — February 5, 2010 @ 7:53 am

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress