VMware Cloud Community
Marv_Gordon
Contributor
Contributor

HP 5308XL, LACP & ESX 3.5

I've followed the instructions and have set three static LACP trunked ports on our Procurve 5308XL (very latest firmware).

I set route based on IP hash for the Vswitch as documented.

Everything seems to work fine until I reboot my test ESX server. Can't ping anything after that.

Anyone else running a similar config?

Note: I do have 2 ports on one gigabit module in the 5308xl and 1 in another gigabit module on the same switch. Might this be the issue ?

Tags (3)
0 Kudos
30 Replies
mike_laspina
Champion
Champion

Hello,

I have some HP 53xx configs.

What is it that you can not ping?

http://blog.laspina.ca/ vExpert 2009
0 Kudos
Marv_Gordon
Contributor
Contributor

Can't ping my esx server/vm's from the physical DC on the production subnet. I haven't had a lot of test time yet...I hope to take a look at this during the week but I've doubled checked everything so far and no luck...

0 Kudos
Marv_Gordon
Contributor
Contributor

I see the problem. When ESX Server reboot the 5308XL ports are being blocked by LACP. I've tried turning off auto configure for the ports and esx server nics...no luck.

Any ideas?

0 Kudos
CiscoKid
Enthusiast
Enthusiast

Just wanted to clear the basics, are your LACP trunk ports configured on VLAN1? According to HP you must conifgure LACP trunk ports on VLAN1.

0 Kudos
mike_laspina
Champion
Champion

You nee to make sure that all the vlans you are using on the ESX vswitches are added and tagged to the trunk port.

The default vlan 1 is untagged. If you are using it you may need to tag it.

I do not use a vlan of 1 as my default for security reasons.

ESX VST will route the tagged packets to the correct vports once this is configured.

e.g.

spanning-tree a trk1 auto-edge-port (This is to enable fast STP)

vlan 100 tagged a trk1

http://blog.laspina.ca/ vExpert 2009
0 Kudos
CiscoKid
Enthusiast
Enthusiast

I totally agree with VLAN1 and security reasons. I had a customer that had a similar behavior with their ESX, NetApp and LACP configuration. The difference in their situation is that they were using 4208vl chassis which may have had a lot more command restrictions.

0 Kudos
Marv_Gordon
Contributor
Contributor

Yes....vlan1

0 Kudos
Marv_Gordon
Contributor
Contributor

Aha.... I'll give this a try.....

0 Kudos
Marv_Gordon
Contributor
Contributor

Finally had a chance to test for a bit last night. With the spanning-command and tagging the symptoms changed. When I rebooted my esx host the ports were NOT blocked... However I still couldn't get an network traffic to pass. Pings would not respond. I also couldn't create any outbound traffic from a guest.

To clarify, Other than the hash setting on the vSwitch and the Vlan ID (used 1 for testing) on the virtual network (I saw no mention in doc of using the hash setting in the virtual network) are all that's needed?

I might give this another shot from home and post my 5308XL relevant settings as well.....

0 Kudos
Marv_Gordon
Contributor
Contributor

Again...blocked by LACP after the host is rebooted :smileymischief:

interface H3

no lacp

exit

interface G2

no lacp

exit

interface G9

no lacp

exit

trunk G2,G9,H3 Trk2 LACP

vlan 3

name "ESX"

tagged Trk2

exit

spanning-tree Trk2 priority 4

0 Kudos
hannisch
Contributor
Contributor

hello,

i have the same problem using a hp 2810.

i configured esx vswitch to ip based policy (2 nics)

configured the switch:

in 23

no lacp

exit

in 24

no lacp

exit

trunk 23-24 Trk1 LACP

exit

spanning-tree Trk1 priority 4

Everytime I reboot ESX server I port is blocked

Everytime I disconnect and reconnect 1 port, this port is blocked

after rebooting the switch or disabling and enabling the blocked port, the switch LACP Status

went to Success.

When I do a show lacp, i got the following output:

PORT LACP TRUNK PORT LACP LACP

NUMB ENABLED GROUP STATUS PARTNER STATUS

-


-


-


-


-


-


23 Active Trk1 Up No Success

24 Active Trk1 Up No Success

I´m wondering that LACP Partner is no, or is this normal on static LACP trunks ?

Or do I have a configuration error and lacp partner has to be yes.

Do you still have a solution for the problem of blocked ports ?

here is the whole config:

hostname "SW07"

snmp-server contact "Admin"

trunk 20-24 Trk1 LACP

ip default-gateway 192.168.1.10

vlan 1

name "DEFAULT_VLAN"

untagged 1-22,Trk1

ip address dhcp-bootp

exit

spanning-tree Trk1 priority 4

password manager

password operator

best regards,

Sven

0 Kudos
Marv_Gordon
Contributor
Contributor

Sven,

No luck yet. I was pulled away from this and hope to get back to it soon. If I find the answer I will post it here.... good luck!!!

0 Kudos
mike_laspina
Champion
Champion

Hi, That would be expected with lacp you need to use trunk.

Issue this command and it should behave on reboot.

trunk 23-24 Trk1 trunk

http://blog.laspina.ca/ vExpert 2009
0 Kudos
hannisch
Contributor
Contributor

Hi Mike,

thank you for the Info. I was not shure taking trunk instead of lacp, because i read that the switch had to be configured 802.3ad compliant to communicate to a ip port based vswitch,

and in the hp dokumentation was described, using trunk is without protocol.

0 Kudos
mike_laspina
Champion
Champion

Your welcome.

Yes I know it is not very clear. It took me a few kicks before I got it figured out.

What they do spec is that it needs to be in static mode and trunk does just that.

FEC will work as well but HP's new firmware releases do not use include it any more so I have standardized on 802.1ad.

http://blog.laspina.ca/ vExpert 2009
0 Kudos
Marv_Gordon
Contributor
Contributor

Got it.... ESX connections survived reboot.

However, virtual machines had no connectivity. I'll be able to spend more time troubleshooting this week.

Thanks for the feedback.

0 Kudos
kingmarino
Contributor
Contributor

Maybe this could be a great time for someone from VMware to jump in and give us feedback on this issue. We have the same problem over here and we would like to have this problem corrected or at least a workaround..

Regards

0 Kudos
w0d0l0ner
Contributor
Contributor

We use 5304XL and 5308XL switches and I have the same problem.

I find that it is not that big of a deal since the ESX are usually not restarted. :smileygrin:

The only way I got the esx to use multiple ports properly was setting the trunk on the switch side as a static LACP.

#trunk B1,F15 Trk1 LACP

On the ESX side I setup the vswitch with IP hash option.

It seems that the output of show LACP says LACP partner "Yes" when the other side is using an active LACP to create dynamic trunks.

If the other side is a static configured LACP partner, then it always seems to say "No".

I assume this just denotes if the switch is recieving the aggregation packets.

The switch always shows that the ports stay at LACP blocking after rebooting the ESX.

I can get the lacp trunk working again by disabling all but one port for a couple of seconds and then reenabling it.

If I setup a trunk with the type "Trunk" then it seems that some of the VM's can't be reached from some network hosts.

The only way I can explain this is that I assume that the traffic is put on a port where it is not expected.

From documentation I read, it seems that the different static trunk types "Trunk", "LACP", and "FEC" (old firmware) have different ways of determining what traffic is placed on which port.

That could be the reason why you could not access the VM's after the reboot, even though you could access the esx.

Using a different client you might get a connection. :(different mac and IP)

You are right though, it would be great if some vmware network guru would get involved.

I once considered opening a case with vmware support, but I just can't go rebooting the ESX machines we have, "just for fun". Smiley Sad

0 Kudos
pauska
Contributor
Contributor

I am experiencing the same problems with a HP ProCurve 28010-24G switch. Tried both LACP and standard trunk, IP hash on vswitch (and other options) and still no go. Sometimes the VM's responds, sometimes not.

It would be lovely if someone from vmware could respond on this matter - as it is a serious bug that renders our bandwith in half.

0 Kudos