mit einem Klick
homelab-network-setup
Practical home and homelab network planning for gateways, switches, access points, IP ranges, DHCP reservations, DNS, cabling, and common beginner mistakes.
Menü
Practical home and homelab network planning for gateways, switches, access points, IP ranges, DHCP reservations, DNS, cabling, and common beginner mistakes.
Instinct-based learning system that observes sessions via hooks, creates atomic instincts with confidence scoring, and evolves them into skills/commands/agents. v2.1 adds project-scoped instincts to prevent cross-project contamination.
Orchestrate building a brand-new feature end to end — research, plan, TDD implementation, review, and gated commit — by delegating each phase to the matching ECC agent. Use when adding a capability that does not exist yet.
Orchestrate bootstrapping a working MVP from a design or spec document — ingest the doc, plan thin vertical slices, scaffold the first end-to-end slice, then TDD-implement, review, and gated commit. Use to turn an SDD/PRD into a running starting point.
Orchestrate altering an existing, working feature to new desired behavior — update its tests to the new spec, change the implementation to match, review, and gated commit. Use when behavior is not broken but should be different.
Orchestrate fixing a bug — reproduce it as a failing regression test, fix to green, review, and gated commit — by delegating each phase to the matching ECC agent. Use when existing behavior is broken or wrong.
Shared orchestration engine for the orch-* skill family. Defines the gated Research-Plan-TDD-Review-Commit pipeline, the size classifier, the agent map, and the two human gates that the orch-* operation skills delegate to. Not usually invoked directly.
| name | homelab-network-setup |
| description | Practical home and homelab network planning for gateways, switches, access points, IP ranges, DHCP reservations, DNS, cabling, and common beginner mistakes. |
| origin | community |
Use this skill to design a home or small-lab network that can grow without needing a full rebuild.
Start by separating device roles:
Internet
|
Modem or ONT
|
Gateway or router NAT, firewall, DHCP, DNS, inter-VLAN routing
|
Managed switch wired clients, AP uplinks, optional VLAN trunks
|
Access points Wi-Fi only; ideally wired backhaul
Servers and NAS stable addresses, DNS names, monitoring
Clients and IoT DHCP pools, isolated later if VLANs are available
Pick a gateway that matches the operator, not just the feature checklist:
| Option | Best fit | Notes |
|---|---|---|
| ISP router | Basic internet only | Limited control and often poor VLAN support |
| UniFi gateway | Managed home network | Good UI, ecosystem lock-in |
| OPNsense or pfSense | Flexible homelab | Strong VLAN, firewall, VPN, and DNS control |
| MikroTik | Advanced network users | Powerful, but easy to misconfigure |
| Linux router | Tinkerers | Document rollback before using as primary gateway |
Avoid the most common default, 192.168.1.0/24, when you expect to use VPNs.
It often conflicts with hotels, offices, and ISP routers.
Example small homelab plan:
192.168.10.0/24 trusted clients
192.168.20.0/24 IoT and media devices
192.168.30.0/24 servers and NAS
192.168.40.0/24 guest Wi-Fi
192.168.99.0/24 network management
Gateway convention: .1
Infrastructure reservations: .2 through .49
Dynamic DHCP pool: .50 through .240
Spare room: .241 through .254
Use home.arpa for local names. It is reserved for home networks and avoids the
leakage/conflict problems of ad hoc names like home.lan.
nas.home.arpa
pihole.home.arpa
gateway.home.arpa
switch-01.home.arpa
Goal: Keep the ISP router but stabilize a small lab.
home.arpa.Goal: Prepare for future segmentation without enabling it immediately.
192.168.1.0/24 when VPN access is planned.network-interface-healthnetwork-config-validation