Microwave Flapping, Damping and the Wrong Timer Reflex

Damping assigns a penalty of about 1000 per withdrawal. The penalty decays exponentially with the configured half-life, and the route is suppressed when the accumulated penalty exceeds 'suppress' (2000) and released when it falls below 'reuse' (750).

Timeline: flap 1 leaves ~1000. Flap 2 a few minutes later adds 1000 on top of a partly decayed penalty, roughly 1700-1800. Flap 3 inside ten minutes pushes the total to roughly 2200-2400, which crosses 2000 and suppresses the prefix. From there the penalty halves every 15 minutes: ~1200 at +15 minutes, ~600 at +30 minutes. 600 is below reuse 750, so the route is released at roughly 30 minutes after the last flap - matching the reported outage almost exactly.

A fourth flap at 20 minutes adds another 1000 to a penalty that had decayed to about 1200, taking it back above 2200 and restarting the clock. Repeated flaps will keep the prefix suppressed until it hits max-suppress (60 minutes here), which caps how long a route can stay damped regardless of penalty.

The operator-visible signature is important: a damped route is still in the RIB-In, so show router bgp routes shows the prefix and even the correct attributes, while the route table and FIB do not have it. That is why the customer says 'BGP shows the routes'. The detailed output will carry the suppressed/damped flag and the current penalty. Also confirm the damping policy is scoped: in SR OS damping applies to eBGP-learned routes, and a damping policy attached to the wrong peer group turns a link problem into a network-wide one.

Neither, on its own, and 10/30 is likely to make things worse. On a fading microwave link you do not have a binary up/down at the physical layer; there are periods of heavy loss that a fast timer will declare dead and an equally fast timer will declare alive again. Going from 30/90 to 10/30 triples the number of session resets per storm, and each reset is 450 withdrawals plus 450 announcements plus a full re-evaluation on 22 clients. The detection gain is 60 seconds on a link that is unusable anyway during a fade.

BFD is worth having, but as a stability tool rather than a fastest-possible detector. Configure it with a multiplier that survives normal fade-induced loss - a few hundred milliseconds interval with a high multiplier, or a slower interval - so that BFD catches a genuinely dead session in seconds while tolerating a burst of loss. Whatever you pick, the hold time must be long enough that a transient BFD failure does not tear down and rebuild the session repeatedly; in SR OS the hold-time and BFD parameters must be consistent or the session will negotiate down in a way you did not intend.

The timers are not the leverage point. The real problem is that 450 prefixes are being withdrawn and re-announced in tight bursts to 22 downstream clients, and nothing absorbs that churn. Throttling matters more than detection: the minimum route advertisement interval spreads successive updates for the same prefix over time rather than emitting them in one burst, damp-peer gives the session exponential back-off so it cannot be hammered back up instantly, and a max-prefix limit with an appropriate idle timeout is the safety net that stops a misbehaving peer from filling the table - even though, at 450 of 1000, it is not the relevant control here.

Damping was designed for a world where instability was pathological. For a last-mile link that is expected to fade, it punishes legitimate availability: the routes come back, the customer's traffic does not, and the timer is invisible to everyone who is not looking at the penalty counter. RFC 7196 argues against it for good reasons. Modern practice is to prevent churn instead of suppressing it.

Plan:

1. Scope damping to nothing, or to a very narrow policy. Remove it from this peer group first. If some damping is retained elsewhere as a deliberate choice for peer networks you do not operate, keep it away from customer-facing groups.
2. Session back-off with damp-peer. Exponential back-off on repeated session failures prevents the reconnect storm from consuming the BGP task, and it is the correct answer to a flapping transport. Combined with a sensible connect-retry, a storm becomes a handful of retries rather than dozens.
3. BFD with realistic parameters, as above, and consistent hold-time on both ends so the negotiated timers are known rather than guessed.
4. Throttle the announcement rate with the minimum route advertisement interval, and check that the RRs and clients are not being handed update bursts that cost more than the prefixes are worth. Where fast convergence is genuinely needed, consider whether the 450 prefixes should be summarised at the PE into a handful of aggregates, which cuts the churn by an order of magnitude.
5. Define the expectation, not just the mechanism. The prefixes will flap with the weather. Use a community on the PE's export to iBGP so downstream routers can hold a stable less-preferred path (a floating static or a summary) while the microwave is down, rather than relying on every router reacting to 450 individual withdrawals.

The judgement to defend in the review: route damping hides an outage from the customer; a throttle plus back-off reduces the cost of the outage without pretending it is not happening.