NM backend does not accept "scope: link" routes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
netplan.io (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Hirsute |
Fix Released
|
Undecided
|
Unassigned | ||
Impish |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
The NetworkManager snap (using the libnetplan YAML backend) makes use of the
"link" routing scope in certain situations, which is represented by an empty or
unspecified gateway/next_hop field in the keyfile definition (e.g.
"route3=2.2.2.2/7", "route4=
We need to make sure netplan is able to read and write such routing information.
[Test Plan]
In addition to runing & passing the full set of unit- and integration-tests
(that contains new tests to check for this regression), as described in
https:/
to make sure the 'netplan try' command is working properly:
$ mkdir -p tmp/etc/netplan
$ cat tmp/etc/
network:
renderer: NetworkManager
ethernets:
eth0:
addresses: [1.2.3.4/24, fe20::3/16]
routes:
- to: 2.2.2.2/7
scope: link
- to: 3.3.3.3/6
scope: link
metric: 4
- to: 4:5:6:7:8:9:0:1/63
scope: link
metric: 5
$ /usr/lib/
$ cat tmp/run/
=> Make sure it generated the "scope: link" routes with empty/missing gateway.
autopkgtest logs:
* Impish:
https:/
https:/
https:/
https:/
https:/
* Hirsute:
https:/
https:/
https:/
https:/
https:/
* Focal:
https:/
https:/
https:/
https:/
https:/
[Where problems could occur]
This upload touches netplan's keyfile parser and keyfile generator, if anything
goes wrong it could impact the NetworkManager snap (using the libnetplan YAML
backend & keyfile parser) and the netplan generator itself in cases where the
NetworkManager backend/renderer is used.
[Other Info]
The full set of autopkgtest logs will be attached after the upload is accepted
into -proposed and the tests have been run on the official autopkgtest.u.c
infrastructure.
=== Original Description ===
NetworkManager keyfiles allows to specify "scope: link" routes, by leaving the gateway/next_hop field unspecified, e.g.:
route3=2.2.2.2/7
route4=
route3=
To keep compatibility, netplan needs to be able to accept "scope: link" routes for the NM backend and render the keyfile accordingly.
description: | updated |
Changed in netplan.io (Ubuntu Jammy): | |
status: | New → Fix Committed |
description: | updated |
Hello Lukas, or anyone else affected,
Accepted netplan.io into focal-proposed. The package will build now and be available at https:/ /launchpad. net/ubuntu/ +source/ netplan. io/0.103- 0ubuntu5~ 20.04.3 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https:/ /wiki.ubuntu. com/Testing/ EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification- needed- focal to verification- done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed- focal. In either case, without details of your testing we will not be able to proceed.
Further information regarding the verification process can be found at https:/ /wiki.ubuntu. com/QATeam/ PerformingSRUVe rification . Thank you in advance for helping!
N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.