I configured IOS device-sensor on one 2960CG-8-TCL switch. IOS is 15.2(2)E.
device-sensor filter-list dhcp list dhcp-list option name host-name device-sensor filter-spec dhcp include list dhcp-list device-sensor accounting device-sensor notify all-changes
Switch does DHCP-Snooping and "show device-sensor cache all" shows the DHCP name:
Device: b2b5.2fff.sa43 on port GigabitEthernet0/1 -------------------------------------------------- Proto Type:Name Len Value DHCP 12:host-name 17 0C 0F 11 31 22 41 50 43 33 31 32 30 30 30 37 38 38
RADIUS probe on ISE is activated and TCPdump shows the accounting packets from the switch (see attachment).
I configured a profiling rule ot check for DHCP-Hostname with "contains". This rule does not work however. The device is getting profiled with a MAC-OUI via RADIUS-probe but the DHCP-Profile is not working.
Here are the screenshot of the profile. It just checks if the dhcp hostname contains "615APC615".
I can see on the authenticator switch in the device-sensor cache that the hostname does contain this. I also see the accounting packtes in the tcpdump on the ise. So they are sent and are beeing received by the ise.
The Radius probe is active and it is working. It does profile the mac address of the client via radius probe and uses the profile "HP-Device" because of the OUI. I don't the see dhcp hostname in the endpoint details however. I think it should be there so that the profiler can use it.
I have another device-sensor using cdp which also does not work. It sends the cdp platform-type and device name. I also see those packets beeing received by the ise. The values are there in the VSA's. The switch (authenticated via MD5 and NEAT) is not profiled however.
Setting the certainty level higher does not help. I think this is not the problem.
The problem is that ISE does not show the values that are beeing sent by device sensor. Look at the attached screenshots. The endpoint details should show all information that is known about the endpoint which is derived from all available probes. There is no dhcp hostname!
Also the profiling does work which can be seen in the endpoint profiling details. There you see that it hits the HP-Device profile because of the OUI derived from the Radius probe. But the hostname filed is empty. There should be the value that is sent by the switch. The switch has it in it's device-sensor cache and it is sent and received by ise as shown in the first screenshot in the first post. The pcap shows the values send by the switch. They are there. But ISE does not take them. If they did show up and the profile did not hit it could b a problem of the profile rule but the values arn't there in the first place.
That is interesting. I haven't worked with the "Device Sensor" much so I am running out of ideas. I really thought the certainty level was going to fix your issue as I have had issues similar like yours in the past where the certainty level of my custom rule was the same as a default one so mine custom rule was never hit. . I thought this was the case with you since your device was hitting the parent policy of "HP-Device" but not moving any further. With that being l would still recommend keeping your custom conditions with higher certainty levels to avoid such situations.
Couple of more things:
1. What profiling probes do you have enabled?
2. Have you tried retrieving the DHCP hostname via another sensor/method. For example, via the DHCP probe and ip-helper?
3. Do you have the following commands entered on your switch:
access-session template monitor
no macro auto monitor
device-sensor notify all-changes
Does anyone have a list of the common CDP, lldp and dhcp TLV's/Option values to send to ISE, the device sensor like all things is a bunch of screws and nails and painstaking research has to be done with each TLV value to know which to send to ISE, incredible!
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...