Route Dampening
Route instability is reflected by route flapping. That is, a route in a routing table disappears and reappears frequently.
A route is added to the routing table, and then is withdrawn. This process is called one route flapping.
When route flapping occurs, a device sends a routing update to the neighbors. The devices that receive the routing update need to recalculate routes and modify routing tables. Frequent route flapping consumes lots of bandwidths and CPU resources, and even affects the normal operation of a network.
Route dampening solves the problem of route instability. In most situations, BGP is applied to complex networks where routes change frequently. To avoid the impact of frequent route flapping, BGP adopts route dampening to suppress unstable routes.
BGP dampening measures the stability of a route by using a penalty value. The greater the penalty value, the more unstable the route. Each time route flapping occurs (route flapping refers to that a route changes from active to inactive), BGP adds a certain penalty value (1000) to this route. When the penalty value of a route exceeds the suppression threshold, the route is suppressed. As a result, BGP does not add the route to the routing table, or advertise any Update message to BGP peers.
The penalty value of the suppressed route decreases to half after a certain period. This period is called half life. When the penalty value decreases to the reuse value, the route is reusable and is added to the routing table. At the same time, BGP advertises an Update message to BGP peers. The penalty value, suppression threshold, and half life can be manually configured. Figure 1 shows the process of BGP route dampening.
Route dampening applies only to EBGP routes. IBGP routes, however, cannot be dampened. Generally, IBGP routes contain the routes from the local AS, which require that the forwarding tables be the same. In addition, IGP fast convergence aims to achieve information synchronization. Therefore, if IBGP routes are dampened, dampening parameters vary on different devices, and thus the forwarding tables are inconsistent with each other.