Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
New Contributor

Traffic Shaping Problems

Hello all,

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)

Fortigate FG30E

10x staff in office

VoIP Phones

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)


Current 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. 








Any assistance much appreciated.


New Contributor


Traffic shaping will only begin to take effect when an interface with traffic shaping configured reaches its capacity. Until this threshold is reached all traffic is treated equally.


You could configure:

config system interface
edit <interface_name>
set inbandwidth <rate_int>
set outbandwidth <rate_int>
Valued Contributor III

Is the rate still in units of kiloBYTES?


See your image. The utilization has a capital B, for Bytes, yet the limit is set in bits...

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at:

Bob - self proclaimed posting junkie!See my Fortigate related scripts at:

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)?





NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C

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.


More documentation on the 5.6 version of this is here:


Hope this helps...


Jeff Roback

Jeff Roback

In this case I'd rather do shaping per policy not per interface. You have more Options then.

Create a Policy for the service with a guaranteed shaper with enough bandwith so the FGT will reserve this bandwith for that one.


"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
Top Kudoed Authors