The label printer in the goods-in bay at a distribution warehouse near Tilburg is reachable from the office and not from the two handheld scanners twenty metres away from it. Both scanners have addresses. Both can reach the internet. Neither can reach a printer they can see across the room, and the person sent to fix it has been told the network is down, which it plainly is not.
This is the fault that ends most people's networking confidence, and it does so for one reason: they know what an address is, what a name is and what a route is, as three separate facts, and a real failure is the question of which of those is lying. The valuable skill on this topic is an order to ask in, not a longer list of definitions.
The one number that decides who is local
The scanners are on 10.20.4.0 and the printer is on 10.20.5.0. Whether that matters is decided entirely by the mask. A subnet mask decides which addresses are local and which need a router. With a /24 mask, only the first three numbers are the local network, so 10.20.4 and 10.20.5 are two different networks and every packet between them has to be routed. With a /22 they would be the same network and the traffic would never leave the switch.
The scanners had a /24 and the office had a /22, which is why the office could print and the bay could not. Nobody had changed anything: the handhelds took their configuration from a different DHCP scope that had been set up for guest devices two years earlier, and inherited a narrower mask than everything else in the building.
Asking each layer, in an order
The first question is whether anything is listening at all, and it is asked on the machine that is supposed to answer.
ss -tlnp- prints
LISTEN 0 128 0.0.0.0:9100 users:(("printer",pid=812,fd=6))
ss -tlnp lists what is listening and which process owns the port, and the two halves of that are both load bearing: a port that nothing is listening on is a different fault from a port held by the wrong process. On the printer the port was open and owned, which convicted the path rather than the device and saved an afternoon of restarting a printer that was working perfectly.
The second question is where the path stops. Traceroute shows where the path stops, not who broke it, which is the distinction that makes it useful rather than misleading. A trace that dies at the third hop tells you the packet reached the third hop and did not reach the fourth. It does not tell you the third device is faulty, and very often the third device is fine and is simply refusing to route between two networks it has not been told about. Reading that output correctly is most of working out which layer is broken.
The fault that looks like slowness
The third thing worth having in advance is the one that produces no error at all. MTU: a packet too large is dropped silently and looks like a slow site. Small requests succeed, large ones hang, and the symptom presents as an application that works for some pages and stalls on others. It is common on links that add a wrapper of their own, which is most tunnels and many broadband connections, and it is invisible to every tool that only sends small packets. Ping with a large payload and the do-not-fragment flag set is the test, and a working link answering small pings and dropping large ones is the whole diagnosis.
One packet, one question
The fork every packet takes, decided by a number nobody looks at
Both arms work perfectly. Which one a machine takes is decided by its mask, and a wrong mask produces a network that is faultless and cannot print.
- The mask says yesShout for it on the local wireNo router involved, and the packet never leaves the switch
- Works even when routing is misconfigured
- Fails the moment the two devices are genuinely on different networks
- What the office machines were doing, with a /22
- The mask says noHand it to the gatewayNow a router has to have been told about both networks, and it had not
- Correct behaviour, and the packet is discarded further along
- Traceroute stops at the hop that was never told
- What the scanners were doing, with a /24
The figure does not say which mask is right, because neither is. The fault is that two groups of devices in one building were given different answers to the same question.
Why the model is worth the hour
This is the topic the rest of the machines, the networks between them, and keeping both standing leans on hardest, because a fault anywhere else in the pillar is routinely reported as a network problem and has to be excluded before anything else can be examined.
The layered model is taught badly, as seven names to memorise for an exam. Its actual value is that it gives the questions an order: a fault at one layer makes every layer above it look broken, and no layer below it can be blamed. Establishing that the wire is live before arguing about DNS is not pedantry, it is the only way to stop testing the same thing three times, and it is what the model everything else refers back to is for.
The Tilburg fault sits at the third layer. Everything below it was perfect, which is why everybody who looked at cables and lights concluded the network was fine, and everything above it was equally perfect, which is why the printer answered when asked from the right place. The numbering and naming that decides this is naming and numbering the machines, and the boxes that were being asked to route between the two networks are the boxes between the machines.
Where people stall
The stall is exactly the moment described at the top: the point at which the abstractions stop being separable. It arrives when somebody who can define an IP address, a DNS record and a gateway meets a fault that is none of those things individually and all of them at once, and concludes that real networks are beyond them. They are not. What is missing is a diagnostic order, and it takes an afternoon to acquire and is almost never taught, because a definition is easy to examine and an order is not.
The second stall is wireless, and it is a physics problem wearing a networking costume. A link that works at the desk and fails at the loading door has not changed its configuration, and no amount of protocol knowledge helps, which is why radio, and everything that interferes with it is a separate cluster rather than a section.
What to open, in 2026
On any modern Linux, ss replaced netstat and ip replaced ifconfig, and both replacements happened years ago while the old commands remain in most tutorials and in a great deal of muscle memory. They are free and already installed. Learn the new pair, and recognise the old ones when reading anything older than about 2018.
When the commands disagree with each other, Wireshark shows what is actually on the wire and settles it. It is free and open source, it replaced guessing from log files, and it is the tool that turns an argument between two teams into a packet capture that one of them is wrong about. Reading a capture is a skill in itself and is worth the afternoon it takes to start.
What none of this settles is what to do once the path is correct and somebody is deliberately using it against you, which is the subject of configuring the boxes, not just naming them at one end and of the topic after this one at the other.