The app team swore it wasn’t them. It wasn’t. It also wasn’t the app.

Ticket comes in: "Can't reach the reporting server, app must be down." Two weeks into a help desk role that's supposed to turn into network engineering, and this is the first real escalation.

Restart the app service. Nothing. Restart it again, because sometimes that's just what fixes things. Still nothing. Ping the app team, they check their logs, service is up, healthy, listening. Forty-five minutes gone and both teams are now firmly convinced it's the other one's fault.

Nobody checked the network path. That's usually where "can't reach the server" actually lives, and there's a reason experienced engineers don't guess at it: they work it bottom-up, one OSI layer at a time, instead of starting wherever the ticket happens to point.

Layer 1, physical: is the interface even up, link light or "show interface status" on the switch. If there's no link, nothing above matters yet.

Layer 2, data link: right VLAN? Check the switch port config and the MAC address table to confirm the server's MAC shows up where expected, then check ARP for a stale entry pointing at hardware that got swapped or a port that got reassigned.

Layer 3, network: does the gateway answer ping? Does the server IP? If the gateway answers and the server doesn't, check the routing table for something missing or wrong. A subnet re-carved without every static route getting updated is a routine cause of "pings from some places, not others."

Layer 4, transport: ping succeeding proves nothing about the port. telnet or nc to the specific port the app listens on tells you whether the TCP handshake actually completes. A host can answer ICMP fine and still hard-refuse the port that matters.

DNS, before the app layer: does the hostname the ticket used actually resolve to the IP being tested? If not, the wrong host has been debugged this whole time.

Layer 7, last: only once everything below checks out does curl -v against the endpoint tell you anything real, the actual status, the actual headers, the actual error.

In this case it was layer 2. A switch config push earlier that day moved the server's port into a different VLAN, and that VLAN's gateway never made it into the routing table. Link light fine. Ping to anything on the same broken subnet fine. Ping to the actual gateway timed out immediately, which the bottom-up method finds in about ninety seconds instead of an hour of two teams pointing fingers.

This is also the exact shape of a real network engineering interview question. Not "define OSI," but "here's a ticket, walk me through isolating it." The candidates who do well aren't reciting seven layers from memory, they're showing they'd check them in order instead of guessing.

That instinct doesn't come from memorizing a diagram, it comes from actually building and breaking networks across the range this scenario touches: physical topology and VLANs at the foundation, routing and switching at the enterprise level, and the architecture decisions above that tie it together. Codelivly's Network Engineer Book Bundle covers that whole arc, L1 through L3, as one connected progression instead of three separate things to cram. If subnetting and VLANs are still the shaky part, the free Routing & Switching Fundamentals path on codelivly.com is a solid place to build that base first.