Did you ever get an answer to where the LACP LAG goes to (the connecting PoE switch, or the controller) ? I have the same question. Did you end up needing port-channels on the connecting switch?
This post shows the controller as being the link aggregator, not the connecting switch?
http://community.arubanetworks.com/t5/Community-Expert-Day-1-17-14/Link-Aggregation-for-AP-225-Uplinks/td-p/133477
But the Aruba User Guide says:
"LACP support is limited to a use case where Enet0 and Enet1 ports of the AP are connected to a switch, and LACP is enabled on the two corresponding switch ports." Does that mean the LAG is formed to the controller, but LACP is only to the connecting switch? (that's a mind-blower).
Also, the documentation mentions that the "2.4GHz tunnels are anchored on the gre-striping-ip," and a sample screenshot in the post above has "show ap system-profile" showing "RF band: g" . What does the LAG have to do with the 2.4GHz radio in particular, or is it because Enet1 is tied to that radio?
It also says you can't enable LACP if the Enet1 port is shutdown -- so if something happened to that one cable, the 2nd cable to Enet0 wouldn't take over, like in a normal LAG?
Finally, the sample configs show only an "lms-ip" configured in the ap system-profile, but not a backup lms-ip, such as if your APs were configured in "high-availability failover" mode (with an "ha group" on a Local/Local active-active pair). I guess the backup controller would have its own gre-striping-ip in its ap system-profile, and if there were a failover, then the LAG would have to be rebuilt to backup controller and its gre-striping-ip. Has anyone put LAG/LACP together with the dual tunnels (lms-ip and backup lms-ip) , and if so, how did you handle the gre-striping-ip?
-nb