Aruba & ProVision-based
cancel
Showing results for 
Search instead for 
Did you mean: 

8212zl High CPU when second link of LACP active

 
c-rhousz
Occasional Contributor

8212zl High CPU when second link of LACP active

I have an HP 8212zl that is connected via 10GbE SFP+ to a pair of 5412zl2 running a DT-LACP link. If the second link on the 8212zl is active then CPU utilization for "System Services" spikes to 100% and we start experiencing traffic issues. 

I've checked the trunk configuration on both ends and they match. I've checked counters on the underlying interfaces and there are no errors or drops. Interface utilization doesn't spike at the time. 

I have this same configuration on two other switches (5406zl2) that do not have this issue. Both links are active and passing traffic without problems.

I'm at a loss of what else to check at this point.

Edit: Just brought up another 8212zl and was successful at bringing up two links of the DT-LACP. There must be a device or misconfiguration on the switch that doesn't work.

2 REPLIES 2
parnassus
Honored Contributor

Re: 8212zl High CPU when second link of LACP active

Knowing software versions involved (on HP ProCurve 8212zl and Aruba 5412R zl2) would be of help IF you're already sure both configurations (DT-LACP on Aruba 5412R zl2 side and normal LACP on HP 8212 zl side) are good enough.

I strongly suggest you to double check (or, at least, compare) what you did with what was described into this (HPE) Aruba Distributed Trunking - Technical White Paper and report back your findings.

c-rhousz
Occasional Contributor

Re: 8212zl High CPU when second link of LACP active

I read through the linked whitepaper and all switches involved are correctly configured. The only difference is number of VLANs involved and the 8212zl is not a router (though has a management IP). 

Given that I have two 5406zl2 configured similarly that are not experiencing issues there must be some incompatibility between the 8212zl and 5412zl2? Or some other part of the switch configuration is incorrect and is exacerbated by the second link being active. Honestly it seems to behave as if there were a loop but it was my understanding LACP control shouldn't allow for that to happen.