topic Re: behaviour after changing CoreXL instances of VS ? in Hyperscale Firewall (Maestro)

behavior after changing CoreXL instances of VS ?

Wolfgang — Thu, 14 Mar 2024 18:48:34 GMT

We changed the CoreXL instances of one virtual system (from 3 to 4 cores). Traffic was loss as expected 30s.

But.... all SGMs switched to down state and did not process any traffic except one. Only after a policy install on the changed virtual system all SGMs are back to active state.

Is this expected behavior ? We had 5 SGMs and if we change the CoreXL configuration of one VS, only one SGM has to handle all traffic. This can be result in an overload of this SGM.

Re: behaviour after changing CoreXL instances of VS ?

Bob_Zimmerman — Thu, 14 Mar 2024 14:23:34 GMT

I get inconsistent results when making changes to CoreXL on my VSs. Sometimes the new workers are allocated, but they don't come up, leading to output like this:

[Expert@SomeVsxFirewall:1 ACTIVE]# fw ctl multik stat ID | Active | CPU | Connections | Peak ---------------------------------------------- 0 | Yes | 2-15+ | 2376 | 7003 1 | No | - | 0 | 0 2 | No | - | 0 | 0 3 | No | - | 0 | 0

I then have to manually run 'fw ctl multik start' once for each stopped worker. While I don't use Maestro and haven't seen your exact behavior, I thought you might like to know people doing similar things also see weird results.

Re: behaviour after changing CoreXL instances of VS ?

Wolfgang — Thu, 14 Mar 2024 14:41:17 GMT

We are running R81.20 and Dynamic_Balancing is enabled. The "magic" should be done in the background 😉

Re: behaviour after changing CoreXL instances of VS ?

Bob_Zimmerman — Thu, 14 Mar 2024 15:26:10 GMT

That firewall was R81.20 jumbo 26. I've seen similar weird behavior when changing CoreXL instance counts on VSs in earlier versions, too. Doesn't happen every time, which is also weird.

Re: behaviour after changing CoreXL instances of VS ?

Wolfgang — Thu, 14 Mar 2024 18:49:24 GMT

I hope someone from Check Point can comment this.

Re: behaviour after changing CoreXL instances of VS ?

_Val_ — Fri, 15 Mar 2024 08:09:43 GMT

Please open a TAC case for this

Re: behaviour after changing CoreXL instances of VS ?

emmap — Fri, 15 Mar 2024 09:01:49 GMT

This issue should have been fixed in earlier versions, if you see it again (especially on current JHFs) please raise a TAC case so we can investigate it.

Re: behaviour after changing CoreXL instances of VS ?

Christian_Koehl — Fri, 15 Mar 2024 09:41:35 GMT

Dear Wolfgang,
which JHF you have running? There is a bug in dyn-bal. It should be solved with R81.20 JHF-43.

In my environment, the bug (or maybe a different dyn-bal bug) still exits. The JHF-43 made it really much better, but didn't solved it finally.

BR,

Christian

Re: behaviour after changing CoreXL instances of VS ?

Wolfgang — Fri, 15 Mar 2024 09:49:07 GMT

We are running

HOTFIX_R81_20_JUMBO_HF_MAIN Take: 43