Chassis Alarm Potential slow peers are: spmd When Fusion Configured
I have two EX9204 in an mc-lag configuration on JunOS 17.1 and whenever Fusion is configured, both chassis throw a system alarm. I have a Fusion configured as a satellite-management cluster consisting of two EX3400-24T. Anybody have any ideas what this alarm means and/or how to rectify?
> show system alarms 1 alarms currently active Alarm time Class Description 2017-04-12 18:52:34 PDT Minor Potential slow peers are: spmd
Hey, thanks for assisting! It will be much appreciated as it's holding me up from starting to roll this into production.
Current case number is 2017-0413-0577, and preceeding case number was 2017-0329-0957 as that one was what let me to discover this chassis alarm/warning. I am very curious to see what you or your colleagues are able to discover.
I will upload the latest logs but what I noticed and able to replicate consistently is whenever Fusion is configured, the alarm will appear 5-8 minutes afterwards and will disappear once I take Fusion out of the configuration.
As an update for everyone, a PR has been elevated. I've been also informed that this warning alarm is pretty much benign and it occurs only upon the restart of the SPMD daemon. Technical explanation is as follows:
There is no issue when the device comes up with fusion configuration for the first time. Issue is seen only when re-spawned with a new process id, which can be achieved by just restarting the SPMD daemon.
SPMD rtsock client is in stuck state due to processed ifstate ack is not 0. unless the ifstate that's acked is 0. rtsock client will continue to be in stuck state hence the alarm is noticed. Even though, ifsmon shows the states acked by SPMD is 100%, this issue is still seen. Looking further into the code to root-cause the issue.