In this post I will explain my best practices in using Aruba APs as an point to point link. This is based on using Aruba Instant in version 8.4 or higher. This will not cover meshing in a controller based environment.
I wrote this post, because in the last month I had a few customer facing problems with their point to point Access Point links. None of these problems were with the APs or Instant itself, but with the network environment or circumstances they were working in. My best practices below fix these problems.
These recommendations are applicable to all APs running Instant OS 8.4 or higher including the AP-387 with it's 60GHz 802.11ad radio.
Intro
First let's take a look at how Aruba Instant and Meshing is working. If you already know all of these you can skip to the "best practices" section down below.
In an Instant Cluster all Access Points in a Layer 2 segment go trough an election, select a master AP (the virtual controller) and sync their firmware and configuration.
Keep in mind: it is not supported to have more than one cluster in one Layer 2 segment! If you do that, things will terribly go wrong. Don't do that!
Meshing is automatically enabled if a country code is set and if the "extended SSID" feature is turned off (on by default).
If this is the case all APs determine their mesh role:
- Portal: AP with wired uplink
- Point: AP with wireless mesh uplink
With meshing and enet0-bridging enabled you can build a point-to-point link and plug a switch into the wired port of the mesh point AP. If configured in the wired port profile VLANs can be transported via meshing.
Starting with Instant 8.4 it is possible to manually define the mesh cluster properties without the need to form an Instant Cluster. This is based on the per-ap settings "mesh-cluster-key" and "mesh-cluster-name".
Keep in mind that the Instant APs also have a "Wi-Fi Uplink" feature which is mutual exclusive with meshing and building a VLAN capable P2P link isn't a scenario for Wi-Fi Uplink.
Problems faced
1. AP RMA: In this case one AP got broken and a replacement was shipped to the customer. The facility manager took the new AP and installed it on the roof like the old one. A few minutes later the customer called "This isn't working!". Well, what happened? There was a new mesh portal AP with no config and an existing mesh point with nowhere to connect to. To make it worse, both APs were getting their IP with DHCP and the lease for mesh point just timed out. Hello darkness APIPA my old friend!
How I finally got CLI access to apply my best practices is a story for another time. Maybe this story includes me sitting on a roof ;-)
2. Mixed installation: The P2P link was running fine for a long time and now the customer wanted to switch over the existing wifi infrastructure to Aruba as well. (Always a good choice if you ask me). So APs got installed and put to the "IT infrastructure mgmt" VLAN and now the customer had the P2P APs and his normal indoor APs in the same Instant Cluster. To use another VLAN wasn't an option there (don't ask me why). Having an Cluster with the P2P link and all other APs isn't a problem by itself, but from an operational standpoint this isn't desirable. You share all common settings, you update your internal wifi and the P2P at the same time (have these the same maintenance window?) etc.
These are the two most common problems I saw and these two can be combined as well, Jackpot!
Best practices
- Static IPs. Give your two P2P APs a static IP! As always, this isn't necessary for normal operation, bit will come in handy during troubleshooting. Your switches have a static IP for management purpose as well, don't they?
- Standalone mode + manual mesh-cluster. For two APs, do you really need a cluster to sync some settings? I don't think so. Using standalone mode and a static mesh-cluster config fixed my described problems 1 and 2.
Config
Here is the CLI config snippet I use for the Mesh Portal and Mesh Point AP.
Mesh Portal:
hostname Mesh-Portal
ip-address <IP> <NETMASK> <GATEWAY> <DNS> <DOMAIN NAME>
conf t
virtual-controller-country <CC>
user admin GENERATE_A_PASSWORD
no wlan ssid-profile SetMeUp
no extended-ssid
exit
commit apply
wr mem
ap-env standalone_mode 1
y
AFTER REBOOT
no mesh-disable
mesh-cluster-name <YOUR MESH CLUSTER NAME>
mesh-cluster-key GENERATE_A_PASSWORD
Mesh Point:
hostname Mesh-Portal
ip-address <IP> <NETMASK> <GATEWAY> <DNS> <DOMAIN NAME>
conf t
virtual-controller-country <CC>
user admin GENERATE_A_PASSWORD
no wlan ssid-profile SetMeUp
no extended-ssid
wired-port-profile default_wired_port_profile
switchport-mode trunk
allowed-vlan all
native-vlan 1
trusted
no shutdown
exit
exit
commit apply
wr mem
ap-env standalone_mode 1
y
AFTER REBOOT
no mesh-disable
mesh-cluster-name <YOUR MESH CLUSTER NAME>
mesh-cluster-key GENERATE_A_PASSWORD
ip-address <IP> <NETMASK> <GATEWAY> <DNS> <DOMAIN NAME>
conf t
virtual-controller-country <CC>
user admin GENERATE_A_PASSWORD
no wlan ssid-profile SetMeUp
no extended-ssid
wired-port-profile default_wired_port_profile
switchport-mode trunk
allowed-vlan all
native-vlan 1
trusted
no shutdown
exit
exit
commit apply
wr mem
ap-env standalone_mode 1
y
AFTER REBOOT
no mesh-disable
mesh-cluster-name <YOUR MESH CLUSTER NAME>
mesh-cluster-key GENERATE_A_PASSWORD
enet0-bridging
wr mem