Cisco ISE Hardware Upgrade Process

[jj2048]

Overview

An existing medium-sized distributed deployment (2 PAN,MNT and 3 PSN) needs to upgrade hardware. For budget reasons, only Primary and Secondary PAN,MNT node will be upgraded, and the existing PAN,MNT node will be re-used as PSNs.

Objective

Upgrade Primary and Secondary (PAN,MNT) node and re-use it for PSN, for PSNs that are LDOS.

Before:

Primary (PAN,MNT) - not ldos (software version old)

Secondary (PAN,MNT) - not ldos (software version old)

PSN1 - not ldos (software version old)

PSN2 - ldos (software version old)

PSN3 - ldos (software version old)

After:

Primary (PAN,MNT) - NEW (recommended version and patch)

Secondary (PAN,MNT) - NEW (recommended version and patch)

PSN1 - not ldos (recommended version and patch)

PSN2 - not ldos (recommended version and patch)

PSN3 - not ldos (recommended version and patch)

Question(s)

Let's just say it's straight forward replacing the unit with software/hardware upgrade.

What is the best approach to upgrade such hardware?

What comes to mind for me is to backup the configuration, re-use the Host name, IP of the existing Secondary Node to the New Hardware and then shutdown the old secondary node, and deploy the new secondary node and upload the backup configurations.

Next will be re-imaging the old secondary node as the new PSN1 then shutdown existing PSN1 then enroll it to the new deployment, continuing with the same process for PSN2-3, until Primary Node to be replaced with the New Hardware.

Are my ideas possible for this scenario?

While waiting for answers I'll try to do a lab setup and update my results here.
Thank you.

[Arne Bier · Accepted solution]

Hello

LDOS? is this related to End of Sale (e.g. SNS-35xx) ?

You didn't mention versions.

SNS-35xx only go as far as ISE 2.6

SNS-34xx only go as far as ISE 2.3

Your approach is correct. You will begin the process by sacrificing your Secondary PAN node first. it will be the new PAN in the upgraded version. Restore the config. Then install you trusted certs, and the Admin System cert (you can re-use the certs from the old box - just make sure you export each Node's Admin/EAP/Portal certs).

Then choose a PSN as your first PSN for the new deployment. I always re-install the server (in this case quicker if done by USB stick - around 90min per server). Then install the necessary trusted cert(s) for the Admin System cert, and then import the Admin cert too. Then I register the PSN. And wait for the sync.

Rinse and repeat.

Last node to go is the old Active PAN/MnT.

I normally patch at the end - since you can kick of a patch process and walk away - it will patch the whole deployment in a sequence.

[paul]

One quick note on this.  The approach Arne laid out is the approach I used to use all the time.  The only drawback is at the end you need to do a couple of things:

1. Promote the old primary admin node back to being primary.
2. Probably rebuild the internal CA as the CA will be rooted off the secondary admin node since it was the first one on the new version.

To save these last two steps, I now flip the Admin roles on the existing deployment and then sacrifice what used to be the primary admin node to be the first upgraded node to the new version.  Then the primary admin node is in the correct spot right away on the new version. 

[jj2048]

Thank you Paul.

I will keep this in mind.

By my understanding, you choose to remove first the existing primary node, then deploy the new hardware as the primary.

Is that correct?

[Arne Bier]

No - you don't start with the old Primary Admin node - you leave that node until the end. The reason is two-fold

1. You want your current PSN's to continue operating and have a platform to monitor
2. You want a backout plan - the PAN is the last remaining (easy) chance to rebuild the deployment

So you start with the old Standby Admin node because this one is ... Standby ;-) You don't log into this node to configure/monitor anything. Therefore you can kill it without affecting anything. If you also run Services on that node, then you need to ensure that none of your RADIUS/TACACS+ clients are relying on this node (hopefully you have Primary/Secondary/Tertiary AAA configured on your NAS's)

[jj2048]

Thank you Arne for the clarifications.

[jj2048]

Thank you Arne.

I missed the part on supported hardware of the version.

Thank you for this information, and I referred back to the release notes of the latest versions.

The devices you mentioned is correct.

[balint.simon]

Hi Arne,

Just to clarify on your solution, we have a distributed deployment, with 34xx hardware and 2.2 software.

How can I add new hardware running 2.7 to the current deployment? I assume it won't accept it as new node, due to the different software version. 

Or am I in fact building up a totally new parallel deployment with the same rules, and clients will connect to whichever they reach during the upgrade?

Thanks,