A government Catalyst SD-WAN edge has up control connections to its controllers, but BFD to the AWS cloud-gateway TLOC is down and no cloud traffic flows. Where should the engineer look first?
Select an answer to reveal the explanation.
Short Explanation
You can think of the control connections as a phone call to headquarters that’s fine while the truck still can’t leave the yard. Since BFD to the cloud TLOC is the data-plane path, check underlay reachability and the firewall in front of it first.
Full Explanation
Catalyst SD-WAN separates control from data. Control connections to the controllers can be up while BFD between the edge and the AWS cloud-gateway TLOC is down. BFD is the data-plane session that must pass across the internet underlay, often through NAT. A local firewall that permits control ports but blocks the data-plane path can produce exactly this split, so check underlay routing, NAT, and the firewall first. The controller certificate has already been accepted; if it were rejected, the control connections would not be up, and a certificate problem would not selectively take down one cloud TLOC. The Cloud OnRamp for SaaS application list affects how SaaS applications are steered; it does not bring up BFD to an AWS cloud gateway, and a private VPC prefix is not a SaaS application list. A BGP password on the campus LAN switch might prevent user routes from entering the edge, but it does not stop BFD on the WAN TLOC. Exam caveat: once BFD is up, a missing prefix shifts the investigation to OMP or cloud-side routing; do not start there while BFD is down. Practical check: show sdwan bfd sessions should show the cloud TLOC up after the firewall permits the data-plane path, while show sdwan control connections stays up throughout.