Network Engineer

Built-in commands only. Nothing to install, no account, nothing to sign up for.

1. 1

   Watch a name turn into an address

   Every connection starts by looking up a name. Run this against a site you use daily, then against a site in another country. Notice you get different addresses — sometimes several.

   Windows

   nslookup bbc.co.uk

   macOS

   dig bbc.co.uk +short

   Linux

   dig bbc.co.uk +short

2. 2

   Trace the path out

   This lists every router your traffic passes through to reach that address. Read the hostnames down the left — you can usually see it leave your house, reach your provider, and cross into a backbone network.

   Windows

   tracert bbc.co.uk

   macOS

   traceroute bbc.co.uk

   Linux

   traceroute bbc.co.uk

3. 3

   Find where the time goes

   Look at the millisecond figures. Somewhere there is a jump — 8ms to 90ms between two hops. That jump is usually the moment your traffic goes long-distance. Now trace somewhere far away and compare where the jump happens.

4. 4

   Break it on purpose, then put it back

   Add a line to your hosts file pointing a site you use at 127.0.0.1, and try to load it. Watch how the failure looks from the browser — the error will not tell you what you just did. Then delete the line. This is the single most useful thing on this list: you have now seen a name-resolution fault from the user's side, which is what half of all "the internet is down" tickets actually are.

   Windows

   notepad C:\Windows\System32\drivers\etc\hosts   (run as Administrator)

   macOS

   sudo nano /etc/hosts

   Linux

   sudo nano /etc/hosts

5. 5

   Optional — watch the actual conversation

   If you want to go further, install Wireshark, capture for ten seconds while loading one page, and filter for "http" or "dns". You will see the individual messages between your machine and the server. This is the one step that needs an install, which is why it is last.

Paper and a pen. Deliberately no tools — the constraint is the point, because architecture is thinking, not diagramming software.

1. 1

   Draw what you actually have

   Your home network, on one sheet. Router, every device, how each connects. If you did the exposure trial you already have the inventory; if not, list them from memory and then check — the gap between what you remembered and what is really there is itself the first finding, and it is the same gap every organisation has.

2. 2

   Draw the lines nothing crosses

   Now mark what can reach what. On a normal home network the honest answer is everything reaches everything — your work laptop, your smart bulb, a guest's phone, the doorbell camera all sit in one flat space. Draw that reality, not the reality you would prefer.

3. 3

   Name the thing that actually matters

   Of everything on that page, what would genuinely hurt to lose or have taken? Usually one or two things: the machine with your work on it, the drive with the family photos. Circle them. Everything else on the diagram exists, in security terms, mainly as a route toward those.

4. 4

   Pick the worst device and follow it

   Choose the least trustworthy thing on the network — the cheapest smart device, the one that has not had a firmware update in three years. Trace, on the diagram, exactly what it can reach if someone takes it. That path is your blast radius, and drawing it is more persuasive than any risk score you could write down.

5. 5

   Redesign it, on a second sheet

   Draw the version where that cannot happen. A separate network for untrusted devices. The important machine somewhere the doorbell cannot reach. Guest access that is genuinely separate. You do not have to build it — you have to be able to justify it.

6. 6

   Now write down what your design costs

   This is the step that separates architecture from wishful thinking. What breaks? Casting to the TV probably stops working. Someone has to maintain two networks. A guest cannot print. Write the honest list, then decide which trade-offs you would actually accept and which you would not. If you cannot articulate the cost of your own design, you will lose every real architecture argument you ever have.

Built-in wireless tools plus your own feet. The optional hardware section needs a computer you own and are willing to open — no purchase required.

1. 1

   Measure what you have been assuming

   Find your current signal strength, right now, where you are sitting. Note the number and the units — dBm is a negative figure where closer to zero is better, and −50 is excellent while −80 is barely usable.

   Windows

   netsh wlan show interfaces

   macOS

   Hold Option, click the Wi-Fi menu — or open Wireless Diagnostics from Spotlight

   Linux

   iw dev wlan0 link    # or: nmcli -f IN-USE,SSID,SIGNAL,CHAN dev wifi

2. 2

   Walk the building and write numbers down

   Take a reading in every room, and at the far corner of each. Write them on a rough floor plan. You are producing a coverage survey — the same artefact, at smaller scale, that a wireless engineer produces before a hospital or a warehouse deployment.

3. 3

   Find the wall that eats your signal

   Look for the sharp drop, not the gradual fade. A gentle decline is distance; a cliff between two adjacent readings is something physical — a wall with foil-backed insulation, a mirror, a boiler, a fridge, a chimney. Go and identify the actual object. This is the moment radio stops being theoretical.

4. 4

   Discover you are not alone on the air

   List the networks around you and the channels they occupy. Count how many are on the same channel as yours. Wi-Fi is a shared medium in a public commons — your neighbour's router degrades yours, and no configuration on your side can fully fix it. That constraint is the defining fact of wireless work.

   Windows

   netsh wlan show networks mode=bssid

   Linux

   nmcli -f SSID,CHAN,SIGNAL dev wifi list

   macOS

   Wireless Diagnostics → Window → Scan

5. 5

   Trace one cable end to end

   Pick any cable in your home — the one from the wall to the router. Follow it physically to both ends. Where does it enter the building, and what is on the other side of that wall? Almost nobody knows. Documenting exactly this, across a building, is a real job that real people are paid to do because the records are always wrong.

6. 6

   Optional — open something and name every part

   Power off, unplug, ground yourself, then open a desktop or an old laptop you own. Identify: the processor and its cooler, the memory, the storage, the power supply, the fans. Trace where the air enters and leaves. Ask where the heat goes. Now imagine ten thousand of these in one room — that question of heat, power and airflow is most of what data centre design actually is.