ADR-0017 rev 3: single switch — PE replaces the SG105E, CCTV rides a VLAN-30 trunk on the LAN1 cable

Viktor prefers not running two switches, so the TL-SG105PE takes over
all rack duties (apartment uplink, 4G, UPS, camera PoE) and the CCTV
segment moves onto a managed tagged trunk over the existing LAN1 cable:
pfSense net3 re-pointed from vmbr2 to vmbr0 tag=30 (applied live; same
MAC so vtnet3/dCCTV survived untouched). This is safe where the original
802.1Q rejection was not, because the managed switch is the only device
on eno1 and polices VLAN-30 membership. eno2/vmbr2 kept dormant as the
documented fallback. Old SG105E retires to cold spare; PE inherits
192.168.1.6. Glossary Segment term updated (all three segments are now
bridge-tags feeding untagged pfSense vNICs).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/adr/0017-cctv-segment-dedicated-pfsense-leg.md

@@ -1,6 +1,6 @@
-# CCTV segment on a dedicated pfSense leg, not an 802.1Q trunk
+# CCTV segment: dedicated pfSense interface, VLAN-30 trunk on the LAN1 cable
 
-Status: accepted (2026-07-02)
+Status: accepted (2026-07-02, rev 3 — single-switch)
 
 ![Network topology — dCCTV segment, flows, and camera-day steps](./0017-cctv-segment-topology.svg)
 
@@ -13,14 +13,22 @@ to pfSense" — but nothing in this network terminates dot1q on pfSense; the
 site idiom is one vlan-aware Proxmox bridge → one tagged VM NIC → one clean
 untagged pfSense interface per segment.
 
-**Decision:** the CCTV segment (`dCCTV`, 10.0.30.1/24) rides a dedicated
-physical leg — R730 `eno2` (spare) → new bridge `vmbr2` → pfSense `net3`
-(vtnet3), untagged end-to-end. The new TL-SG105PE PoE switch is a **dedicated
-CCTV island**: camera in a PoE port, one port patched to eno2, no VLAN table
-at all, mgmt IP inside the segment (10.0.30.6 via Kea). The existing garage
-TL-SG105E (192.168.1.6 — apartment uplink, R730 LAN1, 4G router 192.168.1.7,
-UPS mgmt; exactly one free port) is untouched — it has no PoE and no spare
-port pair, which is also why the two roles cannot share one switch.
+**Decision (rev 3):** ONE switch — the new TL-SG105PE **replaces** the old
+garage TL-SG105E (Viktor prefers not running two switches; retired unit
+becomes a cold spare, its 192.168.1.6 mgmt IP passes to the PE). Five ports,
+all used: apartment uplink, 4G router 192.168.1.7, UPS mgmt (all untagged
+VLAN 1), the camera (untagged VLAN 30, PoE), and the **trunk to R730 `eno1`
+carrying home LAN untagged + CCTV tagged 30** over the existing LAN1 cable.
+pfSense `net3` (vtnet3) sits on `vmbr0` with `tag=30` — exactly the site
+idiom used for dManagementsVms/dKubernetes (bridge-level tag → clean untagged
+vNIC; pfSense still terminates no dot1q itself). The earlier dedicated
+`eno2`/`vmbr2` leg is kept **dormant as a fallback** (rev 2 wired it; moving
+net3 back to vmbr2 restores pure physical isolation in one `qm set`).
+This narrows the earlier 802.1Q objection rather than contradicting it: the
+rejection assumed *unmanaged* switches, where any LAN device could inject
+tagged frames; with the managed PE as the only device on eno1, VLAN-30
+membership is {camera port, trunk port} only, so tag-30 ingress from every
+other port — and from the exposed camera cable — is dropped or contained.
 Cameras are untrusted: default-deny on dCCTV with a single
 NTP-to-gateway exception; Frigate (k8s) pulls RTSP in; ha-sofia (192.168.1.8)
 may reach ISAPI/RTSP directly; home-LAN clients route in via an AX6000 static
@@ -29,29 +37,35 @@ route (10.0.30.0/24 via 192.168.1.2). 10.0.30.0/24 is deliberately NOT in the
 
 ## Considered options
 
-- **802.1Q tag over the existing LAN path (eno1/vmbr0)** — rejected: vmbr0 is
-  vlan-aware with `bridge-vids 2-4094`, so ANY device on the home LAN could
-  inject tagged frames straight into the camera segment (defeats the
-  cable-tap threat model); tag-passing through the unmanaged SW1 is
-  undefined; and it reconfigures the live bridge carrying the host IP and
-  pfSense WAN.
+- **802.1Q over the LAN path behind an UNMANAGED switch** (the original plan
+  read this way) — rejected: any LAN device could inject tagged frames into
+  vmbr0 (`bridge-vids 2-4094`) and tag-passing through a dumb switch is
+  undefined. Rev 3 adopts the tagged path ONLY because the managed PE now
+  polices VLAN-30 membership at the single entry point to eno1; no bridge
+  reconfiguration was needed (vmbr0 was already vlan-aware).
+- **Dedicated physical leg (eno2 → vmbr2 → net3), one switch per role**
+  (rev 1/2 as-built) — superseded by rev 3: it forced either a second switch
+  (6 connections vs 5 ports once the PE also replaced the old switch) or new
+  hardware. Strongest isolation of all options; kept dormant as the fallback.
 - **AX6000 as the camera gateway** — rejected earlier in the design (consumer
   router, no inter-VLAN firewall).
 
 ## Consequences
 
-- eno2 is consumed; eno3/eno4 remain the last spare NICs on the R730.
-- Two Easy Smart switches live in the rack: the OLD TL-SG105E at 192.168.1.6
-  remains the load-bearing shared one (apartment uplink, R730 LAN1, pfSense's
-  backup-WAN path via the 4G router, UPS mgmt — one port free); the NEW
-  TL-SG105PE carries only CCTV. The Easy Smart mgmt-answers-on-every-port
-  quirk is therefore contained: the PE's mgmt UI is only L2-adjacent to
-  cameras, and pfSense still gates all L3.
-- Adding a future camera = one free PoE port on the PE + a Kea
-  reservation; no pfSense/PVE/VLAN work.
-- 2026-07-02 correction: an earlier revision of this ADR described ONE shared
-  PE switch with a port-based VLAN split — written before discovering the
-  live 192.168.1.6 device is a separate, older non-PoE TL-SG105E. No VLAN
-  table exists anywhere in the final design.
+- The switch is now single-point and load-bearing for everything in the rack
+  (apartment uplink, pfSense backup-WAN via 4G, UPS mgmt, CCTV) AND its VLAN
+  table + mgmt password are part of the isolation boundary — the Easy Smart
+  mgmt UI answers on every port, so the password is the gate between a
+  compromised camera and the switch config. All 5 ports are consumed: the
+  next camera forces an 8-port PoE upgrade (the wiring plan already fits it).
+- `eno2`/`vmbr2` stay cabled-ready but dormant (fallback to rev 2's physical
+  leg); eno3/eno4 remain free.
+- The old TL-SG105E is retired to cold spare; the PE inherits 192.168.1.6
+  (Kea reservation by MAC).
+- Revision history (all 2026-07-02): rev 1 assumed one shared PE with a
+  port-VLAN split (conflated the two devices); rev 2 split into two switches
+  after inspecting 192.168.1.6 (old non-PoE SG105E, 4/5 ports used); rev 3
+  consolidated back to one switch — the PE replacing the SG105E — per
+  Viktor's preference, moving CCTV onto a managed tagged trunk.
 - Frigate's ADR-0016 VRAM budget was bumped 2000 → 2300 MiB for the extra
   NVDEC stream.