Algorithms

I have the WFA algorithm, and the Link Balancer seems to distribute the load for IP sessions in round robin.

Please verify that the weights for your GMACs are different.

How does the weight affect algorithm decision making?

The weight is attributed per GMAC. The lowest weight value is preferred. Algorithms using the weight as a metric will calculate the weight difference between two GMACs and incorporate this difference with other metrics in the link selection process. A greater weight difference reduces the chance that the higher weight link will be selected because other metrics will have more importance.

DNS resolution is sometimes slow. My links have very different latency due to their technology or due to my internal DNS server configuration.

If your links have very different latency (for example a T1 and a satellite link), we recommend using an ACL NAT IN statement to force DNS requests (UDP port 53) in OPFA algorithm. For defining exactly which DNS servers will be forced in OPFA algorithm, you can specify the destination IP in the ACL NAT IN statement. Similar configuration could be done for other lantency sensitive protocols to users (like VoIP, HTTP/HTTPS). Less sensitive protocols like FTP and SMTP could be prioritized on the link with greater latency.

How to successfully use the new FOPFA algorithm in a VPN failover scenario

Integrating a VPN failover solution using an Elfiq Link Balancer is even easier with the new FOPFA (Force Order Preferred First Algorithm) algorithm. In a situation where you have two links and a single VPN tunnel, the tunnel will normally be placed on the primary link. And with proper configuration on both VNP endpoints it will become possible to NAT that VPN session on an alternate link. Once the VPN is placed on the secondary link because of a primary link failure, it is possible to bring back that session on the primary link using FOPFA. This new algorithm will force the VPN session placed on the backup link to fail and re-initiate itself on the primary link.

That is true if you observe those general VPN golden rules:

1. Make sure that the other endpoint can accept traffic from the equivalent IP address of the VPN on the secondary link. In cisco language it is called to add another peer IP.

2. Make sure that rekeying time is as low as possible. It goes in the same way for the VPN timeout metric which should be as low as possible.

3. The initiator of the VPN must be placed behind the Elfiq in a way that the VPN will always be seen as an outgoing session. Remember that if the VPN session is an incoming session, it won't be taken in account for the FOPFA. 

If you follow those rules, you should get successful results. But the real optimal solution is to use SitePath MTPX which grants the VPN simultaneous usage of both links and seamless failover with no re-initiation downtime.