44dbd5188c
Groundwork for replacing the USG with the VyOS pair without anything on the
network noticing. Three pieces:
migration/unifi-export.py pulls 13 endpoints off the classic controller into
timestamped JSON plus a normalised inventory: 11 networks, 31 DHCP
reservations, 4 port forwards, 2 firewall rules, 0 static routes. Two things
this turned up that a naive export would have lost:
- 23 of the 31 reservations carry no network_id at all -- UniFi simply does
not store the binding -- so they are resolved by subnet containment
instead. Without that, three quarters of the reservations have no subnet
to be placed in.
- 30 of the 31 sit INSIDE the DHCP pool, which UniFi's dhcpd tolerates and
which is flagged as a warning rather than discovered at cutover.
migration/unifi-to-vyos.py turns that inventory into VyOS `set` commands for
DHCP and DNS only -- the services the USG owns that VyOS must reproduce. Not a
general converter. --prod and --sim come from one code path so the config
proven in the sim and the config applied to the firewalls cannot drift. Prod
mode hard-fails if any reservation is missing, since a silent drop is the
failure mode that matters.
DNS is included because the USG resolves for 5 of 6 VLANs today: UniFi hands
out the gateway's own address whenever dhcpd_dns is empty, verified by
labmaster resolving against 192.168.8.1. Replacing the USG without a forwarder
would take DNS away from those VLANs entirely.
labsim/labsim-dhcp-test.sh proves it by booting throwaway VMs with real
production MACs -- the one piece of production config that transplants
verbatim. Safe because ovs-labsim has no physical NIC, so those MACs cannot
reach the real LAN.
Result on VyOS 2026.08 (kea), 4/4: printer1 got 172.31.10.46 from inside the
pool, sonoff-matter got 172.31.11.67 across the /23 boundary, Hubitat got its
out-of-pool .2, and an unreserved MAC got an unreserved address. kea honours
in-pool host reservations -- the open question blocking the cutover.
Supporting changes to labsim:
- VLAN 10 widened to /23. Every reservation is in LoT and LoT spans 10.0.0.x
and 10.0.1.x, which a /24 cannot represent.
- LoT's host leg moved to .3, because 10.0.0.2 is a real reservation
(Hubitat) that maps onto the host's own address.
- vlans.conf gained optional masklen and host_octet fields, defaulting to
24 and 2 so the other five VLANs are untouched.
- Fixed /etc/network/interfaces hardcoding 255.255.255.0. That file is what
actually takes effect on these Alpine guests -- cloud-init's
network-config is ignored -- so any non-/24 VLAN was silently wrong.
Two generator bugs found by VyOS rejecting the output: static-mapping names
are validated as hostnames, so underscores fail; and two devices named
"espressif" plus two named "thebeast" collided into single names, which would
have overwritten one reservation with another's address.
The raw export holds WiFi passphrases and the WAN PPPoE credentials and is
gitignored.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH
33 lines
1.4 KiB
Plaintext
33 lines
1.4 KiB
Plaintext
# Lab network simulation — VLAN map.
|
|
#
|
|
# Mirrors the real UniFi topology (same VLAN IDs, same roles) but with
|
|
# deliberately DIFFERENT IP ranges so nothing here can collide with, or be
|
|
# confused for, production. The sim subnet always encodes the VLAN id:
|
|
#
|
|
# 172.31.<vlan-id>.0/24
|
|
#
|
|
# Per-subnet address plan (same shape on every VLAN):
|
|
# .1 gateway under test (VyOS/router VM — not created by default)
|
|
# .2 host bridge (how you SSH in from this workstation)
|
|
# .10 the micro VM for this VLAN
|
|
# .254 VRRP VIP (reserved, mirrors production)
|
|
#
|
|
# Format: vlan_id:name:sim_subnet_prefix:real_subnet:[masklen]:[host_octet]
|
|
#
|
|
# masklen defaults to 24 and host_octet to 2. Both exist for VLAN 10, which is
|
|
# the one VLAN that has to be a /23 here: every UniFi DHCP reservation lives in
|
|
# LoT, and LoT spans 10.0.0.x AND 10.0.1.x, which a /24 cannot represent. With
|
|
# /23 the mapping stays readable — 10.0.0.46 -> 172.31.10.46 and
|
|
# 10.0.1.67 -> 172.31.11.67.
|
|
#
|
|
# LoT's host leg is .3 rather than .2 because 10.0.0.2 is a real reservation
|
|
# (Hubitat) and would map straight onto the host's own address. .3 is free in
|
|
# production and sits below the DHCP pool (which starts at .11), so it can
|
|
# never be handed out.
|
|
1:management:172.31.1:192.168.1.0/24
|
|
2:k8s:172.31.2:192.168.8.0/23
|
|
3:kvm:172.31.3:192.168.3.0/24
|
|
9:private:172.31.9:10.0.9.0/23
|
|
10:lot:172.31.10:10.0.0.0/23:23:3
|
|
200:roomates:172.31.200:192.168.2.0/24
|