Understanding Network Infrastructure · Introduction · Start with the whole communication flow
Internet not working? Where should you start?
A diagnostic map: Narrow down connection failures using evidence from the link, addressing, name resolution, path, and service
A browser's ‘Unable to connect to the internet’ message can have many causes. To find where a request or response stopped, you first need to understand how communication works when everything is normal. This book starts with endpoint addressing, switching, and routing, then moves on to real network design, external connections, security, and recovery. We begin with what to check when a connection fails.
Complete book contents · 35 articles
Introduction · Start with the whole communication flow
The same connection failure can have different causes. First trace the request and response between endpoint and server, then read about the work each stage does.
Part 1 · How does my PC get ready to communicate?
Learn how a device decides whether a destination is on the same network, calculate the address space you need, and see how an endpoint receives its settings.
Part 2 · How does data reach nearby devices?
Start by finding the MAC address to send to, then connect that process to VLANs, loop prevention, link aggregation, and forwarding between VLANs.
Part 3 · How does traffic reach other networks and the Internet?
First understand how a router selects a route. Then explore NAT, static-route failover, and route calculation with OSPF.
Part 4 · How do we use these principles to design a real network?
Start with why we separate the functions combined in a home router. Apply roles, addressing, capacity, and failure boundaries to Cisco's reference designs to choose the layers and redundancy you need.
- How do large enterprise networks split a home router's roles?
- How does Cisco choose a network architecture?
- What do access, distribution, and core each do?
- When is one router enough for a small office?
- What changes when a small office uses separate switches and APs?
- How can a company avoid overlapping private IP ranges?
- How much uplink capacity is enough—even after a link fails?
- What else stops when one device fails?
- How far should VLANs extend, and where should routing begin?
- How should switches across multiple wiring closets connect?
- How should switches and routers be configured for redundancy?
- When does a multi-building network need a separate core?
Part 5 · Connecting the enterprise network to branches, clouds, and the Internet
Explore what is needed to connect an enterprise network to branches, clouds, and the internet. Distinguish activating a circuit from obtaining addresses and advertising routes, then move on to BGP and redistribution policy.
Part 6 · Keeping connected networks secure and recovering from failures
Apply the design's security policies to actual traffic paths, then examine attack response, failure testing, and service recovery. During an active compromise, preventing further damage comes first.
Conclusion · One exchange, the whole network
Explain the opening web connection again, and distinguish normal communication from ordinary failures and security incidents. Close the book by connecting the terms you have learned to real design and operational decisions.
Why can the same ‘Internet connection failed’ message have different causes?↑
A blank browser page can have many causes. The wireless connection may be down, the endpoint may not have received an address, or DNS may have failed to resolve the name. A missing route to the destination or a server refusing the connection can look the same to the user: ‘The internet isn't working.’
The first rule of troubleshooting is not to guess which device is at fault. Break the observed symptom into communication stages and check the evidence at each stage. Link status, IP settings, DNS responses, ARP and the routing table, and TCP responses each answer a different question.
Suppose a user reports only that https://www.imbizcorp.com will not open. If Wi-Fi association has been lost, the endpoint cannot send a frame at all. If DHCP fails, the link may be up but the correct source IP and default gateway are missing. If DNS fails, connecting directly by IP address may still work. If TCP fails, a valid DNS answer may be available but no reply arrives for the SYN. These causes produce the same screen, yet the last successful action is different in each case.
Describe failures in terms of observable behavior, not suspected devices. Instead of ‘It looks like a firewall problem,’ report: ‘The endpoint received a DNS answer. One destination observed on 2026-09-03 was 104.21.30.148:443. It sent a SYN there, but no SYN-ACK came back.’ This records both a working stage and the first failure. Even if another person takes over, they can continue using the same packet and timestamp. That is the practical value of stage-by-stage troubleshooting.
For the TCP-based HTTPS connection illustrated in this article to work, the endpoint needs a working link and address configuration, name resolution, a route to the destination, TCP and TLS connections, and a server response. Which devices and records you inspect depends on where it fails. Finding the last working stage and the first failed one narrows the section of the path to investigate.
Sources for this section IETF RFC 1122
Not sure where to start? Check the evidence on your endpoint↑
First check whether the endpoint is connected to the network. An Ethernet port that is up or a connected Wi-Fi indicator is only a starting point for Layer 1 and Layer 2 connectivity. It does not prove that IP communication works end to end.
Next check the IP address, subnet mask, default gateway, and DNS server. If the expected enterprise subnet is 10.20.30.0/24 but the endpoint has 169.254.23.8, investigate the address-allocation process before the web server: DHCP is the earlier checkpoint. If the addressing is correct, check whether the local gateway is reachable.
Starting with nearby evidence does not mean mechanically working up from the physical layer. It means comparing the values most closely related to the symptom that you can check immediately. If only one user is affected, start with that endpoint's IP settings and ARP cache. If everyone on the same access switch fails at once, the uplink and VLAN state may be more relevant. The scope of the failure and the time of the last change help you choose where to start.
Every check needs a baseline for what is normal. Do not stop at an interface being up: check whether error counters are increasing. For a DHCP lease, check whether the prefix and gateway match the design. For the gateway IP, check whether its ARP entry is Complete. Compare the current values with a normally working endpoint or a working port in the same VLAN. Having a value is not the same as having the right value. Without that comparison, an existing setting can easily be mistaken for evidence of normal operation.
For example, if an enterprise endpoint should have an address in 10.20.30.0/24 but has only 169.254.23.8, address configuration comes before the web server. If the address and gateway are correct and the gateway's MAC address is present in the ARP cache, move the investigation to DNS or the next hop. One stage succeeding does not prove the whole connection works; it gives you a reason to check the next stage.
Sources for this section IETF RFC 1122
Link to service: Five checkpoints, five kinds of evidence↑
| Checkpoint | Question to answer | Typical evidence |
|---|---|---|
| Link | Can the endpoint and the first device exchange frames? | Signal, port status, error counters |
| Addressing | Does the endpoint have the correct network settings? | IP, Mask, Gateway, DHCP Lease |
| Name resolution | Does the domain name resolve to the destination IP address? | DNS queries, responses, and cache |
| Path | Are packets and responses forwarded in both directions? | ARP, routes, NAT, and captures at each hop |
| Service | Does the destination process respond to connections and requests? | TCP flags, TLS alerts, and HTTP status |
A single ping cannot assess all five checkpoints. A website may work even when policy blocks ICMP. Conversely, a device may respond normally to ICMP while DNS or a TCP service fails.
These checkpoints are a sequence, not independent tests: one stage's output becomes the next stage's input. If DHCP supplies the wrong DNS server address, name resolution fails. If DNS returns an old server IP address, TCP may work correctly but try to connect to the wrong destination. If ARP cannot find the gateway MAC address, even a correct DNS answer will not let you reach a remote prefix with a packet. Check not only the failing stage but also where its input came from.
Use ping and traceroute to answer specific questions. A gateway ping gives one piece of evidence about a local Layer 2/Layer 3 round trip. A destination-IP ping tests the ICMP path and response policy. Testing by name also involves DNS. Do not turn one command's success or failure into a verdict on the entire network. Record the protocol and destination it actually used so you know which checkpoints it tested.
Choose the test tool to fit the checkpoint. If an address works but a name does not, inspect DNS evidence. If SYN packets keep repeating without a reply, check the return path and firewall. If you receive a TLS alert, check the certificate and cryptographic requirements. Start with the question you need to answer, not the tool's popularity.
Sources for this section IETF RFC 1122
What the diagram shows Compare a successful connection in which the link, addressing, gateway, DNS, and service work together with a failed connection where the chain breaks. Contrast DHCP assignment, a gateway ARP reply, PAT translation, and successful name resolution in the successful case with the APIPA address, failed WAN authentication, and blocked queries in the failed case.
↔ Scroll horizontally to explore the diagram.
Request reached the server? Check the return path too↑
Communication is not complete just because a request packet reaches the server. The server's response must return to the endpoint. Asymmetric routing can be normal, depending on the design. But a stateful firewall or a device that combines connection tracking with NAT may see only one direction. It may then fail to recognize the response as part of the existing flow or find the required NAT mapping.
A packet capture at just one point can lead to a premature conclusion. Correlate the request leaving the endpoint, the same flow at the boundary device, and the response leaving the server, using timestamps and the 5-tuple. Also record where any values change.
Suppose the endpoint at 10.20.30.25:51514 sends a connection request to the server at 104.21.30.148:443 using a SYN. If the server sees the SYN but the endpoint sees no SYN-ACK, the request has reached at least the server. Now follow the response direction: check the server's default gateway, the return route, and the boundary's NAT mapping and firewall state. Capturing the request again will not tell you where the reply disappears.
When correlating captures from several points, account for address changes. The internal source may be 10.20.30.25:51514, while outside NAT it is 198.51.100.8:40001. To confirm that both packets belong to the same flow, compare their TCP sequence numbers, destination, and timestamps alongside the NAT log. Checking both directions does not require a symmetric path. It means confirming that each direction has the necessary routes and satisfies the state requirements of intermediate devices.
Record where and when each packet capture was taken. Match the endpoint's outgoing TCP SYN, the same SYN after address translation at the boundary, and the server's SYN-ACK using sequence numbers, flags, and the 5-tuple. Investigate between the last observed request and the point where the response first disappears. A server responding to ping does not establish that this exchange works.
Sources for this section IETF RFC 1812
Look between the last known-good point and the first failure↑
Scenario: An enterprise laptop cannot open a service by domain name, but it can connect using the server's IP address.
- Check the link and IP configuration. Since direct IP access works, these checks have lower priority.
- On the same endpoint, inspect the DNS query and response for the target name.
- If there is no response, check the path to the configured DNS server and the server logs.
- If the answer contains the wrong address, check the authoritative server's records, split-horizon DNS, and cache expiration.
- After the correction, query the same name again and verify that the actual connection destination has changed.
The point is to avoid suspecting every device at once. Narrow the investigation to the stretch between the last known-good checkpoint and the first failed one.
Record both successful and failed tests in enough detail to compare them. Instead of ‘DNS is normal,’ record the queried name, answer IP, response timestamp, and the DNS server used. For a failed TCP connection, record both IP addresses and ports, the number of SYN retransmissions, and whether any RST or ICMP response arrived. You can then identify the devices and links at the boundary between what worked and what failed.
After a change, repeat the original test under the same conditions. Unless you clear the DNS cache or account for its TTL, you may test with an old answer. Reusing an existing TCP session may bypass the new firewall policy. Preserve captures and counters from before and after the change, and change one condition at a time. That lets you explain what restored service while supporting both quick temporary recovery and root-cause analysis.
The outcome should not be ‘We suspect DNS.’ It should establish which query reached which point and what answer came back. Put the last working evidence beside the first failure, and you can narrow down both the responsible device and the change needed.
Sources for this section IETF RFC 1122 · IETF RFC 1812
Follow one browser request to see what each technology does↑
Begin with the complete request–response round trip in what happens when a browser opens a website. Then learn how addressing and DHCP prepare communication, how ARP and VLANs deliver data locally, and how routing and NAT reach other networks. Apply those principles to real network design, external connections, security, validation, and recovery. At the end, explain that same web connection again to bring the book together.
You do not need to memorize every protocol at the start. Ask the same questions in each article: What input does the device receive? What does it decide? What state does it keep? What does it send next?
In the next article, follow a request to www.imbizcorp.com and its response to see what DNS, ARP, routing, NAT, TCP, and TLS each do. The later articles explain individual steps in detail. When reading about ARP, focus on whose MAC address is needed. For NAT, focus on how addresses and ports change and how the reply returns.
Apply the same approach to command output. A route appearing in the routing table does not prove that packets are being forwarded along it. Check settings and tables, then compare them with actual packets or service responses. That habit helps you find the cause of failures.
It is fine if many terms are unfamiliar at first. Read the whole flow, then return to the parts you need; the earlier examples will make more sense in detail. The final article revisits the same web connection to show how addressing, forwarding, design, and recovery fit into one exchange.
Sources for this section IETF RFC 1122 · IETF RFC 1812 · IETF RFC 8200
What the diagram shows Follow the five segments from endpoint preparation through ARP, DNS, TCP/TLS, PAT, the ISP and IXP, the web server, and the return path. Distinguish the request and response packet arrows, then compare the 192.168.1.50:5001 ↔ 198.51.100.78:15001 translation and reply reverse mapping in the router box.
↔ Scroll horizontally to explore the diagram.
FAQ↑
Shouldn't I restart the router or switch first?
Which layer should I check first?
Glossary↑
These are the key terms used in this article, explained in the context of packet processing.
- Link
- A logical or physical connection over which two network interfaces exchange frames.
- Default Gateway
- An endpoint's first-hop address for sending a packet outside its local network. It identifies the first router used for that traffic.
- DNS Domain Name System
- A distributed system that resolves domain names to resource records such as IP addresses.
- Route
- Information that associates a destination prefix with a next forwarding target and an outgoing interface, among other details.
- 5-Tuple
- A set of values that identifies a flow: protocol, source IP address and port, and destination IP address and port.
- Asymmetric Routing
- Requests and responses pass through different devices or links in this form of routing.
- Packet capture
- A way to verify traffic flow on a specific interface by recording packets' headers and timestamps.
Sources and verification
- IETF RFC 1122 — Communication-layer requirements for internet hosts
- IETF RFC 1812 — IPv4 router forwarding and routing requirements
- IETF RFC 8200 — The IPv6 specification and packet processing model
This troubleshooting sequence is a model for narrowing down the evidence, not a standard set of commands. The commands and log locations depend on the operating system and device.