Revert "doc: user doc for route-flap dampening commands"

This reverts commit 54b34709f8.

Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
This commit is contained in:
Igor Ryzhov 2021-08-02 13:17:42 +03:00
parent c499bf64d0
commit a5c1e10386

View File

@ -515,54 +515,28 @@ Disable checking if nexthop is connected on EBGP sessions
Route Flap Dampening
--------------------
.. clicmd:: bgp dampening [(1-45) [(1-20000) (1-20000) (1-255)]]
.. clicmd:: bgp dampening (1-45) (1-20000) (1-20000) (1-255)
This command enables (with optionally specified dampening parameters) or
disables route-flap dampening for all routes of a BGP instance.
.. clicmd:: neighbor PEER dampening [(1-45) [(1-20000) (1-20000) (1-255)]]
This command enables (with optionally specified dampening parameters) or
disables route-flap dampening for all routes learned from a BGP peer.
.. clicmd:: neighbor GROUP dampening [(1-45) [(1-20000) (1-20000) (1-255)]]
This command enables (with optionally specified dampening parameters) or
disables route-flap dampening for all routes learned from peers of a peer
group.
This command enables BGP route-flap dampening and specifies dampening parameters.
half-life
Half-life time for the penalty in minutes (default value: 15).
Half-life time for the penalty
reuse-threshold
Value to start reusing a route (default value: 750).
Value to start reusing a route
suppress-threshold
Value to start suppressing a route (default value: 2000).
Value to start suppressing a route
max-suppress
Maximum duration to suppress a stable route in minutes (default value:
60).
Maximum duration to suppress a stable route
The route-flap damping algorithm is compatible with :rfc:`2439`. The use of
these commands is not recommended nowadays.
this command is not recommended nowadays.
At the moment, route-flap dampening is not working per VRF and is working only
for IPv4 unicast and multicast.
With different parameter sets configurable for BGP instances, peer groups and
peers, the active dampening profile for a route is chosen on the fly,
allowing for various changes in configuration (i.e. peer group memberships)
during runtime. The parameter sets are taking precedence in the following
order:
1. Peer
2. Peer group
3. BGP instance
The negating commands do not allow to exclude a peer/peer group from a peer
group/BGP instances configuration.
.. seealso::
https://www.ripe.net/publications/docs/ripe-378