| 10 Jul 2025 |
| maciel310 joined the room. | 02:58:34 |
maciel310 | Hey all, hoping someone might be able to help with an issue I'm hitting configuring VLANs. Use case is pretty simple, the only connection should be over the vlan, no untagged traffic or IP assigned. Following the docs (https://nixos.wiki/wiki/Systemd-networkd#VLAN) I came up with this systemd-networkd config, but pinging even local addresses returns unreachable. Any thoughts, or ideas on how to debug?
systemd.network = {
enable = true;
netdevs = {
"20-vlan30" = {
netdevConfig = {
Kind = "vlan";
Name = "vlan30";
};
vlanConfig.Id = 30;
};
};
networks = {
"30-enp0s20f0u1u2" = {
matchConfig.Name = "enp0s20f0u1u2";
vlan = [ "vlan30" ];
networkConfig.LinkLocalAddressing = "no";
linkConfig.RequiredForOnline = "carrier";
};
"40-vlan30" = {
matchConfig.Name = "vlan30";
address = [ "192.168.30.7/24" ];
routes = [
{ Gateway = "192.168.30.1"; }
];
linkConfig.RequiredForOnline = "routable";
};
};
};
| 04:43:33 |
maciel310 | And here's the output of a couple commands to show the state, LMK if there are any other commands that would be helpful
$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 enp0s20f0u1u2 ether carrier configured
3 vlan30 vlan routable configured
3 links listed.
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp0s20f0u1u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 1c:bf:ce:a7:84:b8 brd ff:ff:ff:ff:ff:ff
altname enx1cbfcea784b8
3: vlan30@enp0s20f0u1u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 1c:bf:ce:a7:84:b8 brd ff:ff:ff:ff:ff:ff
inet 192.168.30.7/24 brd 192.168.30.255 scope global vlan30
valid_lft forever preferred_lft forever
inet6 fe80::1ebf:ceff:fea7:84b8/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
| 05:42:58 |
hexa (clat on linux when) | looks good from here | 12:10:14 |
hexa (clat on linux when) | I'd expect the issue will be on the switchport or the other endpoint | 12:10:36 |
hexa (clat on linux when) | different question âĶ what is the least awful way to make sure a consumer of a module I'm providing uses a DNSSEC validating resolver? | 14:21:04 |
hexa (clat on linux when) | given that the resolver can be on the local machine (preferable) or not this seems a bit difficult to assert on ðĪŠ | 14:22:50 |
emily | seems like not really something you can detect before runtime | 14:23:05 |
Sandro ð§ | within reason probably not at all | 14:23:10 |
hexa (clat on linux when) | so I'm wondering what the right approximation would be | 14:23:11 |
Sandro ð§ | You could check if kresd is used with dnssec checks on | 14:23:24 |
emily | I would just do nothing or have services.X.yesIPromiseImUsingDNSSec | 14:23:25 |
emily | especially for remote it's hopeless, but even locally there can be all kinds of layers between an enabled service and what actually ends up being used for DNS resolution | 14:23:49 |
hexa (clat on linux when) | so one thing I could do is check for networking.resolvconf.useLocalResolver | 14:24:14 |
hexa (clat on linux when) | the other thing, that I found super awful was
lib.any (with config; [
services.bind.enable
services.dnsmasq.enable
services.kresd.enable
services.unbound.enable
services.pdns-recursor.enable
]);
| 14:25:03 |
hexa (clat on linux when) | * the other thing, that I found super awful was
lib.any (with config; [
services.bind.enable
services.dnsmasq.enable
services.kresd.enable
services.unbound.enable
services.pdns-recursor.enable
]);
| 14:25:05 |
emily | that would (sorry) break resolved with DNSSEC | 14:25:24 |
hexa (clat on linux when) | but then I found people used dnscrypt2-proxy and other weird stuff | 14:25:28 |
emily | dnscrypt-proxy2 doesn't do DNSSEC validation | 14:25:42 |
hexa (clat on linux when) | resolved is fucked for this use case, I don't care ð | 14:25:47 |
emily | I think it'll pass on the bit from the upstream resolver and that's all | 14:25:52 |
emily | I don't really think asserting on dynamic network conditions is something a module should be doing at all tbh. if the software absolutely needs the DNSSEC validation bit in responses it should be checking for it itself | 14:26:32 |
hexa (clat on linux when) | oh, it does | 14:27:32 |
hexa (clat on linux when) | the software is postfix for example | 14:27:36 |
hexa (clat on linux when) | postfix/smtp[2110025]: warning: DNSSEC validation may be unavailable
postfix/smtp[2110025]: warning: reason: dnssec_probe 'ns:.' received a response that is not DNSSEC validated
| 14:28:05 |
hexa (clat on linux when) | that's what you get with resolved fwiw | 14:28:10 |
K900 | Then just let it fail IMO | 14:28:15 |