- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: Management R80.20 instability
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes outgoing take 47 solve many issues.
More see here:
Jumbo Hotfix Accumulator for R80.20 (R80_20_jumbo_hf)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
March 27th with sessions for both the EMEA and Americas time zones
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jonne, did you make any progress? and you manage only 80.20 gateways with the 80.20 MDM or also older versions?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is a thread talking about this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 .
