BGP vs OSPF — Key Differences and When to Use Each
OSPF is a link-state IGP that finds the fastest path inside your network; BGP is a path-vector EGP…
BGP flapping (BGP flap) occurs when a BGP route repeatedly goes up and down in rapid succession, causing routing instability across the internet or enterprise network. Common causes include unstable physical links, misconfigured timers, and hardware failures. BGP route dampening is the standard fix.
Key takeaways
- BGP flap means a BGP route is repeatedly withdrawn and re-announced, causing network instability
- Common causes: unstable physical link, interface errors, CPU overload, misconfigured hold timers
- BGP route dampening suppresses unstable routes by assigning penalty points per flap
- Dampening parameters: half-life (15 min default), reuse threshold (750), suppress limit (2000)
- To diagnose: use "show ip bgp flap-statistics" and "show ip bgp dampened-paths" on Cisco IOS
- BGP hold timer mismatch (default 180s) can cause premature session drops — verify on both peers
- Fix physical layer issues first — most BGP flaps originate from Layer 1/2 problems
BGP flapping is a BGP session or a prefix repeatedly transitioning between up and down. Each transition forces every affected router to withdraw and reinstall routes, rerun best-path selection, and propagate the change onward — so a single flapping link at the edge can generate churn across many networks.
There are two distinct things people call flapping, and they are troubleshot differently:
- Session flapping — the BGP peering itself keeps resetting. All prefixes from that neighbour drop at once.
- Route flapping — the session is stable, but individual prefixes are withdrawn and re-advertised repeatedly.
Start Here: Which One Is It?
Router# show ip bgp summaryLook at the Up/Down column. If it keeps resetting to a small value, the session is flapping. If it shows days or weeks while prefix counts still move, the session is fine and individual routes are flapping.
Router# show ip bgp neighbors 203.0.113.1 | include reset|Last|flap
Router# show log | include BGP-5-ADJCHANGEThe syslog message names the reset reason directly, which usually shortcuts the whole investigation:
%BGP-5-ADJCHANGE: neighbor 203.0.113.1 Down BGP Notification sent
%BGP-3-NOTIFICATION: sent to neighbor 203.0.113.1 4/0 (hold time expired)Causes of Session Flapping
| Cause | Symptom in the logs | Where to look |
|---|---|---|
| Physical link errors | Interface up/down alongside the BGP reset | show interfaces — CRC, input errors, carrier transitions |
| Hold timer expiry | Notification 4/0, “hold time expired” | Congestion, packet loss, or CPU starving the keepalives |
| MTU mismatch | Session establishes then drops when a large update is sent | ping df-bit size 1500 between peer addresses |
| Maximum-prefix exceeded | Notification 6/1, session torn down | show ip bgp neighbors | include maximum |
| Authentication mismatch | “No MD5 digest” or repeated TCP failures | Password configuration on both ends |
| TTL / multihop misconfiguration | Session never establishes, or drops when the path length changes | See below |
| Route to the peer flapping | iBGP session drops when the IGP reconverges | Peer on loopbacks, not physical interfaces |
| CPU exhaustion | Multiple neighbours flapping simultaneously | show processes cpu sorted |
Where TTL Actually Matters in BGP
This is widely misexplained, so it is worth stating precisely. BGP routes do not carry a TTL that decrements and expires. TTL is a field in the IP packet header, not a BGP path attribute. BGP prevents loops using the AS-path — a router rejects any route whose AS-path already contains its own ASN.
TTL is relevant to BGP in exactly two ways, both about the TCP session rather than the routes:
1. eBGP multihop
eBGP sends its packets with TTL 1 by default, on the assumption that peers are directly connected. If your peer is more than one hop away — peering on loopbacks, or through an intermediate device — the packets die in transit and the session never comes up.
Router(config-router)# neighbor 203.0.113.1 ebgp-multihop 2
Router(config-router)# neighbor 203.0.113.1 update-source Loopback0Set the hop count to the actual distance. Setting it needlessly high weakens the protection TTL 1 provides.
2. GTSM — the TTL security check
The generalised TTL security mechanism inverts the logic: instead of limiting how far your packets travel, it rejects arriving packets whose TTL is too low.
Router(config-router)# neighbor 203.0.113.1 ttl-security hops 1The router now only accepts BGP packets arriving with TTL ≥ 254. Because an attacker several hops away cannot craft a packet that arrives with a high enough TTL, this cheaply defeats remote spoofing attacks against the session. Note that ttl-security and ebgp-multihop are mutually exclusive on the same neighbour.
If a session flaps whenever the underlying path length changes, a mismatched multihop or TTL-security setting is a strong candidate.
Causes of Route Flapping
- An unstable customer or downstream link re-originating the prefix each time it recovers.
- Redistribution churn — an IGP route flapping gets redistributed into BGP and withdrawn on every transition.
- A flapping next hop. If the IGP route to the BGP next hop disappears, the BGP route becomes invalid even though the session is up. Check with
show ip bgp <prefix>for “inaccessible”. - Route-map or prefix-list changes being applied repeatedly by automation.
- Aggregation instability where a component prefix keeps disappearing.
Router# show ip bgp flap-statistics
Router# show ip bgp neighbors 203.0.113.1 flap-statisticsBGP Route Dampening
Dampening suppresses a prefix that flaps too often, so instability in one network does not propagate everywhere. Each flap adds a penalty; the penalty decays exponentially; if it crosses the suppress limit the prefix is withheld until it decays back below the reuse limit.
Router(config-router)# bgp dampening 15 750 2000 60| Parameter | Value above | Meaning |
|---|---|---|
| Half-life | 15 min | Time for the penalty to halve |
| Reuse limit | 750 | Penalty below which the prefix is re-advertised |
| Suppress limit | 2000 | Penalty above which the prefix is withheld |
| Max suppress time | 60 min | Ceiling on how long a prefix can be suppressed |
Router# show ip bgp dampening dampened-paths
Router# clear ip bgp dampening 10.20.0.0 255.255.0.0A caution: dampening was widely deployed in the 2000s and then largely rolled back. Research showed that with aggressive default parameters, a prefix that flapped briefly could be suppressed for far longer than the actual instability lasted, making outages worse rather than better. RIPE’s current guidance (RIPE-378 and successors) recommends much more conservative values if you use it at all. Dampening also treats a symptom — fixing the flapping link is the actual solution.
Practical Stabilisation Measures
- Fix the physical layer first. Most session flapping is a dirty fibre, a failing SFP or a marginal circuit. Check error counters before touching BGP configuration.
- Peer iBGP on loopbacks with
update-source Loopback0, so the session survives a physical link failure when a redundant path exists. - Set a maximum-prefix limit so a neighbour’s leak cannot exhaust your memory — but use
warning-onlyor a restart interval so it does not tear the session down permanently.Router(config-router)# neighbor 203.0.113.1 maximum-prefix 500000 90 restart 15 - Verify MTU end to end with a DF-bit ping between peer addresses. MTU problems produce a distinctive pattern: the session comes up, then drops as soon as a large update is sent.
- Use BFD rather than shortening BGP timers if you need fast detection. Aggressive hold timers cause false positives under load; BFD detects failure in milliseconds without that risk.
Router(config-if)# bfd interval 300 min_rx 300 multiplier 3 Router(config-router)# neighbor 203.0.113.1 fall-over bfd - Enable graceful restart so a control-plane restart does not black-hole traffic that the forwarding plane could still carry.
- Log neighbour changes so you have a history rather than a snapshot.
Router(config-router)# bgp log-neighbor-changes
Frequently Asked Questions
What causes a BGP hold timer expiry?
Keepalives are not arriving within the hold time — usually packet loss, congestion on the link, or high CPU on either router preventing timely processing. Check interface errors and CPU before assuming a BGP configuration problem.
Should I enable route dampening?
Only with conservative parameters, and only if you are genuinely receiving unstable prefixes from a specific peer. Default aggressive values suppress prefixes for far longer than the instability warrants, and the industry moved away from the practice for that reason.
Why does my eBGP session not come up when peering on loopbacks?
eBGP uses TTL 1 by default, so packets to a non-adjacent loopback expire in transit. You need ebgp-multihop with the correct hop count, update-source Loopback0, and a route to the peer’s loopback on both sides.
Does BGP use TTL for loop prevention?
No. Loop prevention in BGP is the AS-path attribute — a router discards any route that already lists its own AS number. TTL is an IP header field and relates only to how far the BGP session’s packets may travel.
How do I find which prefix is flapping?
show ip bgp flap-statistics lists prefixes by flap count. Combine with show ip bgp neighbors <ip> flap-statistics to attribute them to a specific peer.
Will BFD stop my session flapping?
No — BFD detects failures faster, it does not prevent them. It helps by letting you keep normal BGP timers (avoiding false positives from transient congestion) while still failing over quickly when a link genuinely dies.
