BGP Learned the Prefix, but Traffic Still Skips the Tunnel

The branch gateway shows the cloud prefix in its BGP table, the session to the provider is established, and a user's request to that prefix still leaves through the wrong interface. Nothing is broken in the way the monitoring suggests, because "BGP learned it" is a statement about the control plane. Between that table and the packet there are four separate transitions, and the flow stops at exactly one of them. Walk the gates in order and stop at the first one that fails.

First gate: what the neighbor actually sent

Start with the prefix as received, not as summarised. Look up the exact network and mask in the BGP table and record the next hop, the AS path and any community that an import policy might match. A summary route in a dashboard can hide the fact that the specific prefix was never accepted.

Import policy is the usual place a route disappears without an error. A prefix list, a community filter or an inbound route map can drop the update while the session stays up and healthy, which is why a green neighbor light proves so little. The absence of a log line does not mean the absence of a decision. It usually means the decision was made silently, exactly as configured.

show ip bgp 10.60.20.0/24
show ip bgp neighbors 203.0.113.5 advertised-routes
show ip route 10.60.20.0
show ip cef 10.60.20.0

Read the output in that order. The first two tell you whether the information arrived and what the peer says it sent; the last two tell you whether anything reached the routing and forwarding tables. A prefix present in the first command and absent from the third is a selection or installation problem, not a connectivity problem.

Second gate: selection, then installation

BGP chooses a best path, and the chosen path is not automatically installed. The next hop has to resolve, and another route source may already own that prefix with a better administrative distance. A static route left over from the migration will happily win over a valid BGP path and send the traffic somewhere else.

RFC 4271 keeps three ideas apart: what a peer sent, what this speaker chose as best, and what it will advertise onward. Those are conceptual roles rather than three physical databases a vendor must expose, but the separation is exactly what makes "it is in BGP" an incomplete answer.

Also check which routing context you are reading. A route installed in a VRF that the user's interface does not belong to is invisible to that user's packets, and the table looks correct the whole time.

Third gate: the lookup that applies to this flow

Now stop asking about the route and start asking about the packet. Record the user's source address, destination, protocol, port and ingress interface, because every one of those can select a different policy. Then look at the lookup that applies to that combination rather than the general routing table.

ip route get 10.60.20.25 from 10.60.10.40
ip rule show
sudo tcpdump -ni tun0 'host 10.60.20.25'

A more specific prefix is the most common surprise here, and a policy route is the second. Both override the aggregate you were looking at, and neither is visible in a summary of the BGP table.

A ping sourced from the gateway itself is not evidence about a user's session. Different source address, different policy path, and often a different result. Test with the same source the application uses, or accept that the test answers a different question.

Fourth gate: the remote half of the path

If the local lookup does select the tunnel, the packet still has to be accepted by the protection policy, permitted by the forwarding rule, and answered by something on the far side. A crypto ACL that does not include the address pair will drop the traffic while the tunnel reports itself up, which produces a timeout indistinguishable from a routing failure.

The return path matters as much as the outbound one. The cloud side has to know how to reach the branch source, either through a route or through a translation you configured deliberately. Asymmetric return paths are common in designs that were tested from one direction only.

Correlate a fresh authorized connection across three observations: the local policy that matched, the tunnel counters that moved, and the receipt on the remote side where that is visible. If the counters do not move, the packet never entered the tunnel regardless of what the route table says. If they move and nothing arrives, the far side is dropping or misrouting it. Those two outcomes lead to completely different teams.

Name the transition that failed

Write the result as one of five states: not received, not accepted by policy, not selected, not installed, or not matched by this flow. Add a sixth for the case where the local path is correct and the remote end cannot answer. That sentence is the deliverable, and it is far more useful than a screenshot of an established neighbor.

Keep a negative test in the acceptance plan as well: a destination that must not traverse the tunnel, verified after the change. A checklist that only proves the happy path will not catch the broad policy rule someone adds at the next maintenance window.