I am not sure if my implementation of shaping policies are incorrect but I'll list my requirements and how I've currently implemented and hopefully someone can tell me where I've gone wrong..
What we have:
10/10Mbps MPLS WAN link (we've triple checked and these speeds are indeed correct)
10x staff in office
remote RDS environment
1. Uninterrupted service for VoIP calls
2. Uninterrupted service for a connection to our remote RDS server
3. Low priority for all over traffic (packets being dropped here is not an issue)
Whenever Windows updates run or streaming video youtube etc (locally), RDS performance becomes poor jittery/drops out. Whenever it happens we can always narrow it down to one of those two things. And using FortiView we can confirm that traffic is flowing out all of the expected shapers.
I have attached the shaper definitions and shaper policies.
Never liked how traffic shaping is handed on the Fortigate, but mind you, I only really played with it on 4.3 MR3/5.0 firmware. But if memory serves, from an old post (may have been from Bob), true traffic shaping requires setting up the rate limits on your WAN port(s) (both ingress and egress) and assigning shaper policies to all firewall policies. And like Bob has indicated above, the rate values is/was a bit confusing (from firmware to firmware/GUI vs CLI) - (Do I enter kbits or bits?).
Regarding Guaranteed Bandwidth - I was always under the impression that you are essentially allocating (reserving) that much bandwidth for nothing other than the fw polices those shapers are applied to, even if there is no traffic. If OP allocated 6+1 Mbps for both up and down, that leaves 3 Mbps remaining for other traffic.
Looking the screenshot, if all things considered equal, would fw #5 even be needed (other than for counting/tracking purposes)?
Doing QoS well is really difficult on any platform, but the tools available on the Fortigate are pretty disappointing compared to other platforms. If you read through the documentation, it's essentially building a few priority queues, not truly shaping traffic but policing (dropping) traffic, so the fields don't really do what you expect.
A couple high level notes:
1) As mentioned above it's important to set the interface bandwidth (assuming you don't have a full 100 Mbps on a 100 Mbps link). Otherwise nothing else really applies since shaping only kicks in at moments where outgoing bandwidth exceeds the limit.
2) According to the documentation, ALL traffic with guarantees gets put into queue 0 until it's over it's bandwidth limit. Which seems very strange to me, so I generally don't use guarantees at all.
3) Default traffic priority. This seems to vary a bit between versions, but in general it seems like all traffic not flagged otherwise gets set as high priority. I've seen suggestions but haven't confirmed that "Set traffic-priority-level low" will default everything to low, but the safest bet is to have every policy in your list have a shaping rule, and create one with just priority LOW and assign it to the ones you don't need to do anything special with.
I've generally had the best luck using just prioritization and bandwidth limits. Set limits for general internet browsing, as it can be quite bursty and overwhelm other traffic, then put high/medium/low on everything else. . The exact mechanism it assigns the queues is a combination of the high/medium/low and existing DSCP/ToS info, but splitting voice into a higher priority queue will generally help a lot with the "microbursts" of other traffic and keep voice traffic flowing with less jitter.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.