AP 1562 MAP won't join RAP

[NRM9852]

Using 2x 1562's in this exact setup for bridging. I get to the part for whitelisting the MAC address (done), and enabling bridging (done) but the MAP never joins the RAP, with this error in the CLI:

CRIT-MeshAwppAdj[1]: Blacklisting Adjacency due to GW UNREACHABLE

CRIT-MeshAwppAdj[1]: Remove as Parent

CRIT-MeshLink: Link Down Block Root port Mac: xx.xx.xx.xx
CRIT-MeshRadioBackhaul[1]: Remove as uplink

The RAP then starts searching for a MAP again and about 5 minutes later repeats this process. From the RAP, however, I can successfully ping the gateway (192.168.1.1) so it is not unreachable from the controller (Mobility Express) or the RAP.

Any suggestions?

[marce1000]

         - FYI : https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvu32113

 M.

[NRM9852]

Thanks, I am running 8.10.151.0 so thought it would have been corrected. I had both APs on the same switch and they still would not join.

[Rich R]

What code is currently running on the AP?  Remember it won't download the correct code until it is able to join a WLC so it may still be running the old/buggy code.  I would change the AP to LOCAL mode and let it join over LAN connection.  (presume you've made sure you have a working TFTP server where it can download the software from as required by ME).  Once it has joined and has the correct code and you've configured it then you might want to try using it as a mesh AP again?

[NRM9852]

Thanks for the suggestion. They are both running an identical and latest stable version 8.10.151.0, so no downloading should be required? I’ll try local mode.

[R M C]

Hi

Were you able to resolve this?  I am having exactly the same issue with a pair of 1542D ME APs, running 8.10.151.0, I am unable to get the RAP/MAP to form an adjacency.  I also had a similar issue where the MAP could reach its DG and would shut the radios down, I got round this by configuring the MAP's DG to its local switch SVI, though this isn't ideally.  Still no adjacency formed.

I had previously wanted to run them as bridges on our WLC, so had converted them to capwap, though exactly the same problem occured.  I've engaged TAC but they have also drawn a blank.

I think there is a fundamental issue afoot here.  I am tempted to try 8.10.162.0, though it doesn't appear to have any resolved caveats...

[Arshad Safrulla]

Can you post the switchport config for both the AP's? 

[Rich R]

May or may not be related to your problem but worth considering ...

There was some wacky behaviour for default gateway reachability introduced in early 8.10 which we discovered and got bugs raised for which are fixed in the latest code.  Details below.  The point is - check what code is actually running on the AP at the moment.  If it's got old code you might need to apply the workaround to allow it to join and update to fixed code.

TAC explanation:

The 2 documentation bugs CSCvt75255 and CSCvt72197 are simply to document the change in behavior in AireOS8.10mr1/IOS-XE 17.1.1) and AireOS 8.10mr2/IOS-XE 17.2.1).
As you know, the behavior is different from previous releases, so we need to document it for customers to be aware of it.

On the other hand, the software bugs CSCvt89970 and CSCvt89989 are to fix/correct/change that behavior that we found is not correct.
• Bug CSCvt89970 changes this behavior and the GW check (ICMP + arp) is only done IF the AP loses connectivity to the WLC. If the capwap connection is UP, there is no ICMP being sent to the GW.
• Bug CSCvt89989 the changes were the following:
Old behavior: After mesh AP selects an uplink, GW reachable timer starts. AP will have 45s to join the controller. If that joining takes long than 45s, and the ICMP ping to GW is failing, the uplink will be blacklisted and uplink selection process restarts.
New behavior: After mesh AP selects an uplink, the GW reachability is checked thru ICMP ping and ARP entry. If either succeeds, the GW reachable timer is stopped. In case of GW reachability check failure, if the AP has started CAPWAP join processing, the GW reachable timer is also stopped.

[NRM9852]

I've actually made some progress, it seemed like a VLAN/trunk setting and now the radios are joining.

On the controller webpage, under Access Points, open up each AP and go to Radio Settings. Then go to Mesh. Edit the interface at the bottom of the window which opens the "VLAN Mapping" window. Make sure the mode is set to "trunk" (not "access") and that there is a native VLAN ID present. Also fill in all of the allowed VLANs you are using.

[R M C]

Hi

Thanks for that, I've made some progress too!  I get the adjacency forming over the wireless and the MAP joining the ME controller, then it decides to reboot.....  If the end user can work in 5 second spells every 5 minutes, I could be onto a winner!!

[NRM9852]

Sounds like an image problem. Check the checksum and reload?

[R M C]

Checksum matches.  It seems to be whenever the RAP sees the adjacency it reboots. I did have an issue where they were wrestling over who would be the WLC.  I thought I'd resolved, I'm going to wipe the MAP and start again.

[R M C]

It seems like my limited success was very short lived, on the rare occasion I can get the adjacency to form it doesn't stay up long before failing.  I see the MAP broadcasting for a neighbour and the RAP responding, but only occasionally will the adjacency form.  I've got a TAC case open though as of yet they haven't been able to make progress.  It just doesn't seem to work.

[NRM9852]

Not sure what your environment looks like but if you are testing with the radios close together, you might try extending the distance between them and/or adding some attenuation. Have had some similar issues when they are too close together as these radios are meant to be pretty far apart.

[BACT2009]

I too am having the same issue with three 1562's as I'm trying to setup a Point to MultiPoint setup. The first MAP setup and joined the RAP with no issues but then I started on the second MAP and I'm having the same issue you're describing. I watch the log through console and also have a steady ping on the management address I assigned....it'll ping when the discovery starts and it changes the username/password with out issue and it'll show up in the Mobility Express web interface but then it'll stop replying, drop from the web interface and I see the same exact lines you've posted during this time.

I read through this thread and even tried moving the second MAP across the office to about 25-30 away and still same thing...weird because the first MAP is literally 6ft away with no problems. Thinking this can't be it but maybe...wondering if I move both MAP's 20+ feet away if it'll help.

I'll give it a try and it helps, I'll report back. I also have a TAC case open with Cisco about the VLAN-Trunking disable after a reboot even after saving the config before a reboot...I'll email back to the tech who I'm working with about this issue.