Wireless Access

I have a lab with a 7205 controller, AP277 configured as a mesh portal, and AP275 configured as mesh point. All are connected to a S2500 switch to provide a proof of concept to customer. However I cannot get the link to remain up. After a couple of hours the link drops. I have seen the following in the log of the point-

Reboot Information
------------------
AP rebooted Fri Sep 25 11:44:26 GMT 2015; Mesh link could not be sustained for 15 minutes.
------------------------------------------------------------------------------------------

 

 

Around 15 mins before this the portal shows -

[2079]2015-09-25 11:32:19.956: Preserving Recovery PSK.Generating PSK from Passphrase
[2079]2015-09-25 11:32:19.956: SSID - hexdump_ascii(len=7):
     50 65 65 6c 50 4f 43                              PeelPOC
[2079]2015-09-25 11:32:19.956: PSK (ASCII passphrase) - hexdump_ascii(len=13):
     70 33 33 6c 70 30 72 74 35 6b 33 79 21            p33lp0rt5k3y!
[2079]2015-09-25 11:32:20.168: PSK (from passphrase) - hexdump(len=32): 4c f5 ef e8 f9 d2 8e 06 82 aa c7 c6 98 2f 7c c6 10 2b e8 27 59 8d b8 b3 06 85 73 ba e3 28 85 b1
[2079]2015-09-25 11:33:51.778: RX ctrl_iface - hexdump_ascii(len=25):
     44 45 4c 5f 53 54 41 20 39 34 3a 62 34 3a 30 66   DEL_STA 94:b4:0f
     3a 32 65 3a 66 61 3a 33 30                        :2e:fa:30
[2079]2015-09-25 11:33:51.778: CTRL_IFACE DEL_STA 94:b4:0f:2e:fa:30
[2079]2015-09-25 11:33:51.779: WPA: 94:b4:0f:2e:fa:30 WPA_PTK entering state DISCONNECTED
[2079]2015-09-25 11:33:51.779: WPA: 94:b4:0f:2e:fa:30 WPA_PTK entering state INITIALIZE
[2079]2015-09-25 11:46:44.980: RX ctrl_iface - hexdump_ascii(len=70):
     4e 45 57 5f 53 54 41 20 39 34 3a 62 34 3a 30 66   NEW_STA 94:b4:0f
     3a 32 65 3a 66 61 3a 33 30 20 33 30 31 34 30 31   :2e:fa:30 301401
     30 30 30 30 30 46 41 43 30 34 30 31 30 30 30 30   00000FAC04010000
     30 46 41 43 30 34 30 31 30 30 30 30 30 46 41 43   0FAC040100000FAC
     30 32 30 30 30 30  

 

Tech support files attached if anyone can figure out why the link went down or the Point decide to rebootstrap.

You should give us the "show ap mesh tech-support ap-name <name of ap>" before the reboot.  It yields much more info. 

 

- How far apart are the access points?

- What version of ArubaOS are you using?  (I assume 6.4.3.3)

The access points are on a bench in the lab - so not far apart. Correct, they are running 6.4.3.3.

Attached are the mesh tech-support files in case it rebootstraps again.

I would try using a non dfs channel. Check to see in "show log wireless" if there was a radar event. They should be at least 3 meters apart or even further if possible.

There does not seem to be any RADAR events around this time -

Sep 25 11:32:19 :404085:  <WARN> |AP Portal:ca:cd:e0@10.2.52.20 sapd|  AM 94:b4:0f:2c:de:10: ARM HT Channel Interference Trigger new 116E/56 old 100E/128 new_rra 116E/3 TCI 10
Sep 25 11:32:19 :400180:  <WARN> |stm|  handle_ap_message_response: BSS 94:b4:0f:2c:de:12 nothing outstanding

 

Would a channel change cause the AP to rebootstrap?

This message still owriies me though -

Reboot Information
------------------
AP rebooted Fri Sep 25 11:44:26 GMT 2015; Mesh link could not be sustained for 15 minutes.
------------------------------------------------------------------------------------------

does this mean that the link repeatedly dropped before 15mins was reached or does it mean that the link went down and could not be re-established for 15 mins - the latter seems to be the case.

The distance on the bench should not matter, unless this is peculiar to Aruba - I've done a million tests with other devices (Cisco mostly) without issue.

Crazily enough, you need to get more separation between the portal and point if this is on a bench. The radios are power enough and the receivers sensitive enough, that you can 'overdrive' the radios which can cause stability and performance issues. Your RSSI is WELL above 50, which is too high, so you need less power (try setting power to zero) and/or more distance or some kind of attenuation between them. Give that a shot, but what you are seeing is very common so we need to rule that out (the APs being to close and the radios being over-driven). Good luck!

I have reprovisioned the devices and its taken 13 mins for the point to request an IP address and come back on to the controller. I understand the radios come up first, but should I set static IP addresses on the devices?

You would only want to do static IPs if the DHCP server is slow or not present. 13min is obviously far too long. Let us know what happens when you set power to 0 (they will still have some intrinsic EIRP due to the antennas and the fact that the radio can't REALLY run at 0dBm per chain heh). 

 

Just drop the power to zero and get as much separation as you can. Put them in separate rooms if you can, but same room setups are notoriously bad (which of course make benching configs a PITA, but it's a good problem to have the when radios work so well). 

Also, and this is likely part of why you are seeing issues, make sure they are both provisioned for outdoor or auto, and then make sure the portal stays off the DFS. 277 DFS testing IS NOT complete yet so I don'e belive it will join a portal if the 275 is within DFS.

 

Some quick background color because it's a pain...

 

FCC changed the rules on how and what outdoor devices can certify on. Previously, 'outdoor' access points were never allowed to run in the indoor UNI1 space. The 274/275 certified under the old rules, which means it is fully compliant with the Outdoor and DFS channels but CANNOT run un the UNI1 indoor 5GHz channels. They then changed the rules and allowed 'outdoor' access points to run on the indoor UNI1 channels under certain conditions and requirements. Since the 277 is newer, we submitted it for indoor, DFS, and outdoor. However it has not FULLY completed DFS certification, but IS allowed to run on UNI1 and Outdoor non-DFS channels without issue. The 274/275 is ALSO being re-certified under the new rules so that WHEN IT'S ALL SAID AND DONE, the 27x and 228 family can run the entire 5GHz spectrum, but for now we're in this weird limbo between the older 274/275 and the newer 277/228.

 

TL;DR:

274, 275 - DOES NOT support indoor 5Ghz channels, but IS certified for Outdoor UNI3 and DFS. Has been re-submitted for testing to add support for indoor.

277, 228 - DOES supprot indoor 5GHz channels, as well as Outdoor UNI3, but is NOT YET certified for DFS (is pending and should be very soon upon which we will release a DRT). Is current near completion on testing to add DFS (DFS certification just takes longer to accomplish). 

 

Sorry for the confusion, stick your 275 static on 149E for now, drop the power and add some separation to get the RSSI of the mesh link in the 40s, It should then be very stable.

Appreciate the info, however we are not regulated by the FCC - how does this affect operations for ETSI? Channel 149 is not available here.

The device has now failed to re-connect to the controller even though it has a hard wired link available.

What country then? You can run 'show ap allowed-channels country-code us ap-type XXX' to see where there are overlaps or gaps. See example below

 

#####

(Aruba7005) #show ap allowed-channels country-code us ap-type 275

 

Allowed Channels for AP Type 275 Country Code "US" Country "United States"

--------------------------------------------------------------------------

PHY Type                 Allowed Channels

--------                 ----------------

802.11g (indoor)         1 2 3 4 5 6 7 8 9 10 11

802.11a (indoor)         52 56 60 64 100 104 108 112 116 132 136 140 144 149 153 157 161 165

802.11g (outdoor)        1 2 3 4 5 6 7 8 9 10 11

802.11a (outdoor)        52 56 60 64 100 104 108 112 116 132 136 140 144 149 153 157 161 165

802.11g 40MHz (indoor)   1-5 2-6 3-7 4-8 5-9 6-10 7-11

802.11a 40MHz (indoor)    52-56 60-64 100-104 108-112 132-136 140-144 149-153 157-161

802.11g 40MHz (outdoor)  1-5 2-6 3-7 4-8 5-9 6-10 7-11

802.11a 40MHz (outdoor)   52-56 60-64 100-104 108-112 132-136 140-144 149-153 157-161

802.11a 80MHz (indoor)    52-64 100-112 132-144 149-161

802.11a 80MHz (outdoor)   52-64 100-112 132-144 149-161

802.11a (DFS)            52 56 60 64 100 104 108 112 116 132 136 140 144

 

(Aruba7005) #show ap allowed-channels country-code us ap-type 277

 

Allowed Channels for AP Type 277 Country Code "US" Country "United States"

--------------------------------------------------------------------------

PHY Type                 Allowed Channels

--------                 ----------------

802.11g (indoor)         1 2 3 4 5 6 7 8 9 10 11

802.11a (indoor)         36 40 44 48 149 153 157 161 165

802.11g (outdoor)        1 2 3 4 5 6 7 8 9 10 11

802.11a (outdoor)        36 40 44 48 149 153 157 161 165

802.11g 40MHz (indoor)   1-5 2-6 3-7 4-8 5-9 6-10 7-11

802.11a 40MHz (indoor)   36-40 44-48 149-153 157-161

802.11g 40MHz (outdoor)  1-5 2-6 3-7 4-8 5-9 6-10 7-11

802.11a 40MHz (outdoor)  36-40 44-48 149-153 157-161

802.11a 80MHz (indoor)   36-48 149-161

802.11a 80MHz (outdoor)  36-48 149-161

802.11a (DFS)            None

 

(Aruba7005) #

#####

You can run the following to see for your country, and where there is overlap use those on the portal. 

 

#####

(Aruba7005) #show ap allowed-channels country-code us ap-type 275

 

Allowed Channels for AP Type 275 Country Code "US" Country "United States"

--------------------------------------------------------------------------

PHY Type                 Allowed Channels

--------                 ----------------

802.11g (indoor)         1 2 3 4 5 6 7 8 9 10 11

802.11a (indoor)         52 56 60 64 100 104 108 112 116 132 136 140 144 149 153 157 161 165

802.11g (outdoor)        1 2 3 4 5 6 7 8 9 10 11

802.11a (outdoor)        52 56 60 64 100 104 108 112 116 132 136 140 144 149 153 157 161 165

802.11g 40MHz (indoor)   1-5 2-6 3-7 4-8 5-9 6-10 7-11

802.11a 40MHz (indoor)    52-56 60-64 100-104 108-112 132-136 140-144 149-153 157-161

802.11g 40MHz (outdoor)  1-5 2-6 3-7 4-8 5-9 6-10 7-11

802.11a 40MHz (outdoor)   52-56 60-64 100-104 108-112 132-136 140-144 149-153 157-161

802.11a 80MHz (indoor)    52-64 100-112 132-144 149-161

802.11a 80MHz (outdoor)   52-64 100-112 132-144 149-161

802.11a (DFS)            52 56 60 64 100 104 108 112 116 132 136 140 144

 

(Aruba7005) #show ap allowed-channels country-code us ap-type 277

 

Allowed Channels for AP Type 277 Country Code "US" Country "United States"

--------------------------------------------------------------------------

PHY Type                 Allowed Channels

--------                 ----------------

802.11g (indoor)         1 2 3 4 5 6 7 8 9 10 11

802.11a (indoor)         36 40 44 48 149 153 157 161 165

802.11g (outdoor)        1 2 3 4 5 6 7 8 9 10 11

802.11a (outdoor)        36 40 44 48 149 153 157 161 165

802.11g 40MHz (indoor)   1-5 2-6 3-7 4-8 5-9 6-10 7-11

802.11a 40MHz (indoor)   36-40 44-48 149-153 157-161

802.11g 40MHz (outdoor)  1-5 2-6 3-7 4-8 5-9 6-10 7-11

802.11a 40MHz (outdoor)  36-40 44-48 149-153 157-161

802.11a 80MHz (indoor)   36-48 149-161

802.11a 80MHz (outdoor)  36-48 149-161

802.11a (DFS)            None

#####

You can run the following command for your country code to determine where there is overlap and assign the portal to that.

(Aruba7005) #show ap allowed-channels country-code us ap-type 275

Allowed Channels for AP Type 275 Country Code "US" Country "United States"
--------------------------------------------------------------------------
PHY Type                 Allowed Channels
--------                 ----------------
802.11g (indoor)         1 2 3 4 5 6 7 8 9 10 11
802.11a (indoor)         52 56 60 64 100 104 108 112 116 132 136 140 144 149 153 157 161 165
802.11g (outdoor)        1 2 3 4 5 6 7 8 9 10 11
802.11a (outdoor)        52 56 60 64 100 104 108 112 116 132 136 140 144 149 153 157 161 165
802.11g 40MHz (indoor)   1-5 2-6 3-7 4-8 5-9 6-10 7-11
802.11a 40MHz (indoor)    52-56 60-64 100-104 108-112 132-136 140-144 149-153 157-161
802.11g 40MHz (outdoor)  1-5 2-6 3-7 4-8 5-9 6-10 7-11
802.11a 40MHz (outdoor)   52-56 60-64 100-104 108-112 132-136 140-144 149-153 157-161
802.11a 80MHz (indoor)    52-64 100-112 132-144 149-161
802.11a 80MHz (outdoor)   52-64 100-112 132-144 149-161
802.11a (DFS)            52 56 60 64 100 104 108 112 116 132 136 140 144

(Aruba7005) #show ap allowed-channels country-code us ap-type 277

Allowed Channels for AP Type 277 Country Code "US" Country "United States"
--------------------------------------------------------------------------
PHY Type                 Allowed Channels
--------                 ----------------
802.11g (indoor)         1 2 3 4 5 6 7 8 9 10 11
802.11a (indoor)         36 40 44 48 149 153 157 161 165
802.11g (outdoor)        1 2 3 4 5 6 7 8 9 10 11
802.11a (outdoor)        36 40 44 48 149 153 157 161 165
802.11g 40MHz (indoor)   1-5 2-6 3-7 4-8 5-9 6-10 7-11
802.11a 40MHz (indoor)   36-40 44-48 149-153 157-161
802.11g 40MHz (outdoor)  1-5 2-6 3-7 4-8 5-9 6-10 7-11
802.11a 40MHz (outdoor)  36-40 44-48 149-153 157-161
802.11a 80MHz (indoor)   36-48 149-161
802.11a 80MHz (outdoor)  36-48 149-161
802.11a (DFS)            None

Testing, am having posting issues using Chrome, had to switch to Firefox.

I have set a single channel in the AP system profile but the Devices are not using this - Does it also need to be set in another profile?

If you are using 20 mhz channels, you are supposed to use a single channel in the regulatory domain profile. If you are using 40 mhz channels, you need to choose a single channel pair. If you are using 80 mhz channels, you need to choose a single 4-channel set.

I'm not sure what you mean by "If you are using". I have selected one channel as previous posts have suggested - is this correct or not? if not what do I need to do to apply this suggestion?

The administrator has the option of deciding if they are using 20 mhz, 40 mhz or 80 mhz channels.  The ARM profile decides your channel width.  After that, the regulatory domain profile then decides, based on the channel width, what channels are available for use.

 

 Below is the default ARM profile.

- If "allowed bands for 40 mhz channels" is set to a-only and "80Mhz support" is selected, you are using 80 Mhz channels on the 5ghz band.

- If "80Mhz channels" is unchecked and "allowed bands for 40Mhz channels" is set to "a-only" you are using 40Mhz channels on the 802.11a  or 5ghz band.

- If "80Mhz channels" is unchecked and "allowed bands for 40Mhz channels" is set to "none" you are using 20Mhz channels on the 802.11a or 5 ghz band.

 

Depending on the choices above determines what section of the regulatory domain profile is selected.  If I chose a 20Mhz channel width above, with the regulatory domain profile below, my access points will be on channel 36.  If I chose a 40Mhz channel width above, my access points will be on channel 44+ or 48- based on the regulatory domain profile below.  If I chose an 80Mhz channel width above, my access points will be on channel 149E based on the regulatory domain profile below.

Thank you for the explanation, I've now set them on a single 20MHz channel separated them into separate rooms and turned the power down. I'll evaluate and see what happens.

OK, so the devices have been up for nearly 24hours - does this mean that a mesh network will only be stable if set to a single backhaul channel? This seems a bit limited.

No.  It probably means you had the access points too close together.

 

But they haven't moved since setting them to a single channel and now they seem stable?

You should deploy them where they need to be and report back.  Having them too close is not a good variable no matter what channel configuration you use.

Unfortunately the reverse is the reality, they can't be deployed until we have sorted this issue out first. We have a reputation to consider. Currently the customer has an old Cisco mesh which is rock solid and the Aruba solution is not viable with confidence in its stability so low. Having tried this with a separation of at least 8m with the devices in separate rooms without success points to another issue that we need to identify.

We are just guessing based on what you tell us.  Jhoward also mentioned why it is not good to have them too close, in detail.  Please engage someone who is experienced in deploying this solution so they can look at your physical setup to ensure that something is not blocking your deployment.

 

Is having two mesh access points in different rooms when bonding channels a good test for mesh stability? No.  Not many mesh solutions at distance even use bonded channels.  Please engage someone sort this out for you, because there are so many ways to go wrong with this.

8m in clear line of sight is still really not far enough away. Without knowing your environment, interference and existing wireless in the area, etc, it's impossible to know what exactly is causing your issue. Wider channels means it's more susceptible to interference primarily, and in smaller quarters can cause higher degrees of self interference.

 

In no case ever is an indoor same or next to same room deployment a valid 'test' of any vendor's outdoor performance characteristics (be it Aruba, Ruckus, Cisco, etc). Older legacy mesh devices don't have the same issues because the radios aren't as sensititive and channels are not as wide. Other vendors may not be as bad because their radios aren't as sensititve to being overdriven or in general don't have the same Rx ratings. But in nearly every case you want sensitive radios for outdoors and it's a different environment than indoors.

 

The bottom line is you need to get them outdoors to truly assess their capabilities and derive performance characteristics. We know from direct experience as we have hundreds (or more) of mesh deployments using 275s and other 27x families at ranges up to 3-5km that are rock stable and working without any issues. If you cannot assess the link stability in your existing environment, you will need to quantify all RF in your test environment, make sure it's 100% clean, keep the RSSI/SNR of the mesh link below 40, and start small and work your way up (20Mhz, then 40, then try 80).

 

From there, if you still have issues, reach out to me directly (PM here or email me at jhoward@) and we can look at your controller logs, and see if there's a local account team that can come help. Good luck!

Hi all,
i'm in a scenario not so different, and i think that all your suggestions will help me. Thank you all for that.
But.. I've just one more question.
There are some RADAR EVENTS even if there is no radar around here.. anyway: i would like to try some non-DFS channels: 36 40 44 48
Those channels are marked as indoor (but APs are outside, of course) : does it means that transmission level will be at 20db and not at 30db (i'm in Italy).

 

Thank You Gain,

 

N

 

 

Allowed Channels for AP Type 105 Country Code "IT" Country "Italy"
------------------------------------------------------------------
802.11a (indoor)      36 40 44 48 52 56 60 64 100 104 108 112 116 120 124 128 132 136 140
802.11a (outdoor)     100 104 108 112 116 120 124 128 132 136 140
802.11a (DFS)      52 56 60 64 100 104 108 112 116 120 124 128 132 136 140

 

 

 

 

What channel are you running it at now? I think the take away is to run indoor channels outdiirs may violate your ETSI regulations. However, depending on the channel you are on, you may be able to move it to a different DFS channel that is outside of the weather radar range (if that is indeed where you are at). 

Hi,
thank you for answering.
Unfortunately, time after time, all the channels i've tried were marked (at least one time) for RADAR.
This is a reason to use indoor frequencies..
I don't think that the is a radar near the site, but i was not able to find out what is the origin of those problems.. Maybe a Radio Amateur......?

One more thing that maybe it's important, is that if the switch from a frequency to the other one is "fast", maybe could be acceptable.. But at the moment sometimes happen that the remote AP reboot, waiting for the MESH...

Thank you for the support,

N

You can try an indoor. Also make sure that you are running the latest software in case there were changes to the trigger thresholds. But otherwise, TAC.