HPE Aruba Networking & ProVision-based
1821470 Members
2771 Online
109633 Solutions
New Discussion

2920 Stack with Esxi 5.5

 
AlexHeron
Occasional Visitor

2920 Stack with Esxi 5.5

Hi,

 

We are trying to configure our new Procurve 2920 stack with a new Esxi server. We have connected both ports of the server, one to each switch. 1/36 & 2/36

 

Reading any documentation we can find, we should configure the Esxi server to set NIC Teaming to "Route based on IP hash", which we have now done. Then we configure the Trunk on the switch using "trunk 1/36,2/36 trk11 trunk".

 

When we do this, we are unable to ping the  server and only by disabling one of the ports can we gain access to the server again. 

 

How should Esxi NIC teaming and Procurve trunking be setup on a 2920 stack?

 

Thanks

Alex

3 REPLIES 3
Vince_Whirlwind
Trusted Contributor

Re: 2920 Stack with Esxi 5.5

Did you try using LACP on your switches instead of Trunk?

AlexHeron
Occasional Visitor

Re: 2920 Stack with Esxi 5.5

Hi,

 

My understanding was that VMWare Esxi does not support LACP and switch trunk ports should be  configured as trunk, not LACP, and the new version of VMWare Esxi 5.5 only supports LACP with VDS, which we are not using.

 

Thanks

Alex

AlexHeron
Occasional Visitor

Re: 2920 Stack with Esxi 5.5

We have resolved this following information in this blog post comments from Tom Ranson on Wednesday, March 4, 2009 at 2:08 pm

 

http://blog.scottlowe.org/2008/09/05/vmware-esx-nic-teaming-and-vlan-trunking-with-hp-procurve/

 

The issue lay in that there were overriding load balancing configuration settings within the configuration of the ‘Management Network’ of the ESX host; these settings were the ‘defaults’ (i.e. route based upon virtual port ID), however they were configured (tick boxes) to override the configuration of the associated vSwitch! – the Management Network appeared to be set to override a fair number of vSwitch configuration options by default, and was causing all of my issues! Disabling all of these override options (which is appropriate in our configuration), so that the vSwitch configuration options are the only ones considered resolved the ‘no connectivity’ issues – obviously (well, now anyway) the Management Network was attempting to load balance in a means that the ProCurve switch could not handle – i.e. originating virtual port ID.