Traffic shaping causing dropped packets and high pings

[#1]

Hello all. We have implemented a Traffic Shaping policy to limit bandwidth to 500KB both down and up. It seems to work well until we use an application on a workstation that has a large number of concurrent sessions e.g. Google Earth. If I run a pingtest from www.pingtest.net without Google Earth running there is 0% packet loss, 11ms ping with 1-2ms Jitter. As soon as Google Earth is running and someone zooms in and moves around the connection degrades to 7-8% packet loss, 300-400ms pings with 200-300ms Jitter. Is this how the traffic shaping works or is something very wrong with the configuration of our 100A?? If we disable traffic shaping and allow the full 10meg leased line to be available we get no issues? Can anyone suggest what is causing the degredation in the connection from using a simple application like Google Earth on one workstation??

[rwpatterson]

Perhaps Google Earth requires more than 500k by itself and it' s just saturating the pipe. I haven' t tried that myself. Try running a PING and using FTP to get/put a file. Maybe just too small a pipe. My $.02.

[#3]

Perhaps Google Earth requires more than 500k by itself and it' s just saturating the pipe. I haven' t tried that myself. Try running a PING and using FTP to get/put a file. Maybe just too small a pipe.

That' s a 4meg pipe. I' ll try and saturate the pipe with a large single session download and see if the PING is effected. Does anyone know how the Fortigate traffic shaping works? Does it just drop packets randomly to achieve the limit or are they queued in a buffer?

[rwpatterson]

The ' pipe' I was referring to was the shaping policy. 500kb.

[#5]

The ' pipe' I was referring to was the shaping policy. 500kb.

The shaping policy is 500 kilobytes per second = 4 megabits/sec Our total line is 10 meg synchronous. Does traffic shaping just drop packets randomly when the threshold is reached?

[darrell]

You do realize that traffic shaping is measured in kb or kilobits not kB or kilobytes. It does make a difference :).

[#7]

You do realize that traffic shaping is measured in kb or kilobits not kB or kilobytes. It does make a difference :).

Doesn' t appear to be the case on our 100A. When we put in 4096 believing it to be kilobits we had the full 10 meg up and down. We tried a really low value of 100 and had around around 0.8meg up and down. We did a calculation of 4096000/8 = 512000 512000/1024 = 500Kilobytes per second. When we use this figure we get exactly 4meg down and 4 meg up.

[ede_pfau]

OP is right, the parameter for bandwidth is given in units of kilobytes per second. So, 128 stands for 1 MBit/s. In order for traffic shaping to work correctly the FG uses quality of service queuing. - make sure ordinary firewall policies are not assigned " high" priority (as is the default) - specify the maximum bandwidth for the interface involved (interface parameter) - otherwise the rate may be miscalculated - the sum of the guaranteed bw may not exceed the interface maximum bw The FG works with queues (buffers) and prioritization but eventually it has to drop packets if the used bw exceeds the specified max bw for too long. The effect of dropping may be detrimental if TCP traffic is affected as the protocol will resend dropped packets. TS best works for streams (UDP) of many source addresses. If you haven' t already take a look here: http://docs.forticare.com/fgt/archives/3.0/techdocs/FortiGate_Traffic_Shaping_Tech_Note_01-30006-0304-20080407.pdf

[darrell]

I stand corrected, thanks ede_pfau.

[ede_pfau]

this might be useful as well: CLI commands to see dropped packets statistics, P2P traffic shaping and more: http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD30691&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=12497107&stateId=0%200%2012495476