I spent years building applications on top of networks I did not understand. I could point a domain at a server, open a port, and debug a connection refused. What I could not answer was simpler: when a doctor opens an internal application on a hospital laptop, where does that traffic actually go?
Everything I knew about networking came from the box the ISP installed in my house, and that box is a lie of convenience. It looks like one thing. It is at least six.
Start with the network you already have
Almost every developer has this diagram in their head:
Internet
↓
PTCL Router
├── Phone
├── Laptop
├── TV
└── PC
One box, four devices, nothing to explain. Except it is doing six separate jobs at once, and each becomes its own hardware the moment you scale past a house.
What the ISP calls "the router" is actually:
Router connects your home network to the ISP's network
Switch moves traffic between your own devices
Wi-Fi AP turns radio into ethernet frames
DHCP server hands out IP addresses to devices that join
Firewall / NAT rewrites addresses, blocks unsolicited inbound traffic
DNS forwarder answers name lookups by asking someone upstream
Every confusing thing about enterprise networking gets clearer once you stop treating those six as one device.
The same six jobs at hospital scale
Here is a hospital network. Every box maps to one of those six jobs — each now its own device or rack.
INTERNET
│
ISP
│
Internet Edge Router
│
Perimeter Firewall
│
Core Network
/ | \
/ | \
Staff LAN Wi-Fi Datacenter
│ │
APs Datacenter Switch
│ / | | \
Doctors App DB GPU Storage
Assume this addressing plan throughout:
Network Subnet Example
------- ------ -------
Core services 10.1.0.0/16 10.1.1.10 internal DNS
Staff LAN 10.10.0.0/16 10.10.3.40 workstation
Clinical Wi-Fi 10.10.14.0/24 10.10.14.25 doctor's laptop
Datacenter 10.50.0.0/16 10.50.1.11 application server
Switch versus router
This is the distinction that took me longest.
A switch connects devices on the same network. A router connects different networks. That is the whole thing; everything else is detail.
Consider the datacenter switch:
Datacenter Switch
├── App Server 10.50.1.11
├── Database 10.50.2.20
├── GPU / LLM node 10.50.3.30
└── Storage 10.50.4.40
Those machines talk to each other all day — app to database, database to storage, app to GPU node. None of that touches a router or the internet. They share a network, and a switch moves frames between them.
Now put two networks side by side:
Clinical Wi-Fi Datacenter
10.10.14.0/24 10.50.0.0/16
│ │
└────── ??? ────────────┘
A switch cannot bridge these — different address ranges, different broadcast domains. Getting a packet from 10.10.14.25 to 10.50.1.11 needs a device that understands both and forwards between them. That is a router, and the job is called Layer 3 routing.
If you know which side of that line your problem is on, you know which device to go look at.
Why a hospital does not have 200 ISP routers
The naive scaling model is "a hospital is a big house, so it has a lot of home routers."
At home, one device is router and switch and AP and DHCP and firewall. That is fine for four devices and one uplink, and it breaks at scale because those six jobs scale at different rates: a hospital needs two hundred radios but one internet edge, thousands of switch ports but one DHCP authority. Bundling forces you to buy them in lockstep.
So an enterprise unbundles:
Wi-Fi Access Points many — one per coverage area
↓
Access / Floor Switches many — one per floor or wiring closet
↓
Core Switches few — the spine everything connects to
↓
Routers / Firewalls few — the policy and exit points
Those hundreds of access points are not hundreds of networks. They are radios feeding one managed network, configured centrally. A doctor walking between wings changes AP without dropping their session — as far as the network is concerned, they never left.
What happens when a doctor joins the Wi-Fi
The laptop associates with an access point, authenticates, and then has to answer three questions. DHCP answers all three at once.
Doctor joins hospital Wi-Fi
↓
DHCP responds:
IP address: 10.10.14.25
Default gateway: 10.10.14.1
DNS server: 10.1.1.10
These are genuinely different things, and conflating them causes a lot of confusion:
IP address — who am I on this network? The laptop's identity. Other devices on 10.10.14.0/24 can now address it directly.
Default gateway — where do I send traffic that is not for this network? The laptop reaches its own subnet through the switch. For anything else it does not need the route, only who to hand the packet to — a router interface whose entire job is "give it to me, I will find the next hop."
DNS server — who do I ask to turn names into addresses? Nothing about the laptop knows what hospital-ai.internal means. DHCP tells it which resolver to trust.
None of the three mentions the internet. A device can have all three, work perfectly, and never send a packet outside the building.
Internal DNS is still DNS
This one surprised me. I had assumed DNS was an internet service — something out there, run by Cloudflare or Google, that turns public names into public IPs.
It is a protocol. Anyone can run a server that speaks it, including a hospital, for names that exist nowhere on the public internet.
Doctor's laptop → Internal DNS (10.1.1.10)
"What is hospital-ai.internal?"
Internal DNS → Doctor's laptop
hospital-ai.internal → 10.50.0.10
Type that name on your home laptop and you get NXDOMAIN. Inside the hospital it resolves instantly, because the resolver DHCP handed out is authoritative for the .internal zone. This is why internal services get real names instead of hardcoded IPs — db.internal, models.internal, all private, all independent of whether the building has internet today.
Follow one packet into the datacenter
The section I would keep if I could only keep one. A doctor opens the internal application:
Doctor's laptop
10.10.14.25
↓ resolves hospital-ai.internal → 10.50.0.10
↓ destination is not in 10.10.14.0/24, so send to gateway
Nearest Access Point
↓
Floor Switch
↓
Core Network ← routing decision happens here
↓
Datacenter Network
↓
Datacenter Switch
↓
Application Server
10.50.1.11
Every hop is inside the hospital. Cut the fibre to the ISP right now and this request still completes.
That realization reorganized everything else for me. I had been treating the internet as the thing that makes networking work. It is one possible destination.
Now watch the same laptop reach Google
Same doctor, same laptop, different destination:
Doctor's laptop
↓ resolves google.com → a public IP
↓ destination is not internal, send to gateway
Hospital LAN
↓
Core Network
↓
Perimeter Firewall ← "is this allowed to leave?"
↓
Internet Edge Router
↓
ISP
↓
Internet
↓
Google
Compare the two paths and a clean rule falls out: internal destination, traffic stays inside the hospital; external destination, it exits through the internet edge, past the firewall. The ISP matters only when a packet needs to leave — for a hospital, a minority of traffic.
A private IP is not an internet connection
These ranges are reserved for private use and are not routable on the public internet:
10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255
Two hospitals can both use 10.50.1.11 and never collide, because neither address is visible outside its own network.
The home version makes it obvious. Unplug the WAN cable and leave everything else running:
Laptop A 192.168.1.5
Laptop B 192.168.1.6
WAN cable removed
A ↔ B ✅ still works
A → Google ❌ no route out
The switch still forwards frames, DHCP still hands out leases, and A and B still reach each other's dev servers. Having an IP address never implied having internet access — those were always two facts that happened to arrive together.
This is what makes an isolated datacenter possible: servers with private IPs, talking over a switch, fully functional, with no route out.
Core switch versus datacenter switch
Both are switches. They sit at different altitudes.
Core Switch ← the spine of the whole hospital
│
├── Building A
├── Building B
├── Wi-Fi network
├── Staff LAN
└── Datacenter
↓
Datacenter Switch ← the spine of one facility
├── App servers
├── Database
├── Storage
└── GPU nodes
The core connects the major segments of the organization; the datacenter switch connects servers and racks within one facility. A doctor's request crosses the core once, then lives on the datacenter switch while the app talks to the database and the model nodes — east-west traffic never touches the core at all. Different traffic pattern, different job, different hardware.
The firewall is where policy lives
Everything so far described reachability — can a packet physically get there. The firewall answers a different question: should it.
Staff → Internet ✅ allowed, filtered
Doctor → Hospital AI (HTTPS) ✅ allowed
Doctor → PostgreSQL directly ❌ denied
Doctor → GPU / model node ❌ denied
AI datacenter → Internet ❌ denied
Read that last line again, because it matters most for what comes next. The AI datacenter is physically connected to the core switch — packets from it could reach the internet edge. They do not, because the firewall drops them. Reachability and permission are different layers.
That is network segmentation: dividing one physical network into zones and writing rules about which zones may open connections to which. Doctors reach the application over HTTPS and nothing else. Nobody reaches the database directly. The AI zone reaches nothing outbound.
Once you can see that shape, the design of a private AI system stops being mysterious.
The whole model on one screen
Internet
↑
ISP
↑
Edge Router
↑
Perimeter Firewall
↑
Core Network
┌────────────┼────────────┐
│ │ │
Staff LAN Wi-Fi Datacenter
│ │
Doctors DC Switch
/ | \
App DB GPU
A switch connects devices. A router connects networks. A firewall controls which connections are allowed. DNS converts names to addresses. The ISP only becomes relevant when traffic actually needs to leave the hospital.
What I should be able to explain after reading this
- Why a server can have an IP address without having internet access.
- The difference between a switch, a router, an access point, and a firewall.
- What DHCP provides, and why those three values are three different things.
- Why internal DNS does not require an internet connection.
- How
hospital-ai.internalends up reaching a specific datacenter server. - The difference between the internet edge router and the core network.
- Why connecting a datacenter to the core switch does not give every server internet access.
- How subnet and VLAN segmentation work, and what the firewall adds on top.
In the next article I use this hospital network as the foundation for an internal generative AI system, where the LLM, embeddings, retrieval, data, and observability all stay inside the hospital's own infrastructure: Designing an Air-Gapped RAG Architecture for Healthcare.
I write about the systems behind shipping AI features — RAG pipelines, evals, and the gap between demo and production — in my newsletter, AI Shipped. New issue every week.