vh
a95717e810
pfi-gx10 moved from desk Wi-Fi (10.100.10.226, VLAN 10) to the rack on 10.100.50.60 (nh3-servers, VLAN 50), reachable as pfi-gx10.nh3.internal. The address is a DHCP RESERVATION on the UDM, not a host static. Operator ruling during the move, and the better design: a host-side static works until the box moves and is then a stale netplan file on a machine whose address you no longer know. The pre-written playbook wrote a host static; it is kept for its safety ordering and annotated as retired. The port arrived on the native VLAN, not the server VLAN, so switch port 22 was repointed first. port_overrides is a whole-array PUT — two unrelated overrides on ports 21 and 23 were read, preserved and written back, with the original array backed up to a file before the change. Wi-Fi stayed up as the escape hatch until the wired path was proven from outside, and was downed last as its own step. The step worth keeping: while Wi-Fi was up, traffic to nh3-dev still preferred wlP9s9 because that interface sits directly on the userland subnet, so reachability proved nothing about the wired path. `ping -I enP7s7` across the VLAN boundary is what actually settled it before the hatch came down.
3.0 KiB
pfi-gx10 — desk to rack, network
Done 2026-09-03. pfi-gx10.nh3.internal → 10.100.50.60, wired only.
The shape, and why it is this shape
The address lives on the switch/firewall side, not on the host. Operator ruling at the time of the move: a DHCP reservation on the UDM, with the host left on DHCP. A host-side static works until the box moves, and then it is a stale netplan file on a machine whose address you no longer know. A reservation moves with the MAC.
UniFi switch port 22 native network -> nh3-servers (VLAN 50)
UniFi client reservation -> 30:c5:99:3d:a7:45 = 10.100.50.60
host unchanged: still DHCP
playbooks/gx10-rack-network.yaml is kept for its safety ordering but its
host-static approach was not used, and it says so at the top.
⚠ Order is the whole safety argument
The lockout risk in remote network work is applying a config that does not work and losing the only path back. There was never one path:
-
Verify the cable is really in —
/sys/class/net/enP7s7/carrier= 1. Configuring a dead interface and calling it done is a green that costs a rack visit to discover. -
Identify by MAC, not by interface name. Names renumber across kernels;
30:c5:99:3d:a7:45does not. -
Move the switch port, then reserve, then renew — Wi-Fi stays up throughout as the escape hatch.
-
Prove the new address from OUTSIDE before removing anything.
-
⚠ Prove inter-VLAN routing before killing Wi-Fi. This is the step that is easy to skip and expensive to miss: while Wi-Fi was up, replies to nh3-dev (10.100.10.50) still preferred
wlP9s9, because that interface sits directly on the userland subnet. So "I can reach it" proved nothing about whether the WIRED path could. Forcing the interface first is what settles it:ping -c3 -I enP7s7 10.100.10.50 # VLAN 50 -> VLAN 10, 0% loss ping -c2 -I enP7s7 1.1.1.1 # egress -
Down Wi-Fi last, as its own change — a server with two default routes picks one and you find out later, in a way that looks like packet loss.
Editing UniFi port overrides
port_overrides is a whole-array PUT. Read the existing array, filter out
the port you are changing, append your entry, and write the lot back — anything
you omit is deleted. Two unrelated overrides (ports 21 and 23) were on this
switch and were preserved deliberately; the pre-change array is worth backing
up to a file first.
GET /proxy/network/api/s/default/stat/device # find switch by MAC
PUT /proxy/network/api/s/default/rest/device/<id> # {"port_overrides":[...]}
PUT /proxy/network/api/s/default/rest/user/<id> # the reservation
Reservations live on the client object (use_fixedip, fixed_ip,
network_id), not on the network.
Wi-Fi
nmcli radio wifi off — persists across reboot in
/var/lib/NetworkManager/NetworkManager.state, verified by reading it back
rather than assuming. /etc/netplan was backed up to
/etc/netplan.bak-preWifiDown first.