← Problem Library
Network L6 NETWORK-1218 · 20 min

BGP routes appear after reset but disappear again because the route-map matches a community the upstream never sends persistently

A soft reset briefly changes the table, yet learned routes vanish again because policy depends on an attribute the peer path does not consistently carry.

NetworkFoundation OpsLevel 6Free20 min
Scenario

A peer begins showing routes after intervention, but the table empties again once normal policy evaluation resumes.

What to check first
  • Identify the primary failure signal in the Transient Policy Match 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

Verify the attributes your route-map expects are truly present and stable on the peer.

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

Community-field BGP policy problem inspired by Cisco Community discussions where routes appeared transiently because policy matched unstable or absent c... A route appearing once after reset does not prove the policy match is valid in steady state.

What usually causes BGP routes appear in production?

Teams often blame route dampening when the route-map condition is simply not met consistently.

What should you document after resolving BGP routes appear?

Community-based routing policy is brittle if peer-side attribute guarantees were never validated.