Keep Cisco ISE's OUI database current without the cloud feed service

Cisco Identity Services Engine profiles every endpoint that hits the network using a mix of signals: DHCP fingerprints, HTTP user agents, SNMP, and, near the bottom of that stack but still load-bearing, the MAC address's organizationally unique identifier. ISE ships with an OUI snapshot baked into each release and can pull incremental updates from Cisco's cloud through the Profiler Feed Service. Two situations break that pipeline:

• The ISE nodes have no outbound path to Cisco's feed servers, the normal state of affairs in segmented, air-gapped, or otherwise locked-down networks: OT/ICS, government, anything behind a proxy the feed service doesn't like.
• The feed service is reachable but simply hasn't caught up. IEEE assigns new OUI blocks continuously, and Cisco's feed refresh has its own cadence with no guarantee the two line up on any given day.

Either way, the fix is the same: feed ISE a current OUI file directly.

What ISE expects

ISE's profiler OUI updates use a specific schema: a MacAddressVendorMappings root element containing one VendorMapping per OUI, each with a mac_prefix and vendor_name attribute. That's exactly what our Cisco vendorMacs.xml download produces, rebuilt from IEEE's live registry twice a day instead of snapshotted once and left to drift.

<MacAddressVendorMappings xmlns="http://www.cisco.com/server/spt">
  <VendorMapping mac_prefix="00:00:0C" vendor_name="CISCO SYSTEMS, INC."/>
  ...
</MacAddressVendorMappings>

One limitation carries over from the schema itself: mac_prefix only has room for three octets, a /24. IEEE also assigns smaller /28 and /36 blocks (MA-M, MA-S, IAB, CID) that share their top three octets with other organizations, so there's no honest way to represent them in this format without misattributing a shared prefix to whichever vendor happened to sort last. The file sticks to /24 (MA-L) blocks, which is what the format was built for. If you need the smaller allocations too, our CSV and JSON downloads carry the full list.

Loading it into ISE

1. Download the current file from macadress.com/downloads (direct link: cisco-vendor-macs.xml).
2. In the ISE admin console, open the profiler feed screen. Depending on your version this sits under Administration > Feed Service or, on newer releases, Work Centers > Profiler > Feeds; the menu has moved around across the 2.x and 3.x lines, but every version keeps an offline or manual update option alongside the "update from Cisco" one.
3. Choose the offline update path and upload the file. ISE parses it the same way it parses Cisco's own feed, since it's the same schema.
4. Confirm the import: ISE reports how many mappings it loaded, which should be in the tens of thousands and roughly match the block count shown on our downloads page.
5. If ISE already profiled endpoints under the old data, consider re-running profiling on the affected identity groups so previously seen devices pick up the corrected vendor, rather than waiting for their next full re-profile.

Keeping it current

This file rebuilds from IEEE's registries automatically, twice a day, so there's always a fresh one waiting. Air-gapped environments are the common case here: script a periodic transfer across whatever one-way path your network allows (removable media, a data diode, a scheduled export from a jump host with outbound access) and re-run the offline import on whatever cadence fits your change window. No API key or account is needed to fetch it.

Building something that needs a live, per-address answer instead of a periodic bulk file, onboarding automation that resolves a MAC the moment it shows up, for instance? The free JSON API is built for that.