Aruba AP Profiling

[Damien Miller]

I ran in to very minor issue around profiling Aruba AP's and am looking to see if we can get this fixed at the source. ISE was not able to successfully profile an Aruba APIN0325 WAP because the MAC OUI was resolving to a different name than the Aruba parent policy is configured for.  So in short, the ArubaAP profile is nested under the Aruba-Device parent profile which doesn't get hit. It would be nice to see the profiler feed updated to address this.  

Parent profile: Aruba-Device
matches:  OUI CONTAINS ARUBA NETWORKS

Child profile: ArubaAP
matches: DHCP:dhcp-class-identifier EQUALS ArubaInstantAP OR DHCP:dhcpv6-vendor-class EQUALS ArubaInstantAP OR DHCP:dhcp-class-identifier EQUALS ArubaAP

The Aruba AP has a MAC address that begins with AC:A3:1E, and ISE is resolving this OUI as "Aruba, a Hewlett Packard Enterprise Company", not "Aruba Networks". The dhcp-class-identifier attribute is coming through correctly with ArubaAP, so when we make a slight adjustment to the parent profile, it then matches the child correctly.  

As a side discussion to this, I've seen this before with other products as well where the MAC OUI text changes and ISE no longer profiles it, is it normal for these to change?  

[Jason Kunst · Accepted solution]

Please open a tac case and defect for fix

[Damien Miller]

How often should the text of these change? Are we allowed to know where Cisco gets their OUI names?

[chyps · Accepted solution]

The IEEE maintains master OUI lists. These changes do happen from time to time such as here due to company mergers and acquisitions.  It happened about two years ago when many of the OUIs assigned to Apple were consolidated.  Consequently, many of the default ISE profiles based on original OUIs failed to match.  As you probably know, you can address using interim workaround by adding a custom condition to top-level Aruba-Device profile that matches on new OUI value (for example, STARTSWITH Aruba, or CONTAINS Aruba), but agree that ultimate fix would be via profile update. This is a case where you want to test Feed updates offline prior to production import/pull and why automated online feed can have unexpected/undesirable results. Ideally there would be a check for all OUI changes and determine if any impacted default Cisco provided profiles, thus necessitating profile update.