With the nPath routing configuration, you can route outgoing server traffic around the BIG-IP system directly to an outbound router. This method of traffic management increases outbound throughput because packets do not need to be transmitted to the BIG-IP system for translation and forwarding to the next hop. Figure 2.1 shows an nPath configuration.
In bypassing the BIG-IP system on the return path, nPath routing departs significantly from a typical load-balancing configuration. In a typical load-balancing configuration, the destination address of the incoming packet is translated from that of the virtual server to that of the server being load balanced to, which then becomes the source address of the returning packet. A default route set to the BIG-IP system then sees to it that packets returning to the originating client return through the BIG-IP system, which translates the source address back to that of the virtual server. The nPath configuration differs from the typical load-balancing configuration, as you can see in the following section.
The nPath routing configuration differs from the typical BIG-IP load balancing configuration in the following ways:
You need to complete the following tasks to configure the BIG-IP system to use nPath routing:
The first task you must complete to create an nPath routing configuration is to create a custom Fast L4 profile.
After you create a custom Fast L4 profile, you need to create a server pool.
After you create a server pool, you need to create a virtual server that references the customer Fast L4 profile and pool you created in the last two tasks.
You must place the IP address of the virtual server (220.127.116.11 in Figure 2.1 on page 2-1 ) on the loopback interface of each server. Most UNIX variants have a loopback interface named lo0. Microsoft® Windows® has an MS Loopback interface in its list of network adaptors. For some versions of Windows, you must install the loopback interface using the installation CD. Consult your server operating system documentation for information about configuring an IP address on the loopback interface. The loopback interface is ideal for the nPath configuration because it does not participate in the ARP protocol.
For inbound traffic, you must define a route through the BIG-IP system self IP address to the virtual server. In the example, this route is 18.104.22.168, with the external self address 10.1.1.10 as the gateway.
For information about how to define this route, please refer to the documentation provided with your router.
When you create an nPath configuration, the BIG-IP system sees only client requests. Therefore, the timer for the connection timeout is only reset when clients transmit. In general, this means the timeout for an nPath connection should be at least twice as long as for a comparable connection where BIG-IP system sees both client requests and node responses. Following are descriptions of scenarios for setting the timers for UDP and TCP traffic.
When you configure nPath for UDP traffic, the BIG-IP system tracks packets sent between the same source and destination address to the same destination port as a connection. This is necessary to ensure that client requests that are part of a session always go to the same server. Therefore, a UDP connection is really a form of persistence, since UDP is a connectionless protocol. To calculate the timeout for UDP, estimate the maximum amount of time that a server transmits UDP packets before a packet is sent by the client. In some cases, the server might transmit hundreds of packets over several minutes before ending the session or waiting for a client response.
When you configure nPath for TCP traffic, the BIG-IP system sees only the client side of the connection. For example, in the TCP three-way handshake, the BIG-IP system sees the SYN from the client to the server, and does not see the SYN acknowledgement from the server to the client, and does see the acknowledgement of the acknowledgement from the client to the server. The timeout for the connection should match the combined TCP retransmission timeout (RTO) of the client and the node as closely as possible to ensure that all connections are successful. The maximum initial RTO observed on most UNIX and Windows systems is approximately 25 seconds. Therefore, a timeout of 51 seconds should adequately cover the worst case. Once a TCP session is established, an adaptive timeout is used. In most cases, this results in a faster timeout on the client and node. Only if your clients are on slow, lossy networks should you ever need a higher TCP timeout for established connections. Once a FIN packet is received from the client, the TCP Close Timeout option is used to more aggressively remove connections from the BIG-IP system.