network-map: resolve makerspace addressing from on-site checks
- data ports give 10.2.30.0/24 (sjat got .227), gw 10.2.30.1 - 10.2.30.0/24 and 10.0.0.0/24 inter-route via makerspace router - note mf04 IP drift: actual 10.0.0.183, host_vars says .184 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
9ff12700ae
commit
97dabfd928
1 changed files with 18 additions and 14 deletions
|
|
@ -16,23 +16,27 @@ links below. Confirm live values before acting.
|
||||||
| `10.8.0.0/24` | baobab (home) WireGuard plane. Hub **kuku** `10.8.0.1` (UDP `:51194`); mamba `10.8.0.4`. | `AnsibleBaobabV4` |
|
| `10.8.0.0/24` | baobab (home) WireGuard plane. Hub **kuku** `10.8.0.1` (UDP `:51194`); mamba `10.8.0.4`. | `AnsibleBaobabV4` |
|
||||||
| `10.20.10.0/24` | homelab LAN — **fisi** `.17`, kuku `.118`, papa `.11`. | `AnsibleBaobabV4` |
|
| `10.20.10.0/24` | homelab LAN — **fisi** `.17`, kuku `.118`, papa `.11`. | `AnsibleBaobabV4` |
|
||||||
|
|
||||||
## ⚠️ Open question — makerspace addressing
|
## Makerspace addressing — mostly resolved (2026-06-09)
|
||||||
|
|
||||||
The makerspace shows **three different subnets** for hosts that are all
|
Confirmed on-site:
|
||||||
physically there: `10.2.30.0/24` (new CRS310 data VLAN), `172.17.3.0/24`
|
|
||||||
(`makerfloss1`), and `10.0.0.0/24` (`mf04`). It's not yet documented here how
|
|
||||||
they relate — i.e. whether the new switch sits in front of the existing
|
|
||||||
OrangeMakers `172.17.3.x` / `10.0.0.x` network, replaces part of it, or is a
|
|
||||||
parallel segment.
|
|
||||||
|
|
||||||
**To resolve (sjat to confirm on-site):**
|
- A client on the new switch's **data ports** (`ether2–7`) gets a
|
||||||
- What IP does an ethernet client on the new switch's data ports (`ether2–7`)
|
`10.2.30.0/24` lease (sjat's laptop got `10.2.30.227`); gateway `10.2.30.1`.
|
||||||
actually get, and from which DHCP server / gateway?
|
- The data VLAN `10.2.30.0/24` and the existing makerspace `10.0.0.0/24`
|
||||||
- Are `makerfloss1` (`172.17.3.51`) and `mf04` (`10.0.0.184`) reachable from a
|
**inter-route**: from `mf04` (`10.0.0.183`, gw `10.0.0.1`), both
|
||||||
data-port client on the new switch, or are they on a different segment?
|
`10.2.30.1` and `10.2.30.227` ping at <1ms. So the two subnets are different
|
||||||
- Is the `10.2.30.1` uplink gateway the OrangeMakers router, or something new?
|
segments joined by the makerspace router (`10.0.0.1` ↔ `10.2.30.1`), not
|
||||||
|
isolated from each other.
|
||||||
|
|
||||||
Update this section (and the host IPs in [access.md](access.md)) once confirmed.
|
Still loose:
|
||||||
|
- `makerfloss1` is recorded as `172.17.3.51` — a *third* subnet. Not yet
|
||||||
|
confirmed whether it's still on `172.17.3.x` or has moved onto `10.0.0.x` /
|
||||||
|
`10.2.30.x`. Confirm when next on-site.
|
||||||
|
- **IP drift:** `mf04` is actually `10.0.0.183` (DHCP), but
|
||||||
|
`AnsibleBaobabV4/host_vars/mf04.yml` says `ansible_host: 10.0.0.184`. The
|
||||||
|
ProxyJump-via-mamba path there targets the stale `.184`. Either pin a DHCP
|
||||||
|
reservation or update host_vars. (Reaching mf04 over `wg1` `10.13.0.3` is
|
||||||
|
unaffected.)
|
||||||
|
|
||||||
## Public services (makerfloss VPS, `88.99.32.236`)
|
## Public services (makerfloss VPS, `88.99.32.236`)
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Add table
Reference in a new issue