Home / Cisco R&S / Server Load Balancing Using Dynamic NAT Configurations

Server Load Balancing Using Dynamic NAT Configurations

Today I am going to talk about the server load balancing using dynamic NAT. The main purpose of this article is for Users that access the local server from outside Internet will access the server using a single URL or IP address, however the NAT device is used to load share the user traffic to multiple identical servers with mirrored content.

 Let's take an sample topology and talk about the scenario in detail. Please find the below sample topology
Fig 1.1- Server Load Balancing Sample Topology

Outside users A and B access the contents of the Web server with the outside visible IP address 172.16.2.3 (Virtual IP address of the servers). The NAT router translates the traffic destined for 172.16.1.3 to the inside IP addresses 10.1.1.1, 10.1.1.2 and 10.1.1.3 in a round robin fashion and forwards it to the respective server. Each new session initiated from the outside user is translated to the next physical server IP address.
  • User-A initiates a TCP connection with virtual server IP address 172.16.2.3.
  • The NAT router, upon receiving the connection request, creates a NAT translation entry which allocates the next available real server IP address (for example, 10.1.1.1).
  • The NAT router replaces the destination IP address with the allocated real IP address and forwards the packet.
  • The server receives the packet and replies back to the source.
  • The NAT router receives the packet returned from the server and performs the NAT table lookup. The router then translates the source address to the virtual server IP address (172.16.2.3) and forwards the packet.
  • User-B initiates a TCP session with server virtual IP address 172.16.2.3. Upon receiving the connection request, the NAT router translates this to the next available real server IP address (for example, 10.1.1.2) and then forwards the packet to the server.

Since static NAT is bidirectional in the other direction, the destination of the packet will be translated. When doing this form of NAT, it is triggered by sending TCP packets. Sending Internet Control Message Protocol (ICMP) might not trigger the NAT translation.

Non-TCP traffic is directed to the first address in the pool. 

Unlike static inside source NAT and static inside source PAT, the router does not respond to ARP inquiries about the global address, unless that address is not assigned to its interface. Therefore, it might be necessary to add it to an interface like the secondary. It is not possible to redirect ports with this method of translation (for example, 80 and 1087). The ports must match.

Define a pool of addresses that contain the addresses of the real servers.
ip nat pool NATPOOL 10.1.1.1 10.1.1.3 prefix-length 24 type rotary

Define an access-list that permits the address of the virtual-server.
access-list 1 permit host 172.16.2.3

Enable a dynamic translation of inside destination addresses.
!
ip nat inside destination list <ACL name>  pool <Pool Name>
ip nat inside destination  list 1 pool NATPOOL
!

Define NAT inside and outside interfaces.
!
interface gig0/0
ip address 10.1.1.4 255.255.255.0
Ip nat inside
!
interface gig0/1
ip address 172.16.1.1 255.255.255.248
ip nat outside
!

IP addresses 10.1.1.1, 10.1.1.2 and 10.1.1.3 will now be handed out in a rotary fashion when someone tries to access IP address 172.16.2.3

Verify
In order to verify this, initiatie multiple TCP sessions from outside hosts to the virtual IP address. Debug IP NAT translation/show ip nat translation output can be used for verification.

RouteXP_RouterA#
*Jul 15 13:27:41.193: NAT*: s=192.168.1.1, d=172.16.2.3->10.1.1.3 [22864]
*Jul 15 13:27:41.196: NAT*: s=10.1.1.3->172.16.2.3, d=192.168.1.1 [18226]
RouteXP_RouterA#
*Jul 15 13:27:44.329: NAT*: s=192.168.2.1, d=172.16.2.3->10.1.1.1 [35533]
*Jul 15 13:27:44.331: NAT*: s=10.1.1.1->172.16.2.3, d=192.168.2.1 [14573]
*Jul 15 13:27:44.332: NAT*: s=192.168.2.1, d=172.16.2.3->10.1.1.1 [35534]
*Jul 15 13:27:44.332: NAT*: s=192.168.2.1, d=172.16.2.3->10.1.1.1 [35535]
*Jul 15 13:27:44.332: NAT*: s=192.168.2.1, d=172.16.2.3->10.1.1.1 [35536]
*Jul 15 13:27:44.333: NAT*: s=10.1.1.1->172.16.2.3, d=192.168.2.1 [14574]
*Jul 15 13:27:44.365: NAT*: s=10.1.1.1->172.16.2.3, d=192.168.2.1 [14575]
*Jul 15 13:27:44.365: NAT*: s=10.1.1.1->172.16.2.3, d=192.168.2.1 [14576]
*Jul 15 13:27:44.368: NAT*: s=192.168.2.1, d=172.16.2.3->10.1.1.1 [35537]
RouteXP_RouterA#
*Jul 15 13:27:44.369: NAT*: s=192.168.2.1, d=172.16.2.3->10.1.1.1 [35538]
*Jul 15 13:27:44.369: NAT*: s=192.168.2.1, d=172.16.2.3->10.1.1.1 [35539]
*Jul 15 13:27:44.369: NAT*: s=192.168.2.1, d=172.16.2.3->10.1.1.1 [35540]
*Jul 15 13:27:44.371: NAT*: s=10.1.1.1->172.16.2.3, d=192.168.2.1 [14577]
*Jul 15 13:27:44.574: NAT*: s=10.1.1.1->172.16.2.3, d=192.168.2.1 [14578]
RouteXP_RouterA#
*Jul 15 13:27:46.474: NAT*: s=10.1.1.1->172.16.2.3, d=192.168.2.1 [14579]
*Jul 15 13:27:46.478: NAT*: s=192.168.2.1, d=172.16.2.3->10.1.1.1 [35541]
*Jul 15 13:27:46.478: NAT*: s=192.168.2.1, d=172.16.2.3->10.1.1.1 [35542]
*Jul 15 13:27:46.479: NAT*: s=10.1.1.1->172.16.2.3, d=192.168.2.1 [14580]
RouteXP_RouterA#sh ip nat tr
Pro Inside global      Inside local       Outside local      Outside global
tcp 172.16.2.3:23      10.1.1.1:23        192.168.2.1:49703  192.168.2.1:49703
tcp 172.16.2.3:23      10.1.1.2:23        192.168.2.1:50421  192.168.2.1:50421
tcp 172.16.2.3:80      10.1.1.3:80        192.168.1.1:26621  192.168.1.1:26621
RouteXP_RouterA#