cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3690
Views
70
Helpful
10
Replies

Cisco ISE 2.7 Patch 2 to Patch 5

fareed.ahmad
Level 1
Level 1

it appears that for ISE 2.7 Patch 5 is out which addresses the current vulnerability with privilege escalation. We are currently on 2.7 Patch 2.

im reaching out to cisco to see in an effort to install patch 5, do the patches need to be installed incrementally...2, 3, 4, then 5 OR can patch 5 be installed straight away?

2 Accepted Solutions

Accepted Solutions

Yes, it will force a reload of the ISE application after patching.

View solution in original post

Hi @fareed.ahmad ,

 beyond @Greg Gibbs and @ComputerRick said ... please special attention to: CSCvy71406 Update Admin Guide to include manual sync as part of patching process.

Symptom:
Per ISE engineering, we should update the ISE admin guide to include a manual sync as a part of the patching process. This needs to be documented as a best practice step in the admin guide.
Conditions:
Patching ISE
Workaround:
N/A
Known Affected Releases:
2.6(0.908)
2.7(0.904)
3.0(0.902)
3.1(0.901)

 

In other words, after patching, at Administration > System > Deployment > select the Secondary Nodes and Syncup.

 

Hope this helps !!!

View solution in original post

10 Replies 10

Greg Gibbs
Cisco Employee
Cisco Employee

As stated in the Admin Guide:

"Cisco ISE software patches are always cumulative.

...

You can install the required patch version directly. For example, if you are currently using Cisco ISE 2.x and would like to install Cisco ISE 2.x patch 5, you can directly install Cisco ISE 2.x patch 5, without installing the previous patches (in this example, Cisco ISE 2.x patches 1 – 4)."

Hi Greg,

 

thank you for the reply! perfectly explained!

 

also would you be familiar with if ISE requires a reboot after successful installation of patch 5? wondering if i should do this install after business hours... 

Yes, it will force a reload of the ISE application after patching.

Hi @fareed.ahmad ,

 beyond @Greg Gibbs and @ComputerRick said ... please special attention to: CSCvy71406 Update Admin Guide to include manual sync as part of patching process.

Symptom:
Per ISE engineering, we should update the ISE admin guide to include a manual sync as a part of the patching process. This needs to be documented as a best practice step in the admin guide.
Conditions:
Patching ISE
Workaround:
N/A
Known Affected Releases:
2.6(0.908)
2.7(0.904)
3.0(0.902)
3.1(0.901)

 

In other words, after patching, at Administration > System > Deployment > select the Secondary Nodes and Syncup.

 

Hope this helps !!!

Hi @Marcelo Morais 

 

This is interesting. I have never done a manual sync after applying ISE patches. Is that a new requirement?

If you have more than one node in a deployment, at what point should one do the manual sync?

And does this mean EVERY Secondary node must be manaully sync'd after the patch is applied?  

 

I can't remember the last time I had to do a manual sync - but I seem to recall that it takes the node out of service. So it's not something to be taken lightly.

 

If you have any real-world experience of this I would like to know how it works.

 

Question aimed at Cisco:  Why is this a 'best practice'? It seems a bit daft to me - why can't ISE manage itself better?

Hi @Arne Bier ,

 I started doing this sync since I read this bug (this bug was Last Modified on Jul 16, 2021).

 When the resync starts it causes the Node to be out of service.

 In a real world experience: in a Cluster of 20x Nodes, I start the resync on all Secondary Nodesafter patching every Node.

 

Hope this helps !!!

I'm still interested to know whether your nodes were out of sync after applying a patch - ever? I have not had that experience. And I think it's indicative of bad engineering if the vendor starts to recommend this kind of stuff. After applying a patch the node will reboot anyway. It should sort itself out during that time. If not then the product is defective and Cisco should fix it.

Thanks for the headsup, but I think it's the most rediculous thing the BU has recommended end users to do.

Hi @Arne Bier ,

 no, the Nodes were never Out of Sync after applying the Patch.

 I agree with you about: "... After applying a patch the node will reboot anyway. It should sort itself out during that time...", but as soon as I witnessed so many weird things on ISE, I always prefer to eliminate any possibility of a future problem, in this case, resync the Nodes after a Patch as described on CSCvy71406.

 

Regards

Given the increase in complexity and with some deployments being 20+ nodes, I could see issues with nodes getting a large number of queued messages that may have trouble recovering from.

I would probably ensure that there are no changes to the configuration while patching and watch the nodes and only sync those with an excessive number of queued messages.

If it's going to improve cu experience and deployment stability, it may be an extra step but calling it ridiculous of the BU without understanding why is not going to help.  It may not be my favorite thing, but it could mean that patching is more consistent and successful for more customers, and could also save everyone in one of those situations a lot of time and headache.

@ComputerRick - I take that back - it was worded too strongly. The point I was hoping to make was that the software should be intelligent enough to get itself out of trouble/mess, since it has already concluded that something is not optimal (i.e. the icon is not green - too many messages queued, etc.) - so why does ISE not fix that itself?

 

Rather than me ranting off how an end user might feel about it, I'd welcome a technical deep dive from Cisco BU about how these situations come to be in the first place, and why the "sync" button is even there for the user to click. And then, what is the technical reason/justification for asking an end user to push that button, rather than having a self-healing solution. In the world of Computer Science and application development in general, is this an acceptable solution of how a product should behave?

 

In my opinion, modern database applications should not have to behave like this. Given that this manual intervention means that there is some database inconsistency, there should be some programmatic way to get out of this situation that does not involve the user having to make that call. Put another way, what choice does the user have at that point anyway? Just watching the red icon won't fix it - only option is to push the button to get it fixed, right? Why doesn't an application restart/reboot check for that and auto-recover?

 

 

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: