# STEP_033A policy integration plan

Dry-run only. No remote changes were applied.

## Observed current policy

Legacy production policy is still active:

- `ip rule` sends `iif eth1` and `from 10.200.0.0/24` to table 200.
- table 200 default is still `dev vpn1`.
- tables 203/204/205 point to vpn3/vpn4/vpn5.
- no rules for 203/204/205 are present.

## Observed runtime tunnel status

- vpn1 ping rc: 0
- vpn2 ping rc: absent
- vpn3 ping rc: 0
- vpn4 ping rc: 0
- vpn5 ping rc: 0

Important: vpn2 may be absent/down in runtime, so the first pool policy should not depend on vpn2 until it is explicitly repaired or excluded.

## Recommended staged strategy

### Phase 1: no production switch
Create a new isolated policy mechanism but do not attach it to client traffic:
- create/verify tables 203/204/205 only
- create nft mark chain for test source IP only, not all eth1 traffic
- add fwmark rules only for marks 0x203/0x204/0x205 at explicit priorities
- test with a single controlled source or synthetic marked packets if feasible

### Phase 2: canary
Move one controlled test client/IP from VM100 side to pool policy:
- mark only that source on VM101 iif eth1
- verify external IP / connectivity
- rollback removes nft mark rule and fwmark rules

### Phase 3: production cutover
Only after canary:
- either replace old table 200 default strategy
- or gradually mark more client traffic into pool
- keep old table 200/vpn1 as rollback path

## Do not do yet

- do not delete legacy table 200 rules
- do not flush ip rules
- do not globally restart network
- do not include vpn2 in balancing until it is confirmed up