The NOC sees a branch site lose reachability to the data center every few minutes, and one engineer suspects the tunnel rather than an application. Your runbook requires checking control connections, BFD sessions and tunnel state through the SD-WAN Manager APIs before any policy change. Which order of API checks gives you a layer-by-layer readout of where the failure starts?
Select an answer to reveal the explanation.
Short Explanation
Check control connections first, BFD sessions second, and tunnel statistics last—like tracing a problem from the outer layer inward. Each step adds detail, and healthy BFD sessions don’t rule out a control-connection issue.
Full Explanation
SD-WAN Manager (formerly vManage) provides separate read APIs for control connections, BFD sessions, and tunnel statistics. Checking them in sequence organizes troubleshooting from controller connectivity to peer liveness and then tunnel traffic counters. A control-connection issue can affect control-plane functions, but it does not necessarily mean that an existing BFD session or data-plane tunnel is down. BFD session state helps assess overlay peer liveness; it does not, by itself, identify the cause of a failure as an underlay problem. Tunnel statistics provide traffic counters for the tunnel, but they do not necessarily explain why a symptom occurred. Reading these views in sequence gives the runbook a consistent chain of evidence. Querying only BFD state skips the control-connection check the runbook requires. Starting with tunnel statistics reverses the requested order. Changing policy first violates the stated order and risks altering forwarding before the failure is understood. API endpoint names can vary by release, so consult the documentation for the installed version. In a lab, bring down a tunnel and observe which views change.