Multiple nics off different networks on a virtual switch

[I3hd137698]

I think this is going to be a really dumb question but I just started at a new company and I was going over their vm network and they have three networks

172.16.2.x - physical network

175.16.5.x - vm network

10.0.0.0x - iscsi network

When I started documenting the way everything was setup and connected I noticed that on the virtual switches there were two network adaptors tied to each but those nic's were bound to two different IP groups. 

One example is  the physical network has one nic bound to the physical network the other is on the iscsi network.

The Iscsi virtual switch has one nic tied to the iscsi the other to the physical network.

In my last company I worked with (my first with VM) it was not setup this way both nic's were bound to the network and set for load balancing based on route based.

I was planning to move the nic's tied to the vswitches to have the two physical network nic's tied to the physical virtual switch and the same for the iscsi but I wanted to get some feedback from here first in case this may have been setup this way for any reason people here knew about.

Thanks,

[rickardnobel]

Hello and welcome to the forums!

I am a little unsure what you mean that the network adapters are bound to different IP groups. Could you post a screenshot of the networking setup? It will be much easier to discuss network design questions.

[I3hd137698]

Sure, below are the screen shots for the network adapters in the two vswitches, in Vswitch 1 (the VM network) Nic 5 is on the iscsi network and nic3 is on the vm network. In vswitch 2 (iscsi network) Nic 4 is on the VM network and nic 2 is on the iscsi network.

It would make more sense if on Vswitch 1 had nic 3 and 4 and Vswitch 2 had nic 5 and nic 2 like what I had on my previous network. I didn't set either up just trying to work my way through understanding why each would be setup like this.

[rickardnobel]

It does seems to be very incorrect setup. As a matter of fact it is rather a bit strange that it is working at all, so some more checking could be done.

Which portgroups are on vSwitch1 and vSwitch2? Are there any special settings on those portgroups, like active/standby adapters?

Which NIC teaming load balancing policy is being used?

[I3hd137698]

On teh port group it is set to route based on originating virual por tide and failover for link status only but I can't see how it would work if it fails over to a network adaptor on the incorrect network.

I setup a second host with the nic's paired by network and planned to change the first host over to the way I setup host two but wanted to see if anyone knew of any reason why you would set the networks up the way they originally did.

[rickardnobel]

I3hd137698 wrote:

On the port group it is set to route based on originating virtual port id and failover for link status only but I can't see how it would work if it fails over to a network adaptor on the incorrect network.

Do you have several Virtual Machines on the vSwitch? If there is no active/standby NIC order set then some VMs should already be put on the incorrect network..

Do you know if the iSCSI and the Virtual Machine networks are physically separated by different physical switches or by VLANs on the physical switches?

[I3hd137698]

Yes there are about 5 virtual machines on that host and all are working, it doesn't make much sense though.

[rickardnobel]

*Moved thread into Networking area.*

I3hd137698 wrote:

Yes there are about 5 virtual machines on that host and all are working, it doesn't make much sense though.

Do you know how the physical switches are setup? It might be that all connect to the same layer two broadcast domain and that is why it is working at all. If not, it would not make sense at all.

[I3hd137698]

Sorry yes, missed the question in your previous post.  The swiches are configured using port based vlans.

[rickardnobel]

So the outgoing VMnics are really going into separeted networks? Really hard to understand how it can work at all. Clearly it is not correctly configured, but strange that it have not caused both the iSCSI SAN and the VM networks to break.