Let’s not sugarcoat it — networks are messy. Devices get renamed mid-project, subnets appear out of nowhere, and the one guy who *knew* why VLAN 60 existed left six months ago. That’s why this doc exists.
It’s not meant to win formatting awards. It’s meant to save your ass at 2AM when the monitoring dashboard’s flatlined and someone’s asking, “Who set this up?”
This isn’t the full bible of the network, but it’s enough to help you:
– Figure out what connects to what
– See who has access to which bits
– Trace where that mystery 10.0.30.x address leads
– Know who to ping when it’s all falling apart
So yeah — keep it updated. If you change something and don’t jot it down here, you’re just future-you’s worst enemy.
1. Basic Stuff (aka What We’re Dealing With)
– Network Name: Internal LAN — usually referred to as “Techsphere” (or worse things, depending on uptime)
– Owned by: Infra Team — contact Mike or whoever’s not on PTO
– Version: v1.2
– Last sanity check: May 2025
– Main reason this exists: So we don’t have to Slack each other every time someone needs a static IP or asks “Where’s the firewall config?”
2. Overview — What Lives Where
2.1 Topology Sketch
There’s a diagram — yes, an actual diagram — showing the big pieces: DMZ, VLANs, Wi-Fi zones, etc.
Check the shared folder or just yell if it’s missing again. Usually stored in /docs/network-maps/topology-latest.vsdx.
Pro tip: If the diagram doesn’t match reality, assume the network changed and no one told the doc.
2.2 What’s On the Wire (Sample Inventory)
This isn’t the full CMDB. Just the essentials.
| Hostname | IP Address | Device | What It Does | Where It Sits |
| core-sw-01 | 10.0.0.1 | Cisco 2960X | Core switch | Rack A1 |
| edge-fw | 10.0.0.254 | pfSense | Edge firewall | DMZ |
| zabbix-srv | 10.0.20.10 | Ubuntu 22.04 | Monitoring (Zabbix) | Server Room |
If it’s not listed here, it’s either new, forgotten, or still on someone’s desk unplugged.
2.3 IP Addressing — Who Lives Where, Exactly
So here’s the rough breakdown of our IP blocks. This isn’t gospel — things drift sometimes — but it’s close enough to navigate the mess.
| Subnet | Description | DHCP? | Notes |
| 10.0.0.0/24 | Core switching layer | No | Static IPs only, for infra gear |
| 10.0.10.0/24 | Office LAN (users) | Yes | DHCP via AD, leases ~7d |
| 10.0.20.0/24 | Server VLAN | No | Static, tracked in IPAM |
| 10.0.30.0/24 | Wi-Fi (staff) | Yes | WPA2-Enterprise via RADIUS |
| 10.0.40.0/24 | Guest Wi-Fi | Yes | Internet-only VLAN |
| 10.1.1.0/30 | WAN uplinks | No | Point-to-point links, static |
If someone throws a random 10.0.99.x at you — it’s probably a test bench or lab. We don’t always admit those exist.
5.2 Disaster Recovery (When It Hits the Fan)
Okay, let’s be real: if something big goes down, this isn’t the full playbook — but it should give you a solid starting point when things get weird.
If the core switch dies:
- Try rebooting first. If it doesn’t come up, replace with cold spare in Rack A2.
- Configs are in /backup/net-configs/ — look for core-sw-01.conf
If pfSense goes offline:
- Check power first. Seriously, 90% of the time it’s a power hiccup.
- We’ve got a clean USB image and config backup in /rescue-images/
- WAN IP might need to be reissued depending on ISP behavior
If monitoring (Zabbix) is down:
- Check if it’s the host (zabbix-srv) or just the frontend
- You can SSH into it using infra SSH key and restart via systemctl restart zabbix-server
Everything else dead?
- Power outage? Check UPS logs.
- If the NAS is down — backups are mirrored to cloud every 24h (check Borg logs)
- Call Mike. Or panic. But preferably call Mike.
DR test was last run in January 2025 — we recovered the whole stack in ~90 mins. Room for improvement? Sure. But it worked.