November 10, 2009 at 11:51 pm #48911
Show us a capture of your netbalancer configuration.November 11, 2009 at 9:30 am #48912
ThanksNovember 11, 2009 at 2:22 pm #48913
1) Lower the timeout co-effinciency on the gateway configuration to x4 since you have 2G/3G links (this is an optimization tip)
2) I don’t see any BOND00 containing the VPN00 and VPN01 for the L2 load balancing.November 11, 2009 at 3:33 pm #48914
sorry I sent you a wrong screenshot.
But in the mean time I made some test and I discover that the problem is that I am not using 2 zeroshell box but in one side I am using a dedicate server with a single IP even with 2 vpns bonded.
So I have now to order a multi ip from my provider before give up!
I will keep you informed, but I am still interested in your configuration (if is really working)
Many thanks for now
AntonioNovember 13, 2009 at 9:04 pm #48915
It really does work…let me know what parts you would like.
TPNovember 16, 2009 at 12:47 pm #48916
this is my testbed:
client side (Zeroshell):
VPN00 (public ip server)
+ ---> PPP0
VPN01 (public ip server)
+ ---> PPP1
server side (Centos 5 Open VPN server):
eth0 (public ip)
seem work but very slooooow someting like 10kB/s.
may be is because the server have only ONE pubblic IP?
thanks for your help
byeNovember 16, 2009 at 1:48 pm #48917
Unless the subnet mask for the BOND00 and bond0 interfaces is /23 or bigger, this is not correct. You 2 bonds should be in the same subnet.November 16, 2009 at 3:21 pm #48918
Yours is different from mine…we are using 2 Zeroshell devices…to create the tunnels, while it looks like you are doing 1 ZS to an outside server.
We got great help from ppalias in getting ours figured out…so believe him on what he posts.
I agree with his last post…looks like the subnets on the bond are wrong…one side is 192.168.1.X and the second side is 192.168.0.X
we went like this:
(ETH10.1.1.1)ZS–(VPNa)-calls outside of ZS2 —ZS2 (ETH10.1.2.1)
then 2nd adapter on ZS uses VPNB calls 2nd adapter on ZS2
Once creqated…Bond both VPNa and VPNb together on both sides…..gave the bond00 on ZS 172.16.1.1/24 and the bond00 on ZS2 the address of 172.16.1.2/24
Went into routing on ZS and told it that the 10.1.2.X network goes to 172.16.1.2 and on ZS2…told it that the 10.1.1.X network can be found on 172.16.1.1…and it works great (see details earlier in post for best speeds and such)
So if it were me…I would put a 2nd ZS box in so you are building the tunnel between the 2 locations…your life will be easier.
TPNovember 16, 2009 at 3:32 pm #48919
thanks for you answer, the addrees of the bond is a typo error, sorry them are 192.168.0.1 and 2!
So seems you are using 2 ZS boxes but over only one line? or you have 2 lines on the other side too? I think this is the reason.
byeNovember 16, 2009 at 10:39 pm #48920
Yeah the point is to have 2 ZS boxes and 2 lines terminating on each box, so you create 2 VPNs and bond them together to aggregate the bandwidth.November 30, 2009 at 5:21 pm #48921
Yup…we got 2 lines between the ZS boxes. thus 2 vpns, thus 1 bond.March 26, 2010 at 4:01 pm #48922
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.
could you clarify for us what the QoS settings were that you used?May 1, 2010 at 9:28 pm #48923
Sure…the QOS settings we used were to take the DEFAULT QOS – default class for unclassified traffic, set the max bandwidth to whatever the aggregation would be (2 t1s for example would be 3mb/s) and apply it to the bond. No other changes. if the QOS is not there giving it enough max bandwidth, we did not get good aggregation….if any at all.May 26, 2010 at 5:48 am #48924
You must be logged in to reply to this topic.