AAR, DIA, and Firewall Insertion for Voice and SaaS
A financial services firm has 90 branches. Each branch has 100 Mbps MPLS, 300/50 Mbps broadband, and LTE backup. Cisco Webex voice is business-critical and currently rides MPLS; SaaS traffic (Salesforce, Microsoft 365) backhauls to Chicago, giving London users 180 ms latency. Broadband shows 8% packet loss at peak and 60 ms latency; MPLS shows 0.1% loss and 40 ms. The firm wants local internet breakout for SaaS and guest traffic, but security requires inspection at a London firewall with 2 Gbps capacity. Voice must prefer MPLS, use broadband only if MPLS fails, and must never use LTE unless both primary paths fail. The trading application must stay on MPLS. The company uses VPN segmentation for corporate, guest, and voice.
1. Define the AAR SLA classes, application lists, and policy order for voice, trading, SaaS, and default traffic.
Read the worked answer
Create explicit SLA classes rather than one generic threshold. Voice-Strict: loss under 1%, latency under 150 ms, jitter under 30 ms. Critical: loss under 1%, latency under 100 ms. Default: looser thresholds. Build application lists for Webex/voice (UDP 3478 and RTP ranges), the trading application by IP/port, SaaS by application signature, and guest by VPN.
Policy order is top-down and must put voice above SaaS because Webex can match SaaS categories. First match voice: strict SLA, preferred MPLS, backup broadband, and restrict LTE. Second match trading: strict MPLS only, with no internet backup. Third match SaaS: preferred broadband, backup MPLS, and direct internet breakout. Fourth match guest: separate VPN, local internet only. Fifth default: best available path. The restriction on LTE is a policy action, not a routing accident; if voice simply 'prefers' MPLS, LTE can still win during a broadband SLA violation. Use BFD timers that detect real failures without flapping, and validate with synthetic voice traffic.
2. How would you design DIA and service insertion when the only inspection firewall is in London?
Read the worked answer
Backhauling all SaaS to Chicago is the latency cause; backhauling all SaaS to London would recreate it. Use local internet breakout for SaaS and guest. The London firewall at 2 Gbps may have enough aggregate capacity, but sending every branch's SaaS through London adds delay and creates a central failure point. A better design is cloud-delivered security (SIG/Umbrella) at the branch for SaaS, with the London firewall retained for traffic that must reach the data center. If the security policy absolutely requires the London firewall, breakout only selected SaaS traffic to London; do not send guest traffic there unless required.
Use VPN segmentation: corporate SaaS in VPN 1 with DIA and service insertion to the cloud security layer; guest in VPN 2 with local NAT and no route to VPN 1; voice and trading stay on MPLS. Apply NAT pools per VPN so return traffic is symmetric. Service insertion must be policy-based, not default-routed, or all internet traffic will be inspected and the 2 Gbps firewall becomes the bottleneck.
3. How do you enforce the no-LTE rule for voice and avoid asymmetric routing with DIA?
Read the worked answer
Enforce no-LTE in the AAR policy with a restrict action for voice, and also exclude LTE from the voice SLA class. Do not rely on LTE being 'less preferred'; a preferred-color action can still select LTE if the primary path violates SLA or BFD fails. The policy should explicitly drop or hold voice rather than use LTE unless both MPLS and broadband fail, which is a deliberate business decision.
For asymmetric routing, keep inspected flows on one egress. With DIA and a stateful firewall, the return path must pass through the same firewall; use service insertion at the branch or a cloud security service that sees both directions. Avoid ECMP across MPLS and internet for inspected SaaS. Use per-flow hashing and sticky NAT. For voice, test failover by degrading MPLS and broadband separately, and confirm that LTE is only used after both fail. Check that the voice policy is above any default SaaS policy.