Controllerless Networks

Hi,

I have created a Mesh using IAP 275 access points. I followed the procedure in the latest release notes.

1. Connect the IAPs to a wired switch.

2. Ensure that the VC key is synchronized and the country code is configured.

3. Ensure that a valid SSID is configured on the IAP.

4. If the IAP has a factory default SSID (Instant SSID), delete the SSID.

5. If an extended SSID (ESSID) is enabled on the VC, disable it and reboot the IAP cluster.

6. Disconnect the IAPs that you want to deploy as mesh points from the switch, and place the IAPs at a remote

location. The IAPs come up without any wired uplink connection and function as mesh points. The IAPs with

valid uplink connections function as mesh portals.

When I i repowered up my Mesh point it would not create a Mesh with the Mesh portal. After carrying out some debugs I found that reason for this was my current IAP cluster on site had the extended SSID disabled and the autojoin was on. If i turned off auto join off on our current site cluster the Mesh point would join the Mesh portal on the new cluster.

I read that if there is more than one Instant cluster then the Mesh point will not join the Mesh Portal as part of the cluster. Is this correct? If so is there a way round this?

Second question

If i disable 80Mhz wide band option the Mesh link drops to 20MHz. Disabling VHT removes 802.11ac function. But should the Mesh link not use 40Mhz as 802.11n is still supported?

There is currently no way to bridge groups of IAPs in the same cluster with an IAP mesh link. Each building's IAPs owuld need to be on separate networks and form their own cluster. So you would ostensibly have to manage the two IAP clusters separately. 

Hi Jerrod,

I am not trying to bridge IAP clusters. I was trying to create a new seperate cluster using two new instant APs. I created them as a normal cluster and this worked fine. When i changed them to a mesh cluster the mesh point would not join the cluster. The reason for this was that on my exising cluster extended SSID was disabled and autojoin was on. This seemed to prevent the mesh point joining the new cluster that it was provisioned on.

So does this mean that if there any existing IAP clusters in the area that I am deploying next to my new mesh cluster. Will this possibly prevent the mesh points from joining if the extended SSID is disabled and autojoin is on?

If there is an Instant cluster on the same L2 of the mesh point, the wired discovery of the adjacent IAP cluster will supercede the mesh uplink and it will join the other cluster. The only way to prevent this would be to put the mesh point on a different wired network (different L2 domain or different L3 network) from the IAP cluster on the same network, so that it finds nothing on the wire when it comes up.

Are there any changes in this behavior with recent software versions?

Can a building-to-building mesh/bridge be setup in a 'standalone' mode or 'mesh-only' cluster, so that they aren't part of the rest of the cluster? If so, can APs on either side of this bridge be part of a single 'normal' cluster?

I'm trying to figure out how to support normal AP operation, bridge/mesh, and bridged building without having to create a bunch of AP VLANs and manage multiple clusters. 

"Instant does not support the topology in which the Instant APs are connected to the downlink Ethernet port of a mesh point." 

--Does this mean IAPs cannot be connected back-to-back, with one doing mesh/bridge, and the other being a normal client AP? Or for a linear mesh? 

@jhoward, you have a document called 'Outdoor Config Stubs - AOS', do you have something like that for IAP?

Thanks. 

Using standalone mesh to bridge an IAP VC is the best course of action. It requires AOS 8.4 and later. You will essentially configure each IAP as a standalone AP, configure the necessary mesh elements, and then deploy the PtP to L2 bridge the same VLANs on each side to carry the IAPs as needed. Note that the attached is titled for the AP-387, but the setup process is the same for all IAPs doing standalone mesh. 

NOTE - test this on a bench to verify it's working as expected before deploying.

Attachment(s)

Standalone-Mesh PtP.pdf   75 KB 1 version

Stand-Alone_Mesh_SampleOutput.txt   3 KB 1 version

Thanks, exactly what I was looking for when I saw the 8.4.0.0 'Standalone Mesh'. 

Your PDF document is cut off a bit on the ends of the lines, and more importantly the section for the point wired port profile. Do you have a better formatted version, or just the raw text?

Is any of this possible/recommended to be configured in Airwave? We are starting migrations to Aruba, and might end up with 100+ remote sites with IAP clusters, some will need mesh/bridges. Trying to figure out how best to handle Airwave config groups to group VCs as much as possible to reduce admin overhead, but also don't want to lose flexibility or 'put too many eggs in one basket'. And point-to-point links might be best to configure locally and leave as monitor-only in Airwave? 

Thanks. 

I personally have not done a mesh config in instant, and never at all for standalone mesh. Note we also have no mesh visualization in AirWave so it won't necessarily be reflected in the monitoring for things like mesh link status, throughput, etc. Just roleinfo (mesh portal, point, etc)

Thanks Jerrod. Are you able to fix the missing text in that PtP PDF document? 

Here's the whole thing

#####

AP-387 in InstantOS in Standalone Mesh Mode

In most all cases, the pair of AP-387s should be deployed in Standalone mode with mesh (new in 8.4). There are a number of reasons, but the main reason is this allows the APs to run independent of what rides across the links. Unlike a pair of APs running mesh with Instant in a VC where they must be L2 separated from other Instant APs, two AP-387s in Standalone Mesh mode will ignore L2 VC advertisements and run independently, allowing you to bridge an IAP VC over an AP-387 PtP.

Currently Standalone Mesh mode is mostly configured via the CLI only (there are currently no Standalone Mesh GUI elements in 8.4). The minimum commands to put the AP-387 in Standalone Mesh mode are as follows:

1. Interrupt AP boot and enter the following (note this can be done in the GUI but will require multiple reboots). This will allow the AP-387 to run in standalone mode and not look for a controller for firmware (basically forcing Standalone mode)

setenv standalone_mode 1
setenv uap_controller_less 1

2. Once the AP boots up, the following are entered in to the configuration of the AP-387

Set country and disable extended SSID

conf t
virtual-controller-country US
name <AP-Name>
no extended-ssid
exit
commit apply

Configure the clusterless mesh settings (these are written to AP ENV, not in 'config' mode)

no mesh-disable
mesh-cluster-name <cluster name, unique per PtP>
mesh-cluster-key <cluster-key>
commit apply

On the Mesh Point only:

wired-port-profile default_wired_port_profile
 trusted
 no shutdown
 type employee
exit
enet0-bridging <== Note this is written into AP ENV with "enet0_bridging=1"
commit apply

NOTE: Once you apply 'enet0-bridging' on the mesh point, it will no longer come up on the wire. Additionally, if the point and portal are wired to the same VLAN/switch while the mesh is established and the mesh link is up with bridging on the mesh point, it will loop the network. So ensure after the point reboots, that it is removed from the same VLAN that the portal is connected to.

When this is completed, everything will need to be rebooted. Once done, the following commands will verify the standalone mesh role, and if the link is up

show ap mesh cluster status
show ap mesh link
show ap mesh neighbour

Please use the 'Aruba Instant 8.4.0.0 CLI Guide' for more details. The rest of the ethernet config for bridging follows the same rules/commands as the other Instant mesh bridging commands (access, trunk, etc).

Hi Jerrod

I followed the instructions and at the moment both IAP-387 are in proper mode 

One as Mesh Portal and second as Mesh point.

Both have the same cluster name and keys.

However they don't see each other in RF link, even located in the same room one in front of other.

show ap mesh link and show ap mesh neighbour produce NULL output.

How can I debug radio communication?

Hi aralelib,

I was in the same situation - I decided to follow a hunch and upgrade the firmware.  I started with the mesh point AP  - though the upgrade process was a hassle since I wasn't able to communicate with it via the eth0 port and IP I thought I had set.  I also didn't have DHCP server running at the outbuilding where I was deploying the mesh point AP and was lazy, not wanting to trot it back to the main site.  So I ended up factory resetting, allowing it to fully boot (takes a while and you want to let it finish, and then connecting to it using the default IP that results after it times out DHCP (in my case 169.254.207.166).  I was connected to another ethernet port on the same switch that I placed in the same isolated VLAN I intended to use for the standalone mesh.  I connected to the web GUI, logged in with admin/admin (though this took a while - the credentials will fail at first until fully booted). My only purpose in connecting to the web GUI was to ascent to the the country question (US in my case) and upgrade the firmware from the stock 8.4.0.0 to 8.5.0.2 (Hercules by the way). I'm sure I could have done it via TFTP, etc. but this was easiest for me. Note: there was no 'SetMeUp-<MAC>' SSID to connect to.  I don't believe the AP-387's do that, so wired connection was my only option (that I could see). 

Anyway, the reason for this long narrative is that after the firmware update, I went through the procedure again as described by Jerrod....and voila, the mesh came right up.  Tagged my VLAN's at each end (untagged is my isolated mesh VLAN), and all good.  Interestinging, I did not upgrade the mesh portal AP, it is still running 8.4.0.0, no changes.  I probably will upgrade it, but my 'fix' only required upgrading the firmware on mesh point AP.

All I can surmise is that until location regulatory requirement is met, confirming country and/or loading current DRT file with the firmware update, the radios aren't activated?

A couple of small tweaks/additions to Jerrod's excellent directions:

I issued 'saveenv' after the initial setenv commands

On the Mesh Point only instructions, need to go into config mode: 

conf t

wired-port-profile default_wired_port_profile

 trusted

 no shutdown

 type employee

exit

exit

....the second 'exit' gets you back to AP ENV  *then* you can issue:

enet0-bridging

commit apply

Thanks a lot for reply.

It really helps.

Very strange, that Aruba deliver new product with outdated version 8.4.0.0 which has bugs and doesn't work out-of-the box.

Regards

It's not possible to keep all APs in inventory, distro, VADs and VARs on the latest code. When you default an AP (with the EXCEPTION of the 387) you have to make sure you create a VAP (2.4Ghz only, hidden is what I do), otherwise when the AP reboots, it defaults since it doesn't see a VAP, even if you created a mesh cluster or enabled mesh in the VC.

Country code is part of the initial setup as well, so without a VAP and it reboots, the radios are off until defined. It's a huge pain, but it's apparently something we cannot avoid.

---

@aralelib wrote:

Thanks a lot for reply.

It really helps.

Very strange, that Aruba deliver new product with outdated version 8.4.0.0 which has bugs and doesn't work out-of-the box.

Regards

---

I don't think the manufacturer can upgrade code in a sealed box.

Is the unused VAP config still necessary in 8.5 and 8.6 code? I'm setting up a new standalone mesh, and my config didn't seem to be defaulting without one on an AP-377. I went ahead and added one anyway and now the mesh is up, just wondering if it's needed or can be removed. 

I would personally create a VAP, I usually do a 2.4Ghz only, hidden, random SSID VAP. In cases where code upgrades later may change the default behavior, so having that VAP ensures the AP won't default.

Hello Guys

I have a question.

How many AP's support in Instant Mode?

In an Instant mesh network, the maximum

• Hop count is 2,
• Number of mesh points per mesh portal is 8.