ISE AD connect lost after upgrade

[Ayhan Guec]

Hi guys,

after an ISE upgrade the AD connection is lost and i have to join AD manually again. The upgrade procedure takes a very long time as you know and will be not sitting in front of the CLI during the complete upgrade procedure.

The main problem is that the radius Server is up & running and without AD connection all connect attempts fail until i manually join to the AD again. Is there a way how i can stop serving radius request after an upgrade automatically? Or is a fixed planned, that ISE would not loose AD connectivity after upgrade? I want to reach an unattented ISE upgrade procedure.

Is it possible to configure a second NIC from where i can reach ISE for administration purposes and shut down the first NIC during upgrade process so the ISE is unreachable for the NAD's ? Or will the first NIC be automatically active after an upgrade again?

Best Regards

Ayhan

Does anyone know a workaround how i can

Does anybody know a workaround which

[Arne Bier]

By design ISE only listens for SSH connections on first gig0 (or bond0) interface.  Technically it would be possible to allow SSH from other interfaces but Cisco has nailed down the iptables (firewall) that way.

You might be better off making your gig1 serve your radius traffic and having gig0 just for management.

I would never try to perform an unattended ISE upgrade only because I don't trust it.  I would however walk away during a patch cycle and come back expecting it all to work.  That is something ISE has always done well in my opinion.

I have done upgrades where the AD was automatically re-joined.  Perhaps it's a case of HOW to upgrade is performed.  I would never run another official ISE upgrade ever again. It screwed up so badly (even though URT said all was well).  You are better off building new nodes (from .iso) and restoring your last config backup to build a new PAN (start a new deployment).  Then build new standby nodes and register them into the fold. 

[Ayhan Guec]

Hi Arne,
you are right , the upgrade procedure is a pain as it takes a lot of time without detailed information to finish time. Building new notes and restoring a backup is an option but also a lot of work. If upgrade procedure finishes without problems, joining AD is less work to do :-)

[ajc]

Another comment, DO NOT use the restore backup as approach for upgrade. When I upgraded 1.4 version to 2.2 for our 3495 and the brand new 3595 replacing 3395, I realized that 1.4 was not supported by the 3595 so by mistake I followed the restore 1.4 config backup once all the nodes were on 2.2 and now I am getting a preliminary information that the DB could be corrupted due to that approach.

So, my recommendation for those upgrading from 1.4 to 2.2 is to follow the application upgrade approach OR take 1 of your 3495 running 1.4 and make primary PAN, MNT and PSN. Upgrade that unique node to 2.2 using the application upgrade and then join reimaged boxes with 2.2 already installed. This process probably takes more time but for me is the safest one (many people could disagree on this).

[ajc]

AND...There is an identified problem at least on version 2.2 where the AD connector is lost, so the only workaround available is accessing root on the server (SSH) and apply a few commands to recover it. However, sometimes SSH does not work unless you access the server using CIMC and reboot it. I will post the workaround later.

[Ayhan Guec]

Hi Abraham,
this sounds really bad. Do you have an Bug ID for the issue? Loosing the AD connector would bring me into big trouble :(

[ajc]

Not sure if it will be fixed on patch 9 for version 2.2 or version 2.4 coming soon. I have seen that when you get a HIGH DISK UTILIZATION alarm that sometimes requires a complete server reboot but the connector status does not come up. Let me find out the workaround I was busy yesterday