Files
lab/labsim/console-apply.py

117 lines
4.0 KiB
Python
Raw Normal View History

test(labsim): second VyOS router proves DHCP active-passive HA Answers the question a single router could not, and that would otherwise only have been discovered at cutover: with kea high-availability active-passive, does exactly ONE box answer a DHCP request? Yes. Probing sim VLAN 10 with broadcast-dhcp-discover returns offers from a single distinct Server Identifier -- 172.31.10.252, the primary. The secondary runs kea but stays silent. Without this the delta would have put 6 subnets and 84 static-mappings on both boxes with nothing to arbitrate them, and two kea instances would have raced on every broadcast domain. Worth noting the raw response count is misleading: nmap reports "Response 1 of 2" because it sends several discovers, and both replies carry the same server identifier. Counting responses says "2 servers"; counting distinct server identifiers says "1". The second number is the true one. labsim now runs a real pair, mirroring production: router1 172.31.<v>.252 priority 200 DHCP HA primary router2 172.31.<v>.253 priority 100 DHCP HA secondary VIP 172.31.<v>.1 floating, held by the master That required converting router1, which held .1 directly, to .252 plus a floating VIP -- otherwise it is two routers, not a pair. All six VRRP groups show MASTER on router1 and BACKUP on router2. New tooling: - sim-ha-config.py generates each role's config, reusing unifi-to-vyos.py --mode sim for the DHCP half so what is proven here and what production gets share a code path. VLAN 10 correctly carries /23. - console-apply.py applies config over the serial console, which is necessary because a freshly installed VyOS holds the same addresses as its peer and cannot safely be reached over the network at all until reconfigured. Known sim-only quirk, deliberately not chased: router1 cannot ARP router2 on the untagged VLAN 1 while every tagged VLAN works, and VRRP forms correctly on all six groups regardless. Both OVS bonds carry identical vlan_mode/tag/trunks and the bond MACs differ, so this is OVS bond behaviour on the native VLAN with two bonds on one bridge -- not a VyOS config problem, and not present in production, which uses a real switch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH
2026-08-16 23:29:12 +01:00
#!/usr/bin/env python3
"""Apply VyOS config to a labsim VM over its serial console.
Needed because a freshly installed VyOS comes up holding the same addresses as
its peer, so there is a window where it cannot safely be reached over the
network at all. The console does not care.
./console-apply.py --vm labsim-vyos2 --config r2.conf
"""
from __future__ import annotations
import argparse
import sys
import time
import pexpect
def main() -> int:
ap = argparse.ArgumentParser()
ap.add_argument("--vm", required=True)
ap.add_argument("--config", required=True)
ap.add_argument("--user", default="vyos")
ap.add_argument("--password", default="vyos")
vyos: move PPPoE off the config plane onto a gated systemd unit PPPoE HA could not work as written, and the reason is structural rather than a bug: `set interfaces pppoe pppoe0 disable` and `delete` are handled identically by interfaces_pppoe.py -- both UNLINK /etc/ppp/peers/pppoe0. That path is pppd's own options file, so the resting state destroyed exactly what the promotion path needed, and `ppp@pppoe0` restart-looped against it (observed: 47 restarts, zero sessions at the access concentrator). It also made op-mode `connect interface pppoe0` unusable, and put every failover behind a priority-322 commit where one unrelated invalid node fails the whole thing -- which has already taken the 10 gig down once. pppoe0 is now configured identically and ENABLED on both routers, so the peers file always exists, and dialling is gated by a drop-in on the unit: ConditionPathExists=/run/vrrp-wan/may-dial ConditionPathExists=/etc/ppp/peers/pppoe0 /run is tmpfs, so the gate is shut at boot and neither box can dial before VRRP has decided. That matters more than it first appears: with the node enabled, interfaces_pppoe.py restarts ppp on EVERY commit touching the pppoe subtree when the daemon is not running -- so the backup actively tries to dial whenever anything commits. The gate is the only thing making that a no-op, which is why vrrp-wan-reconcile now refuses to bless a box whose drop-in is missing: /etc is per-image, and a VyOS upgrade would otherwise silently remove the protection. may-dial is a LEASE, not a flag. ConditionPathExists is evaluated at start only -- it can prevent a dial, never revoke one -- so a reconciler that stops running while its box is demoted would keep the one ISP session for ever. The reconciler renews the lease; a new 5s vrrp-wan-guard revokes it, and only ever revokes. It fired correctly first time: "GUARD: lease stale (81s > 75s)". Also: remove-then-stop on release (the file's absence blocks a NEW start that a concurrent commit would trigger); a flap damper, because two routers that both believe they hold the VIP will both dial and each dial kills the other's session -- against a real ISP that is how an account gets rate-limited; and a guard on `cfg` returning empty under commit-lock contention, which had already produced one spurious "releasing" on a box that needed nothing. GRACE 90 -> 180. accel-ppp's dead-peer budget is lcp-echo-interval(30) x failure(3) = 90s, so the old value sat exactly on the boundary: a hard failover into an AC that does not replace the stale session would fail its own check, shed the VIPs, and leave both routers in FAULT. The sim could not have tested any of this. Both routers now get the identical WAN -- the secondary had none "because two PPPoE clients sharing one credential is a different failure mode than anything production has", which is backwards: that IS production. It also left the pair incomparable, ten NAT rules against none. Safety now comes from resting state, not asymmetry. Three more things the sim was hiding: - the drift check's secondary regex omitted interfaces pppoe/bonding, nat source and protocols failover, so it reported "in sync" for a box with no WAN at all; - the VRRP health-check and transition-script hooks existed on both live VMs and in NEITHER generator -- the mechanism under test was pure undetected drift; - labsim-vyos's only default route was the libvirt-NAT scaffold, so every "the LAN still has internet" verdict on it was answered by eth2 rather than the WAN. --drop-scaffold applied; the earlier DHCP-failover proof is being re-run because of it. vrrp-wan-install ends the other half of that: the sim's previous proof came from scripts hand-`sed`-ed in place, so the tested behaviour was not the committed behaviour. `--check` now makes that a hard failure. First green run: master holds both WANs, backup released, and the AC reports exactly ONE session. sim-net-apply.sh check: all four in sync. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH
2026-09-05 18:50:16 +01:00
# `save` writes config.boot. For WAN work that is dangerous: the resting
# state must stay `vif 53 disable` on both routers, and saving while a box
# is master persists the ENABLED state -- so a reboot would have it claim
# the cloned MAC. Observed in labsim on 2026-09-02.
ap.add_argument("--no-save", action="store_true",
help="commit without saving (leave config.boot untouched)")
test(labsim): second VyOS router proves DHCP active-passive HA Answers the question a single router could not, and that would otherwise only have been discovered at cutover: with kea high-availability active-passive, does exactly ONE box answer a DHCP request? Yes. Probing sim VLAN 10 with broadcast-dhcp-discover returns offers from a single distinct Server Identifier -- 172.31.10.252, the primary. The secondary runs kea but stays silent. Without this the delta would have put 6 subnets and 84 static-mappings on both boxes with nothing to arbitrate them, and two kea instances would have raced on every broadcast domain. Worth noting the raw response count is misleading: nmap reports "Response 1 of 2" because it sends several discovers, and both replies carry the same server identifier. Counting responses says "2 servers"; counting distinct server identifiers says "1". The second number is the true one. labsim now runs a real pair, mirroring production: router1 172.31.<v>.252 priority 200 DHCP HA primary router2 172.31.<v>.253 priority 100 DHCP HA secondary VIP 172.31.<v>.1 floating, held by the master That required converting router1, which held .1 directly, to .252 plus a floating VIP -- otherwise it is two routers, not a pair. All six VRRP groups show MASTER on router1 and BACKUP on router2. New tooling: - sim-ha-config.py generates each role's config, reusing unifi-to-vyos.py --mode sim for the DHCP half so what is proven here and what production gets share a code path. VLAN 10 correctly carries /23. - console-apply.py applies config over the serial console, which is necessary because a freshly installed VyOS holds the same addresses as its peer and cannot safely be reached over the network at all until reconfigured. Known sim-only quirk, deliberately not chased: router1 cannot ARP router2 on the untagged VLAN 1 while every tagged VLAN works, and VRRP forms correctly on all six groups regardless. Both OVS bonds carry identical vlan_mode/tag/trunks and the bond MACs differ, so this is OVS bond behaviour on the native VLAN with two bonds on one bridge -- not a VyOS config problem, and not present in production, which uses a real switch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH
2026-08-16 23:29:12 +01:00
args = ap.parse_args()
cmds = [l.rstrip() for l in open(args.config)
if l.strip() and not l.lstrip().startswith("#")]
print(f"{len(cmds)} commands to apply to {args.vm}", file=sys.stderr)
c = pexpect.spawn(f"virsh --connect qemu:///system console {args.vm}",
timeout=90, encoding="utf-8")
c.logfile_read = None
c.sendline("")
time.sleep(2)
c.sendline("")
# Log in. A freshly booted box may still be starting services, so allow a
# generous window and re-prod the console rather than failing on the first
# miss.
#
# `# ` matters as much as `$ `: a previous run that died mid-config leaves
# the console sitting in configuration mode, and waiting only for the
# operational prompt then hangs forever against a perfectly healthy VM.
in_config = False
test(labsim): second VyOS router proves DHCP active-passive HA Answers the question a single router could not, and that would otherwise only have been discovered at cutover: with kea high-availability active-passive, does exactly ONE box answer a DHCP request? Yes. Probing sim VLAN 10 with broadcast-dhcp-discover returns offers from a single distinct Server Identifier -- 172.31.10.252, the primary. The secondary runs kea but stays silent. Without this the delta would have put 6 subnets and 84 static-mappings on both boxes with nothing to arbitrate them, and two kea instances would have raced on every broadcast domain. Worth noting the raw response count is misleading: nmap reports "Response 1 of 2" because it sends several discovers, and both replies carry the same server identifier. Counting responses says "2 servers"; counting distinct server identifiers says "1". The second number is the true one. labsim now runs a real pair, mirroring production: router1 172.31.<v>.252 priority 200 DHCP HA primary router2 172.31.<v>.253 priority 100 DHCP HA secondary VIP 172.31.<v>.1 floating, held by the master That required converting router1, which held .1 directly, to .252 plus a floating VIP -- otherwise it is two routers, not a pair. All six VRRP groups show MASTER on router1 and BACKUP on router2. New tooling: - sim-ha-config.py generates each role's config, reusing unifi-to-vyos.py --mode sim for the DHCP half so what is proven here and what production gets share a code path. VLAN 10 correctly carries /23. - console-apply.py applies config over the serial console, which is necessary because a freshly installed VyOS holds the same addresses as its peer and cannot safely be reached over the network at all until reconfigured. Known sim-only quirk, deliberately not chased: router1 cannot ARP router2 on the untagged VLAN 1 while every tagged VLAN works, and VRRP forms correctly on all six groups regardless. Both OVS bonds carry identical vlan_mode/tag/trunks and the bond MACs differ, so this is OVS bond behaviour on the native VLAN with two bonds on one bridge -- not a VyOS config problem, and not present in production, which uses a real switch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH
2026-08-16 23:29:12 +01:00
for _ in range(40):
i = c.expect([r"login:", r"\$ ", r"# ", pexpect.TIMEOUT], timeout=15)
if i == 0:
c.sendline(args.user)
c.expect("Password:", timeout=30)
c.sendline(args.password)
c.expect([r"\$ ", r"# "], timeout=60)
test(labsim): second VyOS router proves DHCP active-passive HA Answers the question a single router could not, and that would otherwise only have been discovered at cutover: with kea high-availability active-passive, does exactly ONE box answer a DHCP request? Yes. Probing sim VLAN 10 with broadcast-dhcp-discover returns offers from a single distinct Server Identifier -- 172.31.10.252, the primary. The secondary runs kea but stays silent. Without this the delta would have put 6 subnets and 84 static-mappings on both boxes with nothing to arbitrate them, and two kea instances would have raced on every broadcast domain. Worth noting the raw response count is misleading: nmap reports "Response 1 of 2" because it sends several discovers, and both replies carry the same server identifier. Counting responses says "2 servers"; counting distinct server identifiers says "1". The second number is the true one. labsim now runs a real pair, mirroring production: router1 172.31.<v>.252 priority 200 DHCP HA primary router2 172.31.<v>.253 priority 100 DHCP HA secondary VIP 172.31.<v>.1 floating, held by the master That required converting router1, which held .1 directly, to .252 plus a floating VIP -- otherwise it is two routers, not a pair. All six VRRP groups show MASTER on router1 and BACKUP on router2. New tooling: - sim-ha-config.py generates each role's config, reusing unifi-to-vyos.py --mode sim for the DHCP half so what is proven here and what production gets share a code path. VLAN 10 correctly carries /23. - console-apply.py applies config over the serial console, which is necessary because a freshly installed VyOS holds the same addresses as its peer and cannot safely be reached over the network at all until reconfigured. Known sim-only quirk, deliberately not chased: router1 cannot ARP router2 on the untagged VLAN 1 while every tagged VLAN works, and VRRP forms correctly on all six groups regardless. Both OVS bonds carry identical vlan_mode/tag/trunks and the bond MACs differ, so this is OVS bond behaviour on the native VLAN with two bonds on one bridge -- not a VyOS config problem, and not present in production, which uses a real switch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH
2026-08-16 23:29:12 +01:00
break
if i == 1:
break
if i == 2:
in_config = True
test(labsim): second VyOS router proves DHCP active-passive HA Answers the question a single router could not, and that would otherwise only have been discovered at cutover: with kea high-availability active-passive, does exactly ONE box answer a DHCP request? Yes. Probing sim VLAN 10 with broadcast-dhcp-discover returns offers from a single distinct Server Identifier -- 172.31.10.252, the primary. The secondary runs kea but stays silent. Without this the delta would have put 6 subnets and 84 static-mappings on both boxes with nothing to arbitrate them, and two kea instances would have raced on every broadcast domain. Worth noting the raw response count is misleading: nmap reports "Response 1 of 2" because it sends several discovers, and both replies carry the same server identifier. Counting responses says "2 servers"; counting distinct server identifiers says "1". The second number is the true one. labsim now runs a real pair, mirroring production: router1 172.31.<v>.252 priority 200 DHCP HA primary router2 172.31.<v>.253 priority 100 DHCP HA secondary VIP 172.31.<v>.1 floating, held by the master That required converting router1, which held .1 directly, to .252 plus a floating VIP -- otherwise it is two routers, not a pair. All six VRRP groups show MASTER on router1 and BACKUP on router2. New tooling: - sim-ha-config.py generates each role's config, reusing unifi-to-vyos.py --mode sim for the DHCP half so what is proven here and what production gets share a code path. VLAN 10 correctly carries /23. - console-apply.py applies config over the serial console, which is necessary because a freshly installed VyOS holds the same addresses as its peer and cannot safely be reached over the network at all until reconfigured. Known sim-only quirk, deliberately not chased: router1 cannot ARP router2 on the untagged VLAN 1 while every tagged VLAN works, and VRRP forms correctly on all six groups regardless. Both OVS bonds carry identical vlan_mode/tag/trunks and the bond MACs differ, so this is OVS bond behaviour on the native VLAN with two bonds on one bridge -- not a VyOS config problem, and not present in production, which uses a real switch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH
2026-08-16 23:29:12 +01:00
break
c.sendline("")
else:
print("never reached a prompt", file=sys.stderr)
return 1
if in_config:
# Drop whatever the previous run left half-built rather than committing
# a candidate nobody has seen.
print("console was left in config mode; discarding stale candidate",
file=sys.stderr)
c.sendline("discard")
c.expect(r"# ", timeout=60)
else:
c.sendline("configure")
c.expect(r"# ", timeout=60)
test(labsim): second VyOS router proves DHCP active-passive HA Answers the question a single router could not, and that would otherwise only have been discovered at cutover: with kea high-availability active-passive, does exactly ONE box answer a DHCP request? Yes. Probing sim VLAN 10 with broadcast-dhcp-discover returns offers from a single distinct Server Identifier -- 172.31.10.252, the primary. The secondary runs kea but stays silent. Without this the delta would have put 6 subnets and 84 static-mappings on both boxes with nothing to arbitrate them, and two kea instances would have raced on every broadcast domain. Worth noting the raw response count is misleading: nmap reports "Response 1 of 2" because it sends several discovers, and both replies carry the same server identifier. Counting responses says "2 servers"; counting distinct server identifiers says "1". The second number is the true one. labsim now runs a real pair, mirroring production: router1 172.31.<v>.252 priority 200 DHCP HA primary router2 172.31.<v>.253 priority 100 DHCP HA secondary VIP 172.31.<v>.1 floating, held by the master That required converting router1, which held .1 directly, to .252 plus a floating VIP -- otherwise it is two routers, not a pair. All six VRRP groups show MASTER on router1 and BACKUP on router2. New tooling: - sim-ha-config.py generates each role's config, reusing unifi-to-vyos.py --mode sim for the DHCP half so what is proven here and what production gets share a code path. VLAN 10 correctly carries /23. - console-apply.py applies config over the serial console, which is necessary because a freshly installed VyOS holds the same addresses as its peer and cannot safely be reached over the network at all until reconfigured. Known sim-only quirk, deliberately not chased: router1 cannot ARP router2 on the untagged VLAN 1 while every tagged VLAN works, and VRRP forms correctly on all six groups regardless. Both OVS bonds carry identical vlan_mode/tag/trunks and the bond MACs differ, so this is OVS bond behaviour on the native VLAN with two bonds on one bridge -- not a VyOS config problem, and not present in production, which uses a real switch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH
2026-08-16 23:29:12 +01:00
for cmd in cmds:
c.sendline(cmd)
c.expect(r"# ", timeout=60)
out = c.before or ""
if "Set failed" in out or "not valid" in out or "Invalid" in out:
print(f"FAILED: {cmd}\n {out.strip()[:200]}", file=sys.stderr)
print("committing...", file=sys.stderr)
c.sendline("commit")
c.expect(r"# ", timeout=300)
commit_out = c.before or ""
vyos: move PPPoE off the config plane onto a gated systemd unit PPPoE HA could not work as written, and the reason is structural rather than a bug: `set interfaces pppoe pppoe0 disable` and `delete` are handled identically by interfaces_pppoe.py -- both UNLINK /etc/ppp/peers/pppoe0. That path is pppd's own options file, so the resting state destroyed exactly what the promotion path needed, and `ppp@pppoe0` restart-looped against it (observed: 47 restarts, zero sessions at the access concentrator). It also made op-mode `connect interface pppoe0` unusable, and put every failover behind a priority-322 commit where one unrelated invalid node fails the whole thing -- which has already taken the 10 gig down once. pppoe0 is now configured identically and ENABLED on both routers, so the peers file always exists, and dialling is gated by a drop-in on the unit: ConditionPathExists=/run/vrrp-wan/may-dial ConditionPathExists=/etc/ppp/peers/pppoe0 /run is tmpfs, so the gate is shut at boot and neither box can dial before VRRP has decided. That matters more than it first appears: with the node enabled, interfaces_pppoe.py restarts ppp on EVERY commit touching the pppoe subtree when the daemon is not running -- so the backup actively tries to dial whenever anything commits. The gate is the only thing making that a no-op, which is why vrrp-wan-reconcile now refuses to bless a box whose drop-in is missing: /etc is per-image, and a VyOS upgrade would otherwise silently remove the protection. may-dial is a LEASE, not a flag. ConditionPathExists is evaluated at start only -- it can prevent a dial, never revoke one -- so a reconciler that stops running while its box is demoted would keep the one ISP session for ever. The reconciler renews the lease; a new 5s vrrp-wan-guard revokes it, and only ever revokes. It fired correctly first time: "GUARD: lease stale (81s > 75s)". Also: remove-then-stop on release (the file's absence blocks a NEW start that a concurrent commit would trigger); a flap damper, because two routers that both believe they hold the VIP will both dial and each dial kills the other's session -- against a real ISP that is how an account gets rate-limited; and a guard on `cfg` returning empty under commit-lock contention, which had already produced one spurious "releasing" on a box that needed nothing. GRACE 90 -> 180. accel-ppp's dead-peer budget is lcp-echo-interval(30) x failure(3) = 90s, so the old value sat exactly on the boundary: a hard failover into an AC that does not replace the stale session would fail its own check, shed the VIPs, and leave both routers in FAULT. The sim could not have tested any of this. Both routers now get the identical WAN -- the secondary had none "because two PPPoE clients sharing one credential is a different failure mode than anything production has", which is backwards: that IS production. It also left the pair incomparable, ten NAT rules against none. Safety now comes from resting state, not asymmetry. Three more things the sim was hiding: - the drift check's secondary regex omitted interfaces pppoe/bonding, nat source and protocols failover, so it reported "in sync" for a box with no WAN at all; - the VRRP health-check and transition-script hooks existed on both live VMs and in NEITHER generator -- the mechanism under test was pure undetected drift; - labsim-vyos's only default route was the libvirt-NAT scaffold, so every "the LAN still has internet" verdict on it was answered by eth2 rather than the WAN. --drop-scaffold applied; the earlier DHCP-failover proof is being re-run because of it. vrrp-wan-install ends the other half of that: the sim's previous proof came from scripts hand-`sed`-ed in place, so the tested behaviour was not the committed behaviour. `--check` now makes that a hard failure. First green run: master holds both WANs, backup released, and the AC reports exactly ONE session. sim-net-apply.sh check: all four in sync. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH
2026-09-05 18:50:16 +01:00
if not args.no_save:
c.sendline("save")
c.expect(r"# ", timeout=120)
# Accept either prompt on the way out. Insisting on `$ ` here hangs against
# a healthy box -- and worse, leaves the console parked in config mode, so
# the NEXT run finds a `# ` it was not expecting either. One strict expect
# turned into two failures.
test(labsim): second VyOS router proves DHCP active-passive HA Answers the question a single router could not, and that would otherwise only have been discovered at cutover: with kea high-availability active-passive, does exactly ONE box answer a DHCP request? Yes. Probing sim VLAN 10 with broadcast-dhcp-discover returns offers from a single distinct Server Identifier -- 172.31.10.252, the primary. The secondary runs kea but stays silent. Without this the delta would have put 6 subnets and 84 static-mappings on both boxes with nothing to arbitrate them, and two kea instances would have raced on every broadcast domain. Worth noting the raw response count is misleading: nmap reports "Response 1 of 2" because it sends several discovers, and both replies carry the same server identifier. Counting responses says "2 servers"; counting distinct server identifiers says "1". The second number is the true one. labsim now runs a real pair, mirroring production: router1 172.31.<v>.252 priority 200 DHCP HA primary router2 172.31.<v>.253 priority 100 DHCP HA secondary VIP 172.31.<v>.1 floating, held by the master That required converting router1, which held .1 directly, to .252 plus a floating VIP -- otherwise it is two routers, not a pair. All six VRRP groups show MASTER on router1 and BACKUP on router2. New tooling: - sim-ha-config.py generates each role's config, reusing unifi-to-vyos.py --mode sim for the DHCP half so what is proven here and what production gets share a code path. VLAN 10 correctly carries /23. - console-apply.py applies config over the serial console, which is necessary because a freshly installed VyOS holds the same addresses as its peer and cannot safely be reached over the network at all until reconfigured. Known sim-only quirk, deliberately not chased: router1 cannot ARP router2 on the untagged VLAN 1 while every tagged VLAN works, and VRRP forms correctly on all six groups regardless. Both OVS bonds carry identical vlan_mode/tag/trunks and the bond MACs differ, so this is OVS bond behaviour on the native VLAN with two bonds on one bridge -- not a VyOS config problem, and not present in production, which uses a real switch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH
2026-08-16 23:29:12 +01:00
c.sendline("exit")
c.expect([r"\$ ", r"# ", pexpect.TIMEOUT], timeout=60)
test(labsim): second VyOS router proves DHCP active-passive HA Answers the question a single router could not, and that would otherwise only have been discovered at cutover: with kea high-availability active-passive, does exactly ONE box answer a DHCP request? Yes. Probing sim VLAN 10 with broadcast-dhcp-discover returns offers from a single distinct Server Identifier -- 172.31.10.252, the primary. The secondary runs kea but stays silent. Without this the delta would have put 6 subnets and 84 static-mappings on both boxes with nothing to arbitrate them, and two kea instances would have raced on every broadcast domain. Worth noting the raw response count is misleading: nmap reports "Response 1 of 2" because it sends several discovers, and both replies carry the same server identifier. Counting responses says "2 servers"; counting distinct server identifiers says "1". The second number is the true one. labsim now runs a real pair, mirroring production: router1 172.31.<v>.252 priority 200 DHCP HA primary router2 172.31.<v>.253 priority 100 DHCP HA secondary VIP 172.31.<v>.1 floating, held by the master That required converting router1, which held .1 directly, to .252 plus a floating VIP -- otherwise it is two routers, not a pair. All six VRRP groups show MASTER on router1 and BACKUP on router2. New tooling: - sim-ha-config.py generates each role's config, reusing unifi-to-vyos.py --mode sim for the DHCP half so what is proven here and what production gets share a code path. VLAN 10 correctly carries /23. - console-apply.py applies config over the serial console, which is necessary because a freshly installed VyOS holds the same addresses as its peer and cannot safely be reached over the network at all until reconfigured. Known sim-only quirk, deliberately not chased: router1 cannot ARP router2 on the untagged VLAN 1 while every tagged VLAN works, and VRRP forms correctly on all six groups regardless. Both OVS bonds carry identical vlan_mode/tag/trunks and the bond MACs differ, so this is OVS bond behaviour on the native VLAN with two bonds on one bridge -- not a VyOS config problem, and not present in production, which uses a real switch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH
2026-08-16 23:29:12 +01:00
c.sendline("exit")
c.close(force=True)
test(labsim): second VyOS router proves DHCP active-passive HA Answers the question a single router could not, and that would otherwise only have been discovered at cutover: with kea high-availability active-passive, does exactly ONE box answer a DHCP request? Yes. Probing sim VLAN 10 with broadcast-dhcp-discover returns offers from a single distinct Server Identifier -- 172.31.10.252, the primary. The secondary runs kea but stays silent. Without this the delta would have put 6 subnets and 84 static-mappings on both boxes with nothing to arbitrate them, and two kea instances would have raced on every broadcast domain. Worth noting the raw response count is misleading: nmap reports "Response 1 of 2" because it sends several discovers, and both replies carry the same server identifier. Counting responses says "2 servers"; counting distinct server identifiers says "1". The second number is the true one. labsim now runs a real pair, mirroring production: router1 172.31.<v>.252 priority 200 DHCP HA primary router2 172.31.<v>.253 priority 100 DHCP HA secondary VIP 172.31.<v>.1 floating, held by the master That required converting router1, which held .1 directly, to .252 plus a floating VIP -- otherwise it is two routers, not a pair. All six VRRP groups show MASTER on router1 and BACKUP on router2. New tooling: - sim-ha-config.py generates each role's config, reusing unifi-to-vyos.py --mode sim for the DHCP half so what is proven here and what production gets share a code path. VLAN 10 correctly carries /23. - console-apply.py applies config over the serial console, which is necessary because a freshly installed VyOS holds the same addresses as its peer and cannot safely be reached over the network at all until reconfigured. Known sim-only quirk, deliberately not chased: router1 cannot ARP router2 on the untagged VLAN 1 while every tagged VLAN works, and VRRP forms correctly on all six groups regardless. Both OVS bonds carry identical vlan_mode/tag/trunks and the bond MACs differ, so this is OVS bond behaviour on the native VLAN with two bonds on one bridge -- not a VyOS config problem, and not present in production, which uses a real switch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH
2026-08-16 23:29:12 +01:00
bad = [l for l in commit_out.splitlines()
if "failed" in l.lower() or "error" in l.lower()]
if bad:
print("commit reported:", file=sys.stderr)
for l in bad[:10]:
print(f" {l.strip()}", file=sys.stderr)
return 1
print("committed and saved", file=sys.stderr)
return 0
if __name__ == "__main__":
sys.exit(main())