VKernel.co.uk – Your interface to the world

Server Load Balancing (SLB) In Cisco IOS

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

Cisco VSS

Long time no see – i’ve been thoroughly busy with university work etc but we are now set to develop VKernel and get this knowledge base off the ground. The first thing i want to talk about is Cisco VSS – Virtual Switching system.

According to Cisco, “A VSS is network system virtualization technology that pools multiple Cisco® Catalyst® 6500 Series Switches into one virtual switch, increasing operational efficiency, boosting nonstop
communications, and scaling system bandwidth capacity to 1.4 Tbps. At the initial phase, a
VSS will allow two physical Cisco Catalyst 6500 Series Switches to operate as a single logical
virtual switch called a virtual switching system 1440 (VSS1440).”

More to come.

Tags: Cisco, VSS

VMWare and Cisco Interconnectivity

As many people know, Virtualization is as prominent a technology in the Networking industry as it is in the Server industry. Like the server market, Virtualization is used in Networking also for consolidation via VLANs – used to make what used to be 100 seperate networks, using seperate NIC’s and Switches, consolidated into one easily manageable and more remote-access friendly switch. Using VLANs you can change what network a port is on with less than 6 commands, opposed to patching and re-patching cables etc. Until recently, Virtual LAN’s and Virtual Servers (ESX for this article) have had no real technological advantage while working in cohesion compared to their physical counterparts, however recently VMWare and Cisco released a white paper outlining plans and guidelines for greater connectivity beetween the 2 technologies.

http://www.vmware.com/files/pdf/vmi_cisco_network_environment.pdf (White Paper)

In VMWare, there are various Networking technologies that have been virtualized – mainly vSwitch(es) and vNIC(s). These virtual entities simulate the actions and features of their physical counterparts, and can be used together to create virtual networks; a series of virtual machines, using virtual NICs to interconnect using a Virtual switch. This can be then further enhanced by briding the vSwitch onto a physical NIC attached to “the outside world”, which, if all on the same subnet, will allow traffic to flow through from the phys. NIC into the virtual servers ensuring full virtual -> physical network flow. The maximum number of virtual switches allowed per VMware ESX install is a staggering 248! Thats 248 virtual Switches running on top of one piece of hardware, not to mention all the VM’s etc. On top of the 248 switches, you are allowed a maximum of 1016 virtual NIC’s, per switch, giving you a potential number of interconnects in the range of 1016 * 248!

Although vSwitches are very similar to physical Switches (pSwitches from here on), there are a few differences:-

• Spanning-Tree Protocol (STP) is not supported on Virtual Switches, as “VMWare infrastructure enforces a single-tier networking topology within the ESX Server”. Basically, the quote says that there is no possible way for you to interconnect multiple vSwitches, thus, “ESX Networks cannot be configured to introduce loops”. Because theres no way for you to attach 2 pNICs to one vSwitch, there is no way to fool an ethernet adapter into doing loopback or any other configuration which could cause a leak between virtual switches.
• “ESX Provides a direct channel from virtual Ethernet Adapters for such configuration information as authoritative MAC Filter Updates, therefore there is no need to learn unicast addresses or perform IGMP snooping to learn multicast group membership” – basically, the vSwitch works by acting as a cable, it notices VM1 trying to send to VM2, therefore it puts a temporary cable inbeetween the VM’s and allows communication, due to this it doesnt need to know multicast group membership.

Due to this apparent transparency and the lack of use for STP, there is no need to cascade virtual switches as virtual infrastrucutre provides no capability to connect vSwitches.

Virtual switch correctness: “It is important to ensure virtual machines or other nodes on the network do not affect the behaviour of the vSwitch”

•  ”Virtual switches do not learn MAC addresses from the network in order to populate their forwarding tables. This eliminates a likely vector for denial- of-service (DoS) or leakage attacks, either as a direct denial of service attempt or, more likely, as a side effect of some other attack, such as a worm or virus as it scans for vulnerable hosts to infect. “
• “Virtual switches make private copies of any frame data used to make forwarding or filtering decisions. This is a critical feature of the virtual switch and is unique to virtual switches. The virtual switch does not copy the entire frame, because that would be inefficient, but ESX Server must make sure that the guest operating system does not have access to any sensitive data once the frame is passed on to the virtual switch.”

 

 More to come. Sam.

Tags: Cisco, Virtualization, VLAN, VTP