A network connection that is not working

Why this matters

"The internet is down" is the most common sentence in support, and it describes at least eight different faults. The value of this lesson is a sequence that tests one layer at a time, in an order where each step eliminates everything below it.

This is the applied lesson for the largest objective on the exam, and it is where domain 2's material becomes diagnostic. Addressing from lesson 12, name resolution from lesson 11, the open/closed/filtered distinction from lesson 8 — each of those was built so that it could be used here.

The exam asks these as scenarios with a partial result stated: a machine has an APIPA address, or pings an address but not a name, or reaches the gateway and nothing beyond. Each of those is a complete diagnosis if you know what the observation rules out.

The lesson

Working outward: interface, cable, address, gateway, name resolution, destination

The sequence, and what each step proves:

1. Is the interface up? Link light on the adapter and the switch, or associated wireless. No link means the cable, the port, or the adapter, and nothing above matters.
2. Does the host have a sensible address? Read the configuration. An APIPA address means DHCP failed, from lesson 13. No address at all means the interface is disabled or has no link. A static address means somebody set it by hand — check the mask and gateway.
3. Can it reach itself? Ping the loopback address. Failure here means the protocol stack is broken, which is rare and is a software problem.
4. Can it reach another host on the same subnet? Success proves the adapter, the cable, the switch and the local addressing all work.
5. Can it reach the default gateway? Success proves the router is reachable and the mask is not preventing local delivery.
6. Can it reach a known external address? Success proves routing and the internet path work. Failure here with a working gateway means a routing or provider problem.
7. Can it resolve a name? Failure here, with step 6 succeeding, is a DNS problem and nothing else. This is the cleanest split in the whole sequence.
8. Can it reach the specific service? A port test, from lesson 8.

Do them in order. Doing step 7 first and concluding "DNS is broken" when the machine has no address at all is the most common wasted hour in this work.

The complementary question, asked before any of the above: who else is affected? One machine, one room, one floor, everyone. That scopes the fault in seconds and decides whether you are looking at a workstation or at infrastructure.

Reading link lights, and what a link with no traffic tells you

Link lights are free evidence and are routinely ignored.

• No light at all. No physical connection. Cable, port, adapter, or the device at the far end is off. Try the other end of the cable, a different port, and a known-good cable — lesson 17's substitution again.
• Solid light, no activity flicker. Physical link established and nothing is being sent. The layer 1 connection is good, so look higher: address configuration, a disabled protocol, or a port the switch has shut down.
• Activity flickering steadily with no traffic expected. Normal background chatter, or something unexpected.
• Link light at the wrong speed. Many adapters and switches indicate speed by colour. A gigabit-capable machine linking at 100 Mbps points at the cable or the termination — lesson 17's "exactly a tenth of the expected speed" signature, which is a broken pair.

The equivalent on wireless is association: the client shows connected or not. Connected with no traffic is the same state as solid-link-no-activity, and it points at addressing rather than at radio.

The commands that answer one question each, and which question each one answers

• ipconfig / ifconfig / ip addr — what address, mask, gateway and DNS servers does this host have? This is step 2 and it is where most diagnoses actually begin.
• ipconfig /release and /renew — ask DHCP again. The standard response to an APIPA address once the cable is confirmed.
• ping — can I reach this host, and how long does it take? Note that a failure does not prove unreachability, because many hosts and firewalls discard the request deliberately.
• tracert / traceroute — where does the path stop? The last hop that answers is where to look. Intermediate hops that do not respond are normal and are not a fault.
• nslookup / dig — what does DNS return for this name, and from which server? Querying a specific server is how you tell a bad record from a bad resolver.
• ipconfig /flushdns — discard cached answers, including a cached negative answer that is why a fixed name still fails.
• netstat — what is this machine connected to, and what is it listening on?
• arp -a — which hardware addresses has this host learned locally? Useful when two devices claim the same address.
• Test-NetConnection or a telnet client to a port — is that specific service reachable? Lesson 8's open, closed, filtered distinction.

Each answers exactly one question. Running them in sequence without knowing which question each answers produces output rather than diagnosis.

No address, wrong address, and the APIPA address that names its own cause

The address is the single most informative thing on the machine.

• 169.254.x.x — DHCP failed. Lesson 13. Check the cable and link first, then release and renew, then look at the DHCP server or the scope. Note that two machines in this state can reach each other, which occasionally produces a confusing report.
• No address at all — the interface is disabled, has no link, or the stack is broken.
• An address from the wrong subnet — a static address left over from another site, or a rogue DHCP server, or the machine is plugged into the wrong network.
• A correct address with the wrong mask — the delivery-decision fault from lesson 12. Local resources fine and the internet broken, or the reverse, depending on which way the mask is wrong.
• A correct address with no gateway — local network perfect, nothing remote. The user says the internet is down while the printer works.
• A correct address with no DNS servers — addresses work, names do not.
• A duplicate address — intermittent connectivity for both machines, and an operating system warning if you look for it. This is what happens when a static address was placed inside the DHCP pool, from lesson 14.

Reading these is faster than any test, which is why step 2 sits where it does.

Slow rather than broken: duplex, saturation, and where to measure

A connection that works badly is a different investigation from one that does not work.

The causes, roughly in order of frequency:

• Wireless conditions. Signal, interference, congestion. Lesson 41 covers this properly; the first test is to try the same task on a cable.
• Link saturation. Something is using the capacity — a backup, a large upload, an update rolling out across the site. Measured rather than guessed: check whether the slowness correlates with a time of day.
• Duplex mismatch. One end set to full duplex and the other to half. Produces a link that works and performs terribly, with collision and error counters rising on the switch. The fix is to set both ends to automatic, which is nearly always correct on modern equipment.
• Speed negotiation to a lower rate, from a cable fault, as above.
• The far end being slow, which is not a local problem at all. Testing a second destination separates them.
• A failing cable producing errors and retransmissions, where throughput is poor and packet loss is visible in a sustained ping.

Where to measure: a sustained ping to the gateway shows loss and jitter on the local segment; a sustained ping to an external address adds the provider's path; a speed test measures the internet link; and copying a large file to a local server measures the internal network with no internet involved. Using the right one of those four is what separates "the internet is slow" from "the switch port is at 100 Mbps".

And the professional habit from lesson 17: record the numbers. "42 Mbps to the local server, 6 per cent loss to the gateway" is a finding; "it felt slow" is not.