← Problem Library
Network L6 NETWORK-1231 · 19 min

BGP peering looks stable but only one prefix set disappears because a route-map now matches communities the upstream stopped sending

The session stays Established, yet one traffic class vanishes because policy still depends on attributes that are no longer guaranteed by the neighbor.

NetworkFoundation OpsLevel 6Free19 min
Scenario

A peer remains healthy and only one class of routes disappears after a provider-side policy change.

What to check first
  • Identify the primary failure signal in the Stable Session, Missing Policy Signal 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 the attribute assumptions behind the route-map, not just session stability.

Questions worth viewing together
What should you verify first when BGP peering looks stable but only one prefix set disappears appears?

Community-field BGP problem inspired by operator and Cisco Community discussions where routes vanished because community-based policy assumptions drifted. An Established BGP session says nothing about whether your policy still matches the same routes.

What usually causes BGP peering looks stable but only one prefix set disappears in production?

Teams often suspect route dampening when the upstream simply stopped sending the community the policy expects.

What should you document after resolving BGP peering looks stable but only one prefix set disappears?

Community-based route policy is brittle if upstream guarantees are undocumented or changed.