So, ich poste hier mal die Antwort von HP.
Hatte dort ebenfalls ein Ticket geöffnet
Sehr geehrter Herr xxxxx,
Ich habe die Antwort vom L2 Kollege bekommen, dass das Verhalten bei dem 1810 bekannt und „as per design“ ist. Auf eine Aktualisierung der Firmware, die dies ändert, wird nicht gearbeitet.
Ich gebe Ihnen unten seine Antwort im Original. Ob das 1910 funktionieren wird, kann ich erst nächste Woche bestätigen, wenn ich es im Labor getestet habe. Die anderen Vorschläge von L2 sind in Punkt 1-3 unten aufgelistet.
“Hello zzzzzzz,
I accepted the elevation subcase for the above referenced issue.
You are correct, this happens because the attached device is not sending LACP BPDUs to the switch when it is in sleep mode, so it tears down the trunk and cannot send traffic to the sleeping device.
On our fully managed switches we behave a bit differently when it comes to LACP. When there are no LACP BPDUs coming in from the peer, the switch is of course not able to aggregate the links into a team. However, the standard allows to bring up a single port in the aggregate group and treat that as if it was a successful LACP trunk. In that way there is still a path open for WoL frames to reach the device, as long as the correct MAC address is used (typically that is the MAC address of the NIC connected to the port with the lowest number within the aggregate).
The standard does not demand that we do it this way, but it does allow it in order to accommodate things like WoL. The 1810 unfortunately does not do things this way. It will block all the ports in the aggregate and not pass any traffic (except for LACP and LLDP BPDUs) on the ports in an aggregate that is not receiving LACP BPDUs from the peer. This is also perfectly compliant with the standard (802.1AD), so we are not our of specifications with the current behavior.
We had an elevation (which I handled) back in 2011 where we investigated the possibility to make the 1810 behave like our fully managed switches (the ones with CLIs). However the risk was deemed too high because it would require changes to almost all areas of the software. That decision still stands. So I’m afraid this is expected behavior and the device is operating as per the design.
There are basically three different options for the customer:
1) They can use one of our fully managed switches instead, they do accommodate the customer’s use scenario very well
2) They can choose not to use sleep mode on devices connecting via an LACP trunk
3) They can choose to use a protocol-less (static) trunk instead of using LACP
I will leave these choices to the customer, so they can pick the one which suits their environment the best. I also just wanted to mention that a software update might not be a bad thing, we have had quite a number of fixes since P.1.18, see attached. Since they are running a P.1 version they would have to first update to P.1.20 which does nothing but prepare the switch for a P.2 version. Then they would immediately update to the most recent P.2 version available. It is NOT wise to run P.1.20 for any length of time as it was never meant for production use, but only to facilitate the update to P.2 versions (it basically re-arranges the way config files etc is stored internally.)
You are welcome to share all of the above with the customer. Please let me know if they have any additional questions or concerns.”
