R81.20 jumbo 90

[the_rock]

I installed it in my lab today, no issues so far, but will give it 24 hours. I do see lots of fixes listed in the official doc.

Andy

https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.20/R81.20/Take_90.htm?tocpath=_____6

[PhoneBoy]

Looks like we have a fix for Blast RADIUS now 🙂 
https://support.checkpoint.com/results/sk/sk182516 

[the_rock]

I think that was included in jumbo 89?

[PhoneBoy]

In JHF 89, we only had fixes for Gaia OS itself, not the other components.

[the_rock]

Got it.

[genisis__]

One thing to meantion - this fix is included in Take_106 for R81, however Take_106 also has an issue related to failover (I get R81 is EoL, but I think Checkpoint should fix this final Jumbo release, rather leave it in a broken state, and yes TAC case raise).
I totally understand that it would be more best effort, but come on, why issue a jumbo with a known issue and then just leave it.

[Lesley]

Just my 2 cents. If you release a new jumbo that will fix your issue it could be it introduces new issues for different customers. At one point it has to end. In this case a portfix based on best effort would make more sense to me. 

[JozkoMrkvicka]

Yeah, you see just fixes which Check Point mentioned in release notes. There might be many many more fixes which were just not mentioned for whatever reason, but are included in T90 🙂

Back to the topic, will have a look on each issue to be declared as fixed in T90. At least going to test Blast RADIUS fix.

[Thomas_Eichelbu]

Hello Folks, 

i installed HFA 90 yesterday to get rid of this nasty 

[16 Nov 16:34:47][fw4_5];[vs_0];[10.X.X.X:52745 -> 1.1.1.1:53] [ERROR]: cmik_loader_fw_context_match_cb: match_cb for CMI APP 31 - DNS_DATA_SOURCE failed on context 201, executing context 366 and adding the app to apps in exception

messages!
after installing HFA90 they are gone! Great success!

But i had a weird issue,
i was installing this HFA90 via CPUSE on a remote GW (Cluster XL R81.20 HFA84) over VPN.
The Installation just started into a few % of progress and suddenly my access to this member stopped.
no SSH, no Ping, etc. not reachable over VPN anymore.
but i was able to reach the affected member over the Sync Interface of the active member.
HFA90 was installed successfully no issues after reboot.
The same issue happened on the the remaining cluster member as well.

did anybody noticed that before? Thats weird, because normally you stay connected on the installing member until its final reboot.

[the_rock]

I updated my lab actually over VPN as well, did not have such an issue. Though I was on jumbo 89, but not sure if that would make any difference.

Andy

[Thomas_Eichelbu]

yes maybe its highly customer depending, or a solar flare just hit the earth, who knows 🙂

[the_rock]

@Thomas_Eichelbu haha, maybe 🤣🤣

[JozkoMrkvicka]

At some point of jumbo update, the installer stops cp services. It might be that the connection was cut during cpstop.

Always connect over serial connection or LOM 😉

[Duane_Toler]

Yeah agreed.  I've had mixed results and had the same effect described in this thread.  Usually, tho, when that happens, I'm able to re-connect to the host via SSH directly to the public external IP.  My policies on customer gateways allow me to have that access from an external management host, tho (for this reason).

[the_rock]

Personally, and I say the same to all my colleagues, when we do any sort of upgrade for the customers, we always ask them to have someone on site if possible, because better be safe than sorry. It could be that 1 time out of 100 when issue happens and no one is there when you need them.

Andy

[Lesley]

I had same issues. 2 vsx gateways all good. Other units jumbo update at 14% stopped showing progress and unit was not reachable. I saw layer 2 connection so it was still alive. Update took around 20-25 minutes each unit. At one point I saw that arp entry was gone and I knew it was rebooting. It is not normal behavior but to be honest there was no impact or any issues during this. But I could imagine that a first timer would break a sweat maybe 😄

[Axel_Winterberg]

Hi Thomas,

just updated a cluster with JHF T90, today. Same issue. After a few % of installing I had to reconnect.

Noticed it on both cluster member.

[the_rock]

Did you open TAC case about it?

Andy

[Thomas_Eichelbu]

Hello,

well no, no TAC case for this topic ... i am currently overloaded with cases and must prioritize on the most important problems ...
today i install HFA90 again on a single gateway again, lets see how it turnes out.

[Axel_Winterberg]

No, Not for this issue. But after installing the JHF T90, we can only connect via local Admin to Smart Console.

SSH and https to the management server are working fine with RADIUS authentication.

But Login with Smart Console over RADIUS stops working. Opened a TAC case SR#6-0004135071

Log of RADIUS shows successfull Login, but we get error message "authentication to server failed"

In Audit Log we see, that the login is denied with "Wrong Password" !!!

[JozkoMrkvicka]

Maybe related to blast-RADIUS articles sk182516 and sk42184?

There is a new registry integrated into T90 - require_message_authenticator which can be set to 1 (0 by default).

[Axel_Winterberg]

Hi Jozko,

I`ve seen this in the Release Notes for T89/T90 and have already set the parameter to "1".

Unfortunately, this has no effect on our issue. I have rebooted the server after save config.

But still the same issue. Have collected fwm debug and uploaded it to the SR. Waiting for Reply.

I have seen some error messages: 

request_handle_tick(rp=945f7c8): server is down. Try another if available.

RADIUS Servers Cannot Be Reached. Dropping Request

But I can still see the successfull authentication in the RADIUS Server Logging!!!

[the_rock]

Thats super odd @Axel_Winterberg 

It is indeed strange you would see proper authentication, but logs show requests dropped. Do you see the same in zdebug?

Andy

[AkosBakos]

Hi Andy,

Install the take 90 is still safe? 🙂

Akos

[the_rock]

@AkosBakos I would say yes.

Andy

[Henrik_Noerr1]

We had to rollback on MLM servers from t89 to t84

There is a performance degradation on the SOLR process causing our two MLM servers maxing all 2x32 cores indexing logs coming in.

The response from RnD is that it is known issue and will be fixed in future jumbo (issue still present in t90)

The issue is not mentioned in the 'Important Notes' but that is not the first time info is missing.

If you have a larger environment I would skip t90 for the indexer load issues and I would skip t89 for the VSX issue.

Regards,

Henrik

[AkosBakos]

Hi Henrik,

Thanks for your feedback. I want to install on a GW cluster which has issues with Routed.

Otherwise, interesting, I have performance issues to on a SMART-1 and we can stick the load increasing to the take 89 install. I have opened a ticket by TAC. If it is possible, can you send me a ticket number where your invertigation was happened? I would attach to my case.

Akos

[Henrik_Noerr1]

6-0004114203

[AkosBakos]

Great, thanks!