We’re in the early stages of a WiFi deployment using Cisco Meraki MR34 access points. One of the things we’re noticing about the product is that while most tasks are pretty self-explanatory, if you need to do something that isn’t, the documentation leaves a bit to be desired. We ran into issues setting these up on trunk ports, and along the way found out some additional operational details that hopefully will be helpful to others.

Before I go any further I should point out that this post, like most of my blog, is based on my direct observations correlated with 3^rd party information when possible. Working with the Meraki access points (AP) we noticed some inconsistent behavior which makes drawing conclusions about their operation much more difficult. The info I’m posting here is therefore my best attempt to explain the behavior we observed. As always if someone reading this has more concrete info or links to anything contradictory, please let me know and I will research and update accordingly.

NOTE: For clarity, when I refer to connectivity to the “Meraki cloud” I am speaking about the AP’s ability to access the Meraki cloud infrastructure in general. Conversely, when I refer to (your) “Meraki WiFi network” or “dashboard” this implies the AP has been imported into and configured specifically for your network. An AP that has unfettered access to the Internet should always be able to access the Meraki cloud, but you need to explicitly import the AP to your dashboard for it to receive a configuration. Also, by “production SSID” I mean those SSIDs you’ve explicitly created in the dashboard rather than the ones the APs broadcast before being configured. Moving on…

Our wireless design requires each access point to be connected to a trunk port (uplink) so we can separate traffic into different VLANs as desired. I don’t think this should be an unusual configuration but following the setup documentation Meraki supplies will make things much more difficult than they need to be. The problem is this: the documentation essentially assumes the AP will receive a DHCP address and will then connect to the Meraki cloud, at which point you can import the AP to your dashboard and use it (the dashboard) to change the AP’s IP address if needed. However the dashboard will not let you set an invalid IP address (i.e. one which would cause it to lose connectivity to the Meraki cloud), which in theory makes sense but consider the following sequence:

• You connect the AP to an access switch port on a network segment with DHCP then
• Import the AP into your Meraki WiFi network (dashboard) then
• You want to change the IP configuration and move the AP over to a trunk port

The dashboard will not allow you to change the IP because the new desired IP (for the trunk port) is invalid on the access port to which you’re connected. In addition, this creates some sort of a conflict where the dashboard won’t allow you to change the IP but will nevertheless complain about an invalid IP configuration even though it hasn’t changed.

With this being the case, the only way to configure an AP with an IP address on a network segment that does not have DHCP is to connect to the AP’s local webserver and make the changes there. Fine. But to do this, you need to be able to associate to the AP; in our case this wasn’t possible once the AP had received it’s configuration from our dashboard and was broadcasting our production SSIDs, because associating to them requires back-end connectivity to RADIUS and/or other network functions that are not accessible unless the AP is already on a trunk port. Bit of a catch-22.

At this point we attempted to hard reset an AP but had no luck doing so; with trial and error we discovered a few interesting points which I’ll first list then explain in more detail as appropriate.

• As noted earlier, once an AP has an IP configuration, you cannot change it via the dashboard to any configuration that would cause the AP to lose connectivity to the dashboard.
• Before an AP has been imported to your dashboard, it will broadcast one or more “Meraki” SSIDs to which you can associate. Once you’ve done so, you can access the AP’s built-in web server at http://10.128.128.128 to configure the uplink properties. This is, as best I can tell, the only way to configure the AP to use an IP address on a network segment without DHCP.
• Once the AP has been imported to your dashboard, it will cease broadcasting the “Meraki” SSIDs so any further access to the local web server will require being able to associate to the AP over your production SSIDs. This may not be possible if the AP has connectivity only to the Meraki cloud and dashboard but not your own infrastructure, as could be the case when an AP is setup on an access segment rather than a trunk port.
• The APs seem to remember if they were part of a Meraki WiFi network the last time they could reach the Meraki cloud. In other words, once an AP is imported into your dashboard and configured, it will not broadcast the “Meraki” SSIDs even if it loses connectivity to the cloud. This makes sense because you want the AP to continue operating locally even without cloud connectivity.
• If the AP was part of a WiFi network the last time it connected to the cloud, you do not seem to be able to hard reset the unit. The only way we could get a hard reset to work was to delete the AP from our dashboard, then allow the AP to connect to the Meraki cloud (so it could see it was no longer part of a WiFi network), then perform the hard reset. Again this makes sense since it prevents someone with only physical access to the device (but no dashboard credentials) from resetting the unit.

So what does all this mean?

If you want to configure an AP out of the box, just:

• Connect the AP to your desired network segment WITHOUT DHCP, or just bring the AP up without network connectivity. (The latter will require a POE injector or power adapter)
• Associate to any of the “Meraki” SSIDs that are broadcast by the AP
• Visit http://10.128.128.128 to access the built-in web configuration
• Click uplink, then enter the desired IP address info
• While not strictly necessary, I would suggest rebooting the unit

Make certain you do not power the unit off until you have a solid green or blue light; if the light is flashing blue, an upgrade is in progress and a power-cycle will likely erase the configuration.

If you need to hard-reset the AP:

• From your Meraki dashboard, delete the AP
• Allow the AP to connect to the Meraki cloud
• Hold the reset button down for 10 seconds (this may vary model to model)

You should now see the “Meraki” SSIDs broadcast again and can follow the procedure above to configure the AP as needed.

One other thing we found out…as of this writing, there is a bug in the released Meraki MR34 firmware which impacts the ability of the AP to broadcast a SSID using MAC authentication. There is a beta patch available by calling Meraki support which seems to resolve the problem.

Thanks for reading!