← Problem Library
Network L6 NETWORK-1248 · 19 min

A BGP session remains Established while one route class disappears because the route-map still depends on communities the upstream stopped exporting

Control-plane adjacency stays healthy, yet policy silently stops matching the routes it once admitted because the upstream attribute contract changed.

NetworkFoundation OpsLevel 6Free19 min
Scenario

A peering stays up after a provider-side change and one business-critical route class vanishes from the local table.

What to check first
  • Identify the primary failure signal in the Healthy Peer, Broken Policy Contract scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Validate which attributes the upstream still sends before changing local timers or reset behavior.

Questions worth viewing together
What should you verify first when A BGP session remains Established appears?

Community-field BGP problem inspired by operator and Cisco Community discussions where route classes disappeared after upstream community changes. An Established BGP session proves transport reachability, not that your policy assumptions are still valid.

What usually causes A BGP session remains Established in production?

Teams often suspect flap damping or soft-reset problems when the upstream simply changed the exported community set.

What should you document after resolving A BGP session remains Established?

Community-based routing policy is brittle without a stable upstream contract.