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
