Wireless Access

Hi,

 

I think I understand the reasons why whitelist sync might be intentionally disabled (if there are MCs that do not need the db replicated to them).

 

However it looks like we have it disabled (having just moved from 6.5 to 8.4.0.4). I think this must have been accidental as we had it enabled on 6.5, or is this defaulting to disabled because there is something fundamentally different in AOS8?

 

Is there any reason not to turn it back on in AOS8? Is this a setting you would normally recommend be enabled?

 

Our cluster design is 2 clusters of 8 MCs (one cluster acting as a back-up cluster, so only active if APs use their bkup-LMS). They are managed on different VLANs. Any member of the active cluster could terminate any AP.

Are you manually whitelisting each access point?

At the moment it is set to temporarily allow-all (an artefact of the migration to AOS8) but normally we use a central provisioning VLAN and just allow that subnet to auto-provision. The model we use is that we provision and group APs centrally (ie in our office), and then install APs, or send APs out to be installed by customers (colleges and depts). 

Ok.  Whitelist sync should be on by default.

 

Please see here:  https://www.arubanetworks.com/techdocs/ArubaOS_85_Web_Help/Content/arubaos-solutions/1cli-commands/dis-whtlist-sync.htm?Highlight=whitelist%20sync

Thanks, I'll pass that on

So I tried enabling whitelist sync using:

 

'no disable-whitelist-sync'

 

This seemed to have no effect. So I ran 'disable-whitelist-sync' (which had an effect even though the MM showed it as already disabled) and then ran 'no disable-whitelist-sync'. It now shows as enabled.

 

The sequence number now matches on all the MCs (apart from one - which is the cluster leader, is that relevant? It's actually showing a higher revision number than all, including the MM!).

 

But we are seeing a lot of this type of message in the controller logs (note - we were seeing these before I turned on sync, but I was hoping sync'ing would solve the issue). On each controller it seems to be a relatively small number of APs, and there's no sign that the AP operation is affected, but it seems odd and the messages are cluttering the logs. I did Google and there was some suggestion it might be APs trying to make S-AAC tunnels. If I look in the whitelist on the MM then the entry is certified-factory-cert as expected, but sure enough on the MC the whitelist entry shows as unapproved.

 

Oct 16 12:34:24 isakmpd[3612]: <103067> <3612> <ERRS> |ike| IKE XAuth failed as the AP xx:xx:xx:xx:xx:xx is not in whitelist
Oct 16 12:34:24 isakmpd[3612]: <103067> <3612> <ERRS> |ike| IKE XAuth failed as the AP xx:xx:xx:xx:xx:xx is not in whitelist
Oct 16 12:34:24 isakmpd[3612]: <103067> <3612> <ERRS> |ike| IKE XAuth failed as the AP xx:xx:xx:xx:xx:xx is not in whitelist
Oct 16 12:34:24 isakmpd[3612]: <103067> <3612> <ERRS> |ike| IKE XAuth failed as the AP xx:xx:xx:xx:xx:xx is not in whitelist
Oct 16 12:34:24 isakmpd[3612]: <103067> <3612> <ERRS> |ike| IKE XAuth failed as the AP xx:xx:xx:xx:xx:xx is not in whitelist
Oct 16 12:34:24 isakmpd[3612]: <103067> <3612> <ERRS> |ike| IKE XAuth failed as the AP xx:xx:xx:xx:xx:xx is not in whitelist
Oct 16 12:34:24 isakmpd[3612]: <103067> <3612> <ERRS> |ike| IKE XAuth failed as the AP xx:xx:xx:xx:xx:xx is not in whitelist
Oct 16 12:34:24 isakmpd[3612]: <103068> <3612> <ERRS> |ike| IKE XAuth failed as the AP xx:xx:xx:xx:xx:xx is not in approved-state in whitelist
Oct 16 12:34:24 isakmpd[3612]: <103068> <3612> <ERRS> |ike| IKE XAuth failed as the AP xx:xx:xx:xx:xx:xx is not in approved-state in whitelist
Oct 16 12:34:24 isakmpd[3612]: <103068> <3612> <ERRS> |ike| IKE XAuth failed as the AP xx:xx:xx:xx:xx:xx is not in approved-state in whitelist
Oct 16 12:34:24 isakmpd[3612]: <103068> <3612> <ERRS> |ike| IKE XAuth failed as the AP xx:xx:xx:xx:xx:xx is not in approved-state in whitelist
Oct 16 12:34:24 isakmpd[3612]: <103068> <3612> <ERRS> |ike| IKE XAuth failed as the AP xx:xx:xx:xx:xx:xx is not in approved-state in whitelist
Oct 16 12:34:24 isakmpd[3612]: <103068> <3612> <ERRS> |ike| IKE XAuth failed as the AP xx:xx:xx:xx:xx:xx is not in approved-state in whitelist
Oct 16 12:34:24 isakmpd[3612]: <103068> <3612> <ERRS> |ike| IKE XAuth failed as the AP xx:xx:xx:xx:xx:xx is not in approved-state in whitelist
Oct 16 12:34:24 isakmpd[3612]: <103103> <3612> <WARN> |ike| 172.xx.xx.118:4500-> IKE SA Deletion: IKE2_delSa peer:172.xx.xx.118:4500 id:2478864774 errcode:OK saflags:0x51 arflags:0xd
Oct 16 12:34:24 isakmpd[3612]: <103103> <3612> <WARN> |ike| 172.xx.xx.100:4500-> IKE SA Deletion: IKE2_delSa peer:172.xx.xx.100:4500 id:2478864771 errcode:OK saflags:0x51 arflags:0xd
Oct 16 12:34:24 isakmpd[3612]: <103103> <3612> <WARN> |ike| 172.xx.xx.27:4500-> IKE SA Deletion: IKE2_delSa peer:172.xx.xx.27:4500 id:2478864772 errcode:OK saflags:0x51 arflags:0xd
Oct 16 12:34:24 isakmpd[3612]: <103103> <3612> <WARN> |ike| 172.xx.xx.102:4500-> IKE SA Deletion: IKE2_delSa peer:172.xx.xx.102:4500 id:2478864770 errcode:OK saflags:0x51 arflags:0xd
Oct 16 12:34:24 isakmpd[3612]: <103103> <3612> <WARN> |ike| 172.xx.xx.126:4500-> IKE SA Deletion: IKE2_delSa peer:172.xx.xx.126:4500 id:2478864773 errcode:OK saflags:0x51 arflags:0xd
Oct 16 12:34:24 isakmpd[3612]: <103103> <3612> <WARN> |ike| 172.xx.xx.171:4500-> IKE SA Deletion: IKE2_delSa peer:172.xx.xx.171:4500 id:2478864775 errcode:OK saflags:0x51 arflags:0xd
Oct 16 12:34:24 isakmpd[3612]: <103103> <3612> <WARN> |ike| 172.xx.xx.172:4500-> IKE SA Deletion: IKE2_delSa peer:172.xx.xx.172:4500 id:2478864769 errcode:OK saflags:0x51 arflags:0xd

 

 

Can you shed any light?

 

Thank you,

Guy

 

 

 

 

- There is no reason to even touch the whitelist configuration sync parameter

- Please open a TAC case.

Morning Colin,

 

I/we had no intention of touching it until it became apparent that it was disabled! We're not sure how that happened, it must have been during the upgrade/migration process.

 

It looks like re-enabling it has had the desired effect - the sequence numbers now match (across all MCs except the cluster leader - I will ask TAC if that's normal). However there were still disparities - there were some APs showing as unapproved on the MCs that were showing as certified on the MM. So it seems that enabling sync didn't trigger a complete sync'ing of the existing entries - new entries do appear to be being sync'd though. So it was easy enough to run the commands on the MM to certify those APs and these changes were pushed down to the MCs successfully.

 

It sort of feels like purging the MC whitelist entries and starting again would be the cleanest solution, but I'm not about to do that on the live system!

 

Thanks for your help.

 

Guy

Hi Guy and Colin,

A customer noticed that when he changed the AP name in the whitelist on the MM, it did not propagate. I came across this post and checked the whitelist sync. It also turned out to be disabled. However, the disable-whitelist-sync parameter is not set (checked with show configuration effective on /mm and /mm/mynode).
I did this installation in 2018 and remember vaguely having issues with renaming APs. But we had to move fast, so we just deleted the whitelist and put in a new one to be able to move on. This was a greenfield Aruba install on version 8.2 (at the time, upgraded up to 8.5 in the time since past). I can't remember touching the sync setting, it's not in my notes and I was not even aware of it before I read this article...
Will ask the customer to toggle the setting and see what happens.

Regards,
Dante

------------------------------
Dante Klerkx
------------------------------

Original Message:
Sent: Oct 17, 2019 03:49 AM
From: Guy Goodrick
Subject: AOS8 whitelist sync

Morning Colin,

 

I/we had no intention of touching it until it became apparent that it was disabled! We're not sure how that happened, it must have been during the upgrade/migration process.

 

It looks like re-enabling it has had the desired effect - the sequence numbers now match (across all MCs except the cluster leader - I will ask TAC if that's normal). However there were still disparities - there were some APs showing as unapproved on the MCs that were showing as certified on the MM. So it seems that enabling sync didn't trigger a complete sync'ing of the existing entries - new entries do appear to be being sync'd though. So it was easy enough to run the commands on the MM to certify those APs and these changes were pushed down to the MCs successfully.

 

It sort of feels like purging the MC whitelist entries and starting again would be the cleanest solution, but I'm not about to do that on the live system!

 

Thanks for your help.

 

Guy