Both LACP interface ethernet1/2 moved out of AE-group

Showing results for 
Show  only  | Search instead for 
Did you mean: 
Please sign in to see details of an important advisory in our Customer Advisories area.

Both LACP interface ethernet1/2 moved out of AE-group

L2 Linker

We've a PA-3050 up and running for over a year now. It is configured with an agregated interface with LACP enabled (mode active, transmission rate Fast). These interfaces are attacheced to a procurve 5406 where the interfaces on the procurve are configured as a trunk of the type lacp.


This was running fine till now. Last 3 days the connection on the aggregated interface was gone for about 10 minutes. During this period the system log is filled with these kind of messages:


lacp-up,ethernet1/1,0,0,general,critical,LACP interface ethernet1/1 moved into AE-group ae1
lacp-up,ethernet1/2,0,0,general,critical,LACP interface ethernet1/2 moved into AE-group ae1
nego-fail,ethernet1/2,0,0,general,critical,LACP interface ethernet1/2 moved out of AE-group ae1
nego-fail,ethernet1/1,0,0,general,critical,LACP interface ethernet1/1 moved out of AE-group ae1


I found this article, and this seems to be the case. (the l2ctrld.log is filled up with these messages). However: I have no idear how to fix this.



show lacp local

LACP Local Information.

System ID: 001ffe-854700

LACP Tx Rx Timer
Port Trunk Mode Aggregated Timer Expired
---- ------ -------- ----------- ------ --------
A3 Trk2 Active Yes Fast No
A4 Trk2 Active Yes Fast No


show lacp peer

LACP Peer Information.

System ID: 001ffe-854700

Local Local Port Oper LACP Tx
Port Trunk System ID Port Priority Key Mode Timer
------ ------ -------------- ----- --------- ------- -------- -----
A3 Trk2 d4f4be-407901 16 32768 48 Active Fast
A4 Trk2 d4f4be-407901 17 32768 48 Active Fast


Palo Alto: 

show lacp aggregate-ethernet ae1


AE group: ae1
Members: Bndl Rx state Mux state Sel state
ethernet1/1 yes Current Tx_Rx Selected
ethernet1/2 yes Current Tx_Rx Selected
Status: Enabled
Mode: Active
Rate: Fast
Max-port: 8
Fast-failover: Disabled
Pre-negotiation: Disabled
Local: System Priority: 32768
System MAC: d4:f4:be:40:79:01
Key: 48
Partner: System Priority: 18176
System MAC: 00:1f:fe:85:47:00
Key: 291
Port State
Interface Port
Number Priority Mode Rate Key State
ethernet1/1 16 32768 Active Fast 48 0x3F
Partner 3 0 Active Slow 291 0x3D

ethernet1/2 17 32768 Active Fast 48 0x3F
Partner 4 0 Active Slow 291 0x3D

Port Counters
Interface LACPDUs Marker Marker Response Error
Sent Recv Sent Recv Sent Recv Unknown Illegal
ethernet1/1 390044 11674573 0 0 0 0 0 0
ethernet1/2 390048 11674600 0 0 0 0 0 0


Cyber Elite
Cyber Elite


So just to verify, the software version on the switch hasn't changed at all right? 


Generally if LACP can't actually negotiate you would want to start looking at the cables and the equipment. Are the cables between the devices in a good state; did the software on either recently change, or where any port configurations modified; have you restarted the firewall to clear any potential issues with the l2ctrld daemon; have you restarted the switch. That would be where I would start. Might be worth also setting up a wireshark capture you could enable when you are seeing this issue to see what side is failing to send LACPDU messages. 

We don't have physical acces to the firewall and the switch at this moment. There were no software changes last period.

I noticed the firewall LACP rates on the firewall, ethernet1/1 & ethernet1/2 are both setup for fast, while it thinks is partner has a slow rate.

Changed the LACP transmission rate to slow, and restarted both the firewall and the switch.

Will monitor the log file for any errors.

I've ran into LACP issues with HP equipment more than once.  Usually I have to reboot the HP switch.  I've never had an issue on the PAN.  Next time try just rebooting the HP.  Do some research on fast-vs-slow.  You definitely want them to match otherwise you can experience issues like you've described.  I prefer fast but slow works great too.

In our setup PA side is slow and other switch is fast.

no issues so far.


Help the community: Like helpful comments and mark solutions.

Also on PA i have LACP mode as passive


Help the community: Like helpful comments and mark solutions.

L1 Bithead

Hey! good question, good answer!


Did you manage to resolve the issue with setting it to Slow transmission rate?

Nope, unfortunately we ended up breaking down the channel and used a single port.

This solved the issue for us. 

I suspect the procurve switch. We're planing to replace it.

If I could vote for that plan, I'd say vote early... vote often...

What should be the best practice

both ends should be same like fast fast?


Help the community: Like helpful comments and mark solutions.

Both ends should be the same for sure.  Slow vs Fast really depends on personal preference and/or use case.  They both work fine.

We are also facing the same issue and we have a setup of Juniper & Palo alto. Juniper side it is LACP active with fast & palo is passive with fast. Does anyone else have the similar issue?




Why don't you have them both set to the same?  Set the PAN for "Active".  I have had zero issues with PAN/Juniper combinations.

Well, that is because it worked that way, the recommendation also says that you must have atleast one side as active & it should be ok. although if I think more deeply keeping active/active both side will make both the devices to send PDU's so an increased traffic or so.

Would u mind sharing the software version of both sides, I have 14.1x.53 on Juniper & 17.1.18 on PA side.



  • 19 replies
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!