Rogue Detector question

I have 2 controllers 2106 both with the same mobility group, I have 3 APs in one controller and 3 APs on the other. I have just one rogue detector. Do I need a rogue detector on both or just in one controller?

Rogue detection is not bound by any regulations and no legal adherence is required for its operation. However, rogue containment usually introduces legal issues that can put the infrastructure provider in an uncomfortable position if left to operate automatically. Cisco is extremely sensitive to such issues and provides these solutions. Each controller is configured with a RF Group name.Once a Lightweight AP registers with a controller, it embeds an authentication Information Element (IE) that is specific to the RF Group configured on the controller in all its beacons/probe response frames. When the Lightweight AP hears beacons/ probe response frames from an AP either without this IE or with wrong IE, then the Lightweight AP reports that AP as a rogue, records its BSSID in a rogue table, and sends the table to the controller. There are two methods, namely Rogue Location Discovery Protocol (RLDP) and passive operation. These two are described in detail in the link below.
http://www.cisco.com/en/US/tech/tk722/tk809/technologies_white_paper09186a0080722d8c.shtml
As you can see from above all APs listen for rogues based on the above criteria but this is costly in resource overhead and is better solved by placing certain APs in rogue detection mode. This will become even more invaluable with the advent of the IDS/IPS solution.

Similar Messages

Best practices for configure Rogue Detector AP and trunk port?

I'm using a 2504 controller. I dont have WCS.
My questions are about the best way to configure a Rogue Detector AP.
In my lab environment I setup the WLC with 2 APs. One AP was in local mode, and I put the other in Rogue Detector mode.
The Rogue Detector AP was connected to a trunk port on my switch. But the AP needed to get its IP address from the DHCP server running on the WLC. So I set the native vlan of the trunk port to be the vlan on which the WLC management interface resides. If the trunk port was not configured with a native vlan, the AP couldn't get an address through DHCP, nor could the AP communicate with the WLC. This makes sense because untagged traffic on the trunk port will be delivered to the native vlan. So I take it that the AP doesn't know how to tag frames.
Everything looked like it was working ok.
So I connected an autonomous AP (to be used as the rogue), and associated a wireless client to it. Sure enough it showed up on the WLC as a rogue AP, but it didn't say that it was connected on the wire. From the rogue client I was able to successfully ping the management interface of the WLC.
But the WLC never actually reported the rogue AP as being connected to the wired network.
So my questions are:
1. What is the correct configuration for the trunk port? Should it not be configured with a native vlan? If not, then I'm assuming the rogue detector AP will have to have a static IP address defined, and it would have to be told which vlan it's supposed to use to communicate with the WLC.
2. Assuming there is a rogue client associated with the rogue AP, how long should it reasonably take before it is determined that the rogue AP is connected to the wired network? I know this depends on if the rogue client is actually generating traffic, but in my lab environment I had the rogue client pinging the management interface of the WLC and still wasn't being picked up as an on-the-wire rogue.
Thanks for any input!!

#what's the autonomous AP's(as Rogue AP) Wired and Wireless MAC address?
it has to be +1 or -1 difference. If Wired MAC is x.x.x.x.x.05 and the wireless mac should be x.x.x.x.x.04 or 06. It is not going to detect if the difference is more than + 1 or - 1.
#Does the switch sees the Rogue AP's wired MAC on its MAC table.
Rogue Detector listens to ARPs to get all the Wired MAC info and forwards to WLC, It compares with Wireless MAC, if there is a +1 or -1 difference then it will be flagged as Rogue on wire. And the client that connected to it is also marked as found on wire.
Regards to Trunking, Only Native vlan matters per trunk link, just configure the right vlan as native and we're done.
It is not mandatory to keep the Rogue detector on Management vlan of wlc. It can also be on L3 vlan also as long as it can join the WLC to forward the learnt wired MACs.
So if we don't have +1, -1 difference on Rogues then you've to use RLDP which will work with your existing setup to find Rogue on wire. there's a performance hit when we use this feature on local mode APs.
Note: For AP join - AP can't understand Trunk, meaning if AP connected to Trunk it'll only talk to its native vlan irrespective of AP mode, however rogue detector listens to the Trunk port to learn MACs via ARPs from different VLANs and forwards to WLC using native vlan.

EDRRM,Monitor & Rogue detector AP

Hello all,
Within the cisco MGN design document it states that " RRM may modify the characteristics of the network and could result in the endpoint being able to receive but have insufficient power to communicate with the access point."
Here are my questions
1.suppose we decide to turnoff RRM (due to the fact that the end-devices are not CCX v2.0 compatible) and that means CleanAir will not function as EDRRM will be impacted.is there a workaround for this? so we can have some kind of fine tuning to minimise the non-rf interference?
2.can a monitor mode AP also be utilised as a rogue detector AP?If so are there any performance issues associated.Is this approach recommnded?
Thanks,
janesh

1.suppose we decide to turnoff RRM (due to the fact that the end-devices are not CCX v2.0 compatible) and that means CleanAir will not function as EDRRM will be impacted.is there a workaround for this? so we can have some kind of fine tuning to minimise the non-rf interference?
EDRRM/CleanAir is really good in your wireless network but the feature's effectiveness hinges upon the client. Not all clients play "nice" with CleanAir.
Generally, laptops/netbook, smartphones & tablets are OK, however, in one particular installation I've got, the wireless VoIP wants RRM and TPC turned off. So this means that CleanAir is useless because the channels cannot change automatically.
There is no "workaround" because RRM is meant to operate automatically. With CleanAir, the AP detects interferrence and the strength and injects logic to change the channel when the interferrence gets stronger. The only "workaround" I can see is to hire someone to continuously stare at the logs and/or WCS/NCS/CPI and manually change channel at the slightest hint of channel interferrence.
can a monitor mode AP also be utilised as a rogue detector AP?If so are there any performance issues associated.Is this approach recommnded?
can a monitor mode AP also be utilised as a rogue detector AP?If so are there any performance issues associated.Is this approach recommnded?
I agree. It's a waste of AP. Now if you have the 3600 with the "ac" module, then you can do this without any service disruption.

RD (Rogue Detector) or RLDP (Rogue Location Discovery Protocol)

Hi all,
Cisco documentaion states that there are two ways for detecting Rogues.
Rogue Detector Access Point
You can make an AP operate as a rogue detector, which allows it to be placed on a trunk port so that it can hear all wired-side connected VLANs. It proceeds to find the client on the wired subnet on all the VLANs. The rogue detector AP listens for Address Resolution Protocol (ARP) packets in order to determine the Layer 2 addresses of identified rogue clients or rogue APs sent by the controller. If a Layer 2 address that matches is found, the controller generates an alarm that identifies the rogue AP or client as a threat. This alarm indicates that the rogue was seen on the wired network.
Rogue Location Discovery Protocol (RLDP)
RLDP is an active approach, which is used when rogue AP has no authentication (Open Authentication) configured. This mode, which is disabled by default, instructs an active AP to move to the rogue channel and connect to the rogue as a client. During this time, the active AP sends deauthentication messages to all connected clients and then shuts down the radio interface. Then, it will associate to the rogue AP as a client.
The AP then tries to obtain an IP address from the rogue AP and forwards a User Datagram Protocol (UDP) packet (port 6352) that contains the local AP and rogue connection information to the controller through the rogue AP. If the controller receives this packet, the alarm is set to notify the network administrator that a rogue AP was discovered on the wired network with the RLDP feature.
So how do you turn on the latter (RLDP)?
Many thx indeed
Ken
The following modes of operations exist:
http://www.cisco.com/en/US/products/hw/wireless/ps430/products_qanda_item09186a00806a4da3.shtml
Q. What are the different modes in which a lightweight access point (LAP) can operate?
A. An LAP can operate in any of these modes:
•Local mode—This is the default mode of operation. When an LAP is placed into local mode, the AP will transmit on the normally assigned channel. However, the AP also monitors all other channels in the band over a period of 180 seconds to scan each of the other channels for 60ms during the non-transmit time. During this time, the AP performs noise floor measurements, measures interference, and scans for IDS events.
•REAP mode—Remote Edge Access Point (REAP) mode enables an LAP to reside across a WAN link and still be able to communicate with the WLC and provide the functionality of a regular LAP. REAP mode is supported only on the 1030 LAPs.
•H-REAP Mode— H-REAP is a wireless solution for branch office and remote office deployments. H-REAP enables customers to configure and control access points (APs) in a branch or remote office from the corporate office through a WAN link without the need to deploy a controller in each office. H-REAPs can switch client data traffic locally and perform client authentication locally when the connection to the controller is lost. When connected to the controller, H-REAPs can also tunnel traffic back to the controller.
•Monitor mode—Monitor mode is a feature designed to allow specified LWAPP-enabled APs to exclude themselves from handling data traffic between clients and the infrastructure. They instead act as dedicated sensors for location based services (LBS), rogue access point detection, and intrusion detection (IDS). When APs are in Monitor mode they cannot serve clients and continuously cycle through all configured channels listening to each channel for approximately 60 ms.
Note: From the controller release 5.0, LWAPPs can also be configured in Location Optimized Monitor Mode (LOMM), which optimizes the monitoring and location calculation of RFID tags. For more information on this mode, refer to Cisco Unified Wireless Network Software Release 5.0.
Note: With controller release 5.2, the Location Optimized Monitor Mode (LOMM) section has been renamed Tracking Optimization, and the LOMM Enabled drop-down box has been renamed Enable Tracking Optimization.
Note: For more information on how to configure Tracking Optimization, read the Optimizing RFID Tracking on Access Points section.
•Rogue detector mode—LAPs that operate in Rogue Detector mode monitor the rogue APs. They do not transmit or contain rogue APs. The idea is that the rogue detector should be able to see all the VLANs in the network since rogue APs can be connected to any of the VLANs in the network (thus we connect it to a trunk port). The switch sends all the rogue AP/Client MAC address lists to the Rogue Detector (RD). The RD then forwards those up to the WLC in order to compare with the MACs of clients that the WLC APs have heard over the air. If MACs match, then the WLC knows the rogue AP to which those clients are connected is on the wired network.
•Sniffer mode—An LWAPP that operates in Sniffer mode functions as a sniffer and captures and forwards all the packets on a particular channel to a remote machine that runs Airopeek. These packets contain information on timestamp, signal strength, packet size and so on. The Sniffer feature can be enabled only if you run Airopeek, which is a third-party network analyzer software that supports decoding of data packets.
•Bridge Mode— Bridge mode is used when the access points are setup in a mesh environment and used to bridge between each other.

Found this in another post here on the forum :
There are 3 ways to detect rogue Aps:
1. Ap in monitor mode (sits and scans all channels. Can detect rogue Aps under 30 seconds
2. RLDP (done passively from normal Aps. Can take up to 15 minutes to detect rogue AP)
3. Rogue Detector (looks for broadcast packets from wireless clients on wired network)
For case number 2, a normal AP would be one in local or h-reap connected mode that normally have clients attached, but that are going off channel occasionally to scan for rogues / noise. The process of trying to validate that there is a network attached rogue (RDLP enabled) could likely be service interrupting depending on your AP layout.
-John

Wired rogue detector

I'm unable to see my 1130 I've setup as a rogue detector after creating a trunk on the port it's connected to. If I remove the trunk and put it into a switchport mode access I can see it fine. The trunk shows as up on the 4510 switch side. I've tried a crossover cable on the trunk, but still no luck. The documentation I've read, http://www.cisco.com/en/US/tech/tk722/tk809/technologies_white_paper09186a0080722d8c.shtml
just describes it as being plugged into a trunk, nothing else, but am I missing part of the configuration?
thank you,
Bill

Hi Bill,
Your AP is on a trunk so that it can get the ARP requests... but it also needs to get to a controller. SO if your AP was originally in VLAN 6, for example, you should set your trunk to native vlan 6 (switchport trunk native vlan 6), so that the AP can still get to the controller...
hth
Jerome

Rogue AP: Question

I need a bit of info with the below topics.
Q1. What is a Rogue AP?
Q2. WLC 4400 is detecting a number of rogue access points from neighboring buildings. How should the WLC 4400 deal with these rogue access points?
Q3. Can the WLC 4400 block these accees points from broadcasting their SSID's into our air space?
Regards,
Colm

For the Clases, you have the ability to define what criteria must be met for a roge to be called friendly or malicious. Under the Security tab > Wireless Protection Policy, Rogue Policies, Rogue Rules.
Class Type:
unclassified <--- AP detected but not matching any policy
friendly <--- AP matches the criteria of a friendly AP
malicious <--- AP matches the criteria of a malicious AP
Update Status:
Contain <--Contain the AP, uses our own AP to spoof the AP to get the clients to join "us" instead of "them" , once again, you need to be real careful with this, as if you are containing your neighbors, there can be reprocussions
Alert <-- Just a message saying there is a rogue

Rogue app question - repost

have set up the rogue app process to kill what is not listed in the exception list, everything seem to be working except for a few apps that are getting terminated even though they are listed in the exception list. rundll32.exe is the main problem although there have been one or two others. Also have one app that is not in the exception list that does not get killed (starcraft.exe). the program is launched by a different exe but loads starcraft.exe as the process. is there something else I need to look at?
this is the registry:
[HKEY_CURRENT_USER\Software\NetWare\NAL\1.0\process management]
"default action"=dword:00000001
"report ignored"=dword:00000000
"report terminated"=dword:00000001
[HKEY_CURRENT_USER\Software\NetWare\NAL\1.0\process management\exception list]
"rundll32.exe"=dword:00000000
zen ver 6.5, workstions are xp sp2
Reply With Quote

blowder,
It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.
Has your problem been resolved? If not, you might try one of the following options:
- Visit http://support.novell.com and search the knowledgebase and/or check all
the other self support options and support programs available.
- You could also try posting your message again. Make sure it is posted in the
correct newsgroup. (http://forums.novell.com)
Be sure to read the forum FAQ about what to expect in the way of responses:
http://forums.novell.com/faq.php
If this is a reply to a duplicate posting, please ignore and accept our apologies
and rest assured we will issue a stern reprimand to our posting bot.
Good luck!
Your Novell Product Support Forums Team
http://support.novell.com/forums/

AP Rogues 'On Network'

We see several Rogue APs in our network which are, according to WCS, not 'On Network'. However, most of them do turn out to be 'On Network': their MAC address appears as connected&active in a switch port. I wonder if this is because the 'On Network' status is never re-examined after first detection? Any suggestions?

A couple of questions
1) What LWAPs are you using
2) Have you enabled Rogue Location Discovery protocol
3) Have you configured dedicated Rogue detector LWAPs
4) Have you got legacy Autonomous APs on your network

Rogue APs/Clients

A couple of quick questions here (5508 WLC, 1142N APs).
I understand if I enable the AP mode to Rogue Detector from the details page of the AP, the AP stops accepting requests and is now looking for rogue items on the wired network. Is this the same when I enable Rogue Location Discovery Protocol? Will I lose the wireless functionality of all of my APs on the controller?
Next question, when I look at the Rogue Summary on the Monitoring page I see three Adhoc Rogue devices. When I select the Detail link only one shows. I remember the other two were HP mutifuction devices with WIFI enabled but I cannot retrieve that information anymore. Ideas?
Thank you,

Q1 ans:
#Both are different technique to find rogue on wire.
#Rogue detector is an AP mode that is applicable per AP.
#RLDP is an global feature that is applicable on AP modes - local, hreap & monitor. Security>> WPS>> General>> RLDP>> drop down menu.
#AP on Rogue Detector mode(listens arp on wire) is not similar to RLDP(that uses wireless).
#AP on Rogue Detector mode will not enable their Radios, so wireless client connection is not possible. The AP will be connected to trunk port of the switch and listens for arp entries on all VLANs, it compares the arp entry against Rogue AP & client info collected by WLC through APs, if it matches then it will make rogue on wire. its not very accurate method.
#AP on RLDP serves client but don't enable this feature on Local/hreap mode AP servicing voice clients(since AP goes off channel and connect to rogue AP that interrupts client service), use dedicated Monitor mode AP for this purpose. When RLDP feature is enabled cisco AP act as wireless client and connect to rogue AP and ping the management interface of WLC, on reply the Rogue AP will be marked as 'Rogue on wire'.
http://www.cisco.com/en/US/products/ps6366/products_tech_note09186a0080b40901.shtml
Q2 ans:
Check First & Last Time Reported On WCS/NCS that stores the history of Rogues.
If you've external trap server setup then it should be there as well.
Security>> WPS>> General>> Expiration Timeout for Rogue AP and Rogue Client entries - configurable between 240 & 3600 secs. If the rogue is not reported/refreshed with in this time frame then it will get deleted from WLC.
Q3 ans:
It is suggested to talk to them to reduce their AP power levels if they're seen very high.
If your client talks to their AP(which is detected as Rogue by WLC) then your own client will be marked as rogue client.
Enable MFP - global Infrastructure mfp for AP & per wlan mfp for Client as mandatory to avoid attacks.

Rogue Detection and SPT issues

Deployed wireless a few months. From a client to infrastrure standpoint, majority of users are happy with the ability to go wireless with their personal and work devices.
The problem we're facing is proper identification of rogue's AP's on our wired network (hot spots aren't important)
I've setup a few linksys AP's connected to our access switches and found WLC/PRIME finds the rogue AP's but when a SPT is performed, both WLC/PRIME state it's not on the wired network (which is not true). If I do a manual trace, in Prime, it will work but I can't do a manual trace everytime I get an alert (we're in a major US city). Further investigation shows the lan and wlan mac address of this linksys router is +/- from one another (confirmed by with arp table on access switch and going into prime and looking at the alert).. Which in this case, Prime should see it as WIRED and mark it as a ROGUE and alert me
Found a document
http://www.cisco.com/en/US/customer/docs/wireless/prime_infrastructure/1.3/configuration/guide/admin.html#wp1603927 stating only the following switches are supported: 3750, 3560, 3750E, 3560E, and 2960.
I can't see how these are the only supported devices, most are older than the 4510. I posted this in another thread and a rep provided me the link
http://www.cisco.com/en/US/products/ps6366/products_tech_note09186a0080b40901.shtml
Read this and even went further and read ROGUE MANAGMENT WHITE PAPER
http://www.cisco.com/en/US/products/ps6366/products_tech_note09186a0080b40901.shtml
This does not mention a limitation of switches support. States if CDP and SNMP is enable, along with the local access switches added to PRIME it should work
Here is the currently list of deployed devices, code and basic configuration
Access Switches - 4510 - image: cat4500e-universalk9.SPA.03.02.02.SG.150-2.SG2.bin
WLC - 5500 - image 7.4.103.9
AIR-CAP3602I-A-K9 - 152 deployed, 151 are configured for Local Mode, 1 is configured as Rogue Detector (trunked with all access vlan's passing thru)
RLDP is enabled on all Local Mode AP's - which after reading is not best practice because of time slicing and the fact is degrades client quality and can kick users off
Basically looking for feedback from others who have deployed wireless and have succesfully configured their environement for ROGUE AP DETECTION with SPT.. What are your thoughts and what do you run?
Thanks in advance

Mark:
Complaints about the performance of Switchport Tracing are pretty common. The best way to build this out is to start with your planted rogue AP is connected to the same switch that your Prime Infrastructure server connects to--or the first wired switch that ESX/ESXi host connects to--and validate that it works there, make whatever changes you need to get it working, then move the planted rogue AP to the next switch and so on. The logging modules Configuration, General, Monitor, GUI, System and Tools should cover everything you need to know why Switchport Tracing isn't giving the results you expect. This "start small and work your way up" helps you learn lessons about what needs to be configured on all your switches to have it working the way you want it to.
Configuring Switchport Tracing

Finding rogue APs that are on wired network

I am beginning to think that there is no way to gaurantee that a rogue AP is connected to your wired network. I have read up on RLDP and "rogue detection". I was excited because I thought rogue detection would accomplish this. However, when I connect an autonomous AP to my wired network it does not get identified as being on my wired network despite the "rogue detector" being in place and connected to a trunk port with all network vlans on it. In thinking through this I believe this is because the radio mac and ethernet macs are different on the autonomous AP. The ethernet mac of the autonomous rogue AP is in the rogue detector dB, not the radio mac. So when the detecting APs sends the radio mac to the rogue detector it doesn't get flagged. Can anyone confirm this? And if so offer any insight to a workaround. I was able to get a "rogue client" flagged as a threat connecting via this AP, because it arp entry is in the rogue detectors dB. But I can't get the AP flagged. If this is the case then rogue detection is more or less useless to me because I care about rogues on my network (obvious security breach) not rogues in other businesses in my area. I rather now when the rogue AP goes in and not have to wait until a rogue client connects to it. Please advise....
Regards Chuck

Network Chemistry makes a free tool (as well as a more advanced product you can buy) that might fit the bill for you. It relies on people properly classifying the devices on their own network with the free tool to build a database of device types based on the vendor ID digits of mac addresses, as well as some snmp scanning (I think). A link is below. I don't have a lot of experience with the tool, only because I'm not entirely convinced of it's accuracy, but to be honest, I've never really used it in a production environment
Good luck!
-Chris
http://www.networkchemistry.com/products/roguescanner.php

Rogue detection

Hi,
I would need some clarifications about rogue AP detection. First, in order to configure the passive rogue detection is it necessary to just setup a rogue detector AP or I also need to enable RLDP? Second, in your experience how much is it reliable?
Thanks,
Matteo

Hi Matteo:
Passive rogue detection is just on--no rogue detector AP required! Just like anything else in life, the more resources you put toward something, the better it's going to be. If you have AP Authentication or MFP configured (which you should anyway), you'll have fewer false alarms and the routines will know not to call your own APs rogues. RLDP will tell you if a rogue AP is just cabled up in your network but doesn't have any clients yet and will allow you to do switchport tracing to find one from the switch side. Rogue Detector APs don't handle client traffic, they just dedicate themselves to listening and reporting rogue activity back to the controller. In a world where budgets are tight, we hear that it can be tough to get funding for APs that don't service clients. Again, you don't *have* to do any of it, just the more you put in, the more accurate your results will be.
As for inaccuracies, that usually comes from folks having things misconfigured in their network or not having enough configured (i.e. choosing to not do RLDP or Rogue Detectors.)
Sincerely,
Rollin Kibbe
Network Management Systems Team

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.

Wired rogue

Hello all,
I am testing rogue on wire using 5508 WLC and , I have a dedicated AP configured as rogue detector and configured the switch port where the Rogue detector is connected as trunk. I have plugged in an autonomous AP with open authentication to the same switch so that it can act as a rogue.
On the WLC, I can see that Autonomous AP as rogue on Wire. But along with that I am seeing another AP as rogue on wire, even though i have plugged in only one Autonomous AP to the switch. does anybody come across this issue before? Thank you.

Hi.
If you have an access point working in both 802.11b/g and 802.11a/g frequencies, then you will be detected as 2 different access points. You can confirm that with the following command
AP1230#show dot11 bssid
Interface     BSSID           Guest SSID
Dot11Radio1   0011.2161.b7c0 Yes atlantic
Dot11Radio0   0005.9a3e.7c0f Yes WPA2-TLS-g
Please rate if it helps

Admin Status for Rogue AP

Hi ,
We have 1242-AG series AP which is configured in Rogue Detector mode. After adding this AP to WLC its showing Admin Status of AP as Down.
When i am trying to enable the Admin Status its giving me following error
" Admin status cannot be enabled for AP in Rogue Detector mode".
Any suggestions on how to enable Admin Status for Rogue Detector AP.
Thanks
Prasad

Rogue Detection under Unified Wireless Networks
http://www.cisco.com/en/US/tech/tk722/tk809/technologies_white_paper09186a0080722d8c.shtml
This may help along with Steves answer

Rogue Detector question

Similar Messages

Maybe you are looking for