AmrudAi — AI IT observability
Book a demo
Home Resources SD-WAN Monitoring: Paths, SLAs and Troubleshooting

Technical guide

How do you monitor SD-WAN beyond tunnel uptime?

SD-WAN monitoring should connect circuit and tunnel state with path quality, policy decisions and the application a user is trying to reach. A healthy tunnel alone does not establish a healthy service. This AmrudAi guide explains the measurements, their limits and a practical evidence sequence for investigating a branch performance complaint.

Which layers should the monitoring record separate?

A useful investigation model keeps the customer service, provider circuit, transport path, tunnel and forwarding policy identifiable. This is a practical way to organize evidence, not a requirement that every vendor expose the same objects or APIs. Start with the application and location affected, then map the observations available for each dependency.

Separate SD-WAN evidence before combining conclusions
Layer Questions to ask Evidence boundary
Underlay and circuit Which edge, provider and transport are involved? What changed? A provider notice or link state alone does not establish application impact.
Overlay and policy Which tunnel and policy selected the path for this traffic? Tunnel reachability does not prove the intended application operation succeeded.
Application and service Which users, destinations and assertions are affected? A test observes its own location, path, credentials and time window.

What must accompany loss, latency and jitter?

Treat a metric name as the beginning of its definition. One-way delay requires a defined source, destination, packet type and timestamp basis; clock uncertainty affects its interpretation. A two-way result measures a different path combination. TWAMP specifies a two-way measurement protocol, but its availability and configuration must be checked for the equipment being evaluated.

Record enough context to compare path measurements
Measurement Record with the value Avoid assuming
Delay Direction, endpoints, method, packet class and timestamp uncertainty. A round-trip value is a directly measured one-way delay.
Packet loss Sent/received sample, observation window and loss timeout. A small sample or an unavailable collector proves a carrier-wide fault.
Delay variation The specific variation definition, sample set and aggregation. Every vendor uses the same meaning for jitter.
Freshness Last successful measurement, API lag and collection status. An old green value describes the current service.

Primary reference: RFC 7679 — A One-Way Delay Metric for IPPM ; RFC 5357 — Two-Way Active Measurement Protocol ; RFC 7680 — A One-Way Loss Metric for IPPM ; RFC 5481 — Packet Delay Variation Applicability Statement .

Why is BFD state not an application success test?

BFD is designed to detect faults in a bidirectional forwarding path. Its state is valuable reachability evidence, but the protocol does not by itself validate an application transaction, DNS answer, TLS handshake or user authorization. Keep the question “is this forwarding path alive?” separate from the question “did the required service operation succeed?”

Primary reference: RFC 5880 — Bidirectional Forwarding Detection .

A named implementation example illustrates another limit. Cisco Catalyst SD-WAN application-aware routing uses tunnel measurements for loss, latency and jitter classification. Its documentation explains configurable collection windows and notes that high-priority BFD probes can experience different treatment from application traffic. Those implementation details are not universal defaults for all SD-WAN vendors or releases.

Primary reference: Cisco IOS XE Catalyst SD-WAN 17.x — Application-Aware Routing .

How should policy thresholds and service commitments be compared?

Keep the routing policy version, traffic class and measurement period beside the observed path choice. A dashboard average may cover a different window from the user’s complaint. The same numeric threshold is not automatically suitable for voice, interactive requests and bulk transfer; evaluate the intended application and the measurement method rather than copying a universal threshold.

A routing product’s SLA class is also not automatically the customer’s contractual service-level calculation. Identify the relevant service definition, eligible period, exclusions and evidence before attributing a breach. Retain independent observations and provider context so a policy decision can be explained without turning temporal coincidence into a root-cause claim.

An illustrative branch complaint: build the evidence sequence

Suppose a branch reports intermittent API timeouts while its tunnels remain up. The aim is to narrow the explanation with comparable observations. This example does not assert a customer result, a universal device capability or automatic remediation.

  1. Scope the affected operation

    Record branch, application endpoint, reported time and affected users. Define a permitted assertion that reflects the failing operation.

  2. Confirm measurement health

    Check freshness, collector execution, authentication and API lag. A stale measurement belongs in the uncertainty record.

  3. Map the selected path

    Identify the available circuit, tunnel and policy evidence for the traffic class. Preserve path changes within the incident window.

  4. Compare like with like

    Align source, destination, direction and aggregation windows. Compare an independent service check with path measurements without treating them as identical tests.

  5. Examine changes and alternatives

    Review authorized configuration, routing and provider-event evidence. Check DNS, TLS and endpoint conditions before attributing every timeout to transport.

  6. Validate the outcome

    After an authorized action, repeat the affected assertion and review path evidence over the agreed interval. Preserve remaining uncertainty and escalation ownership.

What should an SD-WAN evaluation demonstrate?

Acceptance evidence for a supported SD-WAN profile
Area Demonstrate Keep explicit
Coverage Required sites, edges, circuits, tunnels and supported API fields. Vendor, release, adapter, permissions and licensing scope.
Quality Known delay/loss conditions and collector/API interruptions. Measurement semantics, freshness and unknown states.
Policy and failover Path changes and the corresponding service observations. Authorized test conditions and the limits of the available evidence.
Escalation A reproducible circuit/provider incident record. Owner, timestamps, source observations and contradictory results.

Use representative conditions and agreed stop criteria in an authorized evaluation. The acceptance record should show unsuccessful and inconclusive cases as well as successful collection. A colorful map, a reachable tunnel or a provider status page is not a substitute for that evidence.

How does this guide relate to AmrudAi?

AmrudAi’s documented branch and provider workflows connect path observations, collection health, topology, provider context and service investigation. Optional integration with the separate AmrudAi NCM product can add configuration-change evidence. Confirm the selected release, adapters, permissions and test capabilities; this guide does not establish universal vendor coverage, a running implementation or automatic privileged remediation.

Continue with: Branch, WAN and SD-WAN scope · Cross-site performance evidence · Provider-network operations · Separate AmrudAi NCM product .

Common questions

What is a good universal jitter threshold?

There is no single threshold established by this guide. Define the application requirement, variation metric, packet class and measurement window, then validate the policy with representative traffic and supported equipment.

Does a provider outage notice prove the cause?

It is external evidence to compare with the affected circuit, time and observed service behavior. A notice can support an explanation, but unrelated symptoms, stale measurements or contradictory paths must remain visible.

Sources and evaluation boundaries

Sources checked on 20 October 2026. Protocol facts are attributed to their publishers. Worked examples and acceptance questions are illustrative guidance, not customer results or product certification.

  1. RFC 5880 — Bidirectional Forwarding Detection
  2. RFC 5357 — Two-Way Active Measurement Protocol
  3. RFC 7679 — A One-Way Delay Metric for IPPM
  4. RFC 7680 — A One-Way Loss Metric for IPPM
  5. RFC 5481 — Packet Delay Variation Applicability Statement
  6. Cisco IOS XE Catalyst SD-WAN 17.x — Application-Aware Routing

Continue with: Routing and network services · Service assurance · Evaluation guide .

Technical authorship & review

Publisher: AmrudAi . This content is checked against documented product architecture and cited technical sources. Content updated: . Descriptions of planned or adapter-dependent capabilities are not a release certification. Confirm the supported version and acceptance evidence during evaluation.