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

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