Wireless Access

I have a new installation of two controllers at a site where there was already a controller set up (these are two sets of master backup-master).  I have set up ip mobility between the two but I can not seem to get any raoming to happen correctly. one strange thing I see in the logs of the new controller is the following:

Apr  8 18:39:25  wms[3806]: <126049> <WARN> |wms| |ids| Cleared Suspect Rogue AP: A previously classified suspected rogue access point (BSSID ac:a3:1e:f4:b0:41, SSID externalhotspot84 on CHANNEL 1) is no longer considered suspected rogue or it was removed from the network. Additional Info: .
Apr  8 18:39:53  webui[3736]: USER:a0174504@172.22.158.17 COMMAND:<wms ap ac:a3:1e:fd:61:50 mode valid > -- command executed successfully
Apr  8 18:39:53  wms[3806]: <126049> <WARN> |wms| |ids| Cleared Suspect Rogue AP: A previously classified suspected rogue access point (BSSID ac:a3:1e:fd:61:50, SSID halekoa75 on CHANNEL 165) is no longer considered suspected rogue or it was removed from the network. Additional Info: .
Apr  8 18:40:01  webui[3736]: USER:a0174504@172.22.158.17 COMMAND:<wms ap ac:a3:1e:fd:5d:b0 mode valid > -- command executed successfully
Apr  8 18:40:01  wms[3806]: <126049> <WARN> |wms| |ids| Cleared Suspect Rogue AP: A previously classified suspected rogue access point (BSSID ac:a3:1e:fd:5d:b0, SSID halekoa75 on CHANNEL 36) is no longer considered suspected rogue or it was removed from the network. Additional Info: .
Apr  8 18:40:01  wms[3806]: <126075> <WARN> |wms| |ids| AP(40:e3:d6:54:9c:50@hrt2a013w): Valid Client Misassociation: An AP detected a misassociation between valid client 1c:e6:2b:a0:b2:8b and access point (BSSID ac:a3:1e:fd:5d:b1 and SSID externalhotspot84 on CHANNEL 36). Association type is (Association To Hosted AP), SNR of client is 0.
Apr  8 18:40:16  webui[3736]: USER:a0174504@172.22.158.17 COMMAND:<wms ap ac:a3:1e:f4:e8:e0 mode valid > -- command executed successfully
Apr  8 18:42:25  wms[3806]: <126065> <WARN> |wms| |ids| AP(40:e3:d6:54:7b:60@hrt2a012w): Valid Client Not Using Encryption: An AP detected an unencrypted frame between a valid client (24:da:9b:9a:41:8b) and access point (BSSID ac:a3:1e:f5:50:81), with source ac:a3:1e:f5:50:81 and receiver 24:da:9b:9a:41:8b. SNR value is 20.
Apr  8 18:42:25  wms[3806]: <126075> <WARN> |wms| |ids| AP(40:e3:d6:54:7b:60@hrt2a012w): Valid Client Misassociation: An AP detected a misassociation between valid client 24:da:9b:9a:41:8b and access point (BSSID ac:a3:1e:f5:50:81 and SSID externalhotspot84 on CHANNEL 11). Association type is (Association To External AP), SNR of client is 0.
Apr  8 18:42:25  wms[3806]: <126075> <WARN> |wms| |ids| AP(40:e3:d6:54:7b:60@hrt2a012w): Valid Client Misassociation: An AP detected a misassociation between valid client 24:da:9b:9a:41:8b and access point (BSSID ac:a3:1e:f5:50:81 and SSID externalhotspot84 on CHANNEL 11). Association type is (Association To Honeypot AP), SNR of client is 0.
Apr  8 18:42:25  wms[3806]: <126075> <WARN> |wms| |ids| AP(40:e3:d6:54:7b:60@hrt2a012w): Valid Client Misassociation: An AP detected a misassociation between valid client 24:da:9b:9a:41:8b and access point (BSSID ac:a3:1e:f5:50:81 and SSID externalhotspot84 on CHANNEL 11). Association type is (Association To Hosted AP), SNR of client is 0.
Apr  8 18:49:06  wms[3806]: <126005> <WARN> |wms| |ids| Interfering AP: The system classified an access point (BSSID ac:a3:1e:f5:48:e2 and SSID murrawolka on CHANNEL 1) as interfering. Additional Info: Detector-AP-Name:hrt2a011w; Detector-AP-MAC:40:e3:d6:54:81:00; Detector-AP-Radio:2.
Apr  8 18:49:18  sapd[3222]: <404074> <WARN> |AP hrt2a012w@172.18.139.58 sapd|  AM 40:e3:d6:54:7b:70: ARM - increasing power cov-index 4/0 tx-power 4 new_rra 157/5
Apr  8 18:53:09  webui[3736]: USER:a0174504@172.22.158.17 COMMAND:<wms ap ac:a3:1e:f5:52:91 mode valid > -- command executed successfully
Apr  8 18:53:09  wms[3806]: <126049> <WARN> |wms| |ids| Cleared Suspect Rogue AP: A previously classified suspected rogue access point (BSSID ac:a3:1e:f5:52:91, SSID externalhotspot84 on CHANNEL 48) is no longer considered suspected rogue or it was removed from the network. Additional Info: .
Apr  8 18:53:09  wms[3806]: <126075> <WARN> |wms| |ids| AP(40:e3:d6:54:81:70@hrt2a014w): Valid Client Misassociation: An AP detected a misassociation between valid client 68:d9:3c:17:07:b4 and access point (BSSID ac:a3:1e:f5:52:91 and SSID externalhotspot84 on CHANNEL 48). Association type is (Association To Hosted AP), SNR of client is 0.

 

 

I do not understand why there is mis asociation messages showing up here as these are ap's from the other controller that is set up with ip mobility.

 

any suggestions of things to look at?  I have the follwoing displays:

 

(ortamc01w) #show ip mobile active-domains

Active Mobility Domain(s) Total: 1
----------------------------------
Domain name                       Status
------------                      ------
default

(ortamc01w) #show ip mobile domain

Mobility Domains: 1 domain(s)
-----------------------------

Domain name default
   Home Agent Table
   Home Agent      Description
   --------------- ----------------
   172.18.160.14   fab 1
   172.18.160.15   fab 2
   172.25.160.7    admin 1
   172.25.160.8    admin 2

(ortamc01w) #show ip mobile tunnel

Mobile Tunnels: 3 tunnel(s)
---------------------------
Tunnel id 60, datapath port 65596 (1003Ch)
   src 172.25.160.7, dest 172.18.160.14
   encap L2-GRE, mode reverse-allowed, tunnel-users: 0
   tunnel-reference count: 2
Tunnel id 61, datapath port 65597 (1003Dh)
   src 172.25.160.7, dest 172.18.160.15
   encap L2-GRE, mode reverse-allowed, tunnel-users: 0
   tunnel-reference count: 2
Tunnel id 59, datapath port 65595 (1003Bh)
   src 172.25.160.7, dest 172.25.160.8
   encap L2-GRE, mode reverse-allowed, tunnel-users: 0
   tunnel-reference count: 2

 

 

second controller:

(ORFAMC01W) #show ip mobile tunnel

Mobile Tunnels: 3 tunnel(s)
---------------------------
Tunnel id 125, datapath port 65661 (1007Dh)
src 172.18.160.14, dest 172.18.160.15
encap L2-GRE, mode reverse-allowed, tunnel-users: 0
tunnel-reference count: 1
Tunnel id 1290, datapath port 66826 (1050Ah)
src 172.18.160.14, dest 172.25.160.7
encap L2-GRE, mode reverse-allowed, tunnel-users: 0
tunnel-reference count: 1
Tunnel id 126, datapath port 65662 (1007Eh)
src 172.18.160.14, dest 172.25.160.8
encap L2-GRE, mode reverse-allowed, tunnel-users: 0
tunnel-reference count: 1

(ORFAMC01W) #show ip mobile domain

Mobility Domains: 1 domain(s)
-----------------------------

Domain name default
Home Agent Table
Home Agent Description
--------------- ----------------
172.18.160.14 fab 1
172.18.160.15 fab 2
172.25.160.7 admin 1
172.25.160.8 admin 2

(ORFAMC01W) #show ip mobile active-domains

Active Mobility Domain(s) Total: 1
----------------------------------
Domain name Status
------------ ------
default

 

 

 

Valid Client Misassociation only shows up because you have a client that has used encryption on a controller, associating on another foreign WLAN device within earshot of the first.  It is typically used in secure facilities when you want to be notified when your encrypted users associate with foreign access points.  You can remove this message by unchecking "Detect Valid Client Misassociation" in your IDS profile under IDS Unauthorized Device.  This will only generate tons of messages when you are attempting to use ip mobility between controllers that are not part of the master/local cluster.  The second message "Valid Client Not using Encryption" is also used in high security environments when you want to make sure that your enterprise clients are using encryption.  Any time a device that has used encryption in your environment roams to an access point that is NOT in your master/local cluster and it is not using encryption, this message will be triggered, unless you uncheck "Detect Unencrypted Valid Clients".  Even when using ip mobility, access points from a controller not in the same master/local cluster are seen as foreign.  The only way to avoid the message is to uncheck the boxes, or make those two added controllers locals to the first master, instead of two controllers in their individual master/local cluster:

With regards to ipmobility, it is considered as a last resort, because it makes troubleshooting so difficult.  Is there any way you can extend the existing VLANs to the new controllers, so that users end up in the same layer 2 vlans?  ip mobility should work in your situation, but it requires debugging on both controllers to determine what is going wrong...

extending the vlans is not an option.  we are attempting to isolate the two sites so that anything done on one dosen't effect the other,  two buildings next to each other and we want to allow roaming between the two but can not extend the subnets between them.

You are trying to isolate sites, but allow roaming... What kind of isolation do you mean if devices can roam...?

one is an admin building, the other is a manufacturing building,  they are set up  as two seperate sites, i.e. routging only between them no layer 2 connections.  there is a bridge between the two so if you move from one bulding to the other you you will stay connected.  

but any issue (layer 2 wise) will not have any impact to the other building or if we want to take down any of the devices in the admin building it will not effect any connections in the manufacturing building, but yet customers will not have to loos connections when the roam from building to building.

So, I would type "show ip mobile host", "show ip mobile binding" and "show ip mobile visitor" to see what clients might have roamed to each controller..

 

(Aruba7240) #show ip mobile host

Mobile Host List, 1 host(s)
---------------------------
34:77:03:9e:dc:4c
  IPv4: 192.168.1.10
  Roaming Status: Mobile IP Visitor, Service time 0 days 00:03:33
  Home VLAN 100, visiting local VLAN 110

You should also turn on logging for mobileip on each controller:

 

Config t
logging level debugging network process mobileip
logging level debugging user process mobileip

show log network all
show log user all