forked from sonic-net/sonic-swss
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
portmgrd: prevent runtime failure in setting MTU on portchannel membe…
…r (PR sonic-net#3432) Prevent setting the PORT MTU on PortChannel members as it will likely fail and cause portmgrd to exit (The PortChannel itself is where the MTU gets set, not the PORT). The current code is setting a default value for an MTU (9100) even when its a PortChannel member, so this patch prevents that default value from being set. Also if a user were to incorrectly specify an MTU on a Port that is a member of the port channel via `config_db.json` this too would bring down portmgrd, so catch that and just emit a warning instead. The YANG model does NOT support checking for this. In order to not add much overhead for large port count systems, we are also lazily caching portchannel members and only using that cache on a new port being brought up or on failure to set an MTU. The current code *always* attempts to set an MTU on the PORT by setting a default here: https://github.com/sonic-net/sonic-swss/blob/c20902f3195b5bf8a941045e131aa1b863b69fd0/cfgmgr/portmgr.cpp#L163-L172 Then applies it here: https://github.com/sonic-net/sonic-swss/blob/c20902f3195b5bf8a941045e131aa1b863b69fd0/cfgmgr/portmgr.cpp#L222-L226 So it isn't crashing because the user configured the MTU in the PORT config, but rather because it is done by default when the port is created. (But it also would crash if a user set an MTU on a port which is bad since YANG doesn't do anything to prevent this). **NOTE**: this only appears to crash on a freshly loaded config at boot, if you take an existing running configuration and modify it to add a portchannel it works since the PORT is already provisioned so the default MTU setting path isn't taken in the above referenced code. This regression was caused by 8b99543 ... but just reverting that patch isn't the right solution. The startup logic does not appear to be proper as it tries to set a default MTU regardless if its valid to do so for the port or not. Logs show this issue which is a critical failure causing the entire switch to go down: ``` 2024 Dec 17 19:26:20.964259 sw1 INFO swss#supervisord: portmgrd RTNETLINK answers: Operation not permitted 2024 Dec 17 19:26:20.965353 sw1 ERR swss#portmgrd: :- main: Runtime error: /sbin/ip link set dev "Ethernet0" mtu "9100" : 2024 Dec 17 19:26:20.967020 sw1 INFO swss#supervisord 2024-12-17 19:26:20,966 WARN exited: portmgrd (exit status 255; not expected) ``` Signed-off-by: Brad House (@bradh352)
- Loading branch information
Showing
3 changed files
with
107 additions
and
5 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters