SD-WAN Brownout in a Healthcare Network
A healthcare provider operates two hospitals and 12 clinics. Each site has a FortiGate 100F or 200F, MPLS, and broadband; the hospitals also have 5G backup. Clinical traffic includes Epic EHR to a central data center, VoIP between clinics and hospitals, and cloud imaging. The provider uses FortiManager and ADVPN. During a two-hour broadband brownout at one clinic, Epic traffic shifted to MPLS, VoIP jitter rose above 80 ms, and some imaging uploads failed. The SD-WAN rules prefer broadband for Epic and MPLS for voice, but engineers found that return traffic from the data center sometimes used a different path. The clinic has a 100/20 Mbps broadband link and a 20 Mbps MPLS circuit. The CIO wants local internet breakout for cloud imaging but will not accept clinical downtime. The compliance team requires that clinical traffic remain encrypted and that cloud egress be inspected.
1. Diagnose the likely cause of the path asymmetry and VoIP jitter during the brownout. What would you check first?
Read the worked answer
Check whether the SD-WAN rule and the return path use the same criteria. A common cause is that outbound Epic traffic at the clinic switches to MPLS when broadband SLA fails, but the data center’s SD-WAN rule still prefers broadband back to the clinic, or the data center uses a different health-check target and does not detect the brownout. That creates asymmetric routing, retransmissions, and jitter. For VoIP, check whether voice was actually pinned to MPLS in both directions, whether the 20 Mbps MPLS circuit was saturated by shifted Epic traffic, and whether QoS honored EF marking across the ADVPN shortcut. Also check health-check intervals and failover thresholds: aggressive probes can flap, while slow probes leave traffic on a degraded link. Verify that ADVPN shortcuts were rebuilt after the path change. The first evidence to collect is per-link SLA history, SD-WAN rule hits, route selection, and QoS drops at both ends. The judgement is to fix bidirectional path symmetry and capacity before adding more rules.
2. Redesign the SD-WAN rules and health checks for Epic, VoIP, and cloud imaging given the 100/20 Mbps and 20 Mbps links.
Read the worked answer
Use per-application intent with bidirectional symmetry. For VoIP, pin both directions to MPLS with a 5G backup only when MPLS latency and loss cross strict thresholds; reserve bandwidth with QoS and avoid sending voice over broadband unless the SLA is proven. For Epic, prefer MPLS for the clinic because the 20 Mbps circuit is small, but allow broadband when MPLS is down; use multiple health-check targets, longer failure thresholds, and hysteresis to prevent brownouts from causing flapping. For cloud imaging, use local internet breakout to FortiSASE with inspection, but schedule bulk uploads and cap bandwidth so they cannot starve Epic or voice. If imaging is clinical-critical, give it a separate rule and queue rather than sharing Epic’s path. Health checks should test the actual path and application endpoint where possible, not just a public DNS server. Validate by simulating loss and delay on each link and confirming that return traffic follows the same path.
3. How would you integrate secure SD-WAN with SASE for cloud imaging without weakening clinical compliance?
Read the worked answer
Use the FortiGate as the SD-WAN edge and SASE on-ramp, not as a bypass. Cloud imaging traffic should be identified by application and destination, then steered directly to the nearest FortiSASE PoP over an encrypted tunnel for inspection, CASB/DLP where applicable, and logging. Keep clinical EHR traffic on the private MPLS/ADVPN path and do not force it through the internet. Apply the same identity and data policy at the edge and in FortiSASE, and ensure that failover to 5G does not skip inspection. For compliance, log the path, inspection result, and destination for imaging flows, and document why EHR is exempt from internet breakout. The judgement is to segment by clinical risk: imaging can use local breakout with inspection, while EHR remains private. Test with a clinic pilot and a simulated broadband failure before enabling all 12 clinics.