Wireless Access

Hi

We've hit an issue whereby when we reboot an Access Switch hosting our APs (325s) the devices are staying in a notconnected state on the Switch once it has reloaded. Current connectivity is that we have an LACP Port-Channel with 2 connections from the Switch to each AP. Both connections to the AP are up and running prior to the reboot, but stay in a notconnected state on the reboot. We're running Cisco 3850 switches, which are providing PoE+ to the Access Points.

Prior to the switch reboot, if we disable the non-poe interface from the Switch to the AP, save the config and reboot, all the APs come back online as expected, which makes me think the connectivity is related to the LACP config in someway. The config snippet below from the switch details the current Port-Channel and interface config, pulled from the Switch. Is there any additional config that may need to be applied to the APs via the controller in this scenario to get the APs back online.

interface Port-channel102
 switchport access vlan 248
 switchport mode access
 switchport nonegotiate
!
interface GigabitEthernet1/0/1
 description AP102
 switchport access vlan 248
 switchport mode access
 switchport nonegotiate
 power inline port priority high
 channel-group 102 mode active
 spanning-tree portfast
 spanning-tree bpduguard enable
!
interface GigabitEthernet1/0/2
 description AP102
 switchport access vlan 248
 switchport mode access
 switchport nonegotiate
 channel-group 102 mode active
 spanning-tree portfast
 spanning-tree bpduguard enable

Thanks

Did you configure LACP on the AP/Controller side?   http://community.arubanetworks.com/t5/Controller-Based-WLANs/Do-we-have-radio-port-redundancy-on-AP-LACP-GRE-striping-IP-and/ta-p/239920

Thanks for the reply. With regards LACP, good question. I was under the impression it was in place, but based on the CLI output, I'm not so sure. Output below is from the CLI for one of the APs

(Controller) # show ap debug lacp ap-name AP001

AP LACP GRE Striping IP: 0.0.0.0

AP LACP Status
--------------
Link Status LACP Rate Num Ports Actor Key Partner Key Partner MAC
----------- --------- --------- --------- ----------- -----------
Up slow 2 17 10 00:59:dc:a4:9f:80

Slave Interface Status
----------------------
Slave I/f Name Permanent MAC Addr Link Status Member of LAG Link Fail Count
-------------- ------------------ ----------- ------------- ---------------
eth0 b4:5d:50:c7:d7:ea Up Yes 0
eth1 b4:5d:50:c7:d7:eb Up Yes 0

GRE Traffic Received on Enet Ports
----------------------------------
Radio Num Enet 0 Rx Count Enet 1 Rx Count
--------- --------------- ---------------
0 11396 0
1 2824 0
non-wifi 337205 0

Traffic Sent on Enet Ports
--------------------------
Radio Num Enet 0 Tx Count Enet 1 Tx Count
--------- --------------- ---------------
0 7474 0
1 3 0
non-wifi 7690 518176

It looks to my undertrained eye that LACP is in place, though based on the documentation link, we dont have a GRE striping IP in place, though the LMS IP address is configured. I should add from the original post, that the port-channel does become active, we just need to bring it online in a controlled manner one interface at a time.

Having done some further digging, it appears we dont have the gre-striping-ip config in place for any of our APs. Now the query I have is that we have multiple AP groups - 2 x different physical locations. AP-GroupA is just using a single IP address within the LMS configuration, whereas AP-GroupB, which is a remote site with local controllers, has both controller IP addresses within the LMS config.

In order to configure the gre-striping-IP, I'm assuming I need to use the 'AP LACP LMS map' section, and map each gre-striping ip to the relevant LMS address? With regards our remote site, does it allow me to add in both LMS addresses within the mapping section? Also, does adding in the gre-striping-ip cause any interruption to the AP connectivity?

This is currently a production site, so I need to be 100% before making any changes so just ensuring I understand all the details before progressing.

Thanks

In my opinion, having dual-connected APs with LACP would only be useful if you are running 80mhz channels, which is the only time you would potentially have sustained traffic that could exceed a single gigabit of traffic throughput.  Beyond that, it is not really worth the effort of maintaining configurations on both your APs and switches.  Dual-connected AP325s would have to reboot if the main interface that has the POE for some reason gets disconnected and then connect to the second interface, so there is no "hot" failover.  Please more details on striping an LACP here:  http://community.arubanetworks.com/t5/Controller-Based-WLANs/Do-we-have-radio-port-redundancy-on-AP-LACP-GRE-striping-IP-and/ta-p/239920

Thanks for the info. I'm starting to think along similar lines too, whilst I was fairly confident we would never exceed 1gig throughput, I thought dual connectivity might be helpful in the event of a connection failing, but with PoE only being available on the single interface on the 325 there is no validity for dual connections there either.

We had a lot of issues with this. We were also running newer Cisco switch models. The issue was not LLDP or LACP but the PoE circuit on the AP itself. You can apply PoE to either port and that is where the issue lies. The two ports share the same power circuit (or whatever it is called, not an EE) and when the switch reboots it applys power to both ports simultaneously. This causes the AP to shut both ports down. We dealt with a lot of back and forth up to the product managers and eventually this is what was thought to be happening.

Solutions are:

1. Use only one cable

2. If you have multiple switch blades (stack or chassis), plug the second cable into a different blade.

3. Replace the 325 with a 335 that has dedicated power circuits for each port. We ended up going this route and I have not had this issue since.

Edit: change instantaneously to simultaneously

Thanks for the information. In the end we decided to move away from dual uplinks to each AP and connect via a single cable. We've verified with a few Switch reboots and all APs are now coming back online as expected.