06-05-2018 06:25 AM - edited 02-21-2020 10:57 AM
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
06-05-2018 03:46 PM
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.
06-07-2018 12:28 AM
06-07-2018 09:03 AM
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).
06-06-2018 10:20 AM - edited 06-06-2018 10:21 AM
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.
06-07-2018 12:32 AM
06-07-2018 08:54 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide