A static route is required on the next-hop router through which back end servers are connected to their Avi Load Balancer Service Engine (SE).

A static route is required on the next-hop router from the Avi Load Balancer SE to the pool, in the following case:

  • The virtual service’s VIP address or SNAT addresses are not in any of the SE interface subnets.

To make the static route work, the following are the prerequisites:

This section shows sample topologies that use static routing for server response traffic.

Static Routing without HA

Provisioning load balancers without HA is in general not a recommended practice. However, there can be cases where such a configuration may be desirable. For instance, if the SE group is provisioned with only one SE, then HA is not applicable since there is no device to fail over to. If that SE fails, all the traffic will be null routed.

Here is a sample topology without HA. The virtual service’s VIP and SNAT IP addresses are not in any of the SE interface subnets. As a result, a static route from the back end server to the SE is required on the next-hop router.

Static routes can be provisioned on the next-hop router to point to the interface IP of the Avi Load Balancer SE. However, it is recommended to configure a floating interface IP for the SE group and to have the static route use the floating interface as the adjacency. This will allow the smooth addition of a second Avi Load Balancer SE in the future if required, for HA purposes (using High Availability and Redundancy mode).



Similarly, static routes or a default gateway will also need to be provisioned on the SE group, to enable reachability to servers and clients, which might not be Layer-2 adjacent. For information on provisioning a default gateway and static routes on an SE, see Configuring Static Route Settings section.

Static Routing with HA

The SE group belonging to the pool used by the virtual service contains two SEs in legacy HA mode. One of the SEs is active and has ownership of the virtual service’s VIP and SNAT addresses, while the other SE waits in standby mode. IP addresses that are part of the individual virtual service’s configuration (including the VIP and SNAT IPs) are enabled only on the active SE in the SE group.

The active SE responds to Address Resolution Protocols (ARPs) for the VIP and SNAT IP addresses that are in the same subnet as the SE. The active SE also carries traffic corresponding to all the virtual services. The standby SE remains idle unless the active SE becomes unavailable. In this case, the standby SE takes over the active role and assumes ownership of the virtual service’s IP addresses.

Note:

The use of static routes for VIP and SNAT IP reachability in cluster HA configurations is not supported.

Here is an example of a one-armed topology with legacy HA:



In this example, neither the VIP nor the SNAT IP is part of the SE interface’s subnet. For this reason, a floating interface IP (10.10.1.100) is configured. The floating interface IP must be in the same subnet as the attached interface subnet through which the VIP or SNAT-IP is reachable (10.10.1.0/24 subnet in the above topology).

A separate floating interface IP is required for each of the attached interface subnets through which VIP or SNAT IP traffic flows. On the next-hop router used by the server pool for return traffic back to the SE, static routes to the VIP and SNAT IP addresses are configured, with the next-hop set to the floating interface IP.

Following failover, ownership of the VIP, SNAT IPs, and floating interface IP are taken over by the new active SE, as shown here:



The connecting router thus does not see any change, except for the gratuitous ARP update for the floating interface’s IP address, which is now mapped to the interface MAC address the new active SE.