cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1008
Views
25
Helpful
5
Replies

Endpoints lose their IP address after reboots

davedvo
Level 1
Level 1

Hi Cisco ISE Community,

I have been struggling with trying to fix this problem for awhile, and wanted to see if anyone else has also had the same issue and found a fix for it. Most of the 802.1x endpoints with the Cisco Anyconnect Client and NAM module, have been working great with authenticating and authorizing with my ISE servers for over a year now. There are however, a small list of workstations that are unable to gain an IP address, after their daily reboots at about 3 AM. After an interface reboot, these endpoints come back online. The issue, does not affect endpoints that have the "authentication open" command configured on their access interfaces. My ISE version can patch level can be seen below:

 

Version: 3.1.0.518 Patch 2

I am looking to be able to remove them from low-impact mode, and place these endpoints having issues back onto full enforcement.

1 Accepted Solution

Accepted Solutions

davedvo
Level 1
Level 1

I found a workaround to the issue that might help other Cisco customers, that have the same problem. This starts with provisioning a Vlan assignment from my Cisco ISE PAN, to the interfaces connected to Windows workstations that are having the issue. This Vlan is set to the same one that the interface has originally been setup with using the switchport access vlan command. Before, I had my authorization policies just permit access for my users and for the workstations themselves after reboots, provided they had the correct machine certificate. Forcing a Vlan assignment using the ISE authentication profile common task, has provided me a workaround so far. This Vlan gets taken away once a user logs in, and they are given the permit access result. Strangely enough, most interfaces in my company do not require this extra Vlan assignment from ISE. This could indicate either a DCHP helper routing issue, or an issue with the current 2960-X access switch firmware that we are using at 15.2(7)E5.

View solution in original post

5 Replies 5

davidgfriedman
Level 1
Level 1

I don't know if we've had issue with thick client, but for thin clients doing PXE boot, we have needed them to update their PXE boot retries and timeouts to work more nicely with standard ISE timings before DHCP can get through to a VLAN to complete a D.O.R.A cycle. With thick clients, we're more likely to see them not auth because they are not advertising themselves occasionally on the wire, so the switch sometimes as no / expired / cached-out MAC Address information to go on.  Old school warehouse management (conveyor belt related items) systems are more of the "going silent" type and running into an ISE-unapplied (therefore blocked) port.

-David

Hi @davedvo 

 please take a look at Cisco ISE Software Download, ISE 3.1 P2 is a deferred release, please update to ISE 3.1 P3 (installing from scratch).

Note: when you use the authentication open command any new MAC Addr detected on the port will be allowed unrestricted Layer 2 Access to the Network even before any Authentication has succeeded.

Hope this helps !!!

hslai
Cisco Employee
Cisco Employee

If they are also running Cisco AnyConnect NAM your small list of workstations that are not getting IP addresses after daily 3-AM reboot and if they are always/almost the same list, please enable extended logging on NAM and turn them in for analysis by Cisco TAC. Otherwise, try establishing a pattern. It could be too many workstations rebooting at 3-AM and then it would be good to put them in batches and reboot at different times.

Good Afternoon Hslai and Marcelo,

Thanks for the suggestions. I'll have to try upgrading to the latest patch for my version of ISE and to also change the reboot times for the specific endpoints.         

davedvo
Level 1
Level 1

I found a workaround to the issue that might help other Cisco customers, that have the same problem. This starts with provisioning a Vlan assignment from my Cisco ISE PAN, to the interfaces connected to Windows workstations that are having the issue. This Vlan is set to the same one that the interface has originally been setup with using the switchport access vlan command. Before, I had my authorization policies just permit access for my users and for the workstations themselves after reboots, provided they had the correct machine certificate. Forcing a Vlan assignment using the ISE authentication profile common task, has provided me a workaround so far. This Vlan gets taken away once a user logs in, and they are given the permit access result. Strangely enough, most interfaces in my company do not require this extra Vlan assignment from ISE. This could indicate either a DCHP helper routing issue, or an issue with the current 2960-X access switch firmware that we are using at 15.2(7)E5.