LACP/802.3ad aggregation issue

shivi_kl81 · ‎01-28-2009

I have a LACP based etherchannel configured b/w a Cisco catalyst 3750 switch and a server which implements LACP. The ports on the server are configured to be in 'active' LACP mode and the switch ports in 'passive' mode. The ports are configured for long timeout. The aggregation sets up normally without any issues and works fine.

Server -------- Cisco Sw

P1|---------------------|P1

P2|---------------------|P2

I have a situation where, due to some issue in the server, LACPDUs aren't being sent over P2 for a few seconds. The timer (current_while) expires at P2 on the Switch and LACP running on the port moves to 'Defaulted' state. Now, the switch moves port P2 to suspended state and doesn't forward any packets to that port. I don't understand why should the port be suspended. 802.3ad specs is not very clear on this. Is this the expected/correct behavior ...?

I tried this with another switch (diff make) and that also behaves in the same manner.

I recently upgraded my cisco switch software to the latest level (12.2(44)) and I don't see this issue anymore. That is, the port P2 on the switch is not suspended though LACP is in 'Defaulted' state. But my other switch still behaves the same. I am assuming that the new Cisco behavior is correct.

Thanks in advance.

Giuseppe Larosa · ‎01-28-2009

Hello Shivi,

I saw something similar with active configuration

Dec 24 17:00:36: %EC-5-UNBUNDLE: Interface Gi6/7 left the port-channel Po3

Dec 24 17:00:41: %EC-5-L3DONTBNDL2: Gi6/8 suspended: LACP currently not enabled on the remote port.

Dec 24 17:00:41: %EC-5-L3DONTBNDL2: Gi6/7 suspended: LACP currently not enabled on the remote port.

Dec 24 17:01:21: %EC-5-L3DONTBNDL2: Gi6/7 suspended: LACP currently not enabled on the remote port.

Dec 24 17:01:23: %EC-5-L3DONTBNDL2: Gi6/8 suspended: LACP currently not enabled on the remote port.

In our case to solve the server was reloaded. Because it was not sending LACP frames for more then a few seconds.

this switch is a 4506 with an older IOS.

I agree that if the LACP frames are missed for a few seconds would be better to keep the port working if the few seconds are under the keepalive frequency.

I just wonder if the timers are overriden by the active side or by the the device with the lowest LACP system-id (like it happens in STP).

Best Regards

Giuseppe

shivi_kl81 · ‎01-28-2009

A small correction. The server actually wasn't sending LACPDUs for more than 90 seconds, which is the timeout period with 'long timeout' setting. Hence the timer at P2 on the switch timed out and the LACP moved to 'Defaulted' state. I am trying to understand if suspending the port and not forwarding any packets over the port is a correct behavior in this case.

Thanks.

Giuseppe Larosa · ‎01-28-2009

Hello Shivi,

from a security and stability point of view after timeouts can be a good behaviour.

After all, we are using a protocol to negotiate the bundle and to keep it monitored and alive

Hope to help

Giuseppe