Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Alex_Shpilman
Collaborator

Management R80.20 instability

Since upgrading the management from R80.10 to R80.20 in one of my customers, we had constant instability. 

This got escalated after applying HFA33, this week I had to open 4-5 cases about different issues.

The logging from secure gateways dropsped every couple minutes, due to incorrect calculation of available disk space, newly added log servers don't appear in "logs & monitor" tab and not pushed to the DB, one Cloud Gaurd gateway lost its license, Smart Console was crashing every 10 min. 

After applying HFA43 today most of the issues resolved, I gave up on the new vsec license pool and came back to the old but working vsec licensing method.

Did anyone experience something like this with R80.20? 

I am now concerned about our other R80.20 deployments.

0 Kudos
14 Replies
HeikoAnkenbrand
Champion Champion
Champion

Yes outgoing take 47 solve many issues. 

 

More see here:

Jumbo Hotfix Accumulator for R80.20 (R80_20_jumbo_hf)

➜ CCSM Elite, CCME, CCTE
Alex_Shpilman
Collaborator

I decided to go ahead with HFA43 as HFA47 didn't have anything relevant to us.

But definitely not going to deploy HFA33 anymore, it caused me a very stressful week.

0 Kudos
Tal_Paz-Fridman
Employee
Employee

Hi Alex

Can you share the following information:

1) Is the management an a Security Management Server or Multi-Domain Management?

2) The exact upgrade path - source version - Major and Minor.

Thanks

Tal

0 Kudos
Alex_Shpilman
Collaborator

Hi Tal,

1. It's for SMS.

However, a colleague of mine had something similar on MDM, which didn't recognize CLMs after an import from R77.30, HFA43 fixed this issue for him too.

2. I had R80.20 installed from scratch and imported with a DB from R80.10, running from early January. This week applied HFA33 trying to resolve the logging issue, than the TAC gave me a fix for the license on top of HFA33 which didn't help. Yesterday, I uninstalled the fix and HFA33 and installed HFA43. Since then all seems to be good.

 

Thanks.

0 Kudos
Timothy_Hall
Champion
Champion

When you say "instability" do you mean actual process crashes/restarts on the SMS or just functionality issues in the SmartConsole?  Just for future reference, if there were crashes which specific processes were experiencing difficulty?

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Alex_Shpilman
Collaborator

That was a combination of several things:

* SmartConsole crashing very often

* 1 vSEC gateway lost it's license

* Firewalls stop logging to their log servers, running the "doctor-log.sh" suggested that the indexer, smart view, RFL and SOLR processes are constantly crashing - this described on sk146152

* Many log files went missing/corrupted

* At some point I had to failover to secondary SMS because my session got stuck in "internal error", I couldn't publish or discard anything and other users which tried to discard my session got their SmartConsole crashing

 

Darren_Fine
Collaborator

Hi ,

Just to add to the above ...

We have upgraded some clients to R80.20 management JHF take 47.

We have also upgraded the gateways to R80.20 jhf 47 (and some jhf 73 to get some IA issues fixed)

We are experiencing logging issues from some of the R80.20 Gateways to the Management ..i.e this stops working and logs are simply lost (not logging locally there is a connection between the mngmt and the gateways on port 257 but logging doesnt occur) . A cpstop;cpstart seems to resolve this but it can happen intermittently.

We have tickets with TAC.

 

Regards

 

 

 

 

0 Kudos
Jonne_Hannon
Contributor

Hi Darren,

I have also come across the issue of a cluster member stopping logging to mgmt. nor locally after a policy installation.  The other member was logging fine, so it is active now.  I was on JHF 87, but TAC stressed the I should move to JHF 91 immediately, because there are apparently many bug fixes that are not documented in the SK.  Moving to JHF 91 did not resolve issue for me though.  Did you ever get your issue resolved?

Thanks,

 

Jonne. 

0 Kudos
Daniela_Zamfiro
Explorer

Hi Jonne, did you make any progress? and you manage only 80.20 gateways with the 80.20 MDM or also older versions?

0 Kudos
Jonne_Hannon
Contributor

Hi Daniela,

Sorry for late reply.  The MDM manages mostly R80.20 gateways, but there are still a few R80.10 gateways in the mix.  I'm about to deploy an R80.40 3.10 appliance, so we'll see how that goes.  I recently installed JHFA Take 161 on the MDM and started having issues with session corruption, so I have jumped to Take 173.  Takes 103, 118 & 141 seemed to be stable for MDM and Take 118 on gateway has been stable.  Take 118 also addressed VSX memory leaks that required the VSX gateway to be restarted after about 100 days uptime.

Thanks,

Jonne.

0 Kudos
Dawei_Ye
Collaborator

I have the vSEC license disappearing too,and SMS is R80.10.
There is a thread talking about this.

0 Kudos
George_Soslovsk
Employee Alumnus
Employee Alumnus

Hi Alex,
Can you please assist with this details:

1. Was the licensing problem occurring using `vsec_lic` tool or with `cloudguard_config` tool for NSX?

2. Were the vSEC gw with the disappearing license deployed with NSX integration?
0 Kudos
Alex_Shpilman
Collaborator

Hi George,

1. vsec_license_cli was used 

2. Yes, we have NSX integration 

 

For now, I came back to the vsec_central_license and will revisit this later this year after the customer will renew the contract as they are intending to do some cloudgaurd core changes.

 

Thanks.

0 Kudos
George_Soslovsk
Employee Alumnus
Employee Alumnus

Thanks Alex,

I just wanted to clarify that for Gateways that were deployed using the `cloudguard_config' tool for NSX you need to attach license from the `cloudguard_config'  menu itself and not 'vsec_lic_cli' or 'vsec_central_license' tools .

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events