An enterprise runs voice and video over dual Internet links, needs sub-second failure detection, and wants SD-WAN to steer traffic using live loss, latency and jitter per tunnel. Which BFD design on tunnels best provides purpose, timers and path-quality measurement?

The correct design succeeds because running BFD directly on each IPsec tunnel with aggressively tuned hello intervals and multipliers provides both sub-second liveness detection and continuous calculation of loss, latency and jitter that the SD-WAN edge reports for application-aware path selection for voice and video across dual Internet links. BFD tied only to BGP and OSPF neighbors is a sound design for fast routing convergence but fails by concept because it validates control-plane adjacency rather than per-tunnel data-plane quality, so it cannot supply per-path SLA metrics needed to steer traffic. BFD per tunnel with default timers is a legitimate conservative design that does collect SLA metrics for path selection but fails the explicit sub-second requirement because slow hellos delay failure detection and reaction beyond voice and video tolerances during brownouts. BFD per tunnel with tuned hellos used solely for hardware liveness is common for simple up-down monitoring but fails the steering purpose because measurements are not integrated into centralized policy to dynamically select the best path on quality thresholds. A frequent exam caveat is to distinguish OMP timers and routing-protocol BFD, which signal reachability and convergence, from tunnel BFD performance monitoring, which drives SLA-based forwarding, since questions often test timers and measurement purpose together. As a practical check, verify matching BFD intervals and multipliers on both tunnel endpoints, confirm SD-WAN Manager shows live loss, latency and jitter per tunnel, then impair one Internet link and confirm voice moves to the healthy link once the SLA change is detected.