topic Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS in Network Access Control

ISE Profilling - LLDP device-sensor cache updates using RADIUS

ajtm — Sat, 13 Jul 2019 21:35:28 GMT

Trying to use logical profile based on LLDP system-capabilities information in authorization rule but it doesn't work because information is only transmitted to ISE in RADIUS Attribute Value Pair inside accounting request, and the accounting only happens after an RADIUS access-accept.

The only way I can workaround this issue for now is using a rule with temporary access so it can triggers the RADIUS accounting packet to transmit the LLDP cache information to ISE.

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

hslai — Sat, 13 Jul 2019 23:30:41 GMT

Yes, this is how profiling works in general, but not specific to device-sensor or LLDP. See Access Policy and Device Configuration Impact on Profiling

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

ajtm — Sun, 14 Jul 2019 09:34:52 GMT

I understand the concept of allowing some traffic if we use, for instance, DHCP probes.

But, in this case we have the profiling information available the moment we connect the device (phone) - I can see it in the LLDP cache. It would be nice if we could transmit the information in the RADIUS access request...

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

Mohammed al Baqari — Sun, 14 Jul 2019 16:17:59 GMT

With device sensor I don't think this will work because as you said radius
accounting will be sent only after access-request. If you use SNMP polling
in ISE as a probe then you might get it working because SNMP polling can
take place independently from access-request.

**** remember to rate useful posts

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

ajtm — Sun, 14 Jul 2019 19:13:59 GMT

I have snmp trap mac notification configured and I can see snmp traffic between NAD and PSN but information is not being updated!

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

Parag Mahajan — Sun, 14 Jul 2019 20:55:27 GMT

your approach is correct. We also use same solution. temporarry access - DNS, DHCP and ISE access

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

Mohammed al Baqari — Mon, 15 Jul 2019 02:55:59 GMT

Agreed but if you use SNMP query probe then the switch can send CDP info in
the SNMP response which might speed the profiling process compared to
radius accounting packet which has to wait till access-request is sent.

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

ajtm — Mon, 15 Jul 2019 10:24:44 GMT

I can see SNMP traffic when I connect the phone (trap and then query) but I'm unable to decode what information is being transmitted to ISE.

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

ajtm — Mon, 15 Jul 2019 10:29:27 GMT

Yes, DHCP probe works fine but I was trying to avoid temporary access. LLDP cache info should be transmitted in SNMP when the device is connected. MAC move/Link trap and then SNMP query. I can see SNMP traffic but not able to understand what information is being transmitted.

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

hslai — Mon, 15 Jul 2019 14:18:38 GMT

With the profiling component in DEBUG, we may check profiler.log for details of ISE profiling.

Even with SNMP probe, the endpoint needs online for ISE to gather data. The SNMP query triggered by SNMP trap will check whether the endpoint has an active session in ISE. The periodic SNMP queries to the NADs may gather endpoints based on ARP cache and other info such as CDP or LLDP, regardless of active sessions.

Back to device-sensor, IBNS 2 may allow endpoint access locally without auth against ISE in order to send profiling data.

policy-map type control subscriber dsensor-updates
 event session-started match-all
  10 class always do-until-failure
  10 authorize

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

Damien Miller — Mon, 15 Jul 2019 14:22:45 GMT

Is that true even if one was to add "access-session monitor" to the global config? Maybe I misunderstood the command.

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

hslai — Mon, 15 Jul 2019 16:47:28 GMT

AFAIK IBNS 2 is not sending the device-sensor data via RADIUS accounting interim updates unless the endpoints authorized, either locally or by ISE.

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

ajtm — Mon, 15 Jul 2019 17:53:07 GMT

I've just realized that profiling is working fine for Cisco Phones but not for Alcatel Phones.

Cisco Phones are initially identified as Cisco_Devices and subsequently identified as Cisco-IP-Phone-xxxx

But Alcatel Phones stay classified as Alcatel_Devices (OUI policy)

In profiler.log I can see:

On Cisco Phones: CDP and LLDP Attributes, provided by RADIUS Probe

On Alcatel Phones: OUI provided by SNMPTrap Probe

In packet captures in Cisco Phones I can see two RADIUS access-rejects and then one access-accept. This packet includes AVP profile for Cisco-IP-Phone-xxxx

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

hslai — Tue, 16 Jul 2019 01:39:26 GMT

Great. You are getting closer.

If Alcatel phones not providing CDP/LLDP attributes to id them as phones, then we need either look for another attribute/pattern or whitelist them.

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

ajtm — Tue, 16 Jul 2019 08:48:12 GMT

I can see LLDP information of the Alcatel phone in the switch:

SW_POC_Torre_C#show device-sensor cache all
Device: 0080.9f57.640e on port GigabitEthernet1/0/17
--------------------------------------------------
Proto Type:Name Len Value
LLDP 127:organizationally-specific 23 FE 15 00 12 BB 0B 30 30 3A 38 30 3A 39 66 3A 35
37 3A 36 34 3A 30 65
LLDP 7:system-capabilities 6 0E 04 00 20 00 20
LLDP 0:end-of-lldpdu 2 00 00
LLDP 3:time-to-live 4 06 02 01 E0
LLDP 2:port-id 9 04 07 03 00 80 9F 57 64 0E
LLDP 1:chassis-id 9 02 07 04 00 80 9F 57 64 0E

This information is not being transmitted to ISE.

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

hslai — Wed, 17 Jul 2019 00:55:13 GMT

It might depend on the IOS-XE release or platform or ISE release. Also check the filter-list used for LLDP.

In discussing Device Sensor Filter Lists and MUD Profling, I found our teams tested it working with ISE 2.6 and IOS-XE 16.9.1 on 3850.

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

ajtm — Wed, 17 Jul 2019 23:12:23 GMT

No filter configured. I assume this means all the information should be transmitted to ISE. Is this correct?

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

hslai — Sat, 20 Jul 2019 19:56:25 GMT

Yes, I would have assumed so.

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

ajtm — Sun, 21 Jul 2019 17:26:22 GMT

Summing up:

1. The phone information is in the switch LLDP cache

2. No device-sensor filter-list lldp is configured (all the information is kept)

3. mac address-table notification change, mac address-table notification mac-move and snmp trap mac-notification are configured

4. snmp queries are enabled

It should work but it doesn't ...

Is there a way to understand what information is send on SNMP query response packets?

Re: ISE Profilling - LLDP device-sensor cache updates using RADIUS

hslai — Sun, 21 Jul 2019 22:29:43 GMT

Is there a way to understand what information is send on SNMP query response packets?

We should be able to see the info in the SNMP responses in the wired packet captured on SNMP traffic between the ISE PSN and the NAD, if using SNMP v1 or v2c.

In this particular use case that snmpQuery triggered by either snmpTrap or account start, there are some known issues -- CSCvm70858 and CSCuw50171. I think it best to get a Cisco TAC case open to help gathering debug data and/or recreate.