BGP session flapping — interface, route-flap damping, BFD, peer reset

A BGP session that flips between Established and Idle has exactly four causes: the physical interface is flapping (cable, SFP, optics, link partner); route-flap damping has suppressed a prefix and the operator believes the session is the problem; BFD has been misconfigured and tears the session down faster than the hold-time; or the operator (or automation) is clearing the session. Each cause has a different cadence, different evidence, and different fix. The operator who can identify the cadence from the up/down timer and the BGP log finds the cause in minutes.

This lesson walks the four causes, the cadence each one produces, the evidence in show ip bgp summary and show ip bgp neighbors, and the production-grade fix for each. The goal is the ability to look at a flapping session and say “interface flap every 30 seconds — the optics” or “damping — the prefix is suppressed, the session is fine” within the first minute of investigation.

The four causes and their cadence

flowchart TD
  F1[Session flapping] --> Q1{Up/down timer pattern?}
  Q1 -->|"sub-second to a few seconds"| BT[BFD<br/>interval x multiplier too tight]
  Q1 -->|"seconds to a minute, regular"| IF[Interface flap<br/>cable/SFP/optics]
  Q1 -->|"matches a schedule"| RR[Operator/automation clear<br/>task-scheduler, monitoring script]
  Q1 -->|"session stable, prefix missing"| DM[Route-flap damping<br/>prefix is suppressed]

  BT --> FIX2[Fix: widen the BFD interval to what the link and CPU sustain]
  IF --> FIX1[Fix: replace cable/SFP, check link partner]
  RR --> FIX3[Fix: find the schedule, remove the clear, monitor instead]
  DM --> FIX4[Fix: clear the damping, or stop running damping]

The diagram shows the four causes and the cadence each one produces. The up/down timer in show ip bgp summary is the first clue. The BGP log is the second. The third is the operator’s knowledge of recent changes.

Cause 1 — Interface flapping

The physical interface goes up and down. Each time it goes down, the BGP session drops (the TCP socket closes). Each time it comes back up, BGP re-establishes from Idle. The cadence matches the interface cadence — typically a few seconds to a few minutes.

The most common physical causes:

• Bad cable or patch cord. The link partner sees the link down; the local router sees the link down. Both sides flap in sync.
• Bad SFP or optics. The optics reports link down intermittently. The link light on the switch may flicker; the local router sees the link state change.
• Duplex mismatch. The link is up at the physical layer but the line protocol bounces due to excessive CRC errors. The router sees the link as up/down/up/down.
• LACP partner issue. A bonded interface with a misconfigured peer may flap one member while the bond stays up. The BGP session may or may not flap depending on whether the bond has enough bandwidth.
• Power issues on the remote device. The remote switch reboots every few minutes; the link follows.

The cadence: typically 5-60 seconds, regular, repeatable. The evidence: show ip bgp summary shows the up/down timer resetting on a short cycle; the interface’s link state is changing; the log shows the FSM transition Established → Idle on the same cycle.

Diagnosis for interface flap

# BGP's view: the up/down column resets each time
show ip bgp summary

# The interface's view, from VyOS
show interfaces ethernet eth0

# The link and the negotiated speed/duplex, from the driver
ethtool eth0

# Error and drop counters, which a duplex mismatch drives up
ip -s link show dev eth0
ethtool -S eth0

# Link up/down events, timestamped, from the kernel
journalctl -k --since '-30 min' | grep eth0

# BGP's own FSM transitions
journalctl -u frr --since '-30 min' | grep 192.0.2.2

The pairing that identifies this cause is the last two: a kernel link-down message and a BGP FSM transition with the same timestamp, repeating. If the kernel is not logging link events and BGP is still flapping, the interface is not your problem and you should be in one of the other three sections.

ethtool is worth running even when the link looks fine. A link that has negotiated half duplex against a full-duplex partner comes up, stays up, and drives CRC errors until traffic stops passing — which reaches BGP as a hold-timer expiry rather than a link-down, so the FSM log looks different from a cable fault.

The canonical production error: the operator replaces a cable and sees the BGP session stabilise. The fix is straightforward but the operator must confirm the link partner is also clean (a bad cable on the other end may not be visible to the local router’s interface counters).

Cause 2 — Route-flap damping

The BGP session is healthy but a prefix is being suppressed by route-flap damping. The operator sees “the route is missing” and assumes the session is the problem. The evidence is the d status code on the path in show ip bgp, and the flap history in show ip bgp dampening flap-statistics.

Route-flap damping is a mechanism to penalise prefixes that flap (withdraw and re-advertise repeatedly). The penalty increases with each flap, and once the penalty exceeds the suppress threshold, the prefix is suppressed (not advertised to peers) until the penalty decays below the reuse threshold. The default in FRR:

• Suppress threshold: 2000
• Reuse threshold: 750
• Half-life: 15 minutes (the penalty halves every 15 minutes)
• Max suppress time: 60 minutes (the penalty cannot grow beyond the equivalent of 60 minutes)

The canonical use case for damping: a peer in a remote region has a flaky link and the prefix flaps every few seconds. Damping prevents the flap from propagating to the local AS and the rest of the Internet.

The canonical misuse: the operator enables damping globally and a legitimate flap (e.g., a planned maintenance) suppresses a customer prefix for an hour. The fix is to either disable damping or to apply it only to specific peers.

Diagnosis for route-flap damping

# The prefix's own status codes
show ip bgp 198.51.100.0/24

# Every path currently suppressed
show ip bgp dampening dampened-paths

# Flap count, penalty and reuse time per prefix
show ip bgp dampening flap-statistics

# The thresholds actually in force
show ip bgp dampening parameters

# Whether this router is the one running damping
show configuration commands | match dampening

Read the status codes at the left of show ip bgp output rather than the prefix itself. FRR marks a suppressed path d (damped) and a path with flap history that is not currently suppressed h (history); a path that is neither valid nor best has no * or >. A prefix showing d is a prefix the session delivered correctly and damping is holding back — the session is not the problem, and the flap that earned the penalty may have happened at a router several ASes away.

That last command matters more than it looks. Damping can be running on your router, or on the router that fed you the prefix. If your own configuration has no dampening in it, the suppression is somebody else’s and the only thing you control is whether you keep asking them about it.

Configuring it — and the honest gap

Route-flap damping itself is an FRR feature, and FRR’s knob for it sits inside a BGP address-family. This course has not verified a VyOS 1.5 configuration path that enables classic per-prefix damping, and the previous version of this lesson published one that does not exist. Rather than replace an invented command with a vaguer invented command: check your own release before you plan on having this. In configure mode, walk the completion tree with ? at set protocols bgp parameters and at set protocols bgp address-family ipv4-unicast, and look for a dampening node. If it is not offered, VyOS does not expose it on your release and no amount of FRR syntax pasted into the VyOS CLI will change that — the VyOS tree and FRR’s own configuration language are different languages, and this lesson’s other examples are VyOS’s.

Reaching for damping at all deserves a second thought. The RIPE community’s operational guidance moved away from classic damping with the default thresholds years ago, on the evidence that it suppresses legitimate prefixes far more often than it suppresses genuinely pathological ones, and that a single reconvergence event can earn a penalty. Most networks today run no damping and rely on the upstream to be stable, on BFD for fast local failure detection, and on maximum-prefix for the protection damping was reached for by mistake.

What remains fully in your hands is clearing a suppression once it has happened:

clear ip bgp dampening 198.51.100.0/24

This drops the accumulated penalty for that prefix and lets it be used and readvertised immediately, without touching the session.

Cause 3 — BFD misconfiguration

BFD exists to detect a peer failure faster than a routing protocol’s own timers can. Attached to a BGP session, it becomes the thing that tears the session down: when the BFD session goes down, BGP does not wait out its hold time, it drops the peer immediately. That is the point of it, and it is also what makes a BFD that is tuned too tight indistinguishable, from BGP’s side, from a peer that keeps failing.

The arithmetic that decides this is interval × multiplier. FRR’s defaults are a 300 ms transmit and receive interval with a detect multiplier of 3 — the session is declared down after roughly 900 ms without a packet. Tighten the interval to 50 ms and you are declaring the peer dead after 150 ms, and 50 ms means 20 packets per second in each direction, forever, per session. 50 ms is a number you choose deliberately for a low-latency link on a box with the CPU to spare; it is not a number you get by accident.

The cadence, therefore: sub-second to a few seconds, and far faster than anything the BGP hold time (180 seconds by default) would produce on its own. A BGP session cycling faster than its own hold time is close to proof that something else is tearing it down.

Diagnosis for BFD flap

# The BGP session state and cadence
show ip bgp summary

# The BFD session: state, uptime, and the negotiated intervals
show bfd peers

# The profile's configured values
show bfd profile

# What this router asked for
show configuration commands | match bfd

# The correlation: BFD down events and BGP FSM transitions
journalctl -u frr --since '-30 min' | grep -Ei 'bfd|192.0.2.2'

Read the negotiated intervals in show bfd peers, not the configured ones. BFD negotiates: each side advertises its desired transmit interval and its minimum receive interval, and the rate that actually runs is the slower of the two sides’ wishes. A local profile that says 50 ms against a peer that will only accept 300 ms runs at 300 ms — which means the configuration you are reading on your own router is not the configuration in force.

FRR runs its BFD daemon inside the FRR service, so there is no separate bfdd unit to follow; journalctl -u frr carries both the BFD events and the BGP FSM transitions, which is convenient because correlating the two is the whole diagnostic.

Cause 4 — Operator-driven peer reset

The operator (or an automation system) is clearing the BGP session. The cadence matches whatever the automation does — every minute (cron job), every 5 minutes (monitoring check), every hour (configuration sync), or random (manual operator action).

The evidence: a cadence that matches a clock rather than a fault. Faults are irregular; schedules are not. A session that drops at exactly the same offset every minute, or on the hour, is being cleared, not failing.

Diagnosis for operator reset

# The cadence, watched across several cycles
show ip bgp summary

# The FSM transitions and the reason FRR logged for each
journalctl -u frr --since '-1 hour' | grep 192.0.2.2

# Anything VyOS itself is scheduled to run
show configuration commands | match task-scheduler

# And anything scheduled outside the VyOS tree
sudo crontab -l
systemctl list-timers --all

Look at the reason in the FRR log, not just the transition. A session that a human or a script cleared is logged differently from one that timed out or lost its TCP connection, and that difference is what separates this cause from the other three in one line.

Then account for the last two commands. VyOS’s own scheduler lives at set system task-scheduler task <name>, and that is the first place to look — but automation reaching the router over SSH leaves nothing in the VyOS tree at all, and neither does a monitoring system’s “remediation” action. If the cadence is a schedule and the router has no schedule, the schedule is somewhere else and someone else owns it.

The canonical production error is a well-meant health check that clears the session whenever it looks unhealthy — which guarantees the session is never healthy long enough to prove otherwise. The fix is to delete the clear, not to tune it: delete system task-scheduler task <name> for a VyOS-side task, and a conversation for anything else. Monitoring observes; it does not remediate a BGP session.

How the result is validated

show ip bgp summary
show ip bgp neighbors 192.0.2.2
show ip bgp dampening dampened-paths
show ip bgp 198.51.100.0/24
show interfaces ethernet eth0
show bfd peers
journalctl -u frr --since '-30 min' | grep 192.0.2.2

The first is the start — the state and the up/down cadence. The second is the per-peer view. The third answers “is anything suppressed”, which is the one operators skip. The fourth is the prefix view, for when a specific prefix rather than the session is what someone reported. The fifth and sixth are the two mechanisms that can tear a healthy session down from underneath. The seventh is the log that timestamps all of it.

Run them in that order and the cadence plus the log usually name the cause before you reach the end.

How it fails

The production failure modes the engineer must recognise:

• Interface flap due to a bad cable or SFP. Kernel link-down messages and BGP FSM transitions share timestamps. Fix: replace the part, and confirm the far end is clean too — a fault on the partner’s side does not always show in your counters.
• Duplex mismatch. The link stays up, errors climb, and BGP dies on a hold-timer expiry rather than a link event. ethtool eth0 shows the negotiated duplex; ethtool -S eth0 shows the errors. Fix: make both ends agree, preferring autonegotiation on both over forcing both.
• Bond member flap. The bond is up, a member is cycling, and the session drops only when the bond falls below its minimum links. cat /proc/net/bonding/bond0 names the member by its link-failure count.
• Damping suppressing a legitimate prefix. The session is fine and the prefix is d. Fix: clear ip bgp dampening 198.51.100.0/24, and then ask whether this router should be running damping at all.
• BFD tuned tighter than the path can carry. Sub-second cadence, faster than the BGP hold time could produce. Fix: widen the interval to what the link and both CPUs sustain, and read the negotiated values rather than the configured ones.
• A scheduled clear. The cadence matches a clock. Fix: find the schedule — VyOS’s task-scheduler, a crontab, a systemd timer, or an external automation platform — and remove the clear rather than tuning it.

Rollback

Flapping-session fixes vary by cause. The standard rollback paths:

• Interface fix: most of it is physical and has no configuration to reverse. Where you did change the tree — a forced speed or duplex — delete interfaces ethernet eth0 speed and delete interfaces ethernet eth0 duplex return the link to autonegotiation.
• Damping: clearing a suppression with clear ip bgp dampening 198.51.100.0/24 is an operational action with no configuration to roll back. It re-advertises the prefix; it does not stop the next flap from suppressing it again.
• BFD: delete protocols bgp neighbor 192.0.2.2 bfd detaches BFD from the session, which is the right move when BFD is the thing causing the flap. Widening the profile’s interval is the better fix once the session is stable enough to reason about.
• Scheduled clear: delete system task-scheduler task <name> for a VyOS-side task. Anything scheduled outside VyOS is outside the configuration and outside rollback too.

Apply configuration fixes with commit-confirm 5. A flapping session is exactly the situation where the change you make to fix it can be the change that removes your own access, and the timer reverts that without you.

Whole-configuration rollback is the wrong granularity here: it restores an entire previous revision, undoing every other change committed since, to back out one peer’s settings.

Production discipline

Cross-course references

The Linux course’s XIX-Linux-NetFoundations covers the kernel TCP retransmission. The OPNsense course’s XXX-OPNsense-DynamicRouting covers the equivalent FRR BGP session behaviour on the firewall side. The BGP lessons vyos-xxiv-03-bgp-timers and vyos-xxiv-06-bgp-session-troubleshoot cover the broader session debugging. The lesson vyos-xxxii-01-bfd-concept covers BFD in detail; vyos-xxxii-03-bfd-with-bgp covers the BGP+BFD integration.

Quiz