Pardon the newb question [1] and the simplified format [2] of the question below.
We have a VMWare ESX host, ServerA. We have an F5 3400.
They both connect to the same Cisco switch.
[ServerA - vmware].....[Cisco].....[F5-3400]
I've been asked to load-balance four VM Guests [3] on ServerA with the F5.
Because ServerA does not have any free NICs, directly connecting a ServerA NIC to the F5 would involve some re-work on that host's configuration - which I'd like to avoid.
Is there a way to load balance the VMWare guests using the F5 and our existing switch?
Brian Dunbar
Plexus
[1] We have thus far used the F5 for a single application; three Solaris hosts have a public NIC and a NIC connected to the F5. Traffic for the application goes to the F5's interface which sorts out the traffic.
We're a small company with a lean IT department; because I have the 'most' experience with F5 I got this job.
[2] I'm avoiding more technical terms because I may be using them incorrectly and don't with to drag the conversation down blind alleys.
There is no requirement to be directly connected to the LTM. As long as the routing works such that the client can make a connection to the virtual server on the LTM, and the LTM can distribute those connections to the VM IIS servers, it will work fine.
One caveat:
The main thing people are unaware of is that by default the LTM will preserve the client's source IP address when it hands the connection to the IIS server. If the LTM is not the IIS server's default gateway, the return traffic will bypass the LTM and the client will drop it. If you cannot make LTM the def gw, then you need to enable SNAT (typically SNAT automap) on that virtual server. Then, the LTM will change the source address of the client to it's own IP, so that when the IIS server tries to send a response, it will send it to the LTM first, not directly to the client.
The only downside to SNAT is that you lose visibility in your server logs to the real client IP address. You can insert an X-Forwarded-For header in the http profile on the vip, and there is an ISAPI filter here on DevCentral that you can install on IIS to enable it to log the XFF as the client address. (For non-IIS servers there are other ways to capture the XFF header).
Looks like You could use L2 which could avoid SNAT.
[ServerA].... vlan Int ... [Cisco] .... still vlan Int here .... [F5] ... vlan Ext ... [The very same Cisco]... [World and Universe]
Just put both vlans in a VLAN Group - F5 will then handle retagging (if needed) and bridging between the VLANS, but Cisco should not. Any packet coming from External VLAN will have to go via F5 to get to VLAN Int.
The advantage is that you can have a "flat" network where LTM is not the default gateway and still not use SNAT; because it is the bridge that devices talk through to get to the def gw, it can still do load balancing without the SNAT issues I discussed above.
The disadvantages are that it's a more complex setup, it's harder to troubleshoot, and if everything is not done correctly, you will end up with a bridge loop that takes down every device on the network due to a broadcast storm. It becomes particularly tricky when you have a redundant pair of LTM's.
It was designed primarily to replace implementations that were already in this mode (Cisco Local Directors especially) and could not be changed. I never recommend it for newly planned implementations, because in my mind the disadvantages outweigh the one advantage by quite a bit.
