Contained APs

Hi,
I heve problems with clients connected to the wireless network, the network disconnect and reconect them or they suffer low signal even when there are several APs, I found this log on the wireless lan controller
Warning: Our AP with Base Radio MAC XX:XX:XX:XX:XX:XX is under attack (contained) by another AP on radio type 802.11b/g
How can I counteract this effect?

Maybe your neighbors need a visit from you. That message is telling you that they have containment enabled on their AP's which basically is a DOS.
Sent from Cisco Technical Support iPhone App

Similar Messages

Drawbacks of using 4 APs to contain a rogue AP

What are the benefits/drawbacks of using 4 controller-based APs to contain a rogue AP vs using just one. If I understand it correctly a single AP can never be set to contain more than 3 rogues, and will never use more than 30% of its resources to do so. Also, you can set a maximum of 4 APs on "containment duty" against one rogue. I also believe that containment involves sending spoofed messages to the wireless clients which requires your APs to be within range of all the rogue clients.
So.. what do you guys think? Let me know if my conclusions regarding the process are incorrect!
Thanks!

If you actually try this in the lab with a client set to do a continuous ping, you will see that containing with only one AP will still allow clients to connect. The plan here, as it was designed by Airespace, was to only contain radios that you KNOW are a threat. APs on your own wired network were detected by RF and then verified to be on the wired network with a protocol called RLDP. Once an AP was discovered via RLDP, the rogue was automatically contained by a 4 AP containment if 4 APs heard the rogue. An alert was then sent to the administrator and the rogue was mapped for location so that it could be collected. Containing APs that were neighboring was disuaded because of the FCC "Good Neighbor" policy. You needed to make sure the AP was an actual threat to the security of your network before taking action. This became Cisco's policy on all rogue devices and they disabled RLDP from the system. Now if you do a contain you see the Legal Disclaimer that Cisco has put into place. A 4 AP containment will use some resources of your APs but it should not be a long term fix. You should go and deal with the rogue device personally once it is contained and mapped. After dealing with it, set the appropriate rogue state and remove containment.

How to jam rogue APs

Dear
I have detected several rogue APs in my company, one is with no security key. We are using 4402 WLC, i tried to contain those rogue APs , after this it shows these APs as contained, but no effect on SSID, still anyone can use it. Can someone tell me is it possible to disable rogue APs so that they are not used by employees. Thanks

Your theory seems to be correct, as I was able to Contain one SSID of my own D-LINK AP.
What was the RSSI value when you did this? How many APs were assigned to contain?
after that when I contain the client associated with that Contained AP then I was able to dis-associate.
Not a good idea because you'll need to contain alot of clients. What if the clients want to join YOUR valid SSID?
Cud u tell me what are possible RSSI values or distance between which we should be able to contain APs without issues. Is it related with APs or WLC model etc.
Y'know what? I'm not so sure because "containing" an AP isn't really a "sport" you want to brag about and Cisco frowns upon it. I just theorized because your RSSI values are just too low. If you have a value of, say, -75 dBm then there's a chance of being successful.
I plan to implement switch port security with mac-filtering on access switches.
Here's the deal. This is OK if the rogue AP happens to be connected to YOUR network. What if, and this is very common occurance here in Australia, if the rogue AP IS/WAS NOT connected to your network? What if the AP is actually acting as a honeytrap or siphoning your enterprise WLAN traffic and sending it the other side? As Scott recommended, the best way is to go to the owner of the offending rogue AP with two other big and burly colleagues and tell the offender to take the rogue AP out or you'll send your "enforcers" back.
This AP is just two floors away.
What are the inter-floors made of? Are they made of concrete or wood? Sounds like it's made out of concrete which makes propagation of wireless signal more difficult. A recent study in Australia regarding the propagation of rogue APs are caused by staff bringing in their own chop-suey wireless access point. The reason why they are doing it is because they are sick and tired of management telling them "No, you can't do it." The same study stated that if management is un-willing to improve work-related technology then staff will do their best to it themselves and without any authorization or approval. When it comes to wireless technology in the workplace, you'll be surprise to know how many managers are still ignorant about the security implications and consider wireless as a "punishment from G0d".
My opinion is this: Roll out wireless to your floors and buildings.

Drawbacks of ISA

Hi All,
I want to know the Drawbacks of ISA 5.0. It's very urgent.
Thanks and Regards,
Phanikumar

If you actually try this in the lab with a client set to do a continuous ping, you will see that containing with only one AP will still allow clients to connect. The plan here, as it was designed by Airespace, was to only contain radios that you KNOW are a threat. APs on your own wired network were detected by RF and then verified to be on the wired network with a protocol called RLDP. Once an AP was discovered via RLDP, the rogue was automatically contained by a 4 AP containment if 4 APs heard the rogue. An alert was then sent to the administrator and the rogue was mapped for location so that it could be collected. Containing APs that were neighboring was disuaded because of the FCC "Good Neighbor" policy. You needed to make sure the AP was an actual threat to the security of your network before taking action. This became Cisco's policy on all rogue devices and they disabled RLDP from the system. Now if you do a contain you see the Legal Disclaimer that Cisco has put into place. A 4 AP containment will use some resources of your APs but it should not be a long term fix. You should go and deal with the rogue device personally once it is contained and mapped. After dealing with it, set the appropriate rogue state and remove containment.

APs being contained as rogues by an external system

A rogue containment policy is being initiated against my organization's APs and I do not have the tools/knowledge necessary to track down its point of origin. What tools or steps are required to identify who is containing an AP?
Thanks

I currently have this weird issue too
I have no idea why. It started yesterday and continued today. I know that some people are in that area playing around with some Zigbee RFID tags, but I don't think that should make a problem?
Here from the controller logfile:
wism-1250-2: *Apr 09 14:40:03.582: %LWAPP-1-AP_CONTAINED: spam_lrad.c:25558 AP 1200b-6106-1 is being contained on slot 0
Containment is after around 1 minute over (WCS sends two mails, one with containment and one with CLEAR). I don't know if the users have some issues because of this, so far only one complained, but that could also be because he's using an Apple and not a stadard client.
The controller logfile doesn't show a "resolve" of the containment.
Auto containment of rogues is disabled on the controller.
Any ideas? Or did you ever receive an answer from your tac case?
Thanks,
Patrick

Cisco APs not updating after WLC-update

Hello everyone,
I need to update my 5508 WLCs to a newer software, to support new AP-models.
Started with AIR-CT5500-K9-1-7-0-0-FUS.aes and AIR-CT5500-K9-7-0-240-0.aes, everything worked fine. Pre-Downloaded the newer Image to the APs, restarted the WLCs and everything was ok.
Now I tried to update to 7.6.100.0 as well as 7.4.121.0. Both Versions should support my APs, but it doesn't work at all.
Any ideas are highly appreciated.
If you need further output, just let me know.
Regards,
Manuel
These are some informations about the environment, AP-info and logging after "upgrade" to 7.4.121.0, controller-information after downgrading again...
AP# sh ver
Cisco IOS Software, C1240 Software (C1240-K9W8-M), Version 12.4(23c)JA7, RELEASE SOFTWARE (fc1)
ROM: Bootstrap program is C1240 boot loader BOOTLDR: C1240 Boot Loader (C1240-BOOT-M) Version 12.4(13d)JA, RELEASE SOFTWARE (fc2)
AP uptime is 1 minute System returned to ROM by power-on System image file is "flash:/c1240-k9w8-mx.124-23c.JA7/c1240-k9w8-mx.124-23c.JA7"
cisco AIR-LAP1242AG-E-K9 (PowerPCElvis) processor (revision A0) with 27638K/5120K bytes of memory.
Processor board ID FCZ1545812F
PowerPCElvis CPU at 262Mhz, revision number 0x0950
Last reset from power-on LWAPP image version 7.0.240.0
1 FastEthernet interface
2 802.11 Radio(s)
32K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address: 70:CA:9B:07:86:B8
Part Number                          : 73-10256-07
PCA Assembly Number                  : 800-26918-06
PCA Revision Number                  : A0
PCB Serial Number                    : FOC15402NP4
Top Assembly Part Number            : 800-29152-03
Top Assembly Serial Number          : FCZ1545812F
Top Revision Number                  : A0
Product/Model Number                : AIR-LAP1242AG-E-K9
Configuration register is 0xF
AP#dir
Directory of flash:/
2 -rwx      89311 Jan 18 2014 20:41:00 +00:00 event.log
3 drwx          64 Jan 18 2014 20:43:21 +00:00 update
5 drwx        256 Jan 18 2014 20:40:55 +00:00 c1240-k9w8-mx.124-23c.JA7
4 -rwx        6168 Nov 2 2011 23:32:18 +00:00 private-multiple-fs
7 -rwx        395 Mar 1 2002 00:00:05 +00:00 env_vars
15740928 bytes total (8772096 bytes free)
AP#dir
Directory of flash:/c1240-k9w8-mx.124-23c.JA7/
9 -rwx      131328 Jan 18 2014 20:39:46 +00:00 7101.img
10 -rwx        292 Jan 18 2014 20:39:46 +00:00 info
11 -rwx    4642714 Jan 18 2014 20:40:55 +00:00 c1240-k9w8-mx.124-23c.JA7
15 -rwx      131328 Jan 18 2014 20:40:56 +00:00 6701.img
#sh logging --> see attached file
CONTROLLER (unfortunately after downgrading it again):
(Cisco Controller) >show sysinfo
Manufacturer's Name.............................. Cisco Systems Inc.
Product Name..................................... Cisco Controller
Product Version.................................. 7.0.240.0
Bootloader Version............................... 1.0.16
Field Recovery Image Version..................... 7.0.112.21
Firmware Version................................. FPGA 1.7, Env 1.8, USB console 2.2
Build Type....................................... DATA + WPS
System ObjectID.................................. 1.3.6.1.4.1.9.1.1069
IP Address....................................... WLC-IP
Last Reset....................................... Software reset
System Up Time................................... 0 days 0 hrs 26 mins 3 secs
System Timezone Location......................... (GMT +1:00) Amsterdam, Berlin, Rome, Vienna Current Boot
License Level....................... base
Current Boot License Type........................ Permanent
Next Boot License Level.......................... base
Next Boot License Type........................... Permanent
Configured Country............................... DE - Germany
State of 802.11b Network......................... Enabled
State of 802.11a Network......................... Enabled
Number of WLANs.................................. 2
Number of Active Clients......................... 5
Burned-in MAC Address............................ 1C:DF:0F:C6:D8:80
Power Supply 1................................... Present, OK
Power Supply 2................................... Absent
Maximum number of APs supported.................. 150
(Cisco Controller) >show boot
Primary Boot Image............................... 7.4.121.0
Backup Boot Image................................ 7.0.240.0 (default) (active)
(Cisco Controller) >show ap bundle primary
Primary AP Image        Size
ap1g2                  9576
ap3g1                  6684
ap3g2                  11208
ap801                  5192
ap802                  5232
c1100                  3096
c1130                  4972
c1140                  4992
c1200                  3364
c1240                  4812
c1250                  5512
c1310                  3136
c1520                  6412
c3201                  4324
c602i                  3716
(Cisco Controller) >show ap bundle secondary
Secondary AP Image      Size
ap3g1                  6684
ap801                  5192
ap802                  5232
c1100                  3096
c1130                  4972
c1140                  4992
c1200                  3364
c1240                  4812
c1250                  5512
c1310                  3136
c1520                  6412
c3201                  4324
c602i                  3716
Nachricht geändert durch Manuel Sporleder

Hi Scott,
I am not trying to pre-download it anymore, since this doesn't work at all.
If I just restart the controller, the APs are downloading the image telling me "everything is fine", are rebooted and that stated with the old image again.
This is what you can see in the attached log-file:
*Mar 1 00:00:05.873: soap_prepare_new_image_crash: mini ios flash:/c1240-rcvk9w8-mx/c1240-rcvk9w8-mx
*Mar 1 00:00:06.242: %SOAP_FIPS-2-SELF_TEST_IOS_SUCCESS: IOS crypto FIPS self test passed
*Mar 1 00:00:07.662: %SOAP_FIPS-2-SELF_TEST_RAD_SUCCESS: RADIO crypto FIPS self test passed on interface Dot11Radio 0
*Mar 1 00:00:09.054: %SOAP_FIPS-2-SELF_TEST_RAD_SUCCESS: RADIO crypto FIPS self test passed on interface Dot11Radio 1
*Mar 1 00:00:09.152: %LWAPP-3-CLIENTEVENTLOG: Read and initialized AP event log (contains, 1024 messages)
*Mar 1 00:00:09.181: status of voice_diag_test from WLC is false
*Mar 1 00:00:11.381: %LINK-3-UPDOWN: Interface FastEthernet0, changed state to up
*Mar 1 00:00:11.440: %SYS-5-RESTART: System restarted
*Mar 1 00:00:11.441: %SNMP-5-COLDSTART: SNMP agent on host AP is undergoing a cold start
*Nov 2 23:31:59.107: %LINK-5-CHANGED: Interface Dot11Radio1, changed state to reset
*Nov 2 23:31:59.108: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
*Nov 2 23:31:59.929: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0, changed state to up
*Nov 2 23:32:00.107: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio1, changed state to down
*Nov 2 23:32:00.107: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down
*Nov 2 23:32:18.102: %CAPWAP-5-CHANGED: CAPWAP changed state to DISCOVERY
*Nov 2 23:32:18.163: bsnUnlockDevice: not bring radio up: radio 1 is in admin disable state
*Nov 2 23:32:18.345: %SSH-5-ENABLED: SSH 2.0 has been enabled
*Nov 2 23:32:18.759: status of voice_diag_test from WLC is false
*Nov 2 23:32:18.847: Logging LWAPP message to 255.255.255.255.
*Nov 2 23:32:33.181: %CDP_PD-4-POWER_OK: Full power - NEGOTIATED inline power source
*Nov 2 23:32:33.247: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
*Nov 2 23:32:34.212: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to up
*Nov 2 23:32:34.213: %SYS-6-LOGGINGHOST_STARTSTOP: Logging to host 255.255.255.255 started - CLI initiated
*Jan 20 20:32:44.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: WLC-1-IP peer_port: 5246
*Jan 20 20:32:44.001: %CAPWAP-5-CHANGED: CAPWAP changed state to
*Jan 20 20:32:45.479: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: WLC-1-IP peer_port: 5246
*Jan 20 20:32:45.480: %CAPWAP-5-SENDJOIN: sending Join Request to WLC-1-IP
*Jan 20 20:32:45.481: %CAPWAP-5-CHANGED: CAPWAP changed state to JOIN
*Jan 20 20:32:45.483: %CAPWAP-3-ERRORLOG: Invalid event 10 & state 5 combination.
*Jan 20 20:32:45.483: %CAPWAP-3-ERRORLOG: CAPWAP SM handler: Failed to process message type 10 state 5.
*Jan 20 20:32:45.483: %CAPWAP-3-ERRORLOG: Failed to handle capwap control message from controller
*Jan 20 20:32:45.484: %CAPWAP-3-ERRORLOG: Failed to process encrypted capwap packet from WLC-1-IPperform archive download capwap:/c1240 tar file
*Jan 20 20:32:45.494: %CAPWAP-5-AP_IMG_DWNLD: Required image not found on AP. Downloading image from Controller.
*Jan 20 20:32:45.499: %CAPWAP-5-CHANGED: CAPWAP changed state to IMAGE
*Jan 20 20:33:58.755: %DTLS-3-BAD_RECORD: Erroneous record received from WLC-1-IP: Duplicate (replayed) record
*Jan 20 20:33:59.315: image upgrade successfully, system is now reloading
This happens again and again and again...
Regards, Manuel

Best way to configure a network comprising WLSE and many APs ?

Hi the Cisco NetPro community,
I would like to have a discussion with you on the best way to configure a network containing a WLSE and a large amount of Access Points.
The network I want to configure comprises some subnetnorks, each comprising about 10 access points (with some advanced settings for security). It might be a quite long and boring process to set the configuration for all those, so I am looking for the quickest and easiest solution to do so.
First of all, the configuration of IP addresses have to be done on each Access Point after unpacking it. The configuration of my network comprises 1 WDS active AP, 1 WDS backup AP and the rest of infrastructure APs, that for each developement site.
I thought about several solutions :
- 1st solution could be to apply a configuration file (i.e. load the config.txt file) to each AP manually, changing some values (IP, local radius...).
But problem is that passwords can't be changed with text editor because of the passwords written in "hash".
- 2nd solution could be to configure each AP (after IP is set) using its web interface.
No more problem for hash written passwords, but this method is quite boring when surfing on menu pages of the AP web interface...
- 3rd solution, which could appear as the best solution, is to create a template on the WLSE, and to apply it to all APs.
No more boring connection to each AP, but problem are : we need to create as many templates as APs (or change some parameters each time), and we still need to set parameters directly to APs before (SNMP, SSH, WDS configuration...), in order the WLSE to manage the APs.
So, what do you think could be the best solution in order to deploy such a network with many APs ?
How is it possible to avoid (so far as we can) the configuration of APs one by one ?
Thanks a lot in advance for your consideration and your ideas !
Alexis.

Well for one of my clients that had over 60 sites, we actually created a couple of templates. We created a basic template and a template for each site. You can have the ap's obtain the configuration from the WLSE, but you need to configure a DHCP option. My client did mac address reservations, but of course you need the mac address first. I guess you can also let the ap get an address and change it later. They tried doing different things, first let the ap obtain a default config and then pushing out the configuration for that site.
As for the hash, you can set the password in ascii... when you do a show run, then of cours it will be hash'd.
http://www.cisco.com/en/US/docs/wireless/wlse/2.12/user/guide/deploywz.html#wp1936755

APs go into standalone but don't recover

We have an issue of APs losing communication to the WLC, going into standalone mode and not completely returning to LWAPP mode once communication is restored. The controller is a 4404 running version 5.2.178.0. The WLC is at our corporate office and the APs are scattered around the country at small sales offices. We are running H-REAP to the 1242 series APs.
If the WAN link drops or the site loses power, the AP loses communication to the WLC (obviously). When the WAN/power restores, the AP restores communication to the WLC, but clients connecting get 0.0.0.0 as an IP. The local router at the site hands out the DHCP addresses. The fix has been to bounce the PoE switch port or rebbot the AP from the WLC. Removing power to the AP is the best recovery right now. Any ideas how to fix this issue? Thanks

The Bug ID Toolkit isn't allowing me to see the details of the bug.
Information contained within bug ID CSCsx80603 is only available to Cisco employees. It is our policy to make all externally-facing bugs available in Bug Toolkit so the system administrators have been automatically alerted to the problem. By choosing to save this bug, you may be notified when the decision to make this bug available to you has been made. Note: Some product enhancement requests and documentation error bugs may not be available in Bug Toolkit.

VWLC 7.6.120 with cap2602 APs

Running virtual wireless controller 7.6.120 with AIR-CAP2602E-K-K9 model access points. The server crashed a few days ago and now the access points arent able to join to the controller. They join to the controller for about 5 minutes, and i see users actually connecting to it. Then it just disappears. and does the same cycle again. I've also "clear all config" on all of the access points as well. This setup is actually on a drillship and it goes over the VSAT, we have them setup locally onboard at other sites and never had issues until now. I've attached the logs on its behavior on what it does.
I've also upgraded the controller from 7.4.100 to 7.6.120 thinking it would fix the issue. No dice.
Any help would be appreciated.

I downgraded the controller. See the following below.
(Cisco Controller) >show sysinfo
Manufacturer's Name.............................. Cisco Systems Inc.
Product Name..................................... Cisco Controller
Product Version.................................. 7.4.121.0
RTOS Version..................................... 7.4.121.0
Bootloader Version............................... 7.4.121.0
Emergency Image Version.......................... 7.4.121.0
Build Type....................................... DATA + WPS
System Name...................................... RIG201-vWLC
System Location..................................
System Contact...................................
System ObjectID.................................. 1.3.6.1.4.1.9.1.1631
IP Address....................................... 10.254.201.224
System Up Time................................... 0 days 4 hrs 39 mins 57 secs
System Timezone Location......................... (GMT -6:00) Central Time (US and Canada)
System Stats Realtime Interval................... 5
System Stats Normal Interval..................... 180
Configured Country............................... Multiple Countries:KE,US
--More-- or (q)uit
State of 802.11b Network......................... Enabled
State of 802.11a Network......................... Enabled
Number of WLANs.................................. 5
Number of Active Clients......................... 0
Memory Current Usage............................. Unknown
Memory Average Usage............................. Unknown
CPU Current Usage................................ Unknown
CPU Average Usage................................ Unknown
Burned-in MAC Address............................ 00:0C:29:03:42:BC
Maximum number of APs supported.................. 200
AP4c00.82b9.96de#sh inventory
NAME: "AP2600", DESCR: "Cisco Aironet 2600 Series (IEEE 802.11n) Access Point"
PID: AIR-CAP2602E-K-K9 , VID: V01, SN: FGL1729W06B
AP4c00.82b9.96de#sh version
Cisco IOS Software, C2600 Software (AP3G2-K9W8-M), Version 15.2(2)JB3, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2013 by Cisco Systems, Inc.
Compiled Thu 19-Dec-13 04:30 by prod_rel_team
ROM: Bootstrap program is C2600 boot loader
BOOTLDR: C2600 Boot Loader (AP3G2-BOOT-M) LoaderVersion 12.4(25e)JA1, RELEASE SOFTWARE (fc1)
AP4c00.82b9.96de uptime is 3 minutes
System returned to ROM by power-on
System image file is "flash:/ap3g2-k9w8-mx.152-2.JB3/ap3g2-k9w8-xx.152-2.JB3"
Last reload reason:
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
If you require further assistance please contact us by sending email to
[email protected].
cisco AIR-CAP2602E-K-K9 (PowerPC) processor (revision A0) with 180214K/81920K bytes of memory.
Processor board ID FGL1729W06B
PowerPC CPU at 800Mhz, revision number 0x2151
Last reset from power-on
LWAPP image version 7.4.121.0
1 Gigabit Ethernet interface
2 802.11 Radios
32K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address: 4C:00:82:B9:96:DE
Part Number : 73-14511-02
PCA Assembly Number : 800-37898-01
PCA Revision Number : A0
PCB Serial Number : FOC17273MC9
Top Assembly Part Number : 800-38357-01
Top Assembly Serial Number : FGL1729W06B
Top Revision Number : A0
Product/Model Number : AIR-CAP2602E-K-K9
Configuration register is 0xF

Issue containing a rogue AP

My WLC has detected (via 15 detecting radios) a rogue AP with a client connected to it. The infrastructure has not determined that the AP is plugged into the local network. I'm trying to contain the AP - I classify it as "Malicious", update its status to "Contain" & assign 2 APs (though the number of APs don't matter here) to contain the rogue.
Everything looks right, as the WLC shows that the rogue AP is in a "Contained" status. However, after about a minute the WLC shows the rogue having been reverted to an "Alert" status. I've contain other rogues before but have yet to see one not have the "Contained" status stick.
Anyone seen this? Or know why it's happening? Thanks!

Check and verify that the "rogue" is not one of your APs associated to a controller with a different mobility group name but on the same network as your primary mobility group. This is the only way I could think that this is happeneing. Also, try a 4 AP containment. At 2 APs a client could still associate to the rogue thus generating a new alert.

WCS Report - Disassociated APs

Is it possible to run a report containing all Disassociated APs? I tried all the Device reports in the report launch pad and they only report on associated APs. I can obviosly view them in Monitor/Access Points but I cannot report on them. Any help would be greatly appreciated! I wouldnt even mind if I had to run a report on ALL AP's and just filter out Disassociated APs in Excel.
Thanks,
Phil

Never mind - I figured it out.
Report Launch Pad - Device - Inventory
Report Type - AP
Customize - Custome Report name - Disassociated APs
Thanks Phil!

3502i APs not joining controller

So basically my infrastructure consists of four 4402 WLCs running on 7.0.235.3. I'm trying to get new access points to join to the environment, but I am having difficulty doing so. All currently joined APs work fine and are operating well. I'm getting a red, green, off blink code which means it's trying to join, but never does. The other one I get a constantly blinking green but it never joins either. I've setup option 43 in DHCP, added cisco-capwap-controller entries in DNS thinking it was because those are missing, and still cannot get these two access points to join. Can anyone think why it would not be joining?
The access points and WLC are all on the Same VLAN by the way.

Hello,
In a Cisco Unified Wireless network, the LAPs must first discover and       join a WLC before they can service wireless clients.
Originally, the controllers only operated in Layer 2 mode. In Layer 2       mode, the LAPs are required to be on the same subnet as the management       interface and the Layer 3 mode AP-manager interface is not present on the       controller. The LAPs communicate with the controller using Layer 2       encapsulation only (ethernet encapsulation) and do not Dynamic Host       Configuration Protocol (DHCP) an IP address.
When Layer 3 mode on the controller was developed, a new Layer 3       interface called AP-manager was introduced. In Layer 3 mode, the LAPs would       DHCP an IP address first and then send their discovery request to the       management interface using IP addresses (Layer 3). This allowed the LAPs to be       on a different subnet than the management interface of the controller. Layer 3       mode is the dominate mode today. Some controllers and LAPs can only perform       Layer 3 mode.
However, this presented a new problem: how did the LAPs find the       management IP address of the controller when it was on a different subnet?
In Layer 2 mode, they were required to be on the same subnet. In Layer       3 mode, the controller and LAP are essentially playing hide and seek in the       network. If you do not tell the LAP where the controller is via DHCP option 43,       DNS resolution of "Cisco-lwapp-controller@local_domain", or statically       configure it, the LAP does not know where in the network to find the management       interface of the controller.
In addition to these methods, the LAP does automatically look on the       local subnet for controllers with a 255.255.255.255 local broadcast. Also, the       LAP remembers the management IP address of any controller it joins across       reboots. Therefore, if you put the LAP first on the local subnet of the       management interface, it will find the controller's management interface and       remember the address. This is called priming. This does not help find the       controller if you replace a LAP later on. Therefore, Cisco recommends using the       DHCP option 43 or DNS methods.
When the LAPs discover the controller, they do not know if the       controller is in Layer 2 mode or Layer 3 mode. Therefore, the LAPs always       connect to the management interface address of the controller first with a       discovery request. The controller then tells the LAP which mode it is in the       discovery reply. If the controller is in Layer 3 mode, the discovery reply       contains the Layer 3 AP-manager IP address so the LAP can send a join request       to the AP-manager interface next.
Note: By default both management and AP-manager interfaces are left           untagged on their VLAN during configuration. In case these are tagged, make           sure they are tagged to the same VLAN in order to properly receive discovery           and join response from the WLC.
The LWAPP AP goes through this process on startup for Layer 3       mode:
The LAP boots and DHCPs an IP address if it was not previously           assigned a static IP address.
The LAP sends discovery requests to controllers through the various           discovery algorithms and builds a controller list. Essentially, the LAP learns           as many management interface addresses for the controller list as possible via:
DHCP option 43 (good for global companies where offices and             controllers are on different continents)
DNS entry for             cisco-capwap-controller (good for local             businesses - can also be used to find where brand new APs join)
Note: If you use CAPWAP, make sure that there is a DNS entry for                 cisco-capwap-controller.
Management IP addresses of controllers the LAP remembers             previously
A Layer 3 broadcast on the subnet
Over the air provisioning
Statically configured information
From this list, the easiest method to use for deployment is to have           the LAPs on the same subnet as the management interface of the controller and           allow the LAP’s Layer 3 broadcast to find the controller. This method should be           used for companies that have a small network and do not own a local DNS           server.
The next easiest method of deployment is to use a DNS entry with           DHCP. You can have multiple entries of the same DNS name. This allows the LAP           to discover multiple controllers. This method should be used by companies that           have all of their controllers in a single location and own a local DNS server.           Or, if the company has multiple DNS suffixes and the controllers are segregated           by suffix.
DHCP option 43 is used by large companies to localize the information           via the DHCP. This method is used by large enterprises that have a single DNS           suffix. For example, Cisco owns buildings in Europe, Australia, and the United           States. In order to ensure that the LAPs only join controllers locally, Cisco           cannot use a DNS entry and must use DHCP option 43 information to tell the LAPs           what the management IP address of their local controller is.
Finally, static configuration is used for a network that does not           have a DHCP server.You can statically configure the information necessary to           join a controller via the console port and the AP’s CLI. For information on how           to statically configure controller information using the AP CLI, refer to           Manually           Configuring Controller Information Using the Access Point CLI.
For a detailed explanation on the different discovery algorithms that           LAPs use to find controllers, refer to           LAP           Registration with WLC.
For information on configuring DHCP option 43 on a DHCP server, refer           to           DHCP           OPTION 43 for Lightweight Cisco Aironet Access Points Configuration           Example.
Send a discovery request to every controller on the list and wait for           the controller's discovery reply which contains the system name, AP-manager IP           addresses, the number of APs already attached to each AP-manager interface, and           overall excess capacity for the controller.
Look at the controller list and send a join request to a controller           in this order (only if the AP received a discovery reply from it):
Primary Controller system name (previously configured on             LAP)
Secondary Controller system name (previously configured on             LAP)
Tertiary Controller system name (previously configured on             LAP)
Master controller (if the LAP has not been previously configured             with any Primary, Secondary, or Tertiary controller names. Used to always know             which controller brand new LAPs join)
If none of the above are seen, load balance across controllers             using the excess capacity value in the discovery response.
If two controllers have the same excess capacity, then send the             join request to the first controller that responded to the discovery request             with a discovery response. If a single controller has multiple AP-managers on             multiple interfaces, choose the AP-manager interface with the least number of             APs.
The controller will respond to all discovery requests without             checking certificates or AP credentials. However, join requests must have a             valid certificate in order to get a join response from the controller. If the             LAP does not receive a join response from its choice, the LAP will try the next             controller in the list unless the controller is a configured controller             (Primary/Secondary/Tertiary).
When it receives the join reply, the AP checks to make sure it has           the same image as that of the controller. If not, the AP downloads the image           from the controller and reboots to load the new image and starts the process           all over again from step 1.
If it has the same software image, it asks for the configuration from           the controller and moves into the registered state on the controller.
After you download the configuration, the AP might reload again to           apply the new configuration. Therefore, an extra reload can occur and is a           normal behavior.

How to avoid interferences caused by rogues APs

Hi Everybody,
I have a WLC running well with 10 LAPs.
The problem that I have approximatively 60 Rogues APs and I have a lot of perturbations in signals (noise, interference, ...) caused by theses APs.
How to avoid these interferences ?? is it the classification Malicieous APs ??

wow! belay that...DO NOT CONTAIN THE ROGUES!
Unless you can prove they are in your network and shouldn't be, there can be legal ramifications for doing so.
What you need to do first, is adjust the sensiitivity for rogues. by default it's -128, change that to -75. Once you've done this, then you can evalutate which rogues are in your network, or belong to neighboring businesses. For neighboring, go talk to their IT staff and see if you can get them to lower power so you aren't interferring with each other, cause if you see them, they probably see you as well.
HTH,
Steve
Please remember to rate useful posts, and mark questions as answered

How to Prevent or Block Rogue APs from Joining Your Wired or Wireless WLANs

Hi all, I deployed a WLAN with 1 WLC 4400 and 5 1252AP. I do not see the way to Block Rogue APs from Joining the Wired or Wireless WLANs

PART 1
There are three parts to this:
1. detect - automatic
2. classify - by default APs are untrusted/unknown, various methods can be configured to classify them as trusted and threat (connected to wired network).
3. over the air contain (aka mitigate) - in 4.x this is manual, in 5.x you can configure auto-containment
First you need to detect. WLC does this automatically out of the box. It listens the air for unknown APs, clients and ad-hocs. Are you seeing Rogue APs under Monitor > Rogues > Rogue APs?
Next, you can manually classify rogue APs as "known" (internal or external). Starting with 5.0 you can also build rogue rules based on RSSI, SSID, Clients, etc. If an AP is classified as "known" (internal or external), WCS stops alerting you.
Another key classification piece is to detect whether or not the rogue AP is physically connected to your network which is a high security risk. There are three ways WLC can detect it and neither of them is automatic. You must configure these methods manually.
1. Rogue AP Detector, aka ARP sniffing. You have to dedicate one AP as "Rogue Detector" (change AP mode from local to rogue detector). Configure the port the AP is connected to as switchport mode trunk (normally it's switchport mode access). Rogue Detector AP turns off and doesn't use its radios. When WLC detects rogue APs it can also detect the MAC addresses of any clients associated to that rogue APs, and the rogue detector AP simply watches each hardwire trunked VLAN for ARP requests coming from those rogue AP clients. If it sees one, WLC automatically classifies the rogue AP as "threat" indicating that the rogue AP is physically connected to your network. It doesn't actually do anything with the rogue AP, it simply classifies it and alerts you. Also, keep in mind that this method doesn't work if the rogue AP is a Wireless Router, because Wireless Routers NAT and ARP requests don't propagate to the wire.
2. RLDP. Rogue Location Discovery Protocol. This feature is by default turned off and can be enabled under Security > Wireless Protection Policies > Rogue Polices. This feature works only when the rogue SSID is open, meaning that it's not using WEP/WPA/802.1x. When you enable RLDP, your WLC will pick some AP (you can't pick manually) which hears Rogue AP traffic, it will temporarily shut off its radio, turn it into a client, and instruct it to associate to the Rogue AP as client (this is where the requirement comes in for the Rogue SSID to be open authentication). Once associated, AP gets a DHCP IP through Rogue AP, it then sends a special small UDP port 6352 RLDP packet to every possible WLC's IP address (mgmt ip, ap manager ip, dynamic int IPs). If WLC gets one of those packets, it means that rogue AP is physically connected to your network. This method will work when Rogue AP is a Wireless Router. But this method is not recommended. It has an adverse effect on your wireless clients because RLDP AP goes offline for a period of time disconnecting your clients and forcing them to associate to another AP. Also, keep in mind, that WLC runs this RLDP process *once* per detected rogue AP. It doesn't periodically do this, it only does it once. In some later WLC versions, you can configure RLDP to run only on "monitor mode" APs, eliminating impact on your clients. Also, you can manually trigger RLDP for a rogue AP from CLI "config rogue ap rldp initiate ". You can "debug dot11 rldp" to see the process.
3. Switchport Tracing (need WCS, and WLC 5.1). This is a later feature that requires WCS. You can add your Catalyst switches to WCS, and WCS will look at CDP information and MAC tables on your switches to detect whether or not Rogue AP is connected to your network. This works with secured and NAT rogues. You can also *manually* instruct WCS to shut down the switchport that Rogue AP is connected to.

Transfer aps to ext hd

Right now a user has a laptop running snow leopard. They have i movie and idvd but no support aps disk. Is there a way to save those installations and move them to an ext hd and when they do a clean install of lion they can keep the programs?

I don't think we're still in the days when applications were nice neat self-contained packages. now they scatter bits and pieces all over the place. Not sure about iMovie and iDVD though. Is there a reason why they can't just do an upgrade installation?

Contained APs

Similar Messages

Maybe you are looking for