What's New in ISE 3.5 Profiling

Profiling is how ISE works out what an endpoint is. It collects attributes from probes and network devices — DHCP options, RADIUS data, CDP and LLDP, HTTP user agents — and matches them against policy to classify the device. That classification feeds authorization. An endpoint identified as an IP phone gets phone access. An endpoint ISE can't identify gets whatever you give unknowns.

ISE 3.5 changes profiling in two ways. First, it changes how endpoints get classified, with the biggest set of classification features in several releases. And second, it adds tooling to keep the profiling service itself healthy: a resiliency feature that protects PSNs from floods of profiling updates, and new dashboards that show what probe data ISE is actually receiving.

Our ISE 3.5 overview touched on some of this. This post goes further on the profiling side. 

Classification

Most of the classification changes build on MFC labels, which arrived in 3.3. Instead of assigning one profiling policy per endpoint, ISE assigns up to four independent labels: manufacturer, endpoint type, model, and OS. Each label can come from a different source. ISE might take the manufacturer from an OUI rule and the OS from an MDM. Authorization policy can match on any of the four.

3.5 changes how those labels get assigned.

Custom MFC profiling policies replace certainty factors with if/and/or logic. You pick from more than 170 attributes across the dictionaries ISE collects — DHCP, CDP, SNMP, MDM, posture, and more — build conditions, and choose which labels to assign. No weights. No scores. Policies sit in a ranked list, and the first match wins for each label.

Direct mapping policies skip conditions entirely. If an authoritative source already knows what a device is, ISE can take its word for it. The supported sources are MDM (Intune, Jamf, and other integrated MDMs), ISE posture, pxGrid integrations that publish to the IOTASSET dictionary, and ACIDex. Map the MDM's model attribute to the Model label, and every MDM-managed device gets its model from the MDM. One limit: CMDB data brought in through pxGrid Direct isn't a supported source.

The Cloud MFC profiler targets unknowns. ISE sends observed endpoint attributes — not user identity data — to Cisco's cloud, which matches them against thousands of real-world device fingerprints and returns labels. Results are cached for 30 days and reused for similar devices. Those labels apply immediately, with no admin review. They don't change your existing certainty-factor profiling policies; the cloud only assigns MFC labels. That's the difference from the AI/ML rule proposals introduced in 3.3, which suggest rules an admin has to accept. The Cloud MFC profiler needs a Cisco account and outbound HTTPS to Cisco's cloud, so air-gapped deployments can't use it.

SNMP scans reach devices that never talk to ISE. Printers, UPS units, and other infrastructure that doesn't authenticate have always been hard to profile. An SNMP scan queries a subnet or IP range on demand or on a schedule, over SNMP v1, v2c, or v3. The results land in the endpoint database and can drive MFC policies like any other attribute. SNMP also tells you more than what a device is. Fields like sysContact, sysName, and sysLocation can separate a corporate printer from the same model someone plugged in on their own. A single scan covers up to 2,046 endpoints.

All of these policies are managed from a new MFC Profiling Policies tab. It shows each policy's rank, type, assigned labels, and how many endpoints it has matched, which makes it easy to spot policies that never fire.

There's more to MFC than fits here — rule priority across sources, the attribute dictionaries available, and how to roll out new policies safely. We'll cover MFC in depth in a separate post.

Profiler resiliency

Classification is only as good as the profiler's ability to keep up. When it can't, ISE drops data. We covered the most visible symptom in our post on the Profiler Queue Size Limit Reached alarm: a full queue means discarded updates and endpoints stuck on stale profiles.

Profiler resiliency is ISE's answer. It's enabled by default in 3.5 and also available in the latest 3.4 patches. It watches three things, and each has its own response.

Endpoint traffic. ISE tracks update rates per endpoint. An endpoint that exceeds 30 endpoint updates, 15 Context Visibility updates, or 5 database updates per minute is marked chatty. ISE stops processing its probe data for a five-minute cool-off. One noisy device no longer drags down profiling for everyone else.

Queue size. At 80% full, the profiler stops processing interim updates and reclassification. From 90%, it processes only new endpoints. ISE sheds low-value work before the queue fills and starts dropping everything.

PSN load. ISE watches the node's High Load Average alarm. When it fires, the profiler suppresses interim updates and reclassification. That alarm is evaluated every 15 minutes, so the effective cool-off here runs longer than five minutes.

When a monitor triggers, ISE records it in its alarms and in the localStore logs. The thresholds, monitoring windows, and cool-off periods can be tuned through OpenAPI at /api/v1/profiler/resiliency/config — GET to read the current values, PUT to change them, within limits Cisco defines.

Resiliency is a safety net, not a fix. An endpoint in cool-off is still chatty. The cause is still upstream: a NIC problem, a reauthentication loop, a load balancer without persistence.

Probe dashboards

Resiliency handles too much probe data. The new probe dashboards also catch the opposite problem: too little.

Cisco's engineering team found that many deployments hadn't enabled enough probes to profile well. ISE can't classify what it can't see. Before 3.5, finding those gaps meant checking probe settings node by node and guessing at what each network device was sending.

3.5 adds four dashboards to System 360: Probe Status Summary, Probe packets, Probe Config Status, and Probe packets empty. They pull endpoint details from the endpoint cache on each PSN and aggregate them. Filtered by PSN group, PSN, or network device, they show:

• Which probes are enabled on each PSN
• How many network devices are communicating with a PSN, and how many have sent no probe data at all
• How many endpoints each probe has seen
• A per-device breakdown of probe traffic by type

That per-device view cuts both ways. A switch sending zero DHCP data points to a missing helper address or device sensor configuration. A switch sending far more than its peers shows where a flood is coming from — useful when resiliency starts marking endpoints chatty.

The dashboards live in System 360, which has to be enabled. If it isn't, check the performance impact on your deployment before turning it on.

Conclusion

ISE 3.5 works on profiling from both ends. MFC policies, direct mapping, the Cloud MFC profiler, and SNMP scans reduce the number of endpoints ISE can't identify. Resiliency and the probe dashboards keep the profiler healthy enough to do that work, and show you when it isn't.

Please get in touch if you have questions about profiling in your ISE deployment.

Sources

• Cisco Community, ISE Profiling Design Guide

• Cisco Community, Cisco ISE 3.5 Enhanced Profiling

• Cisco Community, Cisco ISE 3.5 Release Announcement

• Taylor Cook, "Supercharge Network Access: New Endpoint Profiling in ISE 3.5," Cisco Live, BRKSEC-1038
• Alex Bubnov, "ISE Profiling Architecture and Troubleshooting," Cisco TAC session, BRKSEC-3519