No LLDP profiling data without DHCP?

[Joseph Johnson]

I am trying to move to closed mode with ISE 2.1. The switches are running XE 3.6.4. Only the RADIUS probe is enabled in ISE because I am using device sensors on the switch. The issue I'm running into is that Avaya IP phones that use LLDP are not being profiled correctly once closed mode (no authentication open, no pre-auth ACL) is enabled. The phones are profiled correctly in low impact mode. In closed mode, the phones are profiled as Avaya-Device (top level profile) based on the MAC OUI but that's where it stops. It does not get reprofiled as Avaya-IP-Phone (child profile) based on the LLDP information.

Port config:

switchport mode access
authentication event fail action next-method
authentication event server dead action authorize
authentication event server dead action authorize voice
authentication event server alive action reinitialize
authentication host-mode multi-domain
authentication control-direction in
mab
authentication violation restrict
authentication periodic
authentication timer reauthenticate server
authentication timer inactivity server dynamic
dot1x timeout tx-period 5
spanning-tree portfast
authentication port-control auto

Device sensor config:

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 accounting
device-sensor notify all-changes
no macro auto monitor
access-session template monitor

I can look at the LLDP information on the switch and see the LLDP cache populating for the port.

The weird thing is that I can create an auth rule based on Avaya-Device to assign a dACL that allows DHCP only and it works properly. If I disable that rule, remove the phone from the endpoints list, and bounce the port, the phone will fail to be profiled as Avaya-IP-Phone. This leads me to believe that none of the LLDP info is being passed to ISE and DHCP info is not available without the DHCP rule or fail open config.

Is this expected behavior or could I be missing a configuration line?

[Gagandeep Singh]

Please provide show version of switch. Is the code a suggested release from CCO.

I have seen sometimes ISE doesn't get profiled. If I put switch on suggested release, it starts working.

http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/200292-Configure-Device-Sensor-for-ISE-Profilin.html

Please cross verify the confoguration from above document.

Regards

Gagan

PS: rate if it helps!!!!!

[Joseph Johnson]

The switch is running IOX XE 3.8.0 now and it still does not work properly. It's a weird issue that goes away if I allow DHCP (nothing else).

[Joseph Johnson]

Latest finding:

So it turns out I don't need to allow DHCP. If I change the default authorization rule from DenyAccess (ACCESS-REJECT) to a custom authorization profile that is ACCEPT-ACCEPT but pushes a dACL with "deny ip any any", device sensor data is received by ISE and the endpoint is profiled correctly.

This is really odd because none of the documentation I've found mentions having to set the default rule to anything other than DenyAccess for closed mode. We tested it several times. The results were always the same.

1. Default rule DenyAccess: No device sensor data received even though the switch shows cached sensor information on the port.
2. Default rule custom with ACCESS-ACCEPT and "deny ip any any" dACL: Device sensor data received.

Does the ACCESS-REJECT completely shut off sending the device sensor data to ISE?

Anyone see a problem with using ACCESS-ACCEPT profile with a deny all dACL as the default rule, as well as no open authentication on the port, and considering the installation "closed mode"?

[Gagandeep Singh]

Hi,

Yes, I have seen this behavior in case of deny access rule. In order to trigger that it needs radius accounting packet to receive on ISE which will only be triggered when you have limited access from ISE for initial authentication.

Let's take the below from one of the internal cases

In absence of Cisco-Device limited policy in the authorization policies, the cisco devices / Cisco-IP-Phone will not get profiled due to the reason that: Radius Accounting packets need to be triggered, which in turn trigger SNMP query to occur from the ISE node. ISE will only trigger SNMP query on the device that pass some level of authorization (with Radius Access-Accept) in the authorization policy. In this case the limited authorization can be defined with Cisco-Device.

During the first authentication and authorization attempt, the endpoint gets (IP phone) profiled to Cisco-Device authorization policy using the limited access policy and causes radius accounting start packet to trigger from the switch. A subsequent CoA is sent after ISE receives sufficient attributes to re-profile the phone. This is a security feature to only allow legitimate cisco-devices to trigger snmp as we do not want just about any devices to trigger SNMP query.

If the concern is about giving limited access with DACL in the Cisco-Device authorization policy, you can create a dummy dynamic VLAN as part of limited access instead of DACL. The Dummy vlan can be any private restricted vlan and the limited authorization profile need to have an Access-Accept to trigger the Radius-Accounting start. So, that the subsequent CoA will re-profile the phone.

regards

Gagan

ps : rate if it helps!!!!