Network evolutions

Thus far, this is looking to be the evilicious plan.

  1. The ns1 VM on zeta will be converted from primary name server that is authoritative for and forwards to external DNS, to being only authoritative for my LAN and providing nothing else.
  2. Cream will be unretired and converted into infrastructure.
    • DHCP services (v4/v6)
    • DNS services ala ns2: secondary for my LAN and forwarding to external DNS.
    • Add CNAME aliases for ns3 and dhcp because I’m silly that way.
  3. Reconfigure Eero to use my Raspberry Pi zero ns2 and Cream as its name servers.

The reasoning for this is while Zeta could provide DHCP services easily and the VM running name services has been effective, Zeta not a machine that I want as a single point of failure—but as a single point of truth, it’s convenient.

Notion here being if Zeta sees downtime, as long as it is less than ns2/ns3 take to expire the local zone information, the impact across my household is just the inconvenience of fixing a computer. That is to say, either transient enough of a failure not to cripple things, or epic enough to convert ns2 over into the authoritive using the already in place ready to swap over into master mode setup that I have. And that simply put, Cream wouldn’t be intended to be fucked with or rebooted, and would in tern have a similar failover of moving to Eero’s DHCPv4 and re-enabling forwarding on ns1.

Except for two pains in my ass:

  1. Cream’s CMOS battery has died in storage since its retirement.
  2. Cream is refusing to boot the install media.

Actually, I should probably just see if Magic (my old Raspberry Pi 2) is still laying around somewhere or donate Victory (my Raspberry Pi 3/8G) to the mission. I had intended to load RHEL9, but Debian and I are still on friendly terms :).

Plus, Cream’s tenor as my previous file server included a history of the NUC being a pain in my ass!

A Rough Network Plan

Now that the great network migration phase two is pretty stable, where I have the new Eero providing the backbone and a pair of name servers providing DNS with a hand managed zone, it’s time for planning the next phase of the operation. That is to say, DHCP services.

For the most part, I stick to IPv6 addresses now with an IPv6 Unique-Local providing the internal definition of my environment. Eero seems to let clients SLAAC away but at some point, I need to snoop closer on its IPv6 support to see if it is doing any kind of goodness like RDNSS/DNSS, but it mostly does DHCPv4.

So, I’m seeing two points of interest here for my DNS arrangements.

Option A.) Ignore the IPv4 world totally and setup DHCPv6 services for my dynamic updates needs. After all, I mostly want AAAA-records not A-records.

Option B.) Set Eero to the good ol’ you’re on your own pal mode and setup both DHCPv4 and DHCPv6 services.

Perhaps I will start with option A, since it is closer to DWIW and should get me what I want; which is IPv6 with dynamic updates to my local domain. But here’s a little thought for option B using Eeero’s default /22 network as a point of reference for the addressing scheme.      -> - -> -> broadcast -> range for routing services; e.g. eero/ap. -> deprecated, reserved for fallback to eero. -> range for network services; e.g., dns, dhcp -> DHCPv4 pool -> | ~512 addresses, half the space.

This would effectively give a static space equal to the first /24 worth of the network that’s intended to be hands of for the oh-shit plan. While the DHCPv4 leasing is pretty aggressive on the Eero, I don’t think I’ve see any devices allocated higher than the first octet. The idea being nothing that’s not a router, an access point, or something getting a lease from switching from my server back to the Eero’s DHCP server should land in this portion of the network.

Following that would be a static space equal to the second /24 worth of the network, intended to be allocated for services. Either by static allocation or just making a static reservation. Let’s just say, as much as I like technology, I’ve managed long enough with a lone /24 for my entire household that I’m sure I’m not going to pull 254 static IPv4 addresses out of my ass anytime soon.

Meanwhile the portion of the network roughly equal to the last /23 of the network, effectively the back half of the network and least likely to be interfered with if the Eero ever happens to ‘forget’ its in static mode, would be client addresses. Which are very much intended to be “Don’t give a fuck about” addresses in the sense that the only IPv4 addresses I use are cases like using dig to poke one of my name servers and not wanting to type its IPv6.

One of the food for thought items on my plate is whether or not I want to ‘unretire’ my old file server, Cream, and turn it into a replacement for ns2. Right now, ns2 is running off a Raspberry Pi Zero W that was originally intended to be a RaSCSI drive for my PowerBook.

Ahh, well, I’ve got other things to do for the moment.

Home network version 7

Recently, I decommissioned my ASUS RT-AC68, A.K.A. the single best piece of networking equipment that I have ever owned (and at this point, the chief contender is a null modem cable). <S> for your decade of service little guy!

Based on the ASUS’s iPhone 4 grade horsepower and almost fast enough speed of Wi-Fi 5 having lasted so long, the key choice in replacing things had two major criteria:

  1. Wi-Fi 7 (802.11be) support.
  2. Mesh network.

The first criteria is driven by the fact that if I’m doing it now as Wi-Fi 7 goes gold or within a few years as more equipment becomes available, it makes no sense to select outgoing Wi-Fi 6[E] equipment — when I plan on using this gear until the tires fall off. Literally, my only complaint about the old guy was the Wi-Fi reception between hosts situated on the exact opposite end of the house from where the modem is located. Yup. Shion, Rimuru, Zeta, Deck, etc are in the same room and all have wireless connectivity but since the access point is at the furtherest distance possible that means local communication suxor. I.e., downloading from Steam == awesome because ASUS AC68, mother fucker; but I/O between Zeta and client machines != so great.

Which generated the second criteria. My segregated IPv6 network on the desk works pretty well, not that Zeta was intended to be functioning as a router among its myriad of other tasks. This makes for some things that are just inconvenient like running service VMs attached to Ethernet, and then wanting to access them in other rooms over wireless. Not to mention dealing with the split domain problem.

Enter the successor: Eero Max 7! In addition to having the chutzpah to compete with the decade old ASUS (the Ferrari of wireless networking back then), each node comes with a pair of 2.5G and 10G Ethernet ports (and a credit card bill😂), which future proofs it in a world where gigabit is becoming too slow. In theory, the system should last until Wi-Fi 7 is the new 802.11g (Wi-Fi 3), or Eero stops working. ASUS was still delivering firmware updates a decade later, which was crazy but appreciated.

Using one mesh node to function as a gateway and pump out signal at that end of the house, and another node situated in my study: this effectively solves the division of networks. My desk’s separate IPv6 network is now demissioned on the software side (Zeta doesn’t mind, lol) and its physical is now a gigabit switch to the local Eeero node. Zeta has a direct connection. But with most of my devices being Wi-Fi 5 on the 5 capable, that should be less of a concern.

So now wireless is pumping out my modem speeds instead of up to 1/3″ when sitting at this edge of the solar system. The old guy could bring the signal like a champion, but Wi-Fi 5 is only when wireless started to deliver “Fast enough” to compete with wired and we’re literally hitting the edge cases 😛.

There is only one real problem with how Eero is a “Basics only” approach to network configuration. See, I’m a DNS kind of guy. I’m not typing 128-bit fucking addresses, and you can take your 32-bit IPv4 addresses and shove them up a post note. Typing IP addresses does not scale when you have more devices than room on a post it note.

Aside from its awesomeness as a wireless router, there is one superb thing that the ASUS AC68 did that made life great. Like many a router, it let you specify a domain for the gateway and defaulted to its own caching DNS resolver. That’s common enough. But it went a step further. The DHCP and DNS was auto stitched together so that modern DHCP clients led to

That is to say, “zeta.home” would just work by setting my server’s hostname to “zeta” and connecting it to DHCP. No need to give a flying fuck about manually configuring a DHCP reservation or even what the IP assignment was, although I used to do reservations for infrastructure as an ‘insurance’ policy.

Then enter Eero where the dealio is: “We don’t care if you give us money, that’s not our problem!”

Which means in solving my routing troubles, I went from the annoyance of wishing I could maintain separate A / AAAA records to “What the fuck, is this the darkages?” which is not a problem that I appreciate, but it is a problem that I can solve easier than running an Ethernet drop across the attic space.

Phase one of this solution was to create a new virtual machine on Zeta, taking advantage of the fact that part of replacing Cream was wanting a system that could function as a VM or container farm. Easy peasy, lemon squeezy it’s an authoritive DNS server with control over “” and functioning reverse DNS because I’m a pain in the ass who doesnt like to do things by halves. That wasn’t so bad, give or take having to remember the fun that is editing zone files. I’ve used .home for a long time now, but figured that I may as well migrate to the convention that replaced it if I’m doing all this crud.

Phase two of this solution was to create a second instance. See, most clients will just send their queries to the first DNS and use the second as a failback. People often think, “Hey, I’ll just put my zones on this and let the other DNS do the other stuff,” and then wonder why nothing works the moment a client starts sending queries to another resolver. There’s also reasons why DNS always comes in at least pairs! Hell, the Internet was made to take a nukin’ and keep on truckin’ so survivability is a thing.

But obviously it’s a bad idea to configure another VM on the same server, or Zeta itself as the second DNS. Plus from a paranoid perspective, it would be kind of nice to put the “Ahh, I’m working on Zeta” safe guard across the building where the gateway is. Thus phase two takes a Raspberry Pi Zero W that’s been waiting on me to solder an RaSCSI for, and turns the machine into a secondary DNS server for For extra abuse the primary and secondary nameservers run on different operating systems with one being run natively on the Raspberry Pi’s OS and the other being a virtualized Red Hat instance on the central server.

Then enter phase 3! Being able to resolve external DNS (e.g., Google), zone transfers, reconfiguring the Eero for custom DNS, being happy not to have misstyped the IPv6 addresses, security wrangling, and testing fail over scenarios. Not to mention documenting the key details in my notes system being I’m that kind of pain in the ass.

The next sticking point however is where the magic happens. See, it’s not rocket science to have a DHCP and DNS server cooperating for the hostname -> hostname.domainname magic. If you’re using dhcpd and bind, the harder trick is knowing that you can actually do that.

But as far as I can tell, Eero’s software doesn’t support a separate DHCP server without running in bridge mode, and that would bring my AC68 out of retirement, so for right now I have zone files configured for key systems only. Phase 4 will likely be to address that after the system gets more stress testing.

It seems that Eeero uses DHCP for IPv4 and IPv6 clients are left to SLAAC, which is great IMHO. I’m all for that because between Stateless Address Auto Configuration and Neighbor Discovery features, you can pretty much just say fuck it and IPv6 hosts will do the right things unless your network is stupid(tm). Unlike an IT department, most of us don’t need to log every single precipice of our network’s activity and aren’t paranoid enough to want to do that at home.

Possible solutions may be to configurize DHCPv6 and ignore IPv4, or see if the good old respect meh authority trick would get the Eero to delegating DHCP to a dedicated server under my control without having to wrestle with the Eero trying to run its own dhcpd, or getting creative with firewalling.

Other than an as an alternative to Names I don’t really care about IPv4 locally anymore, since the things I have that require IPv4 are in the same club of things that know what Apple Talk was–that is to say, equipment so old that it passed old enough to buy beer and entered the old enough to have kids in school vintage of computer hardware.

But in any case, the DHCP portion of things shall be a battle for another time.