Cisco Identity Services Engine Upgrade

[patterson_p]

I would like to upgrade the corporation's Identity Services Engine Server. Unfortunately we are a company that has a high dependency on access to our network access devices.

I have two Identity Services Engine nodes (One primary and one secondary) and would like to DE-register the secondary node making it standalone node, copy the policies over and upgrade and clean up the primary node. 

Next, I would like move our devices to the primary and update and re-register the secondary. 

I am wondering if this is the best way to go about the cleanup/upgrade while causing the least amount of downtime, or if there is a better way of going about this.

Thanks,

Paul

[Cory Peterson]

This all assumes you are running ISE on VMs.

I would recommend just standing up a new node without touching the current deployment.

Build out the new node with a temporary IP address. Create the new cleaned up policy, get everything working. Use a test switch against the new node to test your new policy.

Build out a new Secondary Node using a temporary IP and patch it up to match the primary node, but don't join the nodes together yet.

Once you have verified the new policy is working you can schedule an outage window. During this window you will do the following steps:
- Shutdown the network interfaces on the old nodes.
- Change the IP on the new Parimary and Secondary node to the old IPs.
- From the CLI:

config t
 interface g0
  ip address x.x.x.x y.y.y.y
 end
wr mem

- After this the services will restart.

- Once the services are restarted on the new deployment Join the nodes together.
- Sync happens and services restart.
- Verify everything is working.
- After everything is running smooth for a few weeks delete the old ISE nodes. (This will allow you to have an easy rollback plan if needed.)

[eddiem]

Hi Paul,

Although the scenario you describe may work, it is suggested to let the ISE upgrade process handle that deregistration for you on a two node deployment upgrade.  It's also advisable to use the  'Upgrade Readiness Tool' before the actual upgrade.  This will reduce the risk of upgrade failure and make your maintenance window more predictable. Here's the reference on upgrade readiness tool:

https://www.cisco.com/c/en/us/td/docs/security/ise/2-4/upgrade_guide/b_ise_upgrade_guide_24/b_ise_upgrade_guide_24_chapter_01.html

And here is where you'll find the detailed steps required to upgrade a two node deployment: 

https://www.cisco.com/c/en/us/td/docs/security/ise/2-4/upgrade_guide/b_ise_upgrade_guide_24/b_ise_upgrade_guide_24_chapter_011.html#ID89 

~Eddie

[Arne Bier · Accepted solution]

Simply de-registering one of the nodes doesn't stop your NAS's from using that node that is now standalone.  It will still answer to Radius requests.  So if you want to isolate things for sake of upgrade then you need to consider how to stop those NAS's from using the to-be-isolated ISE node.

Depending on how you want to proceed, I just wanted to mention that after you have de-registered a node, there is no need to copy anything over - the two nodes will have identical config because they were both PAN nodes.

I don't have much faith in the official upgrade path because of personal bad experience and also the consensus on this forum (and from some Cisco Partners I deal with) is that the upgrade does not work well.  The URT is a great tool and should always be used if applicable.

You didn't say what version you are starting from. 

And as Cory mentioned, in VM world it's quite easy to rebuild.  That is the ideal scenario.

If you have two appliances, then I would probably de-register, make sure all NAS's are using the remaining node (depending on whether this is feasible).  And then rebuild the SNS server from the .iso

After rebuild, restore the config backup onto that node.  That is effectively an upgrade anyway, but it seems to work better.  Rinse and repeat with other node.

[patterson_p]

I would tend to agree with this solution. What makes this particular upgrade challenging is that the policies will have to be rebuild. (My predecessor configured all devices under one network device policy.)

In terms of the secondary node, the network devices are configured to look for the secondary node...at least in the CLI configuration for TACACS+. As the nodes are split, the devices will not look for the secondary node at all. (Another design flaw) 

I am using a VM and upgrading from 2.0 to 2.2.