Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Sven_Glock
Advisor

Dynamic Dispatcher in VSX on SP does not forward the connections equally to all CoreXL instances

Dear community,

as I already experienced production issues I want inform you that sk169352 seems also be relevant for R80.30SP JHF49.

I can only say that it happens on maestro, but I think it also happens on the big chassis.
The workaround in sk169352 helps to reduce the wight of the issue.

As far as I know there is no JHF available fixing this issue yet.
I already informed the owner of the SK.

To check if this issue also hits your environment use this command on the relevant VS:
g_fw ctl multik stat

Expected output:
[Expert@fw-ch01-01:5]# g_fw ctl multik stat
-*- 1 blade: 1_01 -*-
ID | Active | CPU | Connections | Peak
----------------------------------------------
0 | Yes | 2-5 | 44656 | 76338
1 | Yes | 2-5 | 4689 | 26566
2 | Yes | 2-5 | 677 | 26215
3 | Yes | 2-5 | 582 | 25974
-*- 1 blade: 1_02 -*-
ID | Active | CPU | Connections | Peak
----------------------------------------------
0 | Yes | 2-5 | 43071 | 73391
1 | Yes | 2-5 | 5099 | 17608
2 | Yes | 2-5 | 756 | 17872
3 | Yes | 2-5 | 585 | 17898

The way you have to implement the workaround differs a bit from the SK:

The change kernel parameter temporary use:
g_fw ctl set int fwmultik_enable_round_robin 1
g_fw ctl set int fwmultik_enable_increment_first 1

For boot resistence add parameter to fwkern.conf:
g_update_conf_file fwkern.conf fwmultik_enable_round_robin=1
g_update_conf_file fwkern.conf fwmultik_enable_increment_first=1

Have a wonderful day!

 

Cheers

Sven

 

6 Replies
_Val_
Admin
Admin

I am not sure I understand. The SK you reference is for regular Gaia, not SP. 

0 Kudos
Reply
Sven_Glock
Advisor

Hi Valeri,

you are right.
The same issue happens on SP, but SP is not referenced in the SK and I did not find any other SK which describes the same behavior in SP.
So I decided to inform the users proactive to avoid other users experiencing the same issue I experienced.

Sorry if my english leads to misunderstanding.


Sven_Glock
Advisor

BTW: SK is now updated!

0 Kudos
Reply
genisis__
Collaborator

I've used this in VSX R80.20, however please note the value of the parameters (1) is now default from R80.40.  So if you have a R80.20 installation, remove the parameters from the fwkern.conf file, after upgrade just check the value of these parameters are set to 1 by default.

 

0 Kudos
Reply
Sven_Glock
Advisor

Hi @genisis__  you are not talking about scalable plattform or maestro, am I right?

0 Kudos
Reply
genisis__
Collaborator

no - pair of 15600s running R80.20 converted to VSX systems, however the parameters can be removed prior to upgrading to R80.40.

Another little pointer, and do check with TAC.  There is a bug (no bug id allocated yet as we discovered it a few weeks ago) if you have vlan interfaces after in-place upgrade you may find some of these are not working ie. arp issues.  Checkpoint do have a fix (I've not tested it yet as I'm waiting for a maintenance window).  This related to moving from kernel version 2.6.x to 3.x.

0 Kudos
Reply