VoIP Degrades While Guest Wi-Fi Exceeds Its Shaper
An office runs a FortiGate 100F with WAN1 at 500/100 Mbps and WAN2 at 200/50 Mbps. Policy routes send VLAN 30 VoIP to WAN1, VLAN 40 guest Wi-Fi to WAN2, and VLAN 10 corporate traffic to WAN1. The administrator creates two traffic shaping policies: one broad policy at the top matching all sources and destinations with a shared shaper of 50 Mbps on WAN2, and one below matching VLAN 30 SIP/RTP with a per-IP shaper of 1 Mbps on WAN1. The intended design is 10 Mbps guaranteed for VoIP and 2 Mbps maximum per guest IP. During a nightly cloud backup from VLAN 10, VoIP calls drop and guest users report speeds well above 2 Mbps. The traffic shaping policy hit counters for the VoIP rule remain at zero. WAN interface bandwidth values were never set. No SD-WAN is configured. The administrator wants to fix shaping without changing the policy routes.
1. Why are the VoIP shaping counters zero and why does VoIP still degrade? Consider policy order, interface bandwidth, and shaper type.
Read the worked answer
The broad shaping policy at the top matches all sources and destinations, so it shadows the specific VoIP policy below it. The VoIP rule never gets evaluated, which explains zero hits for that rule. Even if the VoIP rule were reached, a per-IP shaper of 1 Mbps would cap each call or each source IP rather than guarantee 10 Mbps for VoIP as an aggregate. The guest problem is different: the only guest-relevant policy is a shared 50 Mbps shaper, not a per-IP 2 Mbps shaper, so a single guest can exceed 2 Mbps until the aggregate reaches 50 Mbps.
WAN1 and WAN2 interface bandwidth values are unset, so guaranteed bandwidth has no reference capacity and cannot be enforced reliably. Correct the order first, then use the right shaper type: a shared shaper with guaranteed bandwidth for VoIP, and a per-IP shaper with a maximum for guest.
2. Design the corrected shaping policies. Specify order, shaper type, and interface direction.
Read the worked answer
Place the VoIP shaping policy first: source VLAN 30, destination any, service SIP/RTP, outgoing interface WAN1, shared shaper with guaranteed 10 Mbps, maximum high enough for call load, and high priority. Place the guest policy next: source VLAN 40, destination any, service all, outgoing interface WAN2, per-IP shaper with maximum 2 Mbps. Keep the corporate policy below or add a shared bulk shaper only if the business wants to cap backup traffic.
Set WAN1 and WAN2 bandwidth values to the real uplink rates. Apply shaping on egress because FortiOS traffic shaping controls outbound bandwidth; if inbound VoIP reservation is required, use reverse shaper or upstream QoS on the ISP side. Do not put a broad all-traffic shaper above the VoIP rule, because it will consume the match. Verify that policy routes still forward traffic to the intended WAN and that the shaper is attached to that egress interface.
3. How would you verify that VoIP is actually getting 10 Mbps guaranteed during the nightly backup?
Read the worked answer
Check the VoIP shaping policy hit counters and the traffic shaping monitor during the backup window; the VoIP rule should show active sessions while the backup is running. Confirm WAN1 bandwidth is set and that the VoIP shaper is applied to WAN1 egress, not to an interface that does not carry the calls. Run a synthetic call or iperf test marked with the same SIP/RTP service and source VLAN, and capture traffic on WAN1 to confirm the calls are not being dropped or delayed.
Also verify that backup traffic is not bypassing shaping through another policy, policy route, or application control path. Check session lists for the backup and VoIP flows, confirm the backup is treated as bulk or low priority, and review interface utilization. If VoIP still degrades, check ISP policing, upstream congestion, and whether reverse-path inbound shaping is needed; guaranteed egress bandwidth cannot protect against ISP downstream congestion.