nixos/networking-interfaces: make static routes configurable #27688
Conversation
|
That's strange. Wasn't net-tools deprecated in favor of iproute2? It should at least cover every use case. |
|
|
It works for me: the service is restarted when switching configuration.
Thanks. I'll try to adapt those changes to the new network-interfaces. |
rnhmjoj
force-pushed
the
routes
branch
3 times, most recently
from
834f54f
to
e5972ab
Compare
|
I have tested IPv4/6 addresses/routes. Everything is working except the stop script fails to remove IPv4 routes for some reason. |
|
|
|
I'm trying to write a test but I know exactly zero about perl. import src/nixpkgs/nixos/tests/make-test.nix
{
name = "routes";
machine = {
networking.useDHCP = false;
networking.interfaces."eth0" = {
ip4 = [ { address = "192.168.1.2"; prefixLength = 24; } ];
ip6 = [ { address = "2001:1470:fffd:2097::"; prefixLength = 64; } ];
ipv6Routes = [
{ address = "fdfd:b3f0::"; prefixLength = 48; }
{ address = "2001:1470:fffd:2098::"; prefixLength = 64; nextHop = "fdfd:b3f0::1"; }
];
ipv4Routes = [
{ address = "10.0.0.0"; prefixLength = 16; }
{ address = "192.168.2.0"; prefixLength = 24; nextHop = "192.168.1.1"; }
];
};
virtualisation.vlans = [ ];
};
testScript = ''
my $ipv4Table = <<'END';
10.0.0.0/16 scope link
192.168.1.0/24 proto kernel scope link src 192.168.1.2
192.168.2.0/24 via 192.168.1.1
END
my $ipv6Table = <<'END';
2001:1470:fffd:2097::/64 proto kernel metric 256 pref medium
2001:1470:fffd:2098::/64 via fdfd:b3f0::1 metric 1024 pref medium
fdfd:b3f0::/48 metric 1024 pref medium
END
$machine->start;
$machine->waitForUnit("network.target");
$machine->succeed("ip -4 route list dev eth0 | head -n3") eq "$ipv4Table";
$machine->succeed("ip -6 route list dev eth0 | head -n3") eq "$ipv6Table";
$machine->succeed("systemctl stop network-addresses-eth0");
$machine->succeed("ip -4 route list dev eth0 | head -n-3") eq "";
$machine->succeed("ip -6 route list dev eth0 | head -n-3") eq "";
'';
}How do I make an assertion? |
|
Thank you. |
|
I prefer this way because it's consistent with |
|
I think it's complete now. |
|
What happened here? Who were you talking to? 😲 |
|
No idea, the messages just disappeared today. It was @volth |
|
Updates? What happened to the messages? |
| ''; | ||
| }; | ||
|
|
||
| nextHop = mkOption { |
There was a problem hiding this comment.
Calling this option nextHop is IMHO a bit misleading because there is a nexthop option in ip route that is used for multipath routes yet this option only sets via.
| @@ -1059,6 +1117,9 @@ in | |||
| '' + optionalString (i.mtu != null) '' | |||
| echo "setting MTU to ${toString i.mtu}..." | |||
| ip link set "${i.name}" mtu "${toString i.mtu}" | |||
| '' + '' | |||
| echo -n "bringing up interface... " | |||
| ip link set "${i.name}" up && echo "done" || (echo "failed"; exit 1) | |||
There was a problem hiding this comment.
Do you recall why this is necessary? It should be fine but just interested. :)
There was a problem hiding this comment.
Ah, I meant the bringing up as a whole but didn't see that this was removed from the addresses service. This is fine! 👍
| @@ -189,6 +223,30 @@ let | |||
| ''; | |||
| }; | |||
|
|
|||
| ipv4Routes = mkOption { | |||
There was a problem hiding this comment.
I don't really like the extra v in ipv[46]Routes because the address options are just named ip[46]. Even without the v, the interface looks inconsistent to me because it is not clear that ip[46] is only for configuring addresses. No better idea how we should structure the interfaceOpts either.
There was a problem hiding this comment.
So, what about ip{4,6}.{routes,addresses}?
| }; | ||
|
|
||
| options = mkOption { | ||
| type = types.str; |
There was a problem hiding this comment.
I think it would be more appropriate to use an attrset of strings here. That also makes it more easily to override.
|
I'm wondering if we also need global routes that are not bound to interfaces. For instance, I'm adding unreachable routes to RFC1918 subnets on my routers to no traffic to them except explicitly defined via the default gateway (which is always an ISP in my case). |
rnhmjoj
force-pushed
the
routes
branch
2 times, most recently
from
5f9a127
to
fa6de1b
Compare
|
Any chance to get this into 17.09? |
|
I started working on
|
|
Fixed another conflict. |
|
Just want to express my thanks for your continuous effort of rebasing this. |
|
Thank you, also thank you for trying to get the maintainers' attention on this. |
|
@GrahamcOfBorg test networkingProxy networking.networkd networking.scripted nfs4 |
|
Failure on aarch64-linux (full log) Partial log (click to expand)
|
|
Success on x86_64-linux (full log) Partial log (click to expand)
|
|
Observations: and old PR, useful cleanup, looks fine to me, unchanged tests still pass, no objections even though multiple people have read the code, enthusiastic support from @oxij , commit logs in the relevant directory do not make me want to mention someone… |
|
Whooohoo! **Happy dance** Thanks to everyone involved!
|
|
Hopefully it's not hard to fix, but this breaks NixOS configurations using virtualbox, giving error: @GrahamcOfBorg test virtualbox.headless |
|
Failure on aarch64-linux (full log) Partial log (click to expand)
|
|
Failure on x86_64-linux (full log) Partial log (click to expand)
|
|
Does diff --git a/nixos/modules/virtualisation/virtualbox-host.nix b/nixos/modules/virtualisation/virtualbox-host.nix
index 91a46ac852b..47ae59bb38a 100644
--- a/nixos/modules/virtualisation/virtualbox-host.nix
+++ b/nixos/modules/virtualisation/virtualbox-host.nix
@@ -117,16 +117,16 @@ in
VBoxManage hostonlyif create
cat /tmp/VBoxSVC.log >&2
fi
'';
postStop =
''
VBoxManage hostonlyif remove vboxnet0
'';
};
- networking.interfaces.vboxnet0.ipv4.addresses = { address = "192.168.56.1"; prefixLength = 24; };
+ networking.interfaces.vboxnet0.ipv4.addresses = [ { address = "192.168.56.1"; prefixLength = 24; } ];
# Make sure NetworkManager won't assume this interface being up
# means we have internet access.
networking.networkmanager.unmanaged = ["vboxnet0"];
})]);
}fix it? |
|
See #35185. |
|
Thank you for the fix. |
|
I don't know... maybe retrying a few times with a loop before giving up?
Seems ok as a workaround to me.
But I think this needs to be reported upstream.
@volth Did you report this upstream yet?
|
Motivation for this change
#27380
Things done