Home / Notes / BGP Neighbor & Route Flapping Troubleshooting
NOTES · BGP TROUBLESHOOTING

BGP Neighbor Won't Establish & Route Flapping: A Complete Checklist

A peer stuck in Idle or OpenSent, or a session that keeps bouncing and taking a route with it, is one of the most common escalations on a WAN edge. This is the diagnostic order that separates the handful of root causes behind most of these tickets — the exact display commands, the error codes, and where route iteration quietly breaks a session that otherwise looks fine.

By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026

Why the State Column Tells You More Than the Symptom

I don't start by staring at the configuration — I start by asking which of six states the peer is actually stuck in.

A BGP session moves through a fixed sequence — Idle, Connect, Active, OpenSent, OpenConfirm, Established — and almost every "neighbor won't come up" ticket is really a question of which of those states it's stuck at, not a mystery to be solved by changing settings on both ends at once. A session that reaches Established and then drops, bounces, or quietly sends traffic down only one of several equal-cost paths is a different problem with its own diagnostic order, even though it gets reported the same way: "BGP is down."

What follows is the fault tree this is built on, the checks for each branch with the exact commands to run, the root causes that show up again and again once you're past the first few checks, and a handful of real FAQ answers pulled from actual field cases.

Read the Fault Tree Before You Touch Any Configuration

BGP failures split into exactly two shapes: the neighbor never reaches Established, or it does and something still isn't right.

Placing the symptom on this tree first saves a lot of backtracking later — it tells you which of the sections below actually applies to what you're looking at.

BGP Fault Neighbor Never Reaches Established Established, Then Drops or Flaps Stage 0 · Transport never connectsunreachable peer · ACL blocking TCP 179 Stage 1 · Session parameters mismatchRouter ID conflict · wrong AS · address-family not enabled Stage 2 · Loopback-peering parametersmissing connect-interface / ebgp-max-hop · Device ID 0.0.0.0 Other blockerspeer route-limit exceeded · peer ignore configured Session drops after being Establishedhold-timer expiry · route iteration to Null0 · config change Traffic rides only one of several equal pathsmaximum load-balancing never configured An aggregate/summarized route flapsstatic-vs-IBGP or static-vs-IGP preference tug-of-war

Diagram labels are kept in English for engineering clarity.

Once you know which branch applies, almost every check below is a single display command away from a confirmed cause — the trap is treating a flapping, already-Established session with the same checklist as one that has never come up at all.The same discipline, applied one protocol over, is behind OSPF Neighbor Stuck or Route Flapping? Reading the State Machine to Find the Fault, its sister note for OSPF adjacencies.

Working Through Each State

Six states, one exact command that tells you which one you're stuck in — and where the flap logs explain themselves once you know the error code.

Stage 0 — Confirm Transport Even Connects

If the peer never leaves Idle or Active, don't touch the BGP configuration yet — confirm the two ends can actually reach each other over TCP 179 first.

  1. Ping between the two peer addresses using a command that carries a source address and a real packet size — ping -a source-ip-address -s packetsize host — since a source address confirms the return path is valid too, and a larger packet size confirms a big BGP Update won't silently be dropped somewhere in between.
  2. If the ping fails, that's a routing/link problem to chase down on its own, not a BGP problem.
  3. If the ping succeeds but the session still won't progress, check both ends for an ACL that happens to filter TCP port 179 — often left over from an unrelated security or QoS policy.
<HUAWEI> display acl all
Basic ACL 3001, 2 rules
ACL's step is 5
ACL's match-order is config
  rule 5 deny tcp source-port eq bgp
  rule 10 deny tcp destination-port eq bgp
// undo rule 5 destination-port / undo rule 10 source-port removes the block

Stage 1 — Router ID, AS Number and Address-Family Match

Transport is fine, but the peer still won't leave OpenSent or shows "No Neg" — this is almost always one specific parameter that looks fine in isolation but doesn't actually match the other end.

  1. Check display bgp peer on both ends for the local Router ID. Two peers sharing the same Router ID — common after a cloned configuration — block establishment outright; fix it with router id in the BGP view, generally set to the Loopback address.
  2. Compare the configured AS number against what the other end actually is, not what you expect it to be.
  3. If the session is address-family specific (VPNv4, IPv6, VPNv6), confirm peer enable is configured under that address family on both ends — a one-sided configuration shows as "No Neg" rather than a hard failure.
<HUAWEI> display bgp peer
BGP local router ID : 1.1.1.1
 Local AS number : 41976
 Total number of peers : 12                Peers in established state : 4
  Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State PrefRcv
  10.9.0.8        4         100     1601     1443     0 23:21:56 Established   10000
  10.10.0.10      4         200     1565     1799     0 23:15:30 Established    9999
// Router ID and AS both compared directly against the peer's own values

Stage 2 — Loopback-Peering Parameters

If either end sources the session from a Loopback interface, four extra parameters have to be configured correctly, and a fifth — the Device ID — has to simply not be zero.

  1. Confirm peer connect-interface points at the Loopback used to source the session — without it, the device defaults to sourcing from the outbound physical interface instead.
  2. For an EBGP session built over a Loopback (or any multihop EBGP), confirm peer ebgp-max-hop is configured with a hop count that actually covers the path.
  3. If GTSM is in play, confirm peer valid-ttl-hops is configured symmetrically on both ends — it has to be enabled on both sides together, not just one.
  4. When peering with a different vendor's device and the session refuses to reconnect after a reboot even though the TCP handshake completes cleanly, check whether this device actually has a usable BGP Device ID — if every IP-addressed interface is bound inside a VPN instance and there's no standalone Loopback, the Device ID resolves to 0.0.0.0, which most implementations reject outright.
<Huawei> display bgp vpnv4 vpn-instance VPN1 peer
BGP local Device ID : 0.0.0.0        // invalid -- session will not originate or accept
...
// after adding a Loopback interface outside any VPN instance:
BGP local Device ID : 192.168.1.2
VPN-Instance VPN1, Device ID 192.168.1.2:
Total number of peers : 1  Peers in established state : 1
Peer         V AS     MsgRcvd  MsgSent  OutQ  Up/Down     State       PrefRcv
10.83.255.2  4 39651  10       22       0     02:59:49    Established 1

Stage 3 — Established, Then Drops: Read the Error Code, Don't Guess

A session that was fine and then dropped, or keeps bouncing, leaves an exact reason behind — you don't have to be watching when it happens.

  1. Run display bgp peer <ip> log-info to pull the Up/Down history with an Error Code and Error Subcode for each transition — Cease/Administrative Shutdown means someone ran shutdown or peer ignore; Hold Timer Expired means keepalives simply stopped arriving in time; a config-change subcode means a peer-affecting command was modified.
  2. In the diagnostic view, pads diagnose neighbor bgp prints a one-line plain-English reason per peer without you having to reconstruct it from configuration.
  3. If the reason isn't an admin action, check the physical/IGP path underneath — a route to the peer's Loopback that recurses through a static route can silently redirect the BGP session's own traffic into a Null0 blackhole the moment one physical uplink drops, even while a plain ping (which hashes differently) still succeeds.
<HUAWEI> display bgp peer 10.8.200.26 log-info
 Date/Time     : 2021-02-06 18:34:31+00:00
 State         : Down
 Error Code    : 4(Hold Timer Expired)
 Error Subcode : 0(UnSpecific)
 Notification  : Send Notification

[~HUAWEI-diagnose] pads diagnose neighbor establish-abnormal bgp history-record
NBR-Peer-IP    Last-Detect-Time State       Reason
1.1.1.1        01-27 20:23:49   OpenConfirm The shutdown command is run in the BGP view.
2.2.2.2        01-27 20:23:49   Idle        The peer ignore command is configured for the BGP peer.

Stage 4 — Traffic Uneven or an Aggregate Route Flapping

The session is stable — the "fault" is in how the routes it carries are being used or re-advertised.

  1. If two or more equal-cost EBGP paths exist between the same pair of routers but nearly all traffic rides one of them, confirm maximum load-balancing is configured with a value of 2 or higher on every router that sees the equal-cost routes.
  2. If a summarized/aggregated route flaps continuously with no policy change and no route actually being added or withdrawn, compare the BGP protocol preference against the preference of whatever static or IGP route is also feeding that aggregate — whichever currently wins decides if the aggregate is "up," and a session or protocol blip on the losing side flips it.
[Device] bgp 65001
[Device-bgp] maximum load-balancing 4
// configure identically on every router in the cross-connected mesh

[Device-bgp] preference 65
// set BGP's preference lower (worse) than the static route feeding the same aggregate (default static preference 60)

6 Root Causes That Show Up Again and Again

Once the states above have told you where the problem sits, these six account for most of what's actually wrong.

1. Router ID Collision Blocks the Session Silently

SYMPTOMThe peer never reaches Established even though the transport ping succeeds cleanly — it just sits in OpenSent or cycles.

CAUSETwo peers end up with the same Router ID — often after a cloned or templated configuration where the Loopback address, or the default Router ID selection, wasn't changed on the copy.

FIXSet an explicit, unique Router ID on each device, generally using its own Loopback address.

[Device] bgp 65001
[Device-bgp] router id 2.2.2.2

2. A Leftover ACL Blocks TCP 179

SYMPTOMTransport-layer ping between the two peer addresses works fine, but the session never leaves Idle or Active.

CAUSEAn ACL configured for an unrelated purpose — security filtering, QoS classification — happens to deny TCP source-port or destination-port bgp on the path between the two peers.

FIXCheck display acl all on both ends and remove or narrow the rule that matches TCP port 179.

<HUAWEI> display acl all
Basic ACL 3001, 2 rules
  rule 5 deny tcp source-port eq bgp
  rule 10 deny tcp destination-port eq bgp
[HUAWEI] acl 3001
[HUAWEI-acl-basic-3001] undo rule 5 destination-port
[HUAWEI-acl-basic-3001] undo rule 10 source-port

3. Loopback Peering Missing connect-interface / ebgp-max-hop, or a Device ID of 0.0.0.0

SYMPTOMA session to a different vendor's router refuses to reconnect after a device reboot, even though the underlying TCP connection completes cleanly.

CAUSEIf every IP-addressed interface on the device is bound inside a VPN instance and there's no standalone Loopback, the BGP Device ID resolves to 0.0.0.0 — a value most implementations treat as invalid, so the device won't originate or accept a session at that ID no matter how healthy the transport is. Separately, Loopback-sourced sessions need peer connect-interface, and Loopback-sourced or otherwise multihop EBGP sessions need peer ebgp-max-hop — without either, the session sits unestablished with no obvious error.

FIXAdd a Loopback interface outside any VPN instance (or set router id explicitly) so the Device ID is never 0.0.0.0, and configure connect-interface and ebgp-max-hop wherever the session isn't a plain directly-connected EBGP peer.

[Device] interface loopback 1
[Device-LoopBack1] ip address 192.168.1.2 32
[Device] bgp 64512
[Device-bgp] peer 10.83.255.2 ebgp-max-hop 2
[Device-bgp] peer 10.83.255.2 connect-interface LoopBack1

4. Route Iteration Quietly Redirects the Session Into a Null0 Blackhole

SYMPTOMA dual-uplink BGP session that was fine drops into OpenSent the moment one physical uplink goes down — even though you can still ping the peer's Loopback address from this device.

CAUSEStatic routes toward the peer's Loopback recurse through another static route rather than pointing at an explicit interface and next hop. When one physical link drops, the surviving equal-cost route's next hop iterates into a Null0 route configured for an unrelated blackhole purpose. An un-sourced ping hashes onto the still-working path and succeeds, but the BGP session — sourced from the Loopback — hashes onto the path that now iterates to Null0, and drops.

FIXPoint each static route at an explicit outbound interface and next hop instead of letting it recurse through another static entry.

[Device] undo ip route-static 10.0.0.1 255.255.255.255 192.168.0.1
[Device] ip route-static 10.0.0.1 255.255.255.255 10GE0/0/2 192.168.0.1
<Device> display bgp peer
// the peer at 10.0.0.1 returns to Established once the recursive path is removed

5. Equal-Cost Paths Exist, But Load-Balancing Was Never Enabled

SYMPTOMTwo or more EBGP links of equal cost connect the same pair of routers, but almost all the traffic rides one of them while the other sits nearly idle.

CAUSEBGP only installs and uses a single best path per prefix by default — regardless of how many equal-cost routes actually exist — unless load-balancing is explicitly enabled. Without it, ordinary BGP path selection (lowest Router ID among identical routes, for instance) always lands on the same single path.

FIXEnable maximum load-balancing with a count of 2 or more on every router in the cross-connected mesh, sized for future growth, and confirm what count the far-end vendor's platform supports if it isn't the same as this one.

[Device] bgp 65001
[Device-bgp] maximum load-balancing 4

6. Static-vs-Dynamic Priority Tug-of-War Flaps an Aggregate Route

SYMPTOMA summarized route advertised toward the backbone flaps continuously — downstream peers see it appear and disappear even though nobody touched any policy or added or withdrew a route.

CAUSEThe aggregate is fed by both a static (often blackhole) route and a dynamically learned IBGP or IGP route with a better preference than the static entry. Every time the dynamic route's underlying session blips — even briefly — the preferred source for the aggregate flips between the two, and the aggregate is withdrawn and re-advertised even though nothing about the actual network changed.

FIXSet the dynamic protocol's preference worse (numerically higher) than the static route's, so the static entry stays the stable, permanent source for the aggregate.

[Device] bgp 65001
[Device-bgp] preference 65
// static route default preference is 60 -- keep it better than BGP/IGP for this aggregate's source

Related solution designs

Government IP Bearer NetworkA single backbone carrying every agency's traffic runs on exactly this kind of cross-connected BGP mesh — the load-balancing and priority gotchas above are what keep it stable. ISP / Metro Bearer NetworkThe metro-to-backbone EBGP handoffs this fault tree gets applied to most often — equal-cost uplinks, route reflectors, and the traffic-balance problems that come with scale.

Five Questions That Come Up Constantly

Pulled straight from the field — the ones worth having an answer ready for.

My peer never leaves Idle or Active — what's the fastest way to know which state it's actually stuck in?

display bgp peer shows the current State column directly (Idle / Connect / Active / OpenSent / OpenConfirm / Established). If it's not obvious why it won't progress past that state, the diagnostic-view command pads diagnose neighbor establish-abnormal bgp history-record prints a one-line plain-English reason per peer — "the shutdown command is run in the BGP view," "the peer ignore command is configured" — without you having to reconstruct it from the running configuration.

The session was Established for weeks and then dropped once — how do I find out why after the fact?

display bgp peer <ip> log-info keeps a history of Up/Down transitions with the exact Error Code / Error Subcode pair for each one. Code 6 subcode 2 (Administrative Shutdown) means someone ran shutdown or configured peer ignore; code 4 (Hold Timer Expired) means keepalives simply stopped arriving in time — check the link and CPU load; code 6 subcode 6 means a peer-affecting command, like ebgp-max-hop, was changed. Cross-reference the timestamp against the operation log for the same moment.

Two EBGP links connect the same pair of routers with identical cost, but almost all the traffic rides one of them — why?

BGP only installs a single best path per prefix by default. Without maximum load-balancing configured to a value of 2 or higher on the routers that see the equal-cost paths, only one path is ever used no matter how many equal-cost routes actually exist. Configure it on every router in the cross-connected pair, and check what count the far-end vendor's platform supports if it isn't the same as this one.

A summarized route we advertise upstream keeps flapping even though nobody changed any policy or route — what's actually moving?

This is a priority problem more often than a protocol problem. If the aggregate is fed by both a static route and a dynamically learned IBGP or IGP route, whichever currently has the better preference decides whether the aggregate is "up." When the session behind the dynamic route blips, even briefly, the winning source flips and the aggregate gets withdrawn and re-advertised — nothing in the actual network changed. Set the dynamic protocol's preference worse than the static route's so the static entry stays the stable source.

Configuration looks identical on both ends, but a session with a different vendor's router still won't come up after a reboot — what am I missing?

Check whether this device actually has a usable BGP Device ID. If every IP-addressed interface is bound inside a VPN instance and there's no standalone Loopback, the Device ID resolves to 0.0.0.0, which most implementations reject outright — the device won't originate or accept a session at that ID even though the TCP connection itself completes cleanly. Add a Loopback interface outside any VPN instance, or set router id explicitly, before changing anything else.

Honest Limits of This Note

Honest Limits of This Note

This note is built around the Huawei AR-series router's BGP fault-classification model and its display bgp peer / display bgp peer log-info / pads diagnose neighbor bgp commands, plus the field cases behind them. If your router is a different vendor, the exact commands change, but the underlying logic — Router ID and AS matching, transport-layer ACLs, Loopback-peering parameters, route iteration, missing load-balancing, priority-driven flapping — carries over directly. It doesn't cover BGP FlowSpec, RPKI origin validation, or SR-TE-integrated BGP scenarios in depth.

Peer stuck or flapping right now?

Tell us the exact State column from display bgp peer, or the Error Code from display bgp peer log-info, and we'll help you read it.

WhatsApp an engineer →

Related Reading

OSPF Neighbor Stuck or Route Flapping?Different protocol, same discipline — the same state-machine-first approach applied to OSPF adjacencies. MPLS L3VPN PE-CE Faults: RT Mismatches, Route Leaks and Slow ConvergenceOnce the BGP session itself is solid, this is what breaks next — RT mismatches, cross-domain label problems, and slow convergence in the VPN layer riding on top of it. Multi-Branch VPN Interconnection SolutionBuilding this for more than one branch? See how the same BGP discipline scales across a full hub-and-spoke network.