Wireless Access

I have a number of AP-225's I'd like to configure.  We are using 6.4.0.1 on the controller.  I'm attempting to configure both ports in a LACP configuration on the switch.  Here is my Cisco switch configuration:

interface Port-channel1
description AP-Test
switchport access vlan 155

interface GigabitEthernet1/0/15
switchport access vlan 155
channel-group 1 mode active

interface GigabitEthernet1/0/18
switchport access vlan 155
channel-group 1 mode active

I currently have the AP plugged into port G1/0/15 on the switch, but it appears that it keeps shutting the interface down, and bringing it back up.    When I plug in both ports, it shuts both down, and brings them back up periodically.  Here are the console AP logs:

[ 1130.085048] bonding: bond0: Warning: the permanent HWaddr of eth0 - 9c:1c:12:c0:52:38 - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflicts.
[ 1130.276759] bonding: bond0: releasing active interface eth0
[ 1130.360413] ethernet_device_event: dev eth0 is down
[ 1130.422803] bonding: bond0: releasing active interface eth1
[ 1130.527531] bonding: bond0: setting mode to active-backup (1).
[ 1130.597603] ADDRCONF(NETDEV_UP): bond0: link is not ready
[ 1130.669519] ethernet_device_event: dev eth0 is up
[ 1130.725845] bonding: bond0: making interface eth0 the new active one.
[ 1130.803012] bonding: bond0: first active interface up!
[ 1130.864556] bonding: bond0: enslaving eth0 as an active interface with an up link.
[ 1130.955326] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
[ 1131.032798] bonding: bond0: enslaving eth1 as a backup interface with an up link.
[ 1134.133353] PHY: eth0 (mdio@ffe24000:00) - Link is Up - 1000/Full
[ 1134.488034] PHY: eth1 (mdio@ffe24000:01) - Link is Up - 1000/Full
[ 1181.710790] asap_vap_gone: Got VAP gone indication for vap:0:0 without device unregister
[ 1181.810485] asap_vap_gone: Got VAP gone indication for vap:1:0 without device unregister
[ 1181.960052] bonding: bond0: Warning: the permanent HWaddr of eth0 - 9c:1c:12:c0:52:38 - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflicts.
[ 1182.151755] bonding: bond0: releasing active interface eth0
[ 1182.218485] bonding: bond0: making interface eth1 the new active one.
[ 1182.309939] ethernet_device_event: dev eth0 is down
[ 1182.372494] bonding: bond0: releasing active interface eth1
[ 1182.473523] bonding: bond0: setting xmit hash policy to layer2+3 (2).
[ 1182.550883] bonding: bond0: setting mode to balance-xor (2).
[ 1182.618908] ADDRCONF(NETDEV_UP): bond0: link is not ready
[ 1182.690940] ethernet_device_event: dev eth0 is up
[ 1182.747305] bonding: bond0: enslaving eth0 as an active interface with an up link.
[ 1182.838090] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
[ 1182.915483] bonding: bond0: enslaving eth1 as an active interface with an up link.
[ 1186.161879] PHY: eth0 (mdio@ffe24000:00) - Link is Up - 1000/Full
[ 1186.411670] PHY: eth1 (mdio@ffe24000:01) - Link is Up - 1000/Full
[ 1287.686412] asap_gre_ipv4_err: Received ICMP (DEST_UNREACH, PROT_UNREACH) from 10.100.2.49 for heartbeat tunnel.
[ 1288.688836] asap_gre_ipv4_err: Received ICMP (DEST_UNREACH, PROT_UNREACH) from 10.100.2.49 for heartbeat tunnel.
[ 1289.691281] asap_gre_ipv4_err: Received ICMP (DEST_UNREACH, PROT_UNREACH) from 10.100.2.49 for heartbeat tunnel.
[ 1290.929637] bonding: bond0: Warning: the permanent HWaddr of eth0 - 9c:1c:12:c0:52:38 - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflicts.
[ 1291.121348] bonding: bond0: releasing active interface eth0
[ 1291.202430] ethernet_device_event: dev eth0 is down
[ 1291.264785] bonding: bond0: releasing active interface eth1
[ 1291.366020] bonding: bond0: setting mode to active-backup (1).
[ 1291.436146] ADDRCONF(NETDEV_UP): bond0: link is not ready
[ 1291.508126] ethernet_device_event: dev eth0 is up
[ 1291.564448] bonding: bond0: making interface eth0 the new active one.
[ 1291.641607] bonding: bond0: first active interface up!
[ 1291.703131] bonding: bond0: enslaving eth0 as an active interface with an up link.
[ 1291.793887] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
[ 1291.871441] bonding: bond0: enslaving eth1 as a backup interface with an up link.
[ 1294.937524] PHY: eth0 (mdio@ffe24000:00) - Link is Up - 1000/Full
[ 1295.284525] PHY: eth1 (mdio@ffe24000:01) - Link is Up - 1000/Full

In reading through some documentation here:

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

Yes you need to configure an LACP port-channel on the switch to use both ports. Also keep in mind that the AP only has 1 PD circuit so the AP will need to reboot if the port providing power, drops.

So, true or false?

-- There's an L2 LAG (port-channel for you Cisco folks) with LACP on the connecting switch?

-- There's also an L3 LAG construct on the controller?

-- "show ap debug lacp" is a command issued from the controller, that reports LAG state on an AP to the L2 switch?

-- The L3 LAG on the controller uses the "gre-striping-ip" for source-IP load-balancing across the controller's L3 LAG members, which are GRE tunnels) ?

What about combining LAG/LACP with high-availability fast failover in ha groups?   (I said "backup lms-ip" earlier, but should asked about "ha-group", sorry.)    I guess the "active" ha-controller and "standby" ha-controller each have their own gre-striping-ip, which doesn't need to be routed if all it's doing is providing a source IP for distributing traffic across LAG members (tunnels in this case).  Yes, no?

Thanks for the explanation about the PD circuit, makes sense.

-nb.

-- There's an L2 LAG (port-channel for you Cisco folks) with LACP on the connecting switch?

    true

-- There's also an L3 LAG construct on the controller?

    false, not really. The LAG to the controller from your upstream switch is usually L2 and is configured between the controller      and upstream switch.

-- "show ap debug lacp" is a command issued from the controller, that reports LAG state on an AP to the L2 switch?

     true

-- The L3 LAG on the controller uses the "gre-striping-ip" for source-IP load-balancing across the controller's L3 LAG members, which are GRE tunnels) ?

    false, not really. The GRE striping address allows the access layer switch to use IP load-balancing to balance traffic across both ports down to the AP. 

>>

- There's also an L3 LAG construct on the controller?

    false, not really. The LAG to the controller from your upstream switch is usually L2 and is configured between the controller      and upstream switch.

>>

Sorry, I meant the LAG from the APs to the controller.    It goes:

   AP --- layer2 ---- PoE switch ------ layer3 -----Controller

LAG/LACP is an L2 construct (e.g. LACPDUs have no IP header)  -- and  exists between the AP and PoE switch. 

Sowhat LAG is on the controller when we're showing an LACP LAG to the AP?   (show ap debug lacp).   APs talk to the Controller via L3. Is there a LAG that makes it between the AP and controller over L3?   (Sorry, If I could get hands-on with this and put a Wireshark on it, a lot of these questions would be answered!)

tx,

-nb.

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

Does anyone know how this is accomplished on an Alcatel-Lucent data switch?  I do not see any see anything similar to  "no port-channel standalone-disable".

Regards,

JD

For those that care, on an Alcatel-Lucent switch you simply have to make a lacp of 2 ports and connect the AP-225, then provision as usual.