Configuring the WSM using Device Manager

How IP proxy works

The following figure shows two GSLB sites--one in Burbank and one in Denver--load-balancing HTTP and POP3. Any request that cannot be serviced locally is sent to the peer site. HTTP requests are sent to the peer site using HTTP Redirect. Other application requests are sent to the peer site using IP proxy.

The procedure outlined below explains the three-way handshake between the two sites and the client for a non-HTTP application (POP3). When operator error at site 1 terminates POP3 processes, POP3 requests are fulfilled as follows:

1. The site 1 virtual server received a POP3 TCP SYN request from a user. The WSM determines there are no local resources to handle the request.
2. The site 1 WSM rewrites the request to contain a client proxy IP address as the source IP address, and the Site 2 virtual server IP address as the destination IP address.
3. The site 2 virtual server receives the POP3 TCP SYN request. The request looks like a normal SYN frame, so the WSM performs normal local load-balancing.
4. The site 2 WSM and real servers exchange information. The TCP SYN ACK from Site 2's local real server is sent back to the IP address specified by the proxy IP address.
5. The site 2 WSM sends the TCP SYN ACK frame to Site 1, with Site 2's virtual server IP address as the source IP address and Site 1's proxy IP address as the destination IP address.
6. The site 1 WSM receives the frame and translates it, using Site 1's virtual server IP address as the source IP address and the client's IP address as the destination IP address.

This cycle continues for the remaining frames to transmit all the client's mail, until a FIN frame is received.

See also:

• Configuring IP proxy for non-HTTP redirects
• Configuring GSLB network preferences
• How GSLB works
• Configuring GSLB
• IP proxy for non-HTTP redirects
• About GSLB network preferences
• Server load balancing basics
• Virtual server load balancing