cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7147
Views
4
Helpful
14
Replies

ISE 2.3, C3PL, and DHCP profiling

Joseph Johnson
Level 1
Level 1

I am starting a deployment using the following:

  • Cisco ISE 2.3 with Patch 1 (updated patch)
  • Cisco 3850 with 03.07.05E
    • C3PL is enabled

Device sensors are being used on the switch for profiling. Only HTTP, RADIUS, and Active Directory profiling is enabled on the PSNs. The device sensor configuration is as follows:

ip dhcp snooping

ip dhcp snooping vlan [comma-separated list of VLANs]


device-sensor filter-list dhcp list dhcp_list

option name host-name

option name requested-address

option name parameter-request-list

option name class-identifier

option name client-identifier

device-sensor filter-spec dhcp include list dhcp_list

cdp run

device-sensor filter-list cdp list cdp_list

tlv name device-name

tlv name address-type

tlv name capabilities-type

tlv name platform-type

device-sensor filter-spec cdp include list cdp_list

lldp run

device-sensor filter-list lldp list lldp_list

tlv name system-name

tlv name system-description

tlv name system-capabilities

device-sensor filter-spec lldp include list lldp_list

device-sensor notify all-changes

access-session attributes filter-list list sensor_list

cdp

lldp

dhcp

access-session accounting attributes filter-spec include list sensor_list


When I do a show device-sensor cache interface gi1/0/3 (Macbook Pro w/ OSX Sierra connected), I get the following details:

DHCP    12:host-name                   11 0C 09 42 72 61 64 73 2D 4D 42 50

DHCP    50:requested-address            6 32 04 0A 4A 6C 3A

DHCP    61:client-identifier            9 3D 07 01 98 5A EB CD B8 B5

DHCP    55:parameter-request-list      12 37 0A 01 79 03 06 0F 77 FC 5F 2C 2E


In the ISE Context Visibility > Endpoints list, the laptop only shows up as Apple-Device based on the MAC OU. Nothing is hitting on the Workstation profile list. I suspect it is because IP:User-Agent isn't being processed. The same issue happens with a Windows 7 laptop. It is only seen as a Microsoft-Device and never a Windows workstation (or the specific Windows version). When I click on the details of the endpoint in Context Visibility, I do see dhcp-parameter-request-list and dhcp-requested-address in the list of attributes received along with the endpoint source being RADIUS Probe.


This is not an issue with CDP profiling. The test IP phone, a Cisco 7961, is profiled correctly almost immediately.


Am I missing something in the device sensor configuration? I have used a similar (not exactly the same) device sensor config in other deployments but they were not using the new style authentication without C3PL enabled. One of the old styles was using the command no macro auto monitor to disable the local device analyzer but I didn't find a similar command for the new style configuration. Not sure if that can cause an issue.

1 Accepted Solution

Accepted Solutions

Points of clarification:

  • We do not use posture data for profiling today :-(
  • Counter to popular belief, HTTP probe does NOT need to be enabled to capture user agent data.  We auto capture user agent when client connects to ISE portal
  • DHCP PRL May contribute but may not see Class ID populated
  • HTTP in Device Sensor is only supported on wireless today unlesss there was some more recent IOS-XE or Polaris code release that changed that for wired clients on current switch platforms.

Again, actual endpoint details will reveal what is being captured and if opportunity to expand on profile based on available data, or detection of missing probe opportunities.  For example, AD probe is one of the best and simplest options for gathering detail Windows classification.


Craig

View solution in original post

14 Replies 14

Joseph Johnson
Level 1
Level 1

I just double checked the device sensor cache. For the port the IP phone is connected to, the cache is showing DHCP class identifier information (DHCP option 60). The port where the Macbook is connected is not showing DHCP class identifier information.

Not all Macbooks will populate Class ID and there is no default condition for Mac OS profile to match on DHCP options or Class ID.  For Windows, you should see Class ID = MSFT and that would match the Windows-Workstation profile.  If not seeing that, then requires further investigation.  A screenshot of endpoint attributes for Windows WS would be helpful.

Craig

The Mac OS profile includes IP:User-Agent. That info is found in the class identifier. Not sure why it's not showing up in this one, though. I've used the same laptop in other deployments and it profiled properly. I could test doing DHCP profiling but I doubt it will work since option 60 doesn't appear to be populating.

I'll test another Windows laptop ASAP and post the result.

That is not correct.  The user agent is extracted from HTTP data and we currently do not retrieve HTTP data for Wired connections via Device Sensor today--only wireless.  User Agent is very different than DHCP Class ID.  If think there is a difference in attributes, you can quickly tell difference by enabling DHCP probe on the PSN and adding an ip helper-address to the local gateway of the client which points to that same PSN.

/Craig

I guess I am confused on the way Mac OSX is profiled. I know I've profiled OSX machines in the past with just DHCP because they didn't go through any portal (guest, URL redirect, etc.) so HTTP wasn't utilized. I'll check into it further. I may just have to create a custom profile using the OUI and DHCP parameter request.

If you’re using network device sensor then you were likely to get http probes as well with that and better increase your profile accuracy

https://communities.cisco.com/docs/DOC-71879

Joseph,

The information we typically get to help profile Macs are OUI, User-agent and operating system.  If we just get the OUI, it will fall into the "Apple-Device" policy which will then kick off an OS NMAP scan of the endpoint where we learn the operating system.  That is for wired networks of course.  If wireless, WLCs with HTTP profiling enabled on the SSID will send the User-agent string and can profile it with only that information.

Regards,

-Tim

I wonder if there is any HTTP info coming from the way OSX checks for a captive portal on networks. I could enable the HTTP sensor and grab that if it exist. I'll test that out. I appreciate all the responses.

Edit: They don't want to enable NMAP on the limited number of PSNs they have so that probe is out at the moment. Would be helpful.

Are you doing posturing at all? If you're doing CPP, I would assume ISE could get the user-agent from that as well (Tim and co will correct me if I'm wrong)

Points of clarification:

  • We do not use posture data for profiling today :-(
  • Counter to popular belief, HTTP probe does NOT need to be enabled to capture user agent data.  We auto capture user agent when client connects to ISE portal
  • DHCP PRL May contribute but may not see Class ID populated
  • HTTP in Device Sensor is only supported on wireless today unlesss there was some more recent IOS-XE or Polaris code release that changed that for wired clients on current switch platforms.

Again, actual endpoint details will reveal what is being captured and if opportunity to expand on profile based on available data, or detection of missing probe opportunities.  For example, AD probe is one of the best and simplest options for gathering detail Windows classification.


Craig

Oh I meant profiling when the endpoint hits the CPP since that's technically an ISE portal when they initially connect