After some massive testing…here’s what we found.
The big issue is QOS on the bond. If we turn on the default and tell it it has 3mb guaranteed…then it used all of the lines (except in bonded TCP vpns…see below)
Baseline : No Zeroshell…Transferring 100 MB over the routers back to back , single T1, 11 minutes
Single VPN – 100 mb, TCP, no encryption, no compression – 14min 30 sec
using the 1.2 to 1.3 connection speed.
Dual VPN TCP bonded – 12 min ( again…this is the wierd not full bandwidth issue…even with QOS)
Once we switched to UDP, on a single vpn we got 12 minutes (expected for a little overhead)
Dual UDP bonded VPN we got 7 minutes (and the t1s were both utilizing 1.2 – 1.3 MB each )
We even tested 2 vpns bonded, and pulled one connection mid transfer, then put it back in…and we watched ZS dynamically adjust to the speed differences nicely.
with UDP, we could even turn on encrytion (different ciphers tried up to 256 AES) and we saw little or no difference – maybe extra 30 seconds to transfer on 256 AES
So in controlled testing…the TCP VPN connection really pales compared to the UDP….obviously the connection based TCP protocol adds some overhead on the tunnel…like 30%.
The other thing we did see is this…
We decided to see what would happen if one of the uploads was not capable of the same speed as the other. So we took one of the simulated T1 connections and reduced it to 756K. What we saw was the 2 udp vpn tunnels both used 700K over each line…even though the other line could have done more. Is this by design or a flaw?
SO….if we have tested correctly…we have found that the UDP vpn bond is superior to the TCP bond by over 30%…and we found the a bonded VPN will throttle all connections down to the lowest speed…so if you have 2mb connection, a 1 mb cnnection, and a 256K connection bonded…you will get 3 connections running at the lowest speed of 256K EACH.
AND QOS on the bond is essential to get the bond to utilize the available bandwidth.
So moral of the story…use UDP, QOS, no compression, and make sure the speeds match.
BTW…the graphs all said that /mrtg/statisitcs.html was not found on this server….ideas?
Overall…this is a fantastic product and very resiliant. We are extremely hapy with it once we leaarned the quirks.
I may have been too verbose in these forums…but hopefully all this will help the next guy who reads this.
So..ppalias….what do you think about the 2 issues above?
1. 2 different speed links will link and use only the bandwidth of the lowest link
2. Missing mrtg graphics