Frank
54bb0202c2
Three pages described the fleet; two of them still described the pre-September arrangement. Re-read live on 2026-10-21 (`/v1/models`, `systemctl`, `lspci`, `nproc`, `resolvectl`): - `system/network.md` called Dankclaw the "large inference model" box and Dankserver the "small" one — that is the topology from before the RTX 3090 moved in September. The served ids today are `frank-archon` on Dankserver:7770 (the main model) and `frank-dragoon` (:7770) + `frank-zealot` (:7771) on Dankclaw. The gateway and the DNS pin were re-read too. - `system/dankserver.md` claimed `frank-medium` is *masked*: the unit file does not exist (`is-enabled` answers `not-found`), which is a different fact with a different remedy. And it claimed 8C/16T: this 7700X exposes **8 threads** (`nproc` = 8), so anything sized for 16 is sized for a machine that is not this one. - `system/dankclaw.md` transcribed the engine's slot/KV/context math — `2×262,144 slots over one 524,288 pool, unquantized f16 K+V, MTP off` — while the live unit says `3x200704 slots over one 602112 pool, f16 K + q8_0 V, MTP armed`, and dragoon's ctx had moved too. That math belongs to the serverAppConfigs runbook the page already names: the unit's `ExecStart` is a wrapper script, so any copy here rots on the next engine change. The page now keeps the contract — id, unit, port, engine family, which GPU, and how to prove it — and disowns the numbers, with the reason stated so the next agent does not re-transcribe them. Also recorded, because it is how this audit nearly missed a stopped service: `curl :7770/v1/models` answered normally while `frank-dragoon.service` sat `inactive` with `Result=exit-code` — the container is running outside systemd. A serving port is not a healthy unit. (Flagged for Frank separately; no production unit was touched.) Refs #64
99 lines
3.4 KiB
Markdown
99 lines
3.4 KiB
Markdown
---
|
||
type: reference
|
||
title: Network
|
||
description: LAN topology for the fleet and the client-side DNS pinning rule for multi-homed Linux workstations.
|
||
tags:
|
||
- network
|
||
- dns
|
||
- systemd-resolved
|
||
- workstation
|
||
- unverified
|
||
verified: 2026-10-21
|
||
---
|
||
|
||
# Network
|
||
|
||
How the LAN is addressed, which host answers what, and the one DNS rule that
|
||
bites every Linux workstation with both Wi-Fi and Ethernet plugged in.
|
||
|
||
---
|
||
|
||
## Topology
|
||
|
||
| Host | IP | Role |
|
||
|------|----|------|
|
||
| Router | 192.168.0.1 | DHCP; hands out the DNS server to clients |
|
||
| Dankclaw | 192.168.0.143 | Pi-hole DNS, Caddy edge, Gitea, service stack, secondary inference (`frank-dragoon` :7770, `frank-zealot` :7771) |
|
||
| Dankserver | 192.168.0.235 | Main inference — `frank-archon` on 2× R9700 (TP=2), :7770 |
|
||
| Clients | DHCP from 192.168.0.0/24 | workstations, phones |
|
||
|
||
The router (default gateway `192.168.0.1`, both re-read 2026-10-21) hands clients
|
||
`192.168.0.143` as their DNS server; Pi-hole answers
|
||
every `*.franksdank.cloud` name with the LAN address of the box that serves
|
||
it. Names that resolve to the public WAN address time out on the LAN because
|
||
the G36 has no NAT loopback — a symptom that looks like "the network is
|
||
down" and is not. Full DNS mechanics live in the serverAppConfigs knowledge
|
||
base (`Infrastructure/LAN-DNS.md`); this page is the client-side view.
|
||
|
||
---
|
||
|
||
## The multi-link resolver rule
|
||
|
||
**A Linux client with two `+DefaultRoute` links will flap its DNS.**
|
||
|
||
NetworkManager marks both a wired and a Wi-Fi connection as default routes.
|
||
Both get the same DHCP DNS list from the router, and `systemd-resolved`
|
||
resolves queries against one "current" resolver *per link*. When the links
|
||
disagree — one landed on the Pi-hole address, the other on a DHCP-provided
|
||
upstream that answers with the public WAN IP — every lookup can return a
|
||
different address, and half of them time out on the LAN.
|
||
|
||
Enumerate the links and their resolvers before changing anything:
|
||
|
||
```bash
|
||
nmcli -t -f NAME,DEVICE connection show --active # one entry per default link
|
||
resolvectl status # per-link "Current DNS Server"
|
||
ip -br addr
|
||
```
|
||
|
||
The fix is to pin the LAN resolver **on each connection**, because
|
||
`/etc/systemd/resolved.conf`'s `DNS=` is only a per-link fallback and does
|
||
not override what the link itself was handed:
|
||
|
||
```bash
|
||
for c in "<wired connection>" "<wifi connection>"; do
|
||
nmcli connection modify "$c" ipv4.method auto \
|
||
ipv4.dns 192.168.0.143 \
|
||
ipv4.ignore-auto-dns yes \
|
||
ipv4.ignore-auto-routes no
|
||
done
|
||
nmcli connection up "<wired connection>"
|
||
nmcli connection up "<wifi connection>"
|
||
systemctl restart systemd-resolved
|
||
```
|
||
|
||
`method auto` keeps DHCP for address, gateway, and routes; `ignore-auto-dns
|
||
yes` makes the static resolver the only one used; `ignore-auto-routes no`
|
||
keeps the DHCP routes, so the dual-default traffic path survives.
|
||
|
||
Verify with a cache-clear loop — the name must return the LAN address on
|
||
every run, not on average:
|
||
|
||
```bash
|
||
for i in $(seq 1 10); do resolvectl flush-caches; dig romm.franksdank.cloud +short; done
|
||
```
|
||
|
||
A single successful `dig` proves nothing on a flapping resolver.
|
||
|
||
---
|
||
|
||
## Servers
|
||
|
||
- [Dankserver](/system/dankserver.md) — main model, `frank-archon`
|
||
- [Dankclaw](/system/dankclaw.md) — secondary models, DNS, edge, forge
|
||
|
||
## See Also
|
||
|
||
- [System Documentation](/system/index.md) — bundle navigation
|
||
- [CachyOS](/tools/cachyos.md) — NetworkManager, systemd-resolved, BlueZ
|