migration: vyos001 converted in production, and the config vyos002 needs first

UniFi does offer Native VLAN = None (7.5.10), and its dropdown lists Management
as VLAN 1 -- the API reports vlan:null, which is what made this look like a
blocker. The UI was right.

Applied to USW Aggregation ports 1+2, then the router over ssh vyos@10.0.1.252.
Confirmed by kea's own log: "the interface bond0 has no usable IPv4 addresses
configured" -- it opens no socket on the parent, so there is no wrong pool left
to answer from. VRRP held mastership with no transition; the VIPs never moved.

Proven end to end by the thing that was broken: vyos002's JetKVM console, which
had been sitting on a VLAN 3 port holding Management lease 192.168.1.28, was
restarted and took 192.168.3.14 -- one lease, right pool, right reservation.
That console is what unblocks vyos002.

commit-confirm cannot be driven non-interactively: `vbash -s` hangs on its
prompt. It failed safely (candidate discarded, nothing committed) but the
recovery card's commit-confirm advice only works typed by hand.

vyos002-return.conf carries the two defects that must not survive its next boot.
eth2 is US24 port 16, native VLAN 2 -- disable that port before powering the box
on and the ARP hazard is gone before it can happen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH

migration/vyos002-return.conf

@@ -0,0 +1,37 @@
+# vyos002 — everything that must land before it is trusted on the network.
+#
+# Apply order matters only in that this is ONE commit: the eth2 address and the
+# missing health-check are the two defects that caused the 2026-09-02 outage, and
+# neither should survive a single reboot window.
+#
+#   ssh vyos@192.168.1.253   (or 10.0.1.253 — L2-direct, see RECOVERY-CARD)
+#   configure; <paste>; commit; save
+
+# 1. The ARP poisoner. eth2 is the 1G copper NIC on US24 port 16, native VLAN 2,
+#    and it held 192.168.8.144/23 -- the same subnet as bond0.2. Two interfaces
+#    answering for one subnet is what hijacked 192.168.8.1 and took the cluster
+#    down: eth2's MAC answered while bond0.2's MAC routed.
+#    Origin: eth2 was `address dhcp`, a kea reservation for the ROUTER'S OWN NIC
+#    handed it .144, and a CLI commit froze it static.
+delete interfaces ethernet eth2 address
+
+# 2. The health-check. Without it this box can hold every floating IP while
+#    having no WAN at all -- the outage itself. It goes on the SYNC GROUP; VyOS
+#    rejects it per-group.
+#    /config/vrrp-wan-health must be copied over FIRST (from migration/) and be
+#    chmod +x, or the commit succeeds and the check silently never passes.
+set high-availability vrrp sync-group MAIN health-check script '/config/vrrp-wan-health'
+set high-availability vrrp sync-group MAIN health-check interval '5'
+set high-availability vrrp sync-group MAIN health-check failure-count '3'
+
+# 3. Management onto a tagged sub-interface, matching vyos001 (kea #1117).
+#    Pair this with USW Aggregation port 3 (LAG 3+4) -> Native VLAN = None.
+#    Until that switch change lands, leave these three commented out: vyos002
+#    can run untagged on bond0 while vyos001 runs tagged -- one VLAN is one
+#    broadcast domain, and the coexistence was proven in labsim.
+# set interfaces bonding bond0 vif 1 address '192.168.1.253/24'
+# set interfaces bonding bond0 vif 1 description 'management'
+# delete interfaces bonding bond0 address
+# set firewall group interface-group LAN interface 'bond0.1'
+# delete firewall group interface-group LAN interface 'bond0'
+# set high-availability vrrp group native interface 'bond0.1'