← Problem Library
Network L6 NETWORK-1223 · 20 min

BGP routes appear and disappear because the policy matches on a community that one upstream path strips during normal convergence

The peering session is healthy, yet accepted routes fluctuate because the attribute your route-map expects is not stable across all upstream paths.

NetworkFoundation OpsLevel 6Free20 min
Scenario

A route-map based on BGP community works right after reset and then loses routes during later convergence.

What to check first
  • Identify the primary failure signal in the Community Match Drift 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 that the expected community attribute survives on every steady-state path, not just after a reset.

Questions worth viewing together
What should you verify first when BGP routes appear and disappear appears?

Community-field BGP policy problem inspired by community discussions where routes flapped because policy matched communities that were not consistently... A route appearing once after a reset does not prove your policy match is stable.

What usually causes BGP routes appear and disappear in production?

Teams often blame route dampening when the upstream attribute is actually not persistent.

What should you document after resolving BGP routes appear and disappear?

Community-based route policy is fragile if upstream attribute guarantees were never validated.