Welcome to CheckMatesPartner Community
I am Gil ShwedAsk Me Anything!
Top Tips:for working from home
It's here!CPX 360 Content
CheckMates GO:APT41 and Living Off The Land
CheckMates Live:Virtual Edition
A new Ongoing Jumbo Hotfix Accumulator take for R80.20 (take 87) is available. Please refer to sk137592.
Not available in CPUSE Cloud yet...
@G_W_Albrecht indeed , this is an ongoing take - Available for download via CPUSE by using package identifier only ( . You will not show it as recommanded till it will be GA
Really couldn't imagine why anybody would want to install an "ongoing take", if even the GA takes are not stable.
For an ongoing issue (>1 month, GA Jumbo takes - take 33 more less the most stable one, if module is rebooted daily !) I was asked to try ongoing take 80 : had to throw it off within days ! Perhaps that experience/feedback is the reason why they now talk about 87, not 80 ?
At this moment they are looking for a fix on take 33.
Memory leaks, multiple, apparently ...
Jumbo Take 87 will install over MTA Update T 43 or T 46, but you will have to uninstall MABDA portal fix Check_Point_R80.20_T101_MABDA_sk113410_FULL.tgz and RAD HF fw1_wrapper_HOTFIX_R80_20_JHF_T17_155_MAIN_GA_FULL.tgz before JT 87 can be installed. Both MABDA portal fix Check_Point_R80.20_T101_MABDA_sk113410_FULL.tgz and RAD HF fw1_wrapper_HOTFIX_R80_20_JHF_T17_155_MAIN_GA_FULL.tgz can then be installed upon JT 87 successfully !
At this moment our preference would be to revert to R80.10 : that version ran stably for 3 months, on the customers equipment, until we upgraded to R80.20, because of "rewritten" HTTPS Inspection.
Up till now, for >1 month - ever since upgraded, it is unclear why, but regular reboots are required to keep the module stable. At this moment, we are at a daily reboot at 05:30AM.
@Marc_Lampo this is very unfortunate.
we would be happy to help and understand what is the root cause of the daily reboots.
this is very important for me to get to the bottom of this and fix the issue.
but to do so I need as much information as possible.
please feel free to contact me, I will do my best to help.
The "reason" for the reboot is very simple :
##reboot30 5 * * * /sbin/reboot
The need for the daily reboot : if not, "top" shows less and less free memory up to the point that users, in the customers network, start complaining (speed, surfing fails, ...)
After reboot, we are "back to normal" (performance and functionality) for at least the work day.
There is a, already escalated, SR about this, by the way.
@Marc_Lampo Can i get the SR Number ?
sure - email me : firstname.lastname@example.org
We have multiple cases as well for memory leaks. Reproducable on any VSX environment we have running any ongoing take right now. 5 customers checked, all 5 have the same memory leak. 2 ongoing cases with 2 escalations, daily reboots required to prevent gateway crashes.
Marc, if it helps, we had a similar issue after going from R80.10 -> R80.20 on a 15400 appliance - memory ran out almost daily...and than reboot. As I did not intend going through the painful memory leak try and catch debugs - we just upgraded RAM from the base 8G to 24GB ....now it's stable on a 13G used/reserved RAM.....and yes, I know that's not a real solution :)....but even without this RAM problem I wouldn't go to R80.20/30 yet ....It still has some interesting bugs on SecureXL.
FYI - Take moved to GA today.
Learn Check Point
WELCOME TO THE FUTURE OF CYBER SECURITY