Processing traffic
Virtual server – Address translation
When the packet arrives, BIG-IP translates the destination
IP address from the virtual server to that of the actual server. The client
sees the pool of the servers as a single server hence the teem virtual server.
Although uncommon, you can configure pool member to use
different ports, in which case BIG-IP would also translate the virtual server
port to the actual server port.
Network flow- Packet # 1
First a DNS server resolves the DNS request to virtual
server address on BIG-IP.
In some cases clients must go through a NAT devices (a
device the performs NAT), prior to reaching BIG-IP. In this case the DNS
request is resolved to an address on the NAT device that is translated to the
virtual server address.
The client machine then initiates the connection across the
internet to the virtual server address. At this point the source IP address is
that of client and the destination IP address the virtual server using normal
IP routing process, the packet appears on a BIG-IP interface. BIG-IP receives
the packet and processes it based on virtual server configuration.
By default, BIG-IP translate the destination IP address to
that of a pool member, but leaves the source IP address alone. BIG-IP uses a
combination of monitor results, persistence load balancing method and setting
to choose a pool member.
Asymmetric Routing Problem
If BIG-IP changes an IP address of an incoming packet the
response must return through BIG-IP.
The roundtrip is necessary because BIG-IP is the only device
that knows how to translate the IP address back to its original value so that
the client will accept the response packet.
If the pool member default route does not go through BIG-IP.
As a result, an asymmetric routing problem occurs. The client machine refuses
the response packet because the source IP address differs from the original
destination address. It is now the address of the real server instead of
virtual server.
The only solution is to make sure the packet comes back
through BIG-IP.
One way to accomplish this is to set the server’s default or
state routing so that packets pass back through BIG-IP.
A second option is to use a SNAT, which changes the source
address to BIG-IP address, thus forcing the response packet through BIG-IP.
Network flow – packet
#1 return
Lets assume that we chose to change the server default
route.
By forcing the packet back through BIG-IP, is allows BIG-IP
translate the packets source IP address (which is now the address of the actual
server) back to the virtual server to which the client originally sent the
packet.
Because the source address now matches the original
destination address of the initiation packet, the machine accepts the response.
Network flow-packet #2
For the next initiated packet from either the same client or
a different client the same process occurs flow ever. Here we show BIG-IP load
balancing this next request to a different pool member.
Noticed to the different port than the virtual server. So
port translation will occur also.
Network flow-packet #2 return
Just like our previous example, the response packet must
return through BIG-IP, So that the source address can be translated back to the
virtual server address.
Network flow-packet #3
If a pool member is unavailable, BIG-IP sends the incoming
packet to next available pool member.
How BIG-IP chose this next member is the subject of a future
module. Note that clients are not aware they are being load balanced nor that their
request has been diverted to another server. BIG-IP administrator, however can
configure SNMP traps to alert them when pool members are marked up or down.
More than NAT- Fully proxy
It is important to note that BIG-IP is doing much more than
translating network address. F5 network has implemented a fully proxy architecture
with in BIG-IP.
This means that BIG-IP can have separate TCP connection for the
client and for the server. This allows for tremendous flexibility and robust
functionality within the product.
Great stuff! Thanks
ReplyDelete