ISE Fail Close prevents DHCP after successful 802.1x authentication

[aatahraoui]

Hi

We are using ISE 2.7 and are using enforcement (closed) mode at our main office. It is working fine on all our switch C2960X-UNIVERSALK9-M), Version 15.2(2)E

For some reason the endpoints are stuck with 169.254.x.x IP. This is after the the 802.1x authentication has passed. When I revert ISE to monitor mode for those switches, it does not fix the problem. The PCs are still not able to get an IP, not after a reboot of the PC or defaulting the port config. The trigger for this issue is ISE going into closed mode. What could the issue be?

This is all with some Windows 10 Machines.

[MHM Cisco World]

change the mode from closed to low impact mode.

[aatahraoui]

There is only two option Closed Mode and OPEN Mode (YES/NO)

[Greg Gibbs]

Low Impact Mode is a way of configuring the switch and ISE to permit some traffic prior to authentication/authorisation completing. See the ISE Secure Wired Access Prescriptive Deployment Guide for more details.

The comments "When I revert ISE to monitor mode for those switches, it does not fix the problem. The PCs are still not able to get an IP, not after a reboot of the PC or defaulting the port config." are very suspicious. If the PC still does not get an IP address from DHCP with Monitor Mode enabled or the removing the NAC config completely, something else is wrong.
You might need to look at your 'dhcp snooping' and 'dhcp snooping trust' configuration on this switch as well as the upstream switch(es) and start doing packet captures along the path.

[aatahraoui · Accepted solution]

Thank you Greg, indeed it seems that's related to DHCP in the switch, the switch keep the APIPA IP address in its cache , the issue is fixed after the switch restart, but we still cannot figure out the good DHCP config to try.

We use IP DHCP SNOOPING TRUST for TRUCK Interfaces (DHCP server is set in Core Switch) and all access interface are configured with ip dhcp snooping limit rate 10

[andrewswanson]

Does the bug CSCui35423 "DHCP bindings are not happening at first try" match what you are seeing?

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCui35423

Release notes below for 2960x shows it was resolved with 15.2(2)E3

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15-2_2_e/release_notes/OL-32568.html

hth
Andy

[aatahraoui]

Thanks Andew for this sharing, but not sure if it's the root cause as we have the good version of Cisco IOS  Version 15.2(2)E7