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

Similar Messages

"On wired Rogue" not on wire

Actually I have the following X-File: Since several firmware releases our 4404 WLCs report two Rogue APs as on our network. But they are definetively not on our LAN. They are in neighbour buildings but they belong not to our university. The buildings are not LAN connected.
Has anyone an possible explanation/theory for this?
p.k.

Scott raises an interesting point.
It is possible for Windows-based laptops to permit their wireless connection to be shared with other users. This can result in a layer 2 bridging by the laptop itself between your wired and wireless networks. This is often the result of a misconfigured NIC on the access point. If you can narrow down which machine has this MAC, it could get you a lot farther.
Alternately, if you are hunting an adhoc rogue, in theory, if you could connect to it with a wireless laptop you could perform a network discovery to see what is out there.
Of course, you will want to consider any legal ramifications prior to attempting to do this if it turns out that this rogue equipment is not on your network.
- John
(Please remember to rate helpful posts)

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

WCS Wireless Rogue AP Detection for WIRED AP's

All Ethernet switches have been recorded correctly into WCS but while tracing a "rogue AP" the wired trace fails, has anyone got this feature to work? Is so what conditions need to be met? I.E Does the rouge need to have associated clients, does the rouge AP need a valid IP address.
The WCS looks like it's working while taksed with the wired trace but ends with a fail.
Using standard switch port config Cisco PNAC : dot1x pae authenticator (multi-domain), MAB, WEB-AUTH
Cheers
Jay

Hi,
is your RLDP protocol enabled on the WLCs ? It makes your APs locate the wired rogues.
You also need the rogue AP to be open SSID, if it's encrypted you can connect to it to see where it is located on your wired network ...
Nicolas

Help with Switchport Trace on WCS v 5.2.130

I am having trouble getting the "switchport trace" for rogue devices working. I have imported a seed list of switches and made sure that snmp RW community is correct. However, I am still not able to run the trace and have it return any results - always get "switchport trace failed". Anybody got this working that could offer some additional insight. Thanks in advance.

Currently, WCS provides rogue access point detection by retrieving information from the controller. The rogue access point table is populated with any detected BSSID addresses from any frames that are not present in the neighbor list. At the end of a specified interval, the contents of the rogue table are sent to the controller in a Lightweight Rogue AP Report message. With this method, WCS would simply gather the information received from the controllers; but with software release 5.1, you can now incorporate switch port tracing of wired rogue access point switch port. This enhancement allows you to react to found wired rogue access points and prevent future attacks. The trace information is available only in the WCS log and only for rogue access points, not rogue clients.
http://www.cisco.com/en/US/docs/wireless/wcs/5.2/configuration/guide/5_2ctrlcfg.html#wp1089752

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

WCS Report - Rogues on Wired LAN

Each WLC on our network shows "Rogues on Wired Network" from the Summary screen, however, checking these can be time consuming due to the number of WLC's in the network.
All of the WLC's are connected to a WCS so I was wondering whether a report for "Rogues on Wired Network" is available on the WCS??
I've spent a while looking around the WCS but can't find this information.
Any help that would make checking this easier greatfully recevied...

Unfortunately no. The feature works quite well only since WCS 6.0.
If you have a WCS 4.1 you may be able to update to 5.2 or 6.0 as licensing should be the same. Check with your sales 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.

Doing the impossible? Finding rogues from the wired side

Wondering if anyone has found a valid tool (beyond the sourceforge APTools kind of stuff) to assist in finding APs by culling through the ARP tables on routers etc... brutal stuff here I know. Also- anything in a wireless frame/packets common to all APs (all vendors as part of 802.11) that can be filtered on at the router to possibly block traffic from rogue APs? I think not, but I'm scratchin at anything here...
Lee Badman
CWNA Network Engineer

Hi ,
In AP350 has fnew feature which may help you .
The process takes place as follows:
1. A client with a LEAP profile attempts to associate to a access point A.
2. Access point A does not handle LEAP authentication successfully, perhaps because the access point does not understand LEAP or cannot communicate to a trusted LEAP authentication server.
3. The client records the MAC address for access point A and the reason why the association failed.
4. The client associates successfully to access point B.
5. The client sends the MAC address of access point A and the reason code for the failure to access pont B.
6. Access point B logs the failure in the system log.
http://www.cisco.com/univercd/cc/td/doc/product/wireless/airo_350/accsspts/ap350rn/rn1200.htm

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

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.

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 guest access - Unable to access network

Hello,
I've configured two WLC's with the exact same config one of them has working Wired guest network the other one does not.
The only difference in the two I know of is that the one that does not work is connected to a Cisco 3550 switch, the one that works is connected to a Cisco 7600.
The problem is when I connect a computer to the wired guest network I am able to get an IP address from the Internal DHCP server but unable to access the network.
I've tried pinging the gateway's IP and I get no answer.
The Port-channel interface has the correct VLans and the vlans exist on all switches.
If anyone see an error there or might have an idea why this is not working I would appreciate the feedback.
Config follows below..
regards,
Gk

(Cisco Controller) >show running-config
802.11a cac voice tspec-inactivity-timeout ignore
802.11a cac voice stream-size 84000 max-streams 2
802.11b cac voice tspec-inactivity-timeout ignore
802.11b cac voice stream-size 84000 max-streams 2
location rssi-half-life tags 0
location rssi-half-life client 0
location rssi-half-life rogue-aps 0
location expiry tags 5
location expiry client 5
location expiry calibrating-client 5
location expiry rogue-aps 5
Cisco Public Safety is not allowed to set in thisdomain
ap syslog host global 255.255.255.255
auth-list ap-policy ssc enable
custom-web ext-webserver add 1 217.28.176.114
dhcp create-scope guestnetwork
dhcp address-pool guestnetwork 192.168.34.2 192.168.34.200
dhcp default-router guestnetwork 192.168.34.254
dhcp enable guestnetwork
dhcp dns-servers guestnetwork 212.30.200.200 212.30.200.199
dhcp network guestnetwork 192.168.34.0 255.255.255.0
local-auth method fast server-key *****
interface create guestnetwork 331
interface create guestnetwork-wired 332
interface address ap-manager 10.255.255.90 255.255.255.248 10.255.255.94
interface address dynamic-interface guestnetwork 192.168.34.1 255.255.255.0 192.168.34.254
interface address dynamic-interface guestnetwork-wired 192.168.35.1 255.255.255.0 192.168.35.254
interface address management 10.255.255.89 255.255.255.248 10.255.255.94
interface address service-port 10.60.4.200 255.255.255.0
interface address virtual 1.1.1.1
interface dhcp ap-manager primary 10.255.255.89
interface dhcp dynamic-interface guestnetwork primary 10.255.255.89
interface dhcp management primary 10.255.255.89
interface dhcp service-port disable
interface vlan ap-manager 226
interface vlan guestnetwork 331
interface vlan guestnetwork-wired 332
interface vlan management 226
interface port ap-manager 29
interface port guestnetwork 29
interface port guestnetwork-wired 29
interface port management 29
lag enable
load-balancing window 5
mesh security eap
mgmtuser add root **** read-write
mobility group domain XXXXXXX
mobility symmetric-tunneling enable
network otap-mode disable
network rf-network-name XXXXXXX
radius acct add 1 XXXXXXX 1813 ascii ****
radius auth add 1 XXXXXXX 1812 ascii ****
radius auth management 1 disable
spanningtree port mode off 1
spanningtree port mode off 2
sysname XXXXXXX
time ntp interval 3600
time ntp server 1 XXXXXXX
wlan create 1 hotspot hotspot
guest-lan create 1 hotspot-wired
wlan interface 1 guestnetwork
guest-lan interface 1 guestnetwork
wlan custom-web webauth-type external 1
wlan custom-web ext-webauth-url https://XXXXXXX
wlan session-timeout 1 disable
wlan wmm allow 1
wlan wmm allow 18
wlan security wpa disable 1
wlan security wpa disable 18
wlan radius_server auth add 1 1
wlan radius_server acct add 1 1
guest-lan radius_server auth add 1 1
guest-lan radius_server acct add 1 1
wlan dhcp_server 1 0.0.0.0 required required
wlan enable 1
guest-lan enable 1

Wired to Wireless MAC header Cross Reference

Hey guys! I was wondering if you all could help out compiling a list of the radio mac header to ethernet mac header on all of the aironet based cisco APs. We are starting to implement tighter security here and one of those aspects is making sure rogue aps do not end up being connected to our infrastructure. For the soho equipment it has not been too difficult to track but the cisco equipment has been a lot more difficult. Since the ethernet and radio macs are coming from two different pieces of equipment and the fact that there is no existing document has us at a loss in quick scanning. I will go ahead and get this started it would be really great if we can continue building upon it.
this is just from some old 1200s:
Wired Wireless
00:09:E8:* 00:07:50:*
00:0D:29:* 00:0C:CE:*
00:0E:38:* 00:0E:38:*
00:0E:84:* 00:0E:D7:*
00:0E:D7:* 00:0E:D7:*
00:0F:23:* 00:0F:24:*
00:0F:23:* 00:0F:23:*
00:0F:8F:* 00:0F:90:*
00:0F:90:* 00:0F:90:*
00:0F:90:* 00:0F:F7:*
00:12:43:* 00:11:92:*
00:12:80:* 00:13:19:*
00:12:80:* 00:12:80:*
00:12:D9:* 00:13:19:*
00:13:1A:* 00:13:60:*
00:14:6A:* 00:14:6A:*
00:14:A9:* 00:14:A9:*
Here is some of the new 1242s:
Wired Wireless
00:16:C7:* 00:15:C7:*
00:19:30:* 00:1A:30:*
00:19:55:* 00:19:07:*
00:19:AA:* 00:19:A9:*
00:19:E7:* 00:19:A9:*
00:19:E8:* 00:19:A9:*
00:1A:2F:* 00:19:A9:*
00:1A:6C:* 00:1A:30:*
00:1A:6D:* 00:1A:30:*
00:1A:A1:* 00:1A:30:*
00:1A:A2:* 00:1A:30:*
00:1A:E2:* 00:1A:E3:*

AIR-AP1121G-A-K9 eth: PowerPCElvis Ethernet 00.11.5c Rf: 00.11.21
AIR-AP1121G-A-K9 eth: PowerPCElvis Ethernet 00.11.5c Rf: 00.11.5c
AIR-AP1121G-A-K9 eth: PowerPCElvis Ethernet 00.11.bb Rf: 00.11.5c
AIR-AP1121G-A-K9 eth: PowerPCElvis Ethernet 00.12.00 Rf: 00.12.43
AIR-AP1121G-A-K9 eth: PowerPCElvis Ethernet 00.12.01 Rf: 00.12.01
AIR-AP1231G-A-K9 eth: PowerPC405GP Ethernet 00.12.7f Rf: 00.12.7f Rf: 00.12.d9
AIR-AP1232AG-A-K9 eth: PowerPC405GP Ethernet 00.13.c4 Rf: 00.13.c3 Rf: 00.13.7f
AIR-AP1232AG-A-K9 eth: PowerPC405GP Ethernet 00.13.c4 Rf: 00.13.c4 Rf: 00.13.7f
AIR-AP350-IOS-UPGRD eth: PQUICC_FEC 00.40.96 Rf: 00.07.0e
AIR-AP350-IOS-UPGRD eth: PQUICC_FEC 00.40.96 Rf: 00.09.7c
AIR-AP350-IOS-UPGRD eth: PQUICC_FEC 00.40.96 Rf: 00.0a.41
AIR-AP350-IOS-UPGRD eth: PQUICC_FEC 00.40.96 Rf: 00.0a.8a
AIR-AP350-IOS-UPGRD eth: PQUICC_FEC 00.40.96 Rf: 00.0a.b7
AIR-AP350-IOS-UPGRD eth: PQUICC_FEC 00.40.96 Rf: 00.0a.f4
AIR-AP350-IOS-UPGRD eth: PQUICC_FEC 00.40.96 Rf: 00.40.96

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.

Wired rogue

Similar Messages

Maybe you are looking for