Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've inherited a Dell M1000e blade chassis and 16 M600 blades that I'm now in the middle of migrating from standalone to clustered. Each is running Server 2008 R2 SP1 and Hyper-V. My issue is I'm trying to think of the simplest way to manage traffic segregation for hosting multiple clients within our cluster. In other words, our M1000e chassis is a public cloud that we want to partition off into smaller private clouds for our SMB clients. However, the segregation is purely logical. Multiple clients can and will be hosted on the same physical server. All segregation must be able to fail over between physical hosts along with the VM.

Can anyone point in the direction of some "best practice" approaches to this or similar situations? So far, I've only dealt with private, internal networks, never shared between multiple businesses.

My current plan is to use the "Bind IP Subnet to VLAN" feature of the M6220 blade switches we're using. Then I'll establish the convention with my colleagues that the first two digits of the VLAN are to identify the client, and the last two digits identify a VLAN within the client's private cloud. Then, the first two digits become the second octet of the subnet, and the last two numbers identify the 3rd octet of the subnet.

Example: Company ID: 12 Management VLAN: 99 WAN VLAN: 10 LAN VLAN: 20

IP Subnets: Management: WAN: LAN:

VLAN to Subnet Mappings: VLAN 1299 VLAN 1210 VLAN 1220

This would allow me to segregate 40 clients, each with 100 /24 VLANs. I guess I could reverse the order and do 100 clients each with 40 VLANs, but we're too small of a company for me to image having 40 customers, let alone 100.

In any case, is this a sane plan? I like it because the only VLAN configuration that needs to be done is on the switch and gateway router. Also, if a VM fails from one host to another, it doesn't really matter because the traffic is segregated based on subnet rather than a specific port on the switch. The only down side I can see is that it's not as secure because simply changing the IP of a NIC could potentially put it on another VLAN.

I see this as incredibly unlikely, however, as we will be configuring and managing most, if not all of these environments ourselves, and very few of our clients will directly log into the servers, let alone change IPs. Most of our clients have hired us because they don't have an IT department, so the chances of any of them know what a VLAN even is is incredibly slim.


share|improve this question

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.