behavior after changing CoreXL instances of VS ?

[Wolfgang]

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.

[Bob_Zimmerman]

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.

[Wolfgang]

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

[Bob_Zimmerman]

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.

[Wolfgang]

I hope someone from Check Point can comment this.

[_Val_]

Please open a TAC case for this

[Christian_Koehl]

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

[Wolfgang]

We are running

HOTFIX_R81_20_JUMBO_HF_MAIN Take: 43

[emmap]

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.