DPD marks one AWS tunnel down and BGP withdraws its routes. A static route at distance 1 for the VPC prefix still points at that dead tunnel, and traffic blackholes. What is keeping the bad path?
Select an answer to reveal the explanation.
Short Explanation
You found the static route keeping traffic on the dead tunnel: its distance of 1 still beats BGP after BGP withdraws the VPC route. DPD does not pin that route in place; it was already preferred before the tunnel went down.
Full Explanation
Administrative distance 1 makes the static route more preferred than eBGP at distance 20. When DPD declares the tunnel down and BGP withdraws the VPC prefix, that static route remains installed and continues sending traffic into the dead tunnel, causing the black hole. DPD does not pin a static route to a tunnel; it detects the peer failure, while the static route’s preference is what keeps the bad path active. OSPF on the virtual private gateway is not reinstalling the tunnel at distance 110: the virtual private gateway does not run OSPF in this scenario. The IKE lifetime does not rewrite the static next hop when DPD fires; it does not change this route selection. The fix is to remove the static route or raise its distance above 20 so it can serve as a backup rather than override BGP. Exam caveat: a floating static aimed at a different, healthy tunnel can be useful, but a static aimed at the tunnel that failed creates this black hole. Practical check: inspect the route for the VPC prefix; after removing the distance-1 static, it should use the remaining BGP path.