Wireless Access

Hi,

 

We've had some problems reported with some of our dual-linked Aruba AP's. I've been testing in the office to see if I can narrow things down. I tested initially with an AP-224 on an HP 2920 PoE+ and experienced poe power allocation issues, and have just moved onto a Cisco 2960x and (after limited testing) it looks like I'm seeing similar issues with that. The trunk is set on the switch as static lacp (trk1), and lacp active on the Cisco. LACP ends up shutting down the second link due to the power change initiated (we think) by lldp, but I'm not 100% certain about that.

 

Most of the time only one link comes up, watching the AP output on the console shows that Eth1 is shut down because of insufficient voltage. What is strange is that _sometimes_ after a while Eth1 is brought back up due to power change (LLDP messages prompting this?). Sometimes it'll then stay up, sometimes it goes straight back down again. But most of the time it fails to come up at all.

 

On the HP I could 'fix' the issue by setting the allocated power value manually, and setting 'poe-allocate-by value', but this isn't ideal - surely this shouldn't be necessary?

 

On the Cisco it looks like there is a similar facility for setting the allocated power statically, I haven't had time to test this yet, but again, it seems like this shouldn't be necessary.

 

Has anyone else experienced this? I can see examples dotted around various forums when I Google, but I have yet to find anyone giving a firm solution. I feel like there's probably something simple that I'm missing... but....

 

We're running 6.4.3.4.

 

Thanks

Did u try this: (From AirHeads forum)
For others wondering how to best configure a switch switch for LACP to Aruba APs. The trick is to configure "no port-channel standalone-disable" on the port-channel interface. This allows an AP to connect to the WLC while it hasn't fetched its configuration from the WLC yet. Without it the port-channel members will stay down, preventing the AP from registering and being stuck in a state of limbo.



Alternatively, you could leave the LACP switch configuration until all APs have registered but that means touching the switch each time you add or replace an AP.



Blog post about Aruba AP LACP and Cisco switches:

http://www.djerk.nl/wordpress/2015/cisco-lacp-config-for-aruba-ap

 

---

@kdisc98 wrote:
Did u try this: (From AirHeads forum)
For others wondering how to best configure a switch switch for LACP to Aruba APs. The trick is to configure "no port-channel standalone-disable" on the port-channel interface. This allows an AP to connect to the WLC while it hasn't fetched its configuration from the WLC yet. Without it the port-channel members will stay down, preventing the AP from registering and being stuck in a state of limbo.



Alternatively, you could leave the LACP switch configuration until all APs have registered but that means touching the switch each time you add or replace an AP.



Blog post about Aruba AP LACP and Cisco switches:

http://www.djerk.nl/wordpress/2015/cisco-lacp-config-for-aruba-ap

---

Thanks for this advice, but it wasn't the problem that we were experiencing

So after quite a lot of testing we arrived at these conclusions:

 

Problem seen - ap-224 dual link sometimes (seemingly randomly) fails to form on start-up, power allocation problems suspected.

 

Tested on Cisco 2960-X and HP 2920, both PoE+, no midspan injectors used.

 

We think that this problem arises when power is allocated to Eth1 rather than Eth0.  You can test the theory by connecting Eth1 first, waiting a few seconds, and then connecting Eth0. This will result in the AP running in power saving mode with a single link. Reversing this process we have found that the AP comes up as it should do with a functioning dual link.

 

This seems to be because the AP will always bring Eth0 Up, even if Eth1 is supplying the power. The LLDP negotation that would normally take place for increased power allocation cannot take place in this configuration (a packet capture shows that the AP is sending requests for increased power but that none is being allocated).

 

Solutions - there are a couple of ways that we found to deal with this:

 

a) Allocate PoE statically on the switchports   

        Cisco: 'power inline consumption <value>' eg '25000')

             HP: 'poe-allocate-by power'

                   : 'poe-value 25'

 

b) Turn PoE off on the port connected to Eth1

        Cisco: 'power inline never'

             HP: 'no power-over-ethernet'

 

Solution a) is less than ideal because the switch will take the allocated value out of its available budget, even if the AP isn't actually drawing that much power, much better to use LLDP if possible. So our choice is b), though it's not great having to do this either.

 

Whether this behaviour is as per PoE standards or not we're not sure, but it certainly seems undesirable so (if there isn't one already) we'll initiate a bug report for this...

 

#AP225

Hi,

 

I know this is an older post but I have this exact issue on AP 325s and I have found the same results you did with the packet captures and switch debugs. LLDP is requesting power only on Eth0, even when power is initially given to Eth1 from the switch. This causes the switch to ignore the power request due to the Eth0 port not using PoE.

 

Did you get a permanent solution from Aruba or an official bug?

That's interesting to hear - Aruba are currently saying that they cannot replicate the problem so I am (as we speak) logging the console output and will send them the results.

 

Which ArubaOS version are you using? And make/model of switch?

 

Guy

Aruba is claiming the same for me. I am running version 6.4.4.3. The switch model is a Cisco WS-C4507R+E with line cards WS-X4748-UPOE+E.

Finally received an update on this issue. They are now reporting it as bug #117927. Not much in way of fixing it but at least they have been looking at it.

 

From the email I received from my SE:

----------------------------------------------------------------------------------------------------------------------------------------

We wanted to let you know that Engineering has completed testing and analysis on the POE problem you have been seeing when ETH1 is plugged in before ETH0 .

 

They have closed the bug indicating that there is no remedy that we can make because of switch behavior.

 

We were able to consistently reproduce this problem using a Cisco 3750-X switch running IOS 12.2 code.

 

In summary, the behavior arises because the switch will only provide power on the first port, of a dual homed AP,  that it receives the LLDP request on. So when the AP325 in connected first on the Eth1 port it begins the power negotiation process however when Eth0 comes up, which is preferred by the Ethernet chip in the AP, it attempts to come active using the Eth0 port instead of Eth1. Unfortunately when the switch receives LLDP power requests from the same device on the second port it refuses to reply so the AP never fully powers up being left on 802.3af power from ETH1.

 

We are now seeing this behavior on Cisco, Juniper and HP switches at other customers and they are all tied to this same logic – deny power on the second port where LLDP requests are being sent from by a dual homed device. The only switches it presently works on are only the Aruba Mobility Access Switches. We do anticipate a patch to the HP(now rebranded Aruba-OS) switches soon to also solve this problem.

 

Though this is not the answer we were hoping for, we can replicate the issue 100% of the time and have packet captures to validate the behaviors. Our Engineering team has no way to solve this problem on our end since the Ethernet Chip behavior on the AP is not something we can re-program via software.

 

This leaves only a couple of options for eliminating the re-occurance of this issue -

 

1. Ensure that ETH0 is plugged in first when dual homing APs, or
2. Disable Power on the switch port connected to ETH1, or
3. Not dual home the  AP.

----------------------------------------------------------------------------------------------------------------------------------------

Great that it has been accepted as a bug. It seems fair enough that there isn't a fix for it, but shouldn't this behaviour be documented clearly in the installation instructions?

Great that it has been accepted as a bug. It seems fair enough that there isn't a fix for it, but shouldn't this behaviour be documented clearly in the installation instructions?   <---- since.... well... We was there 2 years ago... nobody know how to helps us.... "una mancha mas pal tigre" :(