Bug 2150888
| Summary: | MACsec tunnel is deactivated when the remote host is not reachable, and never retries | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Beniamino Galvani <bgalvani> | ||||
| Component: | NetworkManager | Assignee: | Íñigo Huguet <ihuguet> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Desktop QE <desktop-qa-list> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 9.2 | CC: | bgalvani, ferferna, lrintel, rkhan, sfaye, sukulkar, till | ||||
| Target Milestone: | rc | Keywords: | Triaged | ||||
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2023-07-20 10:01:31 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Beniamino Galvani
2022-12-05 14:30:52 UTC
I think the issue is related to the carrier state of the macsec interface. With the reproducer in attachment I see that when NetworkManager-config-server is not installed, the macsec connection deactivates and stay down once the remote peer is unreachable. With NetworkManager-config-server installed, the macsec connection always stays up because NM ignores the carrier of the interface. So, a workaround to the issue is to either install NetworkManager-config-server or to create the following configuration snippet: # cat /etc/NetworkManager/conf.d/10-macsec-ignore-carrier.conf [device-macsec] match-device=type:macsec ignore-carrier=yes In any case, there should be a mechanism to retry the activation after the macsec interface gets carrier when NM-config-server is not installed. Created attachment 1930137 [details]
Reproducer
I have used the reproducer and I think that Beniamino is correct. This is what happens when the link comes down with different combinations of ignore-carrier and autoconnect: - ignore-carrier=no, autoconnect=no: macsec connection goes down and stays down - ignore-carrier=no, autoconnect=yes: macsec connection goes down but reconnects with some delay after the link is up again - ignore-carrier=yes: macsec connection doesn't go down and connectivity is OK after the link is up again In all the cases it seems to be doing the correct behaviour, the same than other connection types with each configuration. A potential improvement would be to set ignore-carrier=yes by default for macsec devices, as it is done for bond, bridge, etc. I don't see any reason to implement a reconnection timer, treating macsec in a special way. All devices configured with ignore-carrier=no and autoconnect=no suffer the same problem. So another potential improvement, not only for macsec but for any connection type, would be to implement an "autoreconnect" feature: 1. The connection has autoconnect=no because the user don't want it to be enabled automatically 2. The user manually enable the connection 3. Links comes down so the connection is bring down 4. Now, connectivity is lost until it is manually restored. With the new autoreconnect=yes, connectivity would be automatically restored when the link is up again. As explained in comment 4, and after discussing it with the rest of the team, we think that the behaviour is correct. To have the desired behaviours of Macsec's connectivity being restored, the user needs to set either ignore-carrier=yes or autoconnect=yes. This is coherent with the behaviour of other similar device/connection types. Closing as NOTABUG. For the "autoreconnect" idea, I have filled a feature request upstream: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1353 |