Wireless Access

Hi,

 

We have been experiencing random drops in connectivity for a whole site a couple of times a day.  I noticed in the logs that it is showing the tunnel is going down and up but not sure how further to troubleshoot what might be the cause - can any one help? Logs below:

Virtual Mobility Master running Aruba OS 8.2.2.5

 

(BIRMINGHAM-AT-2) #show log system all | include TUN

Aug  7 14:47:03  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_UP from IKE for default-local-master-ipsecmap mapid 0x44a1, vlanid 9, flags = 0x2 uplink_priority 0

Aug  8 10:14:55  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_DOWN from IKE for default-local-master-ipsecmap

Aug  8 10:15:01  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_UP from IKE for default-local-master-ipsecmap mapid 0x44a1, vlanid 9, flags = 0x2 uplink_priority 0

Aug  9 08:50:52  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_DOWN from IKE for default-local-master-ipsecmap

Aug  9 08:50:59  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_UP from IKE for default-local-master-ipsecmap mapid 0x44a1, vlanid 9, flags = 0x2 uplink_priority 0

Aug  9 09:51:06  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_DOWN from IKE for default-local-master-ipsecmap

Aug  9 09:51:11  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_UP from IKE for default-local-master-ipsecmap mapid 0x44a1, vlanid 9, flags = 0x2 uplink_priority 0

Aug 11 04:55:55  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_DOWN from IKE for default-local-master-ipsecmap

Aug 11 04:56:18  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_UP from IKE for default-local-master-ipsecmap mapid 0x44a1, vlanid 9, flags = 0x2 uplink_priority 0

Aug 12 03:09:04  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_DOWN from IKE for default-local-master-ipsecmap

Aug 12 03:09:21  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_UP from IKE for default-local-master-ipsecmap mapid 0x44a1, vlanid 9, flags = 0x2 uplink_priority 0

Aug 13 08:51:36  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_DOWN from IKE for default-local-master-ipsecmap

Aug 13 08:51:53  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_UP from IKE for default-local-master-ipsecmap mapid 0x44a1, vlanid 9, flags = 0x2 uplink_priority 0

Aug 13 14:19:38  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_DOWN from IKE for default-local-master-ipsecmap

Aug 13 14:20:01  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_UP from IKE for default-local-master-ipsecmap mapid 0x44a1, vlanid 9, flags = 0x2 uplink_priority 0

Aug 14 08:04:09  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_DOWN from IKE for default-local-master-ipsecmap

Aug 14 08:04:33  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_UP from IKE for default-local-master-ipsecmap mapid 0x44a1, vlanid 9, flags = 0x2 uplink_priority 0

Aug 14 11:01:01  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_DOWN from IKE for default-local-master-ipsecmap

Aug 14 11:01:24  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_UP from IKE for default-local-master-ipsecmap mapid 0x44a1, vlanid 9, flags = 0x2 uplink_priority 0

Aug 14 11:06:37  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_DOWN from IKE for default-local-master-ipsecmap

Aug 14 11:07:06  fpapps[3457]: <399838> <3460> <WARN> |fpapps|  Received TUN_UP from IKE for default-local-master-ipsecmap mapid 0x44a1, vlanid 9, flags = 0x2 uplink_priority 0

On the master, type "show master-local stats" to see if any heartbeats are indeed being dropped between the master and the MDs.

On the active controller on that site?&nbsp;
&nbsp;

Last drop was around noon today.  I would do a "clear master-local stats" to reset the counters and see how they grow in the next 24 hours.

 

MDs (controllers) do not need persistent connectivity with the MM.

Clear master local stats on the controller itself or on the mobility master?
&nbsp;
Also do you think maybe this is just showing the connection goes down between the controller and the MM - but that something else is causing the drop to the whole site as well as causing the issue with the communication to MM?
&nbsp;
Is there anything else i should be checking for in the logs ? I noticed this:

Just the controller, for now.

 

I would type "show log system 50" and see if there are any AP bootstraps.  If those APs are at the same site, and they have bootstraps, you have a local issue.

 

 

OK i have cleared the master-local stats

 

I did a show log system 50 but no AP boot straps

 

It is all the Aps and controllers on one site however that have the issue - happened again at 16:35 last night

Removed due to content

Is this a Virtual Machine?  I also saw a log before that said you are running this controller at 90% capacity, which is not advised (EDIT: 80% is the typical advice in a large network).

 

If this is important and you want this resolved quickly, you should open a TAC case.  There could be a number of things at play, here.

Mobility Master is running on Virtual Machines

The Mobility Devices are on site and 7005 Aruba Controllers 2 of them terminatiing only 10 APS and also around 200 clients - should be sufficient from my calculations 

I think the usage you are referring to is the 90% AP usage set in the threshold list: Aug 14 11:01:46 :399838:  <3556> <WARN> |stm|  Resource 'Total APs' has exceeded  80%  threshold (actual:90%).

How do I check the usage or capacity of the device?

I don't think running at 90% numerically has anything to do with the performance.  It is just in the log.  I would have TAC take a look at your setup so that you can see if you even have an issue.

Hi,

So it seems there maybe an issue with our spanning tree settings which is causing a network topology change thus dropping the site in the process: 

 

show spanning-tree:

 

 

Spanning Tree is executing the IEEE compatible Rapid Spanning Tree protocol
Bridge Identifier has priority 4096, address 20:4c:03:19:c5:b4
Configured hello time 2, max age 20, forward delay 15
We are the root of the spanning tree
Topology change flag is not set , detected flag not set , changes 96
Times: hold 1, topology change 35 hello 2, max age 20, forward delay 15
Timers: hello 0, notification 0
Last topology change: 0 days, 1 hour, 5 mins, 33 secs

So my question now is:

 

 

Can the Airgroup service function (i.e. discover devices) whilst spanning-tree is disabled on the controller?

 

We are in a situation where we only have spanning-tree enabled because we need multicast and broadcast traffic to be picked up by the controller.

 

I have read on the other threads in these forums that the controller will detect multicast on a trunked VLAN. Currently our ports on the wireless controllers are acting as 'access' ports.

 

Would switching these to ‘trunk’ ports, with spanning-tree disabled still enable Airgroup to function correctly?

 

Do you have your controllers dual-connected to the infrastructure?  If yes, you should disable spanning tree globally on the controller, and allow the infrastructure to handle spanning tree.  If no, still disable spanning tree and allow the infrastructure to handle it.

We are all for disabling spanning tree but we just need to know that the AirGroup discovery is going to work with spanning tree disabled?

 

Would switching these to ‘trunk’ ports, with spanning-tree disabled still enable Airgroup to function correctly?

Thanks

Unrelated to Airgroup.

So can we disable spanning tree globally and AirGroup will still function with our current setup which is two access ports for two separate VLANs 9 and 12?

How are you using spanning tree?

Currently re-configuring our spanning tree setup and wanting to remove it from the controllers.

 

The only question we are now wondering about is does AirGroup functionality work the same through access ports? As this is how our current ports are configured.

 

Thanks

Unrelated.

So the AirGroup feature would work regardless of the configuration of the ports (access/trunk) and with no spanning tree configured on the controllers themselves?

Feel free to consult with others.  The topic is about random drops on a site, and not airgroup, really.

True but the drops on the site appear to be from having an incorrect understanding of how spanning tree should be configured on controllers all based on the fact we thought we needed to have spanning tree settings applied to allow AirGroup to function correctly.  Appreciate all your help with this and hopefully we can now get to the bottom of the site dropping connectivity :) 

Please ask the person who suggested spanning tree is needed for airgroup why. Maybe there is a misunderstanding.