We are looking at the possibility of purchasing load-balancers for our web servers(2) and mail gateways(2). Unfortunately, we don't have a lot of money to throw at this solution and are therefore looking at the most economic solutions available. As a result, one of our options is what I consider to be for a small office and not necessarily for an enterprise environment. As a result, there are a few features that I consider to be lacking. One in particular is the ability to make a pair of load-balancers highly-available.
The documentation from the manufacturer states that failover in an HA-pair takes 5 seconds plus the amount of time it takes for the ARP-cache to time out. In our case, the default ARP-cache timeout for our ASA5520s is 14400 seconds or 4 hours. That would mean if one of the load-balancers failed, it could take up to 4 hours before the ASA begins to forward packets to the backup device. In my mind, if we are trying to be "highly-available", this is unacceptable. However, I understand that this value was most likely arrived at as a result of testing and is really more of a best-practice. I called my SE to get recommendations/suggestions. He was very helpful in answering my questions and confirming my thoughts that lowering that timeout would most likely increase CPU load and if the CPU load increased enough would potentially affect the stability of the ASA and thereby the stability of any network which depends on that device. I asked for his advice based on experience for lowering that timeout and he mentioned 5000 seconds or approximately 1 hour 23 minutes (from a previous implementation). This is better but still not in an acceptable range for something that's supposed to be "highly-available". I have been following the thread titled "Gratuitous ARP and PIX" and it seems like David is wrestling with some of the same type issues that I am. The only difference is that he mentions that his ARP-cache is set to time out at 5 minutes which seems very low but maybe appropriate for his environment. Like David, I am hesitant to lower the value. However, I'm just curious what the thoughts are from the others on this list about how far I can push that value down. Here are the facts: 1. I am running a pair of 5520s in active/standby with stateful failover. 2. Devices are running with a single context for now. I am considering multiple contexts in the future. 3. The average bandwidth through the device is about 34Mbps with a slated increase of 12Mbps/year over the next 4 years (When the devices will be replaced). Total approaching approximately 84Mbps. 4. This particular pair of devices does not have any service modules 5. There's no VPN taking place on this pair except for one group configured for emergency purposes. Obviously, that will go away if we go to multiple contexts. 6. There are currently 4 VLANs trunked to one interface(4 sub-interfaces), 1 outside interface, 1 inside interface, 1 LAN failover interface and 1 State failover interface. 7. There are about 80 ACL lines, however, almost every single line references a Network Object Group and a Service Group. So, in truth, there are probably a few hundred ACL lines. 8. There are 130+ NAT Statements 9. These devices also run OSPF on the outside and inside interfaces (2 OSPF areas) with about 6 peers. 10. The current CPU utilization is 9% (approximately 15Mbps and 70 connections/second). It's the summer and the majority of students aren't on campus and therefore, bandwidth utilization is down. I also don't have any history on the CPU utilization for high-traffic time. 11. The ARP-cache timeout is set to the default of 14400 12. There are currently 34 entries in the ARP table So, all of that being said, I welcome the thoughts of the members of this list with regard to adjusting the ARP-cache timeout. Thank you in advance for your help. J. Bart Casey Network Engineer Wofford College _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
