Bug 2046293
| Summary: | Configuring pref-src (src) of route not working with dad/ACD | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Thomas Haller <thaller> |
| Component: | NetworkManager | Assignee: | Thomas Haller <thaller> |
| Status: | VERIFIED --- | QA Contact: | Matej Berezny <mberezny> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9.2 | CC: | bgalvani, lrintel, mberezny, rkhan, sfaye, sukulkar, till, vbenes |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | NetworkManager-1.43.4-1.el9 | Doc Type: | No Doc Update |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 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: | |||
NML3Cfg has a mechanism for that, grep for "routes_temporary_not_available". Apparently, it doesn't work properly for the prefsrc case. note that the pref-src could also be on *another* device/profile!! And that might be activated later (or never). It would seem, we need to keep such a route around, until we can configure it. |
Kernel is very picky about accepting a route with "src" parameter. The src address must have a corresponding local route, which it usually has when the IP address is added. Otherwise configuring it fails. Say, you configure this profile: nmcli connection add \ type ethernet \ con-name x \ autoconnect no \ ipv6.method disabled \ ipv4.method manual \ ipv4.addresses 10.0.0.1/24 \ ipv4.routes "10.0.0.0/24 src=10.0.0.1 table=5000" ipv4.dad-timeout 500 this seems a sensible thing to do, because you want to use policy routing and add the device route to another table. Something similar might happen with nmcli connection add \ type ethernet \ con-name x \ autoconnect no \ ipv6.method disabled \ ipv4.method manual \ ipv4.addresses 10.0.0.1/24 \ ipv4.route-table 5000 \ ipv4.routes "10.0.0.0/24 src=10.0.0.1" ipv4.dad-timeout 500 (check both approaches, because they are not exactly the same!) Anyway. With this, DAD/ACD is delaying the addition of the IPv4 address, and the IPv4 local route does not exist. At this point, the pref-src route cannot be added yet. What must happen, is that NM notices this, and retries later when the circumstances are right. I guess, something similar could also happen with IPv6. Test that too!! The underlying problem is because kernel tries to be overly helpful, and requiring that non-trivial relations between addresses/routes are honored. When it should just accept the configuration that the user wants to make. It's not that you couldn't configure wrong routing in kernel, this only captures a very very narrow case.