topic NIC teaming on different switches in Operating System - VMware

NIC teaming on different switches

Antonio_73 — Fri, 08 Jan 2010 13:16:50 GMT

I'm planning to setup a redundant and reliable environment, using more servers and more switches, all based on vmware sphere, hp servers, storages and switches.
Currently I have two DL585 G2 with eight 1GB ports for each server, and two Procurve 2810-24G switches. I want each server to have access to two switches, for every connection.
About iSCSI, I'm planning to use multipathing on dedicated single NICs, so usage of different switches is ok.
Problem arises with NIC teaming for all remaining connections, as vmware states it can be done only on single or stacked switches.
Is the Procurve 2810-24g stacking suitable for this operation or does vmware means another kind of stacking?
Is there anyone wich solved already this problem, having the network always on despite of switch hangs?
Thanks

Re: NIC teaming on different switches

Uwe Zessin — Fri, 08 Jan 2010 14:26:42 GMT

You can do NIC teaming on non-stacked switches as long as you don't select an incompatible load balancing mode that sends the same MAC address across multiple pNICs (route based on IP hash).

Re: NIC teaming on different switches

Antonio_73 — Fri, 08 Jan 2010 17:28:46 GMT

I tried setting a fixed failover order in the teaming (port1-sw1, port2-sw1, port3-sw2,port4-sw2), but after disabling ports on the switch sw1 all hangs.

Re: NIC teaming on different switches

Uwe Zessin — Fri, 08 Jan 2010 17:32:13 GMT

Please define "disabling ports" - did it drop the link?

Re: NIC teaming on different switches

Antonio_73 — Fri, 08 Jan 2010 17:58:04 GMT

I disabled ports on the swicth, so they were 'disconnected' on the vmware side.

Re: NIC teaming on different switches

Antonio_73 — Sat, 30 Jan 2010 15:10:47 GMT

All is working as wanted, in double switch redundant configuration.

Setting IP hash on vmware side, and trunking on switch side (each switch has his own trunk) works well.

The hang was caused by an apparently inoffensive unmanaged switch, linked to both 2810 switches, which instead was managed and caused spanning tree to exclude the second 2810.

Thanks for previous answers.