eyJhb changed the topic of #nixos-on-your-router to: NixOS on your Router || https://logs.nix.samueldr.com/nixos-on-your-router
teto has quit [Ping timeout: 260 seconds]
flokli has quit [*.net *.split]
flokli has joined #nixos-on-your-router
Shados has quit [Read error: Connection reset by peer]
Shados has joined #nixos-on-your-router
veleiro has quit [Ping timeout: 260 seconds]
teto has joined #nixos-on-your-router
rcorrear has left #nixos-on-your-router ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
teto has quit [Ping timeout: 260 seconds]
teto has joined #nixos-on-your-router
<q3k> planning on rebuilding our edge router (BIRD + a bunch of vlans and l3 routing, dns, dhcp) on NixOS this weekend
<q3k> anyone have any protips on that? should i avoid networking.interfaces and instead use something else?
<q3k> i've done this already on some less produciony hardware ie. on an APU at home, and networking.interfaces worked _fine_ for me, but i was slightly sketched out by how janky some nixos-rebuild switches failed
<q3k> like, i'd like to avoid downing interfaces unless strictly necessary, etc
<q3k> and if there's some obvious better solution than using networking.interfaces then i'd like to know
<cransom> i think the only other option is to use networkd. i have no personal experience that it is better or worse, stability wise, than the scripted setup.
<q3k> i'm not sure i trust networkd enough here tbh, at least from my past experiences on other OSes
<q3k> it seemed more geared towards desktops/servers than routers
<hexa-> networkd is much saner than scripted networking
<q3k> hexa-: didn't you have issues with it?
<hexa-> i have networkd setups on machines that do small scale ebgp/igp using bird/babeld
<hexa-> I did
<hexa-> I reported them upstream and they got fixed in a timely manner
<q3k> can i use it without its builtin DHCP server/client?
<hexa-> i also have networkd setups that use lacp+vlans, wireguard, etc.
<hexa-> built-in dhcp client … I'm not sure that is advisable
<hexa-> build-in dhcp server … yes
<q3k> well i'm not planning to be a dhcp client at all
<q3k> but i would like to make it so that it never even attempts to run/touch DHCP on interfaces
<q3k> like, one of these goes to a fairly busy IXP
<q3k> i don't want to suddenly become a DHCP server there, or do proxy arp, or any other stupidity
<cransom> it's dhcp-client is buggy?
<q3k> or have that interface flap because systemd-networkd decided it's a good idea to restart it for no reason
<q3k> also it's those sort of bugs that make me feel it might just not be ready for serious use: https://github.com/systemd/systemd/issues/11575
<{^_^}> systemd/systemd#11575 (by timbuchwaldt, 1 year ago, closed): systemd-networkd fails with large route table
<q3k> like a year ago it would crap itself with a large kernel routing table
<hexa-> q3k: ManageForeignRoutes=no is what you want
<q3k> yeah but that seems like ... a hack?
<q3k> like it's an afterthought
<hexa-> it certainly is
<q3k> like it was never designed for this usage
<q3k> so maybe i just shouldn't use it for this, and instead go with something dumber
<q3k> like what does ManageForeignRoutes even do
<q3k> i get that =no disables loading kernel rt entries into systemd-networkd
<q3k> but why does it do that
<q3k> how does flipping that off affect things
<hexa-> idk
<q3k> yeah and that's the thing that's sketchy
<q3k> i can't have magic here
<{^_^}> systemd/systemd#14858 (by ssahani, 32 weeks ago, merged): network: Add support to ignore foreign routes
<q3k> yeah that doesn't answer my question unless i read more code/documentation to understand what systemd-networkd even does with these routes in the first place
<hexa-> sure
<cransom> i chuckle that in the past, you'd ask your upstreams not give you a full table because the hardware couldn't keep up. we've gone weirdly backwards and the hardware is astronomically faster, but the software is that much worse.
<q3k> i mean networkd is not the first piece of software that hates a full dfz table in the kernel
<q3k> notably dhcpcd absolutely shits itself, too
<hexa-> yeah, servers shouldn't dhcp in the first place
<q3k> sure, but that's not about whether this is dhcpcd of some other daemon
<q3k> point is, a full table in the kernel is a pretty footguny environment
<q3k> for software that doesn't expect that *slaps roof of netlink* this thing can fit so many routes
<q3k> toxic environemtn for software that wasn't written by people who experienced internet routing :P
<q3k> and that's certainly the vibe i get from networkd
<cransom> 'how hard can it be'
<q3k> it's even the basic paradigms that to me seem like poor assumptions, like 'connection' or 'a connection is up or down' or 'there is such a thing as being able to tell that a connection is up or down'
<q3k> all of which flies out the window when you're multihoming and when you have several interfaces give you access to different parts of The Internet
<hexa-> fwiw, i can restart systemd-networkd without a bgp session flapping
<hexa-> that's on my toy server participating in dn42
<hexa-> networkctl knows reload
<hexa-> and that configures stuff, that isn't yet configured
<hexa-> if you want to reconfigure stuff that already exists you can networkctl reconfigure dev
<hexa-> <dev>
<q3k> yeah i'm sure it works fine for dn42
<q3k> but
<q3k> root@edge01:~# ip r | wc -l
<q3k> 835654
<q3k> iirc dn42 has quite less routes than this
<hexa-> root@core1:~/ ip r s t ebgp | wc -l
<hexa-> 813439
<hexa-> it's not like I don't know what you're talking about
<q3k> dn42 has someone announce the DFZ into it?
<hexa-> no
<hexa-> i maintain a bgp speaker in the dfz
<hexa-> on linux
<q3k> ah, sure, but we were talking about your experience with networkd on a dn42 box
<hexa-> that's because i haven't migrated my dfz router to networkd
<hexa-> but that's because it works pretty well as it is
<q3k> right, and i'm gonna let you do that first before i follow :P
NinjaTrappeur1 has joined #nixos-on-your-router
NinjaTrappeur1 has quit [Client Quit]
NinjaTrappeur has quit [Quit: WeeChat 2.8]
NinjaTrappeur has joined #nixos-on-your-router
teto has quit [Ping timeout: 240 seconds]
<cransom> hrm. i haven't had a networking title since 2016. that must have opted me out of the newsletter that would have told me that cisco opened up eigrp and it's an open standard now.
<andi-> the issues networkd had with huge amounts of routes in kernel table should be fixed.
<andi-> the previous release allowed keeping them untouched
<andi-> the current version should remove the cases where the receive buffer overrusn
superherointj has joined #nixos-on-your-router
NinjaTrappeur has quit [Ping timeout: 240 seconds]
NinjaTrappeur has joined #nixos-on-your-router
superherointj has left #nixos-on-your-router ["Leaving"]
ottidmes has quit [Ping timeout: 272 seconds]
ottidmes has joined #nixos-on-your-router
NinjaTrappeur has quit [Quit: WeeChat 2.9]
NinjaTrappeur has joined #nixos-on-your-router
betawaffle has quit [Ping timeout: 260 seconds]
mdlayher has quit [Ping timeout: 260 seconds]
mdlayher has joined #nixos-on-your-router
betawaffle has joined #nixos-on-your-router
feepo has quit [Ping timeout: 244 seconds]
kalbasit has quit [Ping timeout: 244 seconds]
mdlayher has quit [Ping timeout: 260 seconds]
betawaffle has quit [Ping timeout: 260 seconds]
betawaffle has joined #nixos-on-your-router
mdlayher has joined #nixos-on-your-router
kalbasit has joined #nixos-on-your-router
teozkr_ has quit [Ping timeout: 260 seconds]
feepo has joined #nixos-on-your-router
teozkr_ has joined #nixos-on-your-router
mdlayher has quit [Ping timeout: 246 seconds]
betawaffle has quit [Ping timeout: 258 seconds]
mdlayher has joined #nixos-on-your-router
betawaffle has joined #nixos-on-your-router