VMware Cloud Community
Kaimann
Contributor
Contributor
Jump to solution

Standby port channel

Hello,

I  have 2  port channel, 4 physical Nics connected to my VM Guest vSwitch  each port channel on a separated physical switch. So I configured one  port channel to be active and the other in standby mode. Since ESX 4.x I  get warnings that with IP Hash mode standby Nics are not supported.

Thank you in advance!

0 Kudos
1 Solution

Accepted Solutions
a_p_
Leadership
Leadership
Jump to solution

Actually only the warning has been added to 4.x. Using Etherchannel in a active/standby configuration was not and is not a supported configuration.

see http://kb.vmware.com/kb/1004048

The following link shows what will happen in case of a NIC failure. http://www.yellow-bricks.com/2009/10/12/active-standby-etherchannels/

André

View solution in original post

0 Kudos
7 Replies
kermic
Expert
Expert
Jump to solution

IP Hash is used for load balancing and therefore needs 2+ active physical NICs.

Sounds like previously you have been using only 1 active NIC and placed others in standby for failover only.

If you intend to use load balancing (port based, MAC or IP hash), you need to move at least some of your standby adapters to active state.

Hope this helps.

WBR

Imants

0 Kudos
Kaimann
Contributor
Contributor
Jump to solution

Hi kermic,

I understand that if i want to use port channel (LACP) on the vSwitch side i have to use IP Hash. I know that IP Hash dose load balancing too but that’s the idea behind using port channel, or?

Before i had also 2 nics active and 2 standby connected to the switch.

If one physical switch fails the fail over Scenario works… I would like to know why technical VMware shows this warning.

vPort.PNG

0 Kudos
a_p_
Leadership
Leadership
Jump to solution

Actually only the warning has been added to 4.x. Using Etherchannel in a active/standby configuration was not and is not a supported configuration.

see http://kb.vmware.com/kb/1004048

The following link shows what will happen in case of a NIC failure. http://www.yellow-bricks.com/2009/10/12/active-standby-etherchannels/

André

0 Kudos
Kaimann
Contributor
Contributor
Jump to solution

Perfect that is what i y was looking for.

After reading the yellow bricks article it's easy understandable why VMware doesn’t support standby NICs with “IP Hash”

I still need a way to compensate a failure of one physical switch, so i think y let my setup in place. Keeping in mind that in case of failure of one nic i have to take down the other port channel nic fast.

Or there are better ways?

0 Kudos
a_p_
Leadership
Leadership
Jump to solution

If the vSwitch is used for virtual machine traffic, I wouldn't use port channeling at all. You may only benefit from this setup if you run e.g. web servers with a huge amount of outbound traffic to a lot of targets. I don't know your environment, however usually using the default policy "Route based on originating virtual Port ID" and connecting all uplinks as active to different physical switches gives you a good load balancing and also ensures redundancy in case of an uplink or physical switch failure.

André

Kaimann
Contributor
Contributor
Jump to solution

Some years ago, a consultant told us that if we connect various active uplinks to an vPort connected to our Cisco switches the Cisco Switches would block all port but one because of arp flooding problems because the vSwitch can't speak Spanning Tree. So we implemented the port channels. I haven’t thought about not using port channels since then.

I checked using the "Route based on originating virtual Port ID" on our Test environment right now and it look just like it should. In esxtop you can see that VMs or vmk SC ports etc. connect exactly to one vmk nic.

So i will reevaluate our Network setup.

Thanks André

0 Kudos
a_p_
Leadership
Leadership
Jump to solution

You are welcome.

BTW talking about spanning tree, one of the most important settings on the physical switch ports is to set spanning tree to portfast.

For some sample configurations see:

http://kb.vmware.com/kb/1004127

http://kb.vmware.com/kb/1004074

André

0 Kudos