Recently I had a discussion with someone over how server’s and load balancing interact at a L2/L3 layer on a network device. This led me to research Ciscos Load-balancing technologies, specifically SLB which works using a virtual IP which attaches to server farms of “real servers”, i.e. 192.168.0.1 goes to ServerFarm2 in Germany and ServerFarm24 in UK.

This IP, 192.168.0.1 is stored on the Cisco device which is where you will be establishing a TCP flow to (by flow we mean HostIP::Socket < —> DestIP::Socket). You will connect to this IP as if it were another other server; for example using a Windows client you would connect to 192.168.0.1/Share using CIFS; which unbeknown to you is then being farmed from the “other side” of the IP to a server farm and then a real server. This is the inherent beauty of the Cisco.

The terminology used is slightly different than what I have used:
“Virtual Server” – The term used for the IP Address which will be used for accessing the services (CIFS, NFS, HTTP, etc) running on the “real server(s)”. The load balance element will then translate connections to this single IP address and forward packets to one of the aforementioned server farms which have been “bound” to this IP / “Virtual Server”.

It is easier to think of this as a Virtual IP Destination in a sense of “black box mentality”; for the user, just throw your CIFS/NFS/HTTP Requests into this black box, and whatever happens happens, and your packets come back.

“Server Farms” are the logical groupings of the “real servers”; i.e. You could have a server farm defined as “SF-Berlin-WindowsGP2” – Which would be a group of Windows Servers in Group 2 in Berlin. The servers could be 5, 10, 15, etc in number (random integers, not the only choices) and you add all these to the server farm, instead of attaching each one to the Virtual Server / Virtual IP.

“Real Server” – These are the servers we mentioned about, the Windows Servers. You will add these individually which are then added to a server farm.

A sample IOS Config is:

# Real servers
real 192.168.0.1
inservice
real 192.168.0.2
inservice
real 192.168.0.3
no inservice

# Server Farm
ip slb serverfarm SF-Berlin-WindowsGP2
nat server
real 192.168.0.254
inservice
!
real 192.168.0.253
no inservice

#Virtual IP / Virtual Server
ip slb vserver VIRT-Berlin-WindowsGP2
virtual 192.168.1.1 tcp 0
serverfarm SF-Berlin-WindowsGP2
inservice

On the Virtual server point, the “tcp 0” specified that it will listen on all TCP Ports. You can restrict it further by specifiying only certain ports i.e. only 80 for HTTP, 443 for HTTPS, 445 for CIFS, etc.

As this is forwarding VirtualIP:0 to RealServers:0, we can also use SLB to perform port translation, in this exercise we will translate from port 8080 to port 80:

# Real servers
real 192.168.0.1
inservice
real 192.168.0.2
inservice
real 192.168.0.3
no inservice

# Server Farm
ip slb serverfarm SF-Berlin-WindowsGP2
nat server
real 192.168.0.254 8080
inservice
!
real 192.168.0.253 8080
no inservice

#Virtual IP / Virtual Server
ip slb vserver VIRT-Berlin-WindowsGP2
virtual 192.168.1.1 tcp 80
serverfarm SF-Berlin-WindowsGP2
inservice

Finally, you may want to ensure that after WindowsXP:0 has connected to VirtualIP:0 (Thus RealServer11X:0) we continue to connect WindowsXP:0 < —> RealServer11X:0 through the Cisco. You may need to do this for many reasons but I will not go into that in this blog.

For this, you can use the “sticky” command which tells the SLB module of the Cisco CSM to keep passing WindowsXP:0 through to the RealServer11X:0 client.

Cisco defines “sticky” as:

“Make the rules sticky. After an initial connection has been load balanced to a server, make all subsequent connections to that same server.”

The config for this is very simple, in the virtual server / virtual IP config section, add:
sticky 10

This tells the CSM module that does the SLB to use sticky, and provides timeout value of 10 minutes, it all comes together as:

#Virtual IP / Virtual Server
ip slb vserver VIRT-Berlin-WindowsGP2
virtual 192.168.1.1 tcp 80
serverfarm SF-Berlin-WindowsGP2
inservice
sticky 10

Next I’m going to look at SSL Termination on Cisco devices.

Sam