SD-WAN for Voice, HDX, and a 400 GB Nightly Copy
A logistics company runs Citrix SD-WAN at HQ (two 4100 appliances in HA, 500 Mbps MPLS to the carrier, 1 Gbps fibre internet) and at two branches using 210 appliances. Branch 1 has 100/100 Mbps fibre plus a 25/10 Mbps LTE backup; branch 2 has 200 Mbps MPLS and 100/100 fibre. HQ hosts 900 HDX users and each branch has 50-90. There are 200 concurrent SIP calls between sites and a nightly Veeam copy of 400 GB to HQ that must complete by 06:00 without disturbing interactive traffic. Targets are voice MOS above 4.0 and ICA round-trip below 150 ms. Branch 1 shows 4-6% loss and 90 ms jitter on the LTE link in the evening. The security team has licensed the SD-WAN firewall and IPS and wants all branch-to-HQ traffic inspected, including ICA on 443 and 2598.
1. Design the virtual paths and QoS classes. Where would you deliberately avoid per-packet path selection, and why?
Read the worked answer
Virtual paths. HQ-to-branch-2 rides MPLS as the primary path with fibre as a secondary path in Dynamic (per-flow, quality-based) mode. HQ-to-branch-1 uses fibre as the primary path and LTE as a secondary path, also Dynamic. Reserve Auto (per-packet) only for paths with similar latency and jitter; branch 1's LTE at 90 ms jitter against a fibre path with far lower latency will reorder packets, and TCP as well as HDX/EDT interpret reordering as loss and back off. Per-packet is the wrong tool wherever the two paths have materially different round-trip times.
QoS classes:
- Real-time (SIP/RTP): priority, DSCP EF, guaranteed bandwidth of roughly 25 Mbps on MPLS (200 calls at about 87 kbps plus overhead), no upper rate limit that would clip calls, and packet duplication to fibre and LTE for branch 1 if the release supports it for that class.
- Interactive (HDX/ICA): high priority, shaped but generous, and protected from the backup by the scheduler; ICA is bursty and latency-sensitive, so give it priority over bulk rather than a tight ceiling.
- Bulk (Veeam): lowest priority, rate-limited so 400 GB fits the window. 400 GB in ten hours averages about 90 Mbps, so a 120-150 Mbps cap with best-effort scheduling is realistic; run it after 20:00 and send it over internet where policy allows.
- Default/business: fair-share remainder.
Verify that the configured WAN link speeds match reality, because shaping is calculated from them, and confirm the MPLS provider honours DSCP or the markings are cosmetic.
2. After IPS is enabled, ICA fails at branch 2 but works at branch 1. How do you diagnose it, and how do you keep inspection without breaking HDX?
Read the worked answer
A failure on one branch and not the other points to a path-specific or policy-specific cause, not a global misconfiguration.
Diagnosis:
- Check the drop location. Read the SD-WAN firewall and IPS event logs for the branch-2 appliance around the failure time, filtered on 443 and 2598. A signature hit with a reset is a false positive; no log entry at all means the traffic is being dropped or fragmented before inspection.
- Check MTU and fragmentation. Secure virtual paths add encapsulation overhead, and ICA often sets the DF bit. If the effective path MTU is smaller than the client's MSS, large packets vanish and ICA degrades or fails. Test with DF-bit pings across the path, and apply MSS clamping or reduce the interface MTU.
- Check path symmetry. If dynamic path selection moves one direction onto a different path mid-flow, a stateful firewall sees a half-open flow and drops it. Confirm both directions of the ICA flow use one virtual path and that state is preserved.
- Check HA state sync if the branch-2 pair has recently failed over; an unsynchronised firewall state table resets established flows.
Fix without disabling protection: move the HDX class into an inspection-exempt or bypass profile and inspect it at HQ after decryption, or disable the specific false-positive signature for that class while keeping the rest of the policy. Do not turn off IPS globally, and record the exemption with an owner and a review date.
3. A WAN link failure on the active HQ appliance caused a 90-second voice outage. What would you check, and how would you prove path quality to the business afterwards?
Read the worked answer
The 90 seconds is too long for a healthy pair and suggests two separate problems.
First, link-failure detection: check the probe or failover thresholds on the WAN link and the virtual path. If detection alone accounts for tens of seconds, voice is already gone before any switchover starts. Tune the failure-detection intervals against the jitter and loss you actually see, rather than setting them so tight that the LTE backup triggers on normal evening variance.
Second, HA behaviour: confirm the two appliances are synchronised, that VRRP and security state (firewall sessions, IPS state, IPsec keys) replicate, and that the LAN-side gateway moves cleanly. If the firewall state table was not synchronised, established RTP and ICA flows reset even though the failover itself was fast.
Third, path policy: verify that voice fails to the backup path rather than waiting for the primary to be declared dead, and that the backup path has the reserved real-time bandwidth to take the calls.
Proving quality: SD-WAN Center provides per-virtual-path loss, latency, and jitter plus per-class bandwidth, which is the right evidence for the voice and backup questions, but it does not provide user-level ICA round-trip. That comes from ADC AppFlow into Citrix ADM (HDX Insight). Sync all three systems to the same NTP source, then compare ADM's ICA RTT spikes with SD-WAN's path jitter over the same five-minute window: jitter on both implicates the WAN, RTT spikes in ADM with a clean path implicate the data centre, and gaps in both point at measurement rather than the network.