Consider macsec sectag header size in getPortMtu during InitializePort#2789
Consider macsec sectag header size in getPortMtu during InitializePort#2789judyjoseph merged 1 commit intosonic-net:masterfrom
Conversation
|
@dgsudharsan can you take a look at this PR, we are seeing an issue in broadcom based platforms -- where in with macsec when we add the SEC_TAG_HEADER size it goes beyond the MAX MTU supported in SAI and it errors out. |
We do not have macsec in our platforms. However I am not sure if you need to reduce by default for all scenarios. I prefer skipping setting the MTU when its greater than max allowed MTU and later setting it when configuration is played to have value 9100 |
What I did
With macsec profile attached on multiple interfaces, there is a orchagent crash due to SIGABRT seen in Broadcom based devices.
Steps to recreate
Why I did it
During the InitializePort, on broadcom platforms, the getPortMTU() SAI call returns back the max value supported by ASIC.
This crash in the above logs is due to a race condition were in macsecorch/portsorch tries to set the MTU by adding the MACSEC_SEC_TAGSIZE to this max MTU value resulting in a MTU above what SAI nsupports.
Ideally the port MTU should have been configured to the port MTU ( 9100 ) before macsecmgt/macsecorch gets a chance to update the port MTU to include the SEC_TAG_SIZE of 32 bytes. But if that don't happen and PortsOrch::setMACsecEnabledState is called to enable MACSEC from macsecorch this code (https://github.com/sonic-net/sonic-swss/blob/master/orchagent/portsorch.cpp#L8233) -- will set the MTU as the max MTU returned from SAI + 32 bytes, resulting in SAI_STATUS_INVALID_PARAMETER.
Fix is to reduce the MTU got from SAI during initializePort to take care of MAX_MACSEC_SECTAG_SIZE. We need not check if this is a macsecPort -- it will not be set as a macsecPort by then here during InitializePort is called.
How I verified it
Verified the same steps and no crash seen.
Details if related