BGP Protocol Analysis

Protocol-reasoning-driven analysis skill for BGP peering, path selection, and
route propagation. Unlike device health checks that compare metrics against
thresholds, BGP analysis requires interpreting protocol state machines, walking
the best-path algorithm, and validating policy application across the control
plane.

Commands are labeled [Cisco], [JunOS], or [EOS] where syntax
diverges. Unlabeled statements apply to all three vendors.

When to Use

• - BGP peer reported down or stuck in a non-Established state
• Suspected route leak — prefixes appearing in tables where they should not
• Path selection not matching expectations after policy changes
• Convergence too slow after planned maintenance or unplanned failover
• Post-change verification of BGP configuration (new peers, policy updates, community changes)
• Capacity planning for prefix table growth or session scaling
• Investigating asymmetric routing caused by inconsistent BGP attributes

Prerequisites

• - SSH or console access to the router (read-only privilege sufficient)
• BGP process running on the device with at least one configured peer
• Knowledge of expected peer topology: which neighbors should be up, expected

prefix counts per peer, intended path selection outcomes

• - Awareness of configured routing policy: route-maps, prefix-lists, community

filters, AS-path access lists, and local-preference assignments

• - For iBGP: understanding of the route-reflector or full-mesh topology

Procedure

Follow this diagnostic flow sequentially. Each step builds on the data from
prior steps. The procedure moves from broad inventory to targeted diagnosis.

Step 1: BGP Session Inventory

Collect all peer states and compare against expected topology.

[Cisco]
CODEBLOCK0

[JunOS]
CODEBLOCK1

[EOS]
CODEBLOCK2

Record each neighbor: address, AS number, state, prefixes received, up/down
time. Compare against expected topology — every configured peer should appear.
A peer missing from output means it was never configured or was removed. Any
peer not showing a numeric prefix count is not Established — proceed to Step 2
for that peer.

Step 2: Peer State Diagnosis

For any peer not in Established state, the BGP FSM state reveals the failure
domain. This is the core diagnostic reasoning step.

[Cisco]
CODEBLOCK3

[JunOS]
CODEBLOCK4

[EOS]
CODEBLOCK5

Interpret the FSM state to isolate the failure:

• - Idle → BGP process not attempting connection. Causes: administratively

shut down, no route to peer address, configured remote AS does not match, or
maximum-prefix limit hit triggering teardown.

• - Connect → TCP SYN sent, waiting for response. Peer is unreachable at

Layer 3 or a firewall is blocking TCP port 179.

• - Active → TCP connection attempt failed, retrying. Same causes as Connect

but the router has cycled back. Check: ACLs blocking port 179, peer not
configured for this neighbor, peer address unreachable.

• - OpenSent → TCP connected, OPEN message sent, no reply. Remote end

accepted TCP but is not sending OPEN — typically remote BGP not configured
for this neighbor or remote peer in admin shutdown.

• - OpenConfirm → OPEN received but parameters rejected. Check: AS number

mismatch, capability negotiation failure (AFI/SAFI mismatch), hold timer
negotiation failure, authentication (MD5/TCP-AO) mismatch.

Check "last reset reason" and "last error" fields — they often provide the
definitive cause. Reference: references/state-machine.md for full FSM detail.

Step 3: Route Table Analysis

For Established peers, verify prefix exchange matches expectations.

[Cisco]
CODEBLOCK6

[JunOS]
CODEBLOCK7

[EOS]
CODEBLOCK8

Compare received prefix count against baseline. Significant deviation indicates:

• - Drop >10% → upstream is withdrawing routes (maintenance, filter change, or failure)
• Increase >10% → route leak or new prefixes originated upstream
• Zero received → peer is Established but sending no routes (missing export policy

on JunOS, or outbound filter on remote blocking everything)

Check advertised prefix count similarly — confirm this router is sending the
expected number of routes to each peer.

Step 4: Path Selection Verification

When traffic takes an unexpected path, walk the BGP best-path algorithm to
identify which attribute is making the selection.

[Cisco]
CODEBLOCK9

[JunOS]
CODEBLOCK10

[EOS]
CODEBLOCK11

The best-path algorithm evaluates in this order (first difference wins):

1. 1. Weight (Cisco/EOS local, highest wins — JunOS does not use weight)
2. Local Preference (highest wins, default 100)
3. Locally originated (network/aggregate preferred over learned)
4. AS Path length (shortest wins)
5. Origin (IGP < EGP < Incomplete)
6. MED (lowest wins, compared only within same neighbor AS by default)
7. eBGP over iBGP (external preferred)
8. IGP metric to next-hop (lowest wins)
9. Router ID (lowest wins, tiebreaker)

Identify which attribute selects the current best path. If unexpected, check
the route-map or policy applying that attribute on ingress.

Step 5: Route Filtering Validation

Verify that route-maps, prefix-lists, and community filters apply as intended.

[Cisco]
CODEBLOCK12

[JunOS]
CODEBLOCK13

[EOS]
CODEBLOCK14

For suspected route leaks: examine the RIB for prefixes that should not be
present. Check inbound filters on the peer that is the source. Common leak
causes: missing or misordered prefix-list entry, regex error in AS-path
filter, community match that is too broad.

For missing routes: verify the outbound policy on the advertising peer is not
filtering the prefix. On JunOS, a peer with no export policy sends nothing by
default — this is the most common JunOS-specific omission.

Step 6: Convergence Assessment

Evaluate convergence behavior and route stability.

[Cisco]
CODEBLOCK15

[JunOS]
CODEBLOCK16

[EOS]
CODEBLOCK17

Check for dampened (suppressed) routes — these indicate persistent flapping.
Review the BGP update activity: high update/withdrawal rates indicate churn.
After a planned change, measure convergence time from the change event to the
last BGP update. Compare against the target convergence window.

Threshold Tables

Operational parameter norms for BGP — these are protocol-level expectations, not
device resource thresholds.

Parameter	Cisco Default	JunOS Default	EOS Default	Notes
Hold Timer	180s	90s	180s	Negotiated to lower value
Keepalive Interval

60s | 30s | 60s | Hold/3 by convention |
| ConnectRetry Timer | 120s | Varies | 120s | Time between TCP attempts |
| MRAI (eBGP) | 30s | 0s (immediate) | 30s | Minimum Route Advertisement Interval |
| MRAI (iBGP) | 5s | 0s | 5s | Lower than eBGP for faster iBGP convergence |
| Default Local Pref | 100 | 100 | 100 | Same across vendors |

Table Size Norms (IPv4 unicast):

Deployment Type	Expected Prefixes	Warning	Critical
Internet edge (full table)	~950K	>1M	>1.1M
Internet edge (partial)

5K–100K | Varies | Per design |
| Enterprise WAN | 100–10K | >2x baseline | >5x baseline |
| Data center leaf | 50–5K | >2x baseline | >5x baseline |

Convergence Targets:

Scenario	Target	Acceptable	Degraded
eBGP failover	< 90s	90–180s	> 180s
iBGP reconvergence

< 30s | 30–60s | > 60s |
| Full table reload | < 5min | 5–10min | > 10min |

Decision Trees

Peer Not Established

CODEBLOCK18

Unexpected Route Selection

CODEBLOCK19

Report Template

CODEBLOCK20

Troubleshooting

Session Flapping

Peer cycles between Established and Idle/Active repeatedly. Common causes:
unstable underlying transport (IGP flap, link errors), aggressive hold timers
on congested control planes, or MTU issues on the path causing fragmented
keepalives to be dropped. Check last reset reason and correlate with interface
or IGP events at the same timestamps.

Route Oscillation

The same prefix alternates between two or more paths. Caused by inconsistent
MED comparison across route reflectors, or deterministic-MED not enabled when
multiple exit points exist to the same neighbor AS. Enable always-compare-med
and deterministic-med to stabilize.

Memory Pressure from Full Table

Full Internet table (~950K IPv4 prefixes) requires 1–2 GB of RIB memory
depending on path diversity. Symptoms: slow convergence, peer resets during
table reload. Mitigate with soft-reconfiguration inbound (trades memory for
stability) or ORF (Outbound Route Filtering) to reduce inbound load.

Community Stripping

Routes arrive without expected communities. Check each transit AS in the path —
many providers strip non-standard communities by default. Use large communities
(RFC 8092) for end-to-end propagation across providers that strip standard
communities.

JunOS Default Export Policy

JunOS sends no routes to a peer without an explicit export policy. If a peer
shows Established with zero prefixes sent, add an export policy. This is the
most common JunOS-specific BGP issue and does not occur on Cisco or EOS.