Vantage Media: Peak-Hour Degradation on a Branch Service Connection
Vantage Media's São Paulo office houses 900 staff on a 300 Mbps internet circuit shared with guest Wi-Fi. A single service connection over that circuit carries all office traffic to Prisma Access; there is no local breakout and no second circuit. Between 10:00 and 14:00 local time, Microsoft Teams calls pixelate and drop and SharePoint feels slow; outside that window, staff report normal performance.
Prisma Access Insights shows the service connection up throughout, but latency to the branch rises from 60 ms to 180 ms and packet loss reaches 2–4 per cent in the same window. Mobile users in Brazil report only mild degradation. No QoS profile is applied to the service connection, the office router performs no egress shaping, and the guest SSID is unrestricted. ADEM is licensed but has only recently been enabled on office endpoints. The CISO wants a decision: buy a second circuit, upgrade the existing one to 600 Mbps, or escalate to Palo Alto to fix Prisma Access.
1. Set out the triage sequence: what you would collect, in what order, and what each result would rule in or rule out.
Read the worked answer
Step 1 - Localise the fault to a segment
The most useful early observation is already in hand: mobile users in Brazil are only mildly affected while the office is severely affected. Mobile users do not traverse the São Paulo circuit or office router. That substantially reduces the probability that the Prisma Access compute location, the backbone or the security processing layer is the cause, and points at the branch circuit or the LAN in front of it.
Step 2 - Prove where loss begins
- Pull ADEM data for office endpoints during 10:00–14:00: hop-by-hop latency and loss, plus Teams call quality metrics. If loss appears on the first hop past the office router, the LAN or router is implicated. If it appears on the ISP segment, the circuit is.
- Compare with tunnel monitoring from the Prisma side toward the branch router. Loss seen from both directions on the same segment is the circuit.
- Run an independent probe (a small test host on a separate path, or an endpoint on a mobile hotspot) at the same time to distinguish congestion from provider fault.
Step 3 - Correlate with load
Read the ISP router interface counters for the 300 Mbps uplink across the day. If utilisation approaches line rate exactly in the degraded window, this is congestion, not a Prisma fault. Check the guest SSID client count and volume for the same window.
Step 4 - Exclude the tunnel itself
Confirm the tunnel stays up, that rekeys are not coinciding with the window, and that no QoS or bandwidth limit is applied on the Prisma side. Rule out a routing change or a second path being preferred in the same hours.
Only after these steps does escalation to the vendor make sense, and it should carry the evidence rather than a symptom description.
2. Based on the likely findings, identify the bottleneck and explain precisely what a Prisma Access QoS profile can and cannot fix.
Read the worked answer
The bottleneck
Latency rising from 60 to 180 ms with 2–4 per cent loss, confined to the busiest four hours and confined to traffic that crosses the branch circuit, is the classic signature of a saturated uplink with deep buffers: queueing delay plus tail drop. A 300 Mbps circuit shared with an unrestricted guest SSID and no egress shaping has no mechanism to protect real-time traffic when demand exceeds capacity. The circuit is not broken and Prisma Access is not misbehaving; the office is simply out of capacity at peak, and unclassified traffic competes equally with voice and video.
What Prisma Access QoS can do
A QoS profile on the service connection classifies traffic leaving Prisma Access toward the branch and inside the tunnel, so Teams and other real-time flows can be placed in a high-priority class ahead of bulk downloads and software updates. That removes one source of competition and improves behaviour when the tunnel itself is the constrained resource. It also gives visibility into which applications consume the link.
What it cannot do
It cannot stop guest Wi-Fi or general browsing from saturating a 300 Mbps local loop before the tunnel is even involved, and it cannot influence ISP-side queuing or the local router's egress scheduler. Marking inside the tunnel is preserved end to end only if the customer device respects it. So a QoS profile alone will produce a modest improvement at best while the circuit remains oversubscribed by unmanaged traffic.
Implication
The fix has to include shaping and capacity at the branch, with Prisma-side QoS as a complement rather than the answer. Anyone promising that a QoS profile alone resolves this has not looked at where the packets are queued.
3. Recommend a target design and a sequenced plan, with the expected effect of each step, and address the CISO's three options directly.
Read the worked answer
Immediate (days, low cost)
- Apply egress shaping on the office router toward the service connection, prioritising the tunnel and real-time classes and deprioritising bulk.
- Cap the guest SSID - for example 30–40 Mbps with per-client limits - and move guest traffic behind a rate-limited policy.
- Apply a QoS profile on the service connection so real-time applications drain first and bulk transfers are constrained.
Expected effect: peak-hour latency and loss should fall materially because the queues that cause them are being fed less. Measure with ADEM before and after; if latency at 10:00 drops to within 20 ms of the 06:00 baseline, congestion was the whole story.
Short term (weeks)
- Pull circuit utilisation data for 30 days and decide on bandwidth from evidence. If P95 utilisation is already at 85–90 per cent of 300 Mbps after shaping, an upgrade to 600 Mbps is justified; if it is 55 per cent, an upgrade buys headroom for growth but will not fix a scheduling problem.
- Consider local internet breakout for trusted SaaS at the branch, keeping the service connection for data-centre and internal traffic. This removes the hairpin to a compute location for traffic that never needed it and cuts both latency and tunnel load.
Structural (quarter)
- Add a second circuit from a different ISP with its own service connection tunnel. This is the option that addresses both the peak-capacity problem and the current single point of failure; today a circuit outage removes all branch connectivity to the data centre.
Answering the CISO directly
A second circuit, yes - but for redundancy and capacity, not as the first move. A 600 Mbps upgrade, only if utilisation data supports it. Escalating to fix Prisma Access, no: the evidence points to the branch edge, and the vendor case would not survive the first question about the local uplink.