Unsolved
This post is more than 5 years old
7 Posts
0
50046
5324 LACP not working with firmware > 1.0.0.47?
Hi,
I have a Dell PoweConnect 5324 switch since about 3 years. Two servers are connected through two different LACP LAG (ie 802.3ad channel groups), one Apple Xserver running OSX 10.4 and one Linux server (debian Etch with a 2.6.26 kernel).
Today, I wanted to take benefits of the new (in firmware 2.0.X.Y) option to setup 802.3ad load balancing for channel groups, so I upgraded the switch to 2.0.1.3. Immediately the switch couldn't establish the 802.3ad links with both servers.
In fact the switch reported no failure, but the ports wouldn't associate (ie sh lacp port-channel reported no peers), but both servers reported a successful association. Moreover the sh lacp ethernet reported that there was no synchronization. No settings either on the switch nor the servers could make the association works.
I tried also 2.0.0.40 with the same result.
So back to 1.0.0.47 (and a non-working switch when it encountered the newish configuration) and not load-balancing hash algorithm.
I guess that's the difference between a $3000 cisco switch and a dell rebranded $1000 switch :-)
If someone have the solution to my issue, please speak up.
Thanks,
Brice
bh1633
909 Posts
0
February 9th, 2009 13:00
Did you update the bootcode when you updated the firmware?
bh1633
909 Posts
0
February 9th, 2009 14:00
Please post the config file the recent versions of firmware that does not work for you.
Masterzen
7 Posts
0
February 9th, 2009 14:00
Yes, otherwise you get a non-bootable switch and you have to connect with a serial cable to clean the mess :-)
Masterzen
7 Posts
0
February 11th, 2009 00:00
Hi,
Here is all the information I collected during my tests this morning:
With the working firmware (1.0.0.47):
Working Configuration:
LACP information on the switch:
Still same config, working firmware, the linux server gives the following information
Now the same information with firmaware 2.0.1.03 (non working LACP)
Configuration
Note: the switch when converting the config to version supported by the firmware transformed my port-channels in ON mode instead of AUTO. I manually changed the config to have LACP on. It also added a lacp timeout short for the 4 involved ports. I tried with the LONG timeout, but it doesn't change anything.
Switch LACP information
and on the linux side
So it seems the linux server seems to see the switch, but not the reverse
Any idea?
the switch has the following characteristics: (taken after a reload to 1.0.0.47 and a new fresh configuration)
Thanks for any help!
bh1633
909 Posts
0
February 11th, 2009 09:00
Odd.
I set this up (no with Linux, with another switch) and I was unable to reproduce. There is one odd thing I notice in your data for the failing case on the 5324:
Aggregation: INDIVIDUAL
The mib says: "Returns a value of TRUE if more than 1 port is configured in the channel; otherwise, returns a value of FALSE. "
The config file obviously has 2 ports in this port-channel. So I suspect the automatic configuration file conversion when going from 1.0.0.47 to 2.0.1.3
Can you load 2.0.1.3, delete the confi file, reboot, manually type in only the LACP config lines and see if it works with Linux?
bh1633
909 Posts
0
February 11th, 2009 10:00
I did the test with against a newer model dell switch (5448).
If you can capture and compare LACP BPDUs between the 1.0.0.47 and 2.0.1.3 firmware, that would be interesting data.
Since the config file conversion is giving odd results, I think deleting the config with 2.0.1.3 and then re-entering a minimal config will give us some good data.
Do you have a newer Dell switch you can try? 54xx or 35xx?
Masterzen
7 Posts
0
February 11th, 2009 10:00
is it with another Dell switch or another brand/model?
I suspect the switch doesn't conform exactly as the standard. I don't have a proof of that of course, I'd have to capture the 802.3ad PDU to see that, which I'll certainly do if that's possible to capture such packets from a non-active bond on linux (or individual members).
Yes, I'll try this tomorrow morning (the switch is used as a core switch for a small network so I can't interrupt traffic whenever I want).
The thing is, after conversion, the port-channel is in mode ON (no LACP), so I have to remove the individual ethernets from the port-channel and form again the port-channel. OK, that's not quite the same thing as a full erase.
I don't have support anymore on this switch, but is there a way I can submit a bug report to dell, since I don't think the engineers who designed the firmware browse this forum?
Thanks for your help.
Masterzen
7 Posts
0
February 12th, 2009 08:00
Hi,
I removed the configuration before upgrading as you suggested and indeed it fixed the issue!
Thank you very much for your help.
Now I have to convince the switch to load balance the traffic :-)
bh1633
909 Posts
0
February 12th, 2009 08:00
Look at the "Configuring Load Balancing" section of this doc:
http://support.dell.com/support/edocs/network/pc5324/en/UG_Ad/UGAdd.pdf
For an indepth the default LAG hashing algorithm used by most switches (this is written for a blade server switch, but the concepts are simple enough to apply to a standalone switch. The switch in this doc and the 5324 have same hashing options):
http://support.dell.com/support/edocs/network/LAG1855/LAGConsiderationv0.5.pdf
gb1001
1 Message
0
May 5th, 2013 04:00
I upgraded a PowerConnect 5324 switch to version 2.0.1.4 (boot version 1.0.2.02) and three Linux hosts running LACP stopped working. Restarting the switch didn't help. Restarting the Linux hosts didn't help.
YUK WORKAROUND (as suggested above):
- delete the startup configuration
- restart the switch
- restore the configuration
I manually cut-n-pasted small sections of the configuration through the console.