Who rated this post

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