Wireless Access

last person joined: 4 hours ago 

Access network design for branch, remote, outdoor and campus locations with Aruba access points, and mobility controllers.
Expand all | Collapse all

AOS8 whitelist sync

Jump to Best Answer
  • 1.  AOS8 whitelist sync

    Posted Aug 13, 2019 10:40 AM

    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.



  • 2.  RE: AOS8 whitelist sync

    Posted Aug 13, 2019 12:07 PM

    Are you manually whitelisting each access point?



  • 3.  RE: AOS8 whitelist sync

    Posted Aug 13, 2019 12:39 PM

    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). 



  • 4.  RE: AOS8 whitelist sync
    Best Answer

    Posted Aug 13, 2019 12:58 PM


  • 5.  RE: AOS8 whitelist sync

    Posted Aug 13, 2019 01:05 PM

    Thanks, I'll pass that on



  • 6.  RE: AOS8 whitelist sync

    Posted Oct 16, 2019 08:01 AM

    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

     

     

     

     



  • 7.  RE: AOS8 whitelist sync

    Posted Oct 16, 2019 06:49 PM

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

    - Please open a TAC case.



  • 8.  RE: AOS8 whitelist sync
    Best Answer

    Posted Oct 17, 2019 03:50 AM

    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