Warning: R81.20 JHF 89 for VSX

[Duane_Toler]

I had a multi-hour call with Diamond TAC today dealing with a VSX cluster R81.20 after an update to JHF 89.  We had one VS with an interface with multiple VLANs that was missing the highest VLAN on the monitored list.  No matter what trick we did, we couldn't get the 2 JHF 89 gateways to sync up with the 1 older JHF gateway.  It was affecting only ONE VS, too, not the others.  All others worked just fine!

I rolled back JHF 89 and instead installed JHF 84 and all is well now.  This may not affect everyone, but TAC told me about another case they had with the exact same issue.

Hopefully your updates aren't as troublesome, and may they bring you success, but be aware of your multi-VLAN interfaces for VSX.  JHF 89 doesn't seem to play nice with those.

[Alex-]

Apparently a known issue.

https://community.checkpoint.com/t5/Management/VSX-VS-Cluster-State-in-Smartconsole/m-p/231363#M4030...

We also have an SR open for this on VSX running R81.10 and Take 150 onwards.

[the_rock]

Good to know! I had old client tell me about it the other day, but I was not aware it was a known issue until I saw your post.

Andy

[JozkoMrkvicka]

If we face issues with monitored VLANs, in most cases cpstop;cpstart from problematic VS help.

If not fixed after cprestart, there is not documented command:

fw vsx restart_vs <VSID>

Example for restarting VS 3: fw vsx restart_vs 3

Try that if it helps.

[Duane_Toler]

Yep, did that, too. Good idea. Didn’t help, tho. VS remained down on the JHF 89 gateway. 
Full rollback was the only remaining option.

[Jan_Kleinhans]

Hello,

as Alex already mentioned we are one of the customers with this issue. And also TAC told us about other cases. Our case is open since 22 October. We are waiting for a debug script.

As it seems that there are more and more users experiencing this problem I wonder why checkpoint doesn't place a warning or at least a "known issue" so that customers planning to go to the "recommended" release will have something to go on.

[MatanYanay]

Hi @Jan_Kleinhans 

we will add it to the important note of the jumbo by tomorrow 

[Jan_Kleinhans]

Hello Matan,

you posted an entry this morning in this case. Where is this entry? Was the information wrong?

Regards,

Jan

[MatanYanay]

Hi @Jan_Kleinhans  we are still working on the most accurate communication. 

meanwhile, be aware we have a fix and it will be released in the jumbo we plan to release next week 

Thanks

Matan.

[MatanYanay]

Hi All 

We have identified an issue with the new Jumbo take that affects the VSX cluster env with VLANs.

During the installation on the Standby member, a temporary monitoring mismatch occurs:

the Standby begins monitoring only the lowest VLAN, while the Active member monitors both the lowest and highest VLANs.

This mismatch causes an "ACTIVE!" (on the member running the pre JHF 89 version) or Down state (instead of Standby state on the member running JHF 89) to be triggered.

Although this is a cosmetic issue and does not impact traffic flow or failover functionality, we still recommend that VSX customers wait for the next Jumbo release ( Plan to be released next week). Important note in the jumbo doc will be added today as well 

For customers who wish to proceed with the installation, an SK with detailed installation instructions will be published today (and shared on this thread).

[genisis__]

Will this also include a Jumbo update for JHFA106 on R81 (The issue is on this as well - TAC case raised and identified)

[Chris_Atkinson · Accepted solution]

sk182819 was published for this issue.

[the_rock]

Awesome!

[JozkoMrkvicka]

doing cpstop on active member cannot be considered as "manual failover". Better wording should be "hard switchover with small outage". Maitanance window is needed anyway.

It is also not clear from the article if cpstop/failover should be done from VS0 or from specific VS. Depending if VSX is in HA or VSLS mode.

In which world can happen that affected VS will be in STANDBY state while highest VLAN is not monitored correctly ? It has to be in DOWN state and "normal failover" cannot happen due to LPRB or IAC Pnote problem.

[JozkoMrkvicka · Accepted solution]

Starting from R81.20 Take 89, ONLY lowest VLAN is monitored.

[the_rock]

Looks like just came out today.

[Alex-]

The SK mentions this issue is fixed in R82.

We don't see upgrading VSX clusters to R82 before a year of hotfixes if not more.

We see a similar  issue in R81.10 and hope some fixes will roll out for other versions as well.

[JozkoMrkvicka]

Only R81.10, R81.20 and R82 are still supported. All other versions are EoL already (R81 reached EoL in October 2024).

I agree with you about R82. Once R82 is not declared as Recommended version, there is no way I am going to put this version on production firewall. There are tons of bugs within R81.10 and R81.20. I will be surprised if R82 is exception.

Back to the topic - What does it mean that highest VLAN issue is fixed in R82 ? If it is by design that monitoring of highest VLAN is no longer available starting from R81.20 Take 89, what/how it is fixed in R82 ? R82 is just R81.20 Take 89 with updated kernel and fancy new features...

[genisis__]

We have a commercial agreement to extended support, hence my question and the fact a new Jumbo has been released for R81, so it makes sense CP should fix this issue prior going to final recommended release.

[Chris_Atkinson]

R81.20 JHF T90 was released with the fix for this issue.

https://community.checkpoint.com/t5/Product-Announcements/R81-20-Jumbo-Hotfix-Accumulator-take-90-ha...

[the_rock]

I see came out today, let me install it in the lab.

Andy

[JozkoMrkvicka]

"Problem" solved then, close all the cases 🙂 

 

[the_rock]

@JozkoMrkvicka 

 

[genisis__]

Just need R81.10 and R81 Jumbo's to know be updated.

[Chris_Atkinson]

R81.10 JHF T171 was released with the same fix.

[JozkoMrkvicka]

so, it looks like sk182816 which was about "Starting from R81.20 Take 89, ONLY lowest VLAN is monitored" has been deleted.

At the end it was really a bug and not a feature ?

Didnt want to be too specific, thus general, ordinary, any Vendor.

[the_rock]

lol

[PhoneBoy]

The SK was deleted because, it turns out, it's a duplicate.
The correct SK is: https://support.checkpoint.com/results/sk/sk182819

[JozkoMrkvicka]

If I remember correctly what was written within deleted sk182816, it was that starting from R81.10 Take 169 and also R81.20 Take 89, only lowest VLAN is monitored by default.

Within sk182819 it is mentioned that by default both lowest and highest VLANs are monitored by default:

The Standby VSX Cluster Member starts monitoring only the lowest VLAN, while the Active VSX Cluster Member continues to monitor both the lowest VLAN and the highest VLAN (which is the default behavior).

Anyway, I will test it in LAB and report back where is the truth.