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
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 22.214.171.124. From the 126.96.36.199 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 188.8.131.52 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.
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.
1. Yes IAP 277 supports meshing 2. With a 6.5 dBi antenna (integrated with AP-277) and a clear LOS...
1. Yes IAP 277 supports meshing
2. With a 6.5 dBi antenna (integrated with AP-277) and a clear LOS, 180-200 meters should work well (though your Bandwidth requirements will be the deciding factor).
You can use below link to calculate link budget:
AP specific details to fill in link budget can be found from datasheet here:
...;". 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.
...the users have the same access no matter where they are or how they connect. Even if the appropriate...
We use all Aruba switches on our edge network (about 325 switches, 95 stacks), however we use tunneled-node on only a few ports (where we need a public IP for a device, but don't have a public subnet in the building).
With Aruba's user centric model and new ClearPass functionality, you can get very granular on the switch without tunneling all of the traffic. For example, you can create the same roles on the switch as you would on the controllers and return the role from ClearPass so the users have the same access no matter where they are or how they connect. Even if the appropriate access controls do not exist on the switch, ClearPass can push the appropriate access controls down dynamically in real time.
Thanks for the information, it's greatly appreciated! So essentially all of the access...
Thanks for the information, it's greatly appreciated!
So essentially all of the access controls, role definition, etc exists on ClearPass...and ClearPass then pushes that down to the switch based upon authentication/authorization/etc? How do you guys handle ports where printers are connected?
Are you guys using Aruba (s3500 w/sfp ports?) at the distribution layer?
...access from our Class B address space (to stop spammers from off campus). We have 4 Cisco...
We have some generic ACLs that exist on all of the switches that apply everywhere on campus, but we push down custom roles for more specific roles.
We currently use MAC Auth on the wired side. If the device is registered as a printer, ClearPass will return a printer role which only allows access from our Class B address space (to stop spammers from off campus).
We have 4 Cisco 6500s in two VSS pairs on our distribution layer and route at the edge. We will be considering the all fiber S3500 switch for the next upgrade cycle.
Role Config Example:
Access Request from ClearPass returning the printer role based on attributes from our registration system:
RADIUS response back to the switch: