Go to main content

Configuring an Oracle® Solaris 11.3 System as a Router or a Load Balancer

Exit Print View

Updated: December 2018
 
 

ILB Operation Modes

ILB supports stateless DSR and NAT modes of operation for IPv4 and IPv6 in single-legged and dual-legged topologies.

Direct Server Return Mode

In DSR mode, ILB balances the incoming requests to the back-end servers but allows the return traffic from the servers to the clients to bypass it. However, if you set up ILB to be used as a router for a back-end server, the response from the back-end server to the client is routed through the system that is running ILB. ILB's current implementation of DSR does not provide TCP connection tracking, making it stateless. With stateless DSR, ILB does not save any state information of the processed packets except for basic statistics. Being stateless, the performance is comparable to the normal IP forwarding performance. The DSR mode is best suited for connectionless protocols.

    Advantages:

  • DSR provides better performance than NAT because only the destination MAC address of packets is changed and servers respond directly to clients.

  • There is full transparency between the server and the client. The servers see a connection directly from the client IP address and reply to the client through the default gateway.

    Disadvantages:

  • The back-end server must respond to both its own IP address (for health checks) and the virtual IP address (for load-balanced traffic).

  • Being stateless, adding or removing servers causes connection disruption.

The following figure shows the implementation of ILB in the DSR mode.

Figure 4  Direct Server Return Topology

image:This figure shows the Direct Server Return Topology.

In this figure, both back-end servers are in the same subnet (192.0.2.0/27) as the ILB box. The servers are also connected to the router so that they can reply directly to clients after receiving a request forwarded by the ILB box.

Network Address Translator Mode

ILB uses NAT in stand-alone mode strictly for load-balancing functionality. In this mode, ILB rewrites the header information and handles the incoming as well as the outgoing traffic. ILB operates in both the half-NAT and full-NAT modes. However, full-NAT also rewrites the source IP address, making it appear to the server that all connections are originating from the load balancer. NAT does provide TCP connection tracking (meaning that it is stateful). The NAT mode provides additional security and is best suited for Hypertext Transfer Protocol (HTTP) or Secure Sockets Layer (SSL) traffic.

    Advantages:

  • Works with all back-end servers by changing the default gateway to point to the load balancer

  • Adding or removing servers without connection disruption is possible because the load balancer maintains the connection state

    Disadvantages:

  • Slower performance than DSR because processing involves manipulation of the IP header and servers send responses to the load balancer

  • All the back-end servers must use the load balancer as a default gateway

The general implementation of the NAT mode is as shown in the following figure.

Figure 5  Network Address Translation Topology

image:This figure shows the Network Address Translation Topology.

In this case, all requests to the VIP go through the ILB and are forwarded to the back-end servers. All the replies from the back-end servers pass through the ILB for NAT.


Caution

Caution  -  The NAT code path that is implemented in ILB differs from the code path that is implemented in the IP Filter feature of Oracle Solaris. Do not use both these code paths simultaneously.


Half-NAT Load-Balancing Mode

In the half-NAT mode of the ILB operation, ILB rewrites only the destination IP address in the header of the packets. If you are using the half-NAT implementation, you cannot connect to a VIP address of the service from the same subnet on which the server resides. The following table shows the IP addresses of the packets flowing between the client and ILB, and between ILB and back-end servers.

Table 5  Request Flow and Response Flow for the Half-NAT Implementation When the Server and Client Are on Different Networks
Request Flow Sequence
Source IP Address
Destination IP Address
1. Client –> ILB
Client
VIP of ILB
2. ILB –> Server
Client
Server
Response Flow Sequence
Source IP Address
Destination IP Address
3. Server –> ILB
Server
Client
4. ILB –> Client
VIP of ILB
Client

If you connect the client system to the same network as that of the servers, the intended server responds directly to the client, and the fourth step in the table does not occur. Therefore, the source IP address for the server response to the client is invalid. When the client sends a connection request to the load balancer, the response occurs from the intended server. From this point onwards, the IP stack of the client correctly drops all the responses. For this scenario, the request flow and response flow proceed as shown in the following table.

Table 6  Request Flow and Response Flow for the Half-NAT Implementation When the Server and Client Are on the Same Network
Request Flow Sequence
Source IP Address
Destination IP Address
1. Client –> ILB
Client
VIP of ILB
2. ILB –> Server
Client
Server
Response Flow Sequence
Source IP Address
Destination IP Address
3. Server –> Client
Server
Client

Full-NAT Load-Balancing Mode

In the full-NAT implementation of the ILB operation, the source and destination IP addresses are rewritten to ensure that the traffic goes through the load balancer in both directions. The full-NAT mode makes it possible to connect to the VIP from the same subnet that the servers are on.

The following table depicts the IP addresses of the packets flowing between a client and ILB, and between ILB and a back-end server by using the full-NAT mode. No special default route using the ILB box is required in the servers. Note that the full-NAT mode requires the administrator to set aside one IP address or a range of IP addresses to be used by ILB as source addresses to communicate with the back-end servers. Assume that the addresses used belong to subnet C. In this scenario, ILB behaves as a proxy.

Table 7  Request Flow and Response Flow for the Full-NAT Implementation
Request Flow Sequence
Source IP Address
Destination IP Address
1. Client –> ILB
Client
VIP of ILB
2. ILB –> Server
Interface address of the load balancer (subnet C)
Server
Response Flow Sequence
Source IP Address
Destination IP Address
3. Server –> ILB
Server
Interface address of the ILB (subnet C)
4. ILB –> Client
VIP of ILB
Client