Search the Community
- ClearPass Recipe Review
- ClearPass Recipe Submission
- Admin Tool - Assign Role in Bulk
- Admin Tool - User Search
- CWNP Conf 2015
- Airheads Conference Vegas 2015
- Wlan Pro Conference 2015
- Airheads Conference Shanghai 2014
- WLAN Pro Conf EU 2014
- CWNP Conference 2014 (Sep 22 - 24)
- Airheads Local 2014
- Wireless Field Day 7 (Aug 6-8, 2014)
- Black Hat 2014 Contest
- Airheads EMEA Italy 2014 (June 9 - 13)
- Americas Airheads Conference 2014
- WLAN Professionals Summit 2014
- Airheads Roadshow 2013
- EMEA Airheads Conference 2013
- APJ Airheads Conference 2013
- Americas Airheads Conference 2013
- Americas Airheads Conference 2012
- APJ Airheads Conference 2012
- EMEA Airheads Conference 2012
- Airheads EMEA 2012 Contest: How to Enter - Contest Terms & Conditions
- Airheads EMEA 2012 Contest: Create your Entry to Win Here!
- Airheads Conferences Prior to 2012
- Americas Airheads Local Events 2012
- EMEA Airheads Local Events 2012
- Wireless Field Day 3 @ Aruba Networks
- Wireless Tech Field Day 2- Silicon Valley
- Wi-Fi Mobility Symposium- San Jose, CA USA
- SDN Apps
Channels 5 and 7 overlap each other, so they should not be used, because it causes interference and bad performance. Unfortunately the controller allows the administrator to configure any channels, but to avoid interference, it should be channels 1, 6 and 11.
The channel column in your screenshot here: http://community.arubanetworks.com/aruba/attachmen
ts/aruba/Aruba-Apps/349/1/aruba_dashboard.jpg says what channels your access points are on.
...access points could not be pinged in the manner you suggested. I would upgrade directly to...
That issue was resolved in ArubaOS 220.127.116.11. From the 18.104.22.168 release notes:
The bug symptom is generic and all-encompassing, but the bug was opened because access points could not be pinged in the manner you suggested.
I would upgrade directly to 22.214.171.124 after reviewing the release notes, however, since it just went GA this week and you would benefit from other fixed issues.
..."), there is an ipsec tunnel built between the access point and the controler for management traffic...
If you have control plane security enabled ("show control-plane-security "), there is an ipsec tunnel built between the access point and the controler for management traffic. Historically there was an issue where if a management device is on the same VLAN as the controller, the access point would respond to the ping from that device through the controller's tunnel and the traffic would be dropped. If you ping the access point from a different subnet, it would not send it through the tunnel, so it would work.
Ping is not essential for the access point to work, because an access points is never managed externally from anything besides the controller's ip address. Turning off control plane security would fix your issue, but it involves some downtime and it does nothing but allow you to ping your access points from the subnet of the controller, which is not important.
I understand that ping is not essential for an access point to work. But when you moving from...
I understand that ping is not essential for an access point to work. But when you moving from a system where this was part of the troubleshooting process for the Tier 1 and Tier 2 support it is helpful if as much of the system and available troubleshooting methods can be migrated from one system to the next. If that is not possible with Aruba, which I find odd, then we will just have to convey to them that Aruba doesn't support that kind of troubleshooting method.
I still find it odd that when I had another TAC case not related to this, that the first thing the TAC person asked me to do was ping the AP from my PC. Sounds like there is a bit of a disconnect there.
- Aruba Central
...there is no license assigned to them, you should have local access to the IAP & should be make...
IAP's would be controlled by Central only if licenses are assigned to it.
If there is no license assigned to them, you should have local access to the IAP & should be make configuration changes.
If possible , share the screenshot from the subscription assignment page.
Hi, Yes, they are. I did put them back because this is a live network and I need access...
Yes, they are. I did put them back because this is a live network and I need access and control for the APs.
I will unsubscribe them now and will check on them in 2 hours and see their status.
Please check with TAC on removing the APs from Activate if needed
No, they are disconnected from Central, and Central shows them as 'Down'. Thank you!
You can check the officially supported devices from the 'AirWave - Supported Infrastructure Devices...
You can check the officially supported devices from the 'AirWave - Supported Infrastructure Devices' guide that is available from:
If your device is not in there, you have chances that basic monitoring through the standard/basic SNMP attributes may give some results. I never had the possibility to try Avaya switches and APs with Airwave.
Hi, Official IMC supports monitoring features (via SNMP) on mainy Avaya devices (I ...
Official IMC supports monitoring features (via SNMP) on mainy Avaya devices (I saw in the device matrix, switches, voip, video, security devices). Moreover, if the Avaya device is not in the "pre-defined" Avaya device models list, we can quickly add the device model in the WebUI (using SNMP sysoid to identify it).
I also checked the adapters (for configuration management), and I found (in the latest release), that there is an adapter to manage configuration file backup and software image deploy on "Avaya ERS 8600; 8800 switches, OS version 7.x, VSP 9012 switches, OS Version 3.3.x.x.".
Finally, if you like programming, you can add your own adapter TCL scripts to manage configuration for other device models.
...;". That will provide a list of access points that the access point can see and the average RSSI...
On the commandline, you can type: "show ap monitor ap-list ap-name <name of access point>". That will provide a list of access points that the access point can see and the average RSSI (signal strength). You can then attempt to locate that AP by the access points that have the strongest signal relative to that AP.
THank you! I was able to pull up the listing and I can obviously see where the closest 5 Access...
THank you! I was able to pull up the listing and I can obviously see where the closest 5 Access Points are....except...it displays the BSSIDS and I've yet to find how I can seach for which AP is using that BSSID. I can see the BSSIDs of a radio by looking at the 'Overview" of it in the web interface but that's the only place I've found to view it. Any further thoughts?
Thank you again for the help!!
Using the CLI, you can type show ap bss-table bssid bssid_here which will give you the AP name...
Using the CLI, you can type show ap bss-table bssid bssid_here which will give you the AP name for that BSSID.
For wifi, Each device would have a macaddr and it's generally a physical/PHY layer limitation of th...
For wifi, Each device would have a macaddr and it's generally a physical/PHY layer limitation of the chipsets (for all vendors) that supports up to 255 associated clients. So there's not much chance to go over 255 per client.
Better solution is something like Meridian where the tracking is done client-side and there's no receive-back PHY limitation on the receiver/radio.
If client drivers later on start preferring or weighting W2 APs, then it will matter, but for now t...
If client drivers later on start preferring or weighting W2 APs, then it will matter, but for now that has not really been seen or been an issue so long as proper design guidelines are followed in terms of coverage, AP power, etc.