01-16-2003 02:25 AM - edited 03-02-2019 04:14 AM
Hello all.
What is the default configuration, to be enabled or disabled? Is there a show command with which I can find out if it is enabled or not?
I am trying to find some documentation on this command but on CCO there are only a few lines describing its operation..
Any comments about its use..?
Solved! Go to Solution.
01-16-2003 03:51 AM
By default it is enabled.
The command is documented in some depth under RIPE-229 (RIPE Routing-WG Recommendations for Coordinated Route-flap Damping Parameters):
http://www.ripe.net/ripe/docs/routeflap-damping.html
3.3 Tuning External BGP Failover
Cisco IOS by default implements a feature known as "fast-external-fallover".
This feature immediately clears the BGP session whenever the line-protocol
to the external neighbour goes down. This feature is desirable so that
there is fast failover in case of link failures - the router can withdraw
paths as soon as the line goes down, rather than waiting for BGP keepalive
timers. The drawback of this, however, is that circuits which are prone
to unreliability will cause BGP sessions to drop and return (i.e. flap),
resulting in instability within the ISP's network, and the potential for
flap damping by upstreams or peers.
If fast-external-fallover is turned off, the BGP sessions will survive
these short line-flaps as it will use the longer BGP keepalive/hold timers
(default 60/180 seconds). The drawback of turning it off - and currently
it has to be done for a whole router and can not be selected peer-by-peer -
is that the switch-over to an alternative path will take longer.
We recommend turning off fast-external-fallover whenever possible:
!
router bgp 65501
no bgp fast-external-fallover
!
Alternatively it might be considered acceptable to retain
"fast-external-fallover" and to turn off "interface keepalives" on unreliable
circuits to overcome the immediate BGP resets on any significant CRC
error period.
Another potentially more satisfactory alternative would be to use a shorter
per-neighbour BGP keepalive timer that has to be applied on both routers
(e.g. 10 seconds that gives a hold-timer of 30 seconds):
!
router bgp 65501
neighbor w.x.y.z timers 10
!
In JunOS, this instability can be avoided by using the following
commands:
- out-delay
group, or an individual peer. This implements a delay between when the
routing table receives the routing information and when the
information is exported to BGP peers.
- hold-time sec; applicable to all BGP peers, all peers in a group or an
individual peer. This allows a shorter per neighbor holdtimer to be
applied on both routers (30 sec will gives keepalives of 10 sec).
- hold-time msec; to be configured in the router interfaces where the BGP
peering will be established. This delays the propagation of the
interfaces-down events to the routing protocol.
01-16-2003 03:51 AM
By default it is enabled.
The command is documented in some depth under RIPE-229 (RIPE Routing-WG Recommendations for Coordinated Route-flap Damping Parameters):
http://www.ripe.net/ripe/docs/routeflap-damping.html
3.3 Tuning External BGP Failover
Cisco IOS by default implements a feature known as "fast-external-fallover".
This feature immediately clears the BGP session whenever the line-protocol
to the external neighbour goes down. This feature is desirable so that
there is fast failover in case of link failures - the router can withdraw
paths as soon as the line goes down, rather than waiting for BGP keepalive
timers. The drawback of this, however, is that circuits which are prone
to unreliability will cause BGP sessions to drop and return (i.e. flap),
resulting in instability within the ISP's network, and the potential for
flap damping by upstreams or peers.
If fast-external-fallover is turned off, the BGP sessions will survive
these short line-flaps as it will use the longer BGP keepalive/hold timers
(default 60/180 seconds). The drawback of turning it off - and currently
it has to be done for a whole router and can not be selected peer-by-peer -
is that the switch-over to an alternative path will take longer.
We recommend turning off fast-external-fallover whenever possible:
!
router bgp 65501
no bgp fast-external-fallover
!
Alternatively it might be considered acceptable to retain
"fast-external-fallover" and to turn off "interface keepalives" on unreliable
circuits to overcome the immediate BGP resets on any significant CRC
error period.
Another potentially more satisfactory alternative would be to use a shorter
per-neighbour BGP keepalive timer that has to be applied on both routers
(e.g. 10 seconds that gives a hold-timer of 30 seconds):
!
router bgp 65501
neighbor w.x.y.z timers 10
!
In JunOS, this instability can be avoided by using the following
commands:
- out-delay
group, or an individual peer. This implements a delay between when the
routing table receives the routing information and when the
information is exported to BGP peers.
- hold-time sec; applicable to all BGP peers, all peers in a group or an
individual peer. This allows a shorter per neighbor holdtimer to be
applied on both routers (30 sec will gives keepalives of 10 sec).
- hold-time msec; to be configured in the router interfaces where the BGP
peering will be established. This delays the propagation of the
interfaces-down events to the routing protocol.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide