"Does anyone had problems bindings different type of NICs in the same Vswitch ?"
No, I do it all the time.
"When a NIC is certified, is sure that I can put in a cluster with other certified NICs ?"
Yes, you must have some other problem. Are you sure the physical switch ports that the NICs connect to are configured properly? I would suggest binding each nic to a vswitch one at a time, to see which exactly work on their own and which don't.
Yes, I'm sure !
I've tried invert the cable from Broadcom NICs and the INTEL and nothing changes.
I've tried to connect the two INTEL interfaces using a cross cable to exclude the phisical switch and nothing changes.
I've tried to bind each nic one at a time, but also when adding the first INTEL all networking went down.
Not helping but just confirming: At TSX event in Nice this year, a network guy from VMware specifically confirmed that mixing different brands of nics in a virtual switch is NO problem.
I'm thinking so, but reading vmware documentation and forum I can't find a clear answer, so I wrote this post.
I think it's a NIC's problem and not a vmware problem.
We encountered a similar problem back when ESX 2.5. We were told that the issue was fixed in 3.0, but after upgrade, the problem persisted. We have Dell 6650 with 2 Broadcom Gb and 2 Intel Pro 1000. Both chipsets are certified, but we found out that the issues originated from misconfigured NIC's and NetSwitches.
There is a problem when traffic shaping is used with VLANs. Most Net Admins would like to shape the traffic at the NetSwitch, but with ESX, that doesn't work well, becuase the vSwitch and the Net Switch can't agree on a specific protocol to use.
We found out that if ESX handles the traffic shaping with the NICs set to Load Balance and the NetSwitch set to just handle the VLANs, no traffic shaping or bonding on the NetSwitch end, the problem went away.
I've seen the same happen between Cisco and Nortel switches in the past. Always remember that standards are not implemented the same way by vendors, so decide which vendor product must have the ultimate control and let that product handle the rest, the other pieces should follow (not always, though).
Hope this helps.
This is a pretty common practice as alot of servers come with built-in Broadcom's and additional NIC's are usually Intel. It's been said the Intel's perform much better then the Broadcom but this should not effect your ability to mix them. Just make sure any NIC you use is on the HCL list.
The VMware support guys told me not to mix different types of nics, either he was wrong or just telliing me some BS to buy some more time.
I would ask them to point you to some documentation that states this and the reasons why you should not.
The suggestion to
notmix NIC vendors is a holdover to earlier versions of ESX where it was known to cause issues. There isn't any reason why you can't mix NIC vendors in ESX 3.x.
In actuality, mixing NIC vendors in a team provides a certain element of redundancy. In
rarecircumstances I have seen both the e1000 and tg3 VMkernel drivers hang or unload, so having the other vendor in the mix provides a little insurance.
Hey nice crown Paul!
Why thank you, Mr. Siebert!