Skip to content

feat: add services VLAN 50 for long-lived service VMs - #23

Merged
jmgilman merged 2 commits into
masterfrom
feat/services-vlan50
Oct 16, 2026
Merged

jmgilman merged 2 commits into
masterfrom
feat/services-vlan50

Conversation

@jmgilman

Copy link
Copy Markdown
Contributor

Summary

Adds a routed services VLAN 50 (10.10.50.0/24, gateway 10.10.50.1 on gw01) for long-lived service VMs. First consumer: media01 (static 10.10.50.20) on Incus member nas01. It sits off both management VLAN 10 and the OVN-owned VLAN 40 uplink.

Path: gw01 eth1 (SFP+ 2) ⇄ sw-core01 sfp-sfpplus8 (trunk) and sw-core01 sfp-sfpplus7 ⇄ nas01. The lab LAGs do not carry VLAN 50.

gw01 (vyos/gw01/config.boot.tmpl)

  • eth1 vif 50 holds 10.10.50.1/24 directly. There is no bridge because no untagged access port shares the VLAN. The header interface map is updated.
  • Adds network-group LAB_SERVICES 10.10.50.0/24.
  • Forward/input jump rule 150 on eth1.50 → SERVICES_FORWARD / SERVICES_LOCAL.
  • DHCP shared-network-name LAB_SERVICES (subnet-id 4, router and DNS 10.10.50.1, range .200–.250), listening on eth1.50.
  • CoreDNS (assets/coredns/Corefile) binds 10.10.50.1 for both glab.lol and the recursive zone. Its listeners are per-address.

Firewall policy

Source → destination Result
services → internet (!RFC1918) accept
services → mgmt / OOB / sandbox / home drop new connections (replies are already accepted globally)
services → anything else default drop (logged)
services → gw01 ICMP, DNS udp/tcp 53, DHCP 67 (same as sandbox; no NTP, no SSH)
management → services accept (MGMT_FORWARD rule 35)
home → services already allowed (WAN_FORWARD accepts any HOME_NETWORKS source)
Tailscale → services already allowed (TAILSCALE_FORWARD → LAB_NETWORKS 10.10.0.0/16, TS_ROUTES already includes 10.10.0.0/16)
Internet egress NAT already covered (source NAT rule 100 masquerades 10.10.0.0/16)

sw-core01 (routeros/sw-core01/bridge.tf)

  • New routeros_interface_bridge_vlan.vlan50, tagged on sfp-sfpplus8 (gw01 trunk) and sfp-sfpplus7 (nas01). Both ports are already admit-only-vlan-tagged bridge ports. README note added.

Tooling

  • verify.py post-sync assertions now require eth1 vif 50 address 10.10.50.1/24, the DHCP listener on eth1.50, and the rule 150 jumps. The operational check requires eth1.50 up with its address. policy.py requires the services gateway in the template. Tests are updated, and one new test asserts that services → management is blocked.

Apply order

  1. sw-core01 first: just snapshot && just plan && just apply. The expected plan is 1 to add (vlan50) with nothing else changed.
  2. gw01 second: CI= moon run network:vyos-sync.
  3. Then the nas01/Incus side (VLAN 50 on its fast link) and media01.

Validation

moon run network:check passes: lock, format, lint, typecheck, pytest (43 passed), vyos-validate, routeros-check (tofu fmt -check, validate). tofu plan and VyOS commit-time syntax checks were not run because they need device credentials or the live box.

Routed 10.10.50.0/24 for long-lived service VMs (first: media01 on
nas01), off both management VLAN 10 and the OVN-owned VLAN 40 uplink.

- gw01: eth1 vif 50 10.10.50.1/24, SERVICES_FORWARD/SERVICES_LOCAL,
  management-to-services accept, DHCP LAB_SERVICES, CoreDNS binds.
- sw-core01: VLAN 50 tagged on sfp-sfpplus8 (gw01) and sfp-sfpplus7 (nas01).

Apply sw-core01 first, then gw01.
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 16, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-16T16:11:24.586125Z 8176a67 PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8176a6799f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@@ -1,5 +1,5 @@
glab.lol:53 {
bind 10.10.10.54 10.10.10.1 10.10.40.1 10.10.70.1
bind 10.10.10.54 10.10.10.1 10.10.40.1 10.10.50.1 10.10.70.1

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Restart CoreDNS so the new VLAN bind takes effect

On an in-place gw01 rollout, the assets stage only overwrites the mounted Corefile, and the subsequent configuration load does not change the container definition or explicitly restart it. CoreDNS rereads a changed Corefile only when its reload plugin is configured, which this Corefile does not enable; VyOS's restart always setting merely controls behavior after the container exits. Consequently, the running process retains its old listeners and does not answer on 10.10.50.1, while the existing verification probes only VLAN 10 and still passes. Restart CoreDNS after the new interface is committed, or otherwise add a reliable post-commit reload mechanism.

Useful? React with 👍 / 👎.

The VLAN 50 sync staged a Corefile binding 10.10.50.1, but the running container kept its old listeners until a manual restart.
@jmgilman
jmgilman merged commit f088bfa into master Oct 16, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant