Virtualizing my router - any experience to share? Pos/cons?

[non_burglar@lemmy.world]

For sure, if your thing is leaning into network configs, nothing wrong with it, especially if you have proper failover set up.

I think virtualized routing looks fun to the learning homelabber, and it is, but it does come with some caveats.

[oisteink@feddit.nl]

So 3+ hosts for clustering or 2 hosts and an qdevice to fake it

[rivalarrival@lemmy.today]

I used the same approach at the family business for years without any major problems. Go for it.

[kalpol@lemmy.world]

It works great as long as you have a method to access the server directly when the router machine is down. A laptop set to a static IP on the same subnet will let you access the host when you b0rk something. Keep a backup config on that machine
It's pretty great though. Just remember pfsense won't support more than 7 external interfaces when you start getting crazy with vlans

[resetbypeer@lemmy.world]

Ran it for 1.5 years and it stepped away from it. Besides the fact that as soon as your host goes down or you do maintenance on your host, the network becomes kind of useless (ESP if you have multiple segmentated nets). The other thing to keep in mind is to pass through physical nics. Using just the vnics will potentially lead to security risks.

[non_burglar@lemmy.world]

OVS is fine, you can make live changes and something like spanning port traffic is a bit less hassle than using tc, but beyond that, it's not really an important component to a failover scenario over any other vswitch, since it has no idea what a TCP stream is.

[gamegod@lemmy.ca]

The other thing to keep in mind is to pass through physical nics. Using just the vnics will potentially lead to security risks. That’s the reason I went back to physical fws.

I could throw an extra NIC in the server and pass it through, but what are the security risks of using the virtualized NICs? I'm just using virtio to share a dedicated bridge adapter with the router VM.

[gamegod@lemmy.ca]

Even if the virtualized router is down, I'll still have access to the physical server over the network until the DHCP lease expires. The switch does the work of delivering my packets on the LAN, not the router.

Thanks for the tip about the pfSense limit. After running pfSense for like 8 years, my opinion is that is flush with features but overall, it's trash. Nobody, not even Netgate, understands how to configure limiters, queues, and QoS properly. The official documentation and all the guides on the internet are all contradictory and wrong. I did loads of testing and it worked somewhat, but never as well as it should have on paper (ie. I got ping spikes if I ran a bandwidth test simultaneously, which shouldn't happen.) I don't necessarily think OpenWRT is any better, but I know the Linux kernel has multithreaded PPPOE and I expect some modern basics like SQM to work properly in it.

[kalpol@lemmy.world]

Even if the virtualized router is down, I'll still have access to the physical server over the network until the DHCP lease expires. The switch does the work of delivering my packets on the LAN, not the router.

Yes, of course it depends on your network topology. If you have a link in the same subnet you're good (and can configure a static IP if need be). But if you're using vlans you can get in a pickle if the router is down. In my setup everything on the user side is segregated so if the router goes down I have to take a dedicated management laptop and plug into the host management network directly on the management switch where i keep a port empty. This maintains segregation and in practices means I take my ancient Acer Aspire One used for nothing else into the server room that looks strangely like a laundry room and plug it in.

[ikidd@lemmy.world]

Yes. You can just get by with 2 devices but you need to set expected_votes=1 in the cluster config somewhere, don't recall where, and I've encountered issues with stability with that solution, seems like it'll get undone though I haven't used it for years to say if that's still the case.

The q-device will work on anything Linux that's available when the second node is down. Not having the tie-breaker isn't the end of the world, it just means you have to go in after you bring up the second node and start some things manually, and if you're replacing nodes in a 2-node cluster, it's much nicer to have the q-device.