September 21, 2011 at 1:52 pm #43125
I currently am trying a proof of concept test for work…and am running into an odd issue.
Currently, we have one instance of ZS in our datacenter running in VMWare ESX and another in our office on a Sokeris net5501. The ZS device in the office is connected to two ADSL lines, each of which has a VPN back to the ZS device in the DataCenter. These two VPNs are then bonded on both ends and assigned a /30 subnet. I followed a few of the tutorials on link aggregation to get this far and it works flawlessly.
Now, where I experience the issues; I add all usable IP’s to the bond on the Datacenter side (ie: 208.65.xx.177 and 208.65.xx.178 – but uncheck active on 208.65.xx.178). On the office ZS device, I assign the IP 208.65.xx.178 to the bond. Create a netbalancer rule to direct all traffic that is not on either of the VPN ports to go to the IP of the Bond in the DataCenter (208.65.xx.177). After doing this, nothing is wrong. Everything works perfectly. I can run speedtests, surf, etc. When I run into an issue is after exactly FOUR hours. I’ve had smokeping running against the IP I assigned to the office ZS to confirm the pattern.
After exactly 4 hours, the public IP assigned to the ZS device in the office becomes unreachable. You cannot ping it, you cannot surf out to the internet, nothing. All the modems are connected to the ISP, they have not flapped… The VPNs are up on both ends, the bond is up on both ends…. Is there something I am missing? Is there a timeout somewhere? or am I assigning IP’s in the wrong way? I even tried bridging a larger /29 subnet to ETH00 on the office ZS device, assigned another IP to a device behind ETH00 and got the same results; The IP’s assigned to ZS and the device behind ETH00 went unreachable after exactly 4 hours.
Hopefully someone can shed some light, I am at my wits end here!
ZS is an amazing product and if I can figure this out, I can stop my boss from buying a sub-standard solution …. 😉
Thanks in advanceSeptember 21, 2011 at 4:47 pm #51958
The problem was with my Cisco… ARP entries were timing out after 4 hours. Thank you Fulvio for a wonderful product!
You must be logged in to reply to this topic.