R80.20.M2 Management - Finalizing Stuck at 99% During Policy Installs

[Heath]

Setup is 2x Management Server 5150 with dedicated SmartEvent server all running R80.20.M2 pushing policy to a single 5800 HA ClusterXL setup all running R80.10. The management and cluster are located at the same site. The access/threat policy takes less than 3 minutes to succeed on the cluster but the 99% finalizing status takes a very long time to complete. I've just pushed a policy and it again finished in 3 minutes but has been stuck at 99% finalizing for the past 45 minutes...

 image.png

Is anyone else experiencing this after updating your management to R80.20.M2 or R80.20 in general?

[PhoneBoy]

I would open a TAC case so we can investigate.
Overall with R80.20, the policy push time should take around 2 minutes.
While times above 2 minutes are not uncommon in some scenarios, 45 minutes of "finalizing" time is definitely unusual.

[Tomer_Sole]

Finalizing step is for post-policy installation activities, most notably Install Database at the log server in order to ensure that names of hosts are displayed instead of IP addresses at the log cards. So by the time that you see Finalizing, the enforcement already happens.

[Heath]

That 99% finalizing finished after almost exactly 2 hours. This time of finalizing aligns with what another employee is experiencing when pushing to this same cluster. Yet another employee says he does not have these same issues:

image.png

I updated the version above because it's R80.20.M2 for the management. After talking with my team, we are also seeing these issues:

- SmartConsole > Gateways & Servers clicking on a gateway or cluster will open up a, seemingly, random gateway object. This is not resolved until you close and re-open the SmartConsole

- SmartConsole > Logs & Monitor sometimes this tab is unresponsive and it will have to be opened in the top menu

- SmartConsole login sessions using RADIUS get hung where we cannot login. Rebooting the management does not help the situation but it clears randomly after time where we can login. Local logins still work during this time.

[Heath]

We have opened a TAC case and will update this ticket with the resolution.

[Tal_Paz-Fridman]

Hi 

Is this something that is happens every time or at least frequently? 

If so please contact me directly at [email protected] so that we can collect the relevant debug information and analyze with R&D.

Best wishes

Tal

[Heath]

After working through some troubleshooting with support we narrowed it down to this happening on a certain gateway. I think it was amplified because this is one of our more active environments. I believe we gave some debugs to support last week. I'll include you on the messages with support. Thanks for following up!

[Tal_Paz-Fridman]

Great. If you still want me to have R&D look at it directly please send me the following files for the install policy that is stuck:

$MDS_FWDIR/log/cpm.elg

$MDS_FWDIR/log/install_policy.elg

Also from the first message this is a Security Management Server?

Best wishes

Tal

[Heath]

Will do. Our admin is going to include you in the ticket we have opened. Thanks!

[Julie_Paul]

Any updates or fixes on This?

[Tal_Paz-Fridman]

Hi @Julie_Paul 

This issue was also handled by TAC and resolved with a W/A.

The problem was related to the policy that was installed on the gateway (please refer to SR 6-0001670596 for further information).

Tal

[Heath]

We have yet to apply the suggestions from TAC. We will update after this is resolved on our side here and via the ticket.

[Tal_Paz-Fridman]

Thanks for update!

Tal

[Heath]

Still trying to capture the correct debugs for support...

[Vladimir]

I have observed this behavior when IPS updates were performed during policy installation and the TP profile called for them NOT to be in Staging mode.

The longer the period between IPS updates, the longer the installation of the policy takes.