# Upgrading a VyOS image on the router pair

VyOS keeps `/config` across an image upgrade and **replaces `/etc`**. Everything
in `/config` survives; anything the WAN mechanism put in `/etc` does not.

## What an upgrade silently removes

`/etc/systemd/system/ppp@pppoe0.service.d/10-vrrp-wan-gate.conf` — the gate.

That drop-in is the only thing stopping the **backup** from dialling. With
`pppoe0` enabled on both routers (which it is, by design), `interfaces_pppoe.py`
restarts ppp on every commit touching the pppoe subtree when the daemon is not
running. Without the gate, the backup dials on the next `pulumi up`, hand
commit, or boot-time config load — and Vodafone is a single-session account, so
it takes the session off the live master.

`vrrp-wan-reconcile` fails **closed** here: it refuses to dial at all when the
drop-in is missing, and logs

```
REFUSING to dial: gate drop-in ... is missing (VyOS upgrade?)
```

so the symptom is "PPPoE never comes up", not "both routers dialled". That is
the safe direction, but it does mean an upgraded router has no PPPoE until the
gate is reinstalled.

The systemd **units and timers** also live in `/etc` and go the same way.

## Do this, one router at a time

Never both at once — the surviving router must be able to hold the VIPs.

1. **Upgrade the BACKUP first.** Confirm which it is:
   ```
   sudo /config/wan-panic status          # "holds VIP : no"
   ```
2. Install the image and reboot as normal.
3. **Reinstall the mechanism** from a checkout of `lab`:
   ```
   migration/vrrp-wan-install --vip 192.168.1.1 --host vyos@<router>
   migration/vrrp-wan-install --check  --host vyos@<router>     # must be clean
   ```
4. **Verify the gate is shut and nothing dialled:**
   ```
   systemctl show ppp@pppoe0 -p ConditionResult -p ActiveState -p NRestarts
   ```
   Want `ConditionResult=no`, `ActiveState=inactive`, `NRestarts=0`. Check the
   wire too, not just state: `sudo tcpdump -i bond0.51 -nn pppoed` — no PADI.
5. Confirm it reaches **BACKUP**, not FAULT:
   ```
   show vrrp
   ```
   FAULT on every group means the health check is failing — most likely
   `/config/vrrp-wan-health` did not get reinstalled, or `vrrp-wan.conf` is
   missing so `GRACE` and the VIP fall back to defaults.
5b. **Check IPv6 came back with it.** `vrrp-wan-install` now carries
   `he-tunnel-follow`, so `--check` covers it, but `/config/he-secrets` is a
   secret placed by Pulumi and is only checked for *presence*:
   ```
   sudo /config/he-tunnel-follow status      # role, tunnel src, MTU
   ```
   Want the box's own role, and — on the master — a tunnel source equal to the
   **10 gig** address with MTU 1480. `/config` survives an upgrade, so the
   `system task-scheduler` entry that runs this every minute survives too; it is
   the units and the ppp gate in `/etc` that do not.
6. Confirm `config.boot` still pins the safe resting state:
   ```
   sudo /config/vif53-pin-boot-disable --check    # config.boot disable : 1
   ```
7. Only once the upgraded box is a healthy BACKUP, fail over and repeat for the
   other router. `migration/wan-drill` does that unattended, or by hand:
   `sudo /config/wan-panic` on the box you want to give up mastership.

## After both are done

```
migration/vrrp-wan-install --check --host vyos@10.0.1.252
migration/vrrp-wan-install --check --host vyos@10.0.1.253
cd kubernetes-deployment && npm run vyos:export -- --router vyos001=10.0.1.252 --router vyos002=10.0.1.253
npm run vyos:render && npm run vyos:verify -- --router vyos001=10.0.1.252 --router vyos002=10.0.1.253
```

Both should read "in sync". If the export shows `interfaces pppoe pppoe0
disable` coming back, something reinstated it — the
`pppoe-gated-not-config-disabled` override exists to prevent exactly that, so
check it is still in `infra/vyos/subtrees/overrides.json`.

## If it goes wrong

`migration/RECOVERY-CARD-wan-panic.md`, or `/config/RECOVERY-CARD.md` on either
router. Short version, on vyos002: `sudo /config/wan-panic`.