R80.20 Jumbo Hotfix Accumulator - New Ongoing Take #87

[Yifat_Chen]

A new Ongoing Jumbo Hotfix Accumulator take for R80.20 (take 87) is available. Please refer to sk137592.

• The new releases will not be published via CPUSE as a recommended version.
• Availability:
  • Will be provided by customer support
  • Available for download via CPUSE by using package identifier

Impotent Note:

• If you have Jumbo Hotfix Accumulator Take 73 installed on your machines, it must be uninstalled manually before Take 87 installation. 
  For other Jumbo Takes, this is not necessary. 

[G_W_Albrecht]

Not available in CPUSE Cloud yet...

[Yifat_Chen]

@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   

[Marc_Lampo]

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 ...

[G_W_Albrecht]

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 !

[Marc_Lampo]

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.

[Davidbi]

@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.

[Marc_Lampo]

The "reason" for the reboot is very simple :

##reboot
30 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.

[Marc_Lampo]

There is a, already escalated, SR about this, by the way.

[Yifat_Chen]

@Marc_Lampo  Can i get the SR Number ? 

[Marc_Lampo]

sure - email me : marc.lampo@telenetgroup.be

[License_at_Qsig]

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.

[Tilen_Pegan]

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.

[Yifat_Chen]

FYI - Take moved to GA today.