Monitoring, Troubleshooting, and Operations
What to monitor
Key signals are tunnel state (up/down), link quality (latency, loss, jitter from health probes), SLA compliance per path, flow/traffic analytics by application and class, and device health (CPU, memory, sessions). Orchestrator dashboards aggregate these; local appliance views show per-tunnel and per-interface detail. Alarms and syslog/SNMP feed external systems.
Troubleshooting method
Work bottom-up: underlay link up and addressed correctly, then health probes succeeding, then tunnel established, then routing reachable, then policy matching the intended class. Common faults: a probe target blocked so a healthy link is marked down; NAT/firewall blocking IPsec so no tunnel forms; asymmetric routing breaking stateful flows; a policy rule ordered above the intended one; DPI not identifying an app so it falls to default class.
Traps
- Treating a red tunnel as a routing problem when it is a probe or NAT problem.
- Ignoring that failover timing depends on probe interval and threshold settings.
- Looking only at Orchestrator when the issue is local to the appliance's path measurement.
- Forgetting to check both directions of a flow for asymmetric return paths.
Worked example
Users report poor voice quality at one branch. Check per-tunnel loss/jitter: if the preferred MPLS tunnel exceeds the SLA threshold but traffic has not moved, verify the BIO threshold and probe interval. If the backup internet tunnel is down, check NAT-T and firewall UDP. If both tunnels are healthy but voice is still poor, confirm DPI classified the flow into the real-time class and that QoS is applied.
Rule of thumb
Isolate layer by layer and confirm the measurement before the policy: a policy cannot steer around a path the appliance does not know is bad.