Networking Fundamentals

Every network conversation, from loading a webpage to sending an email, is really just packets of data hopping between devices. Two models describe this:

• OSI model (7 layers): the academic reference model — Physical, Data Link, Network, Transport, Session, Presentation, Application.
• TCP/IP model (4 layers): the practical model the real internet actually runs on — Link, Internet, Transport, Application.

You don't need to memorize every layer's trivia. What matters practically: problems tend to live at a specific layer, and knowing roughly which layer you're dealing with tells you which tool to reach for. A cable problem is Layer 1. A "wrong IP" problem is Layer 3. A "can't reach the website by name" problem is usually Application layer (DNS).

An IPv4 address is four numbers (0-255) separated by dots, like 192.168.1.42. Every address has two parts: the network portion and the host portion, split by the subnet mask.

• Private ranges (never routed on the public internet): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
• CIDR notation (e.g. /24) is shorthand for the subnet mask — /24 means 255.255.255.0, giving 256 addresses (254 usable).

The core skill: given an IP and a CIDR prefix, figure out the network address, broadcast address, and usable host range. This shows up constantly in real troubleshooting — and the Subnet Calculator in the Engineer Toolkit does this instantly once you understand what it's actually computing.

DNS is the internet's phone book — it turns human-readable names (raven-academy.com) into IP addresses computers actually route to. Without it, you'd need to memorize IP addresses for every site you visit.

Common record types:

• A — maps a name to an IPv4 address
• AAAA — maps a name to an IPv6 address
• CNAME — an alias pointing to another name
• MX — where mail for a domain should be delivered
• TXT — arbitrary text, often used for domain verification and email security (SPF/DKIM)

The classic diagnostic trick: if you can reach a service by its IP but not by its domain name, the problem is DNS specifically — not connectivity in general.

DHCP automatically assigns IP addresses so nobody has to configure them by hand. The process is called DORA:

1. Discover — the client broadcasts "I need an IP"
2. Offer — a DHCP server responds with an available address
3. Request — the client asks to actually use that address
4. Acknowledge — the server confirms the lease

If a device can't reach a DHCP server, Windows and most OSes fall back to a self-assigned address in the 169.254.0.0/16 range — called an APIPA address. Seeing one of these is a strong, specific signal: the DHCP handshake failed, and that's exactly where to focus troubleshooting.

Three devices do most of the physical work in a typical network:

• Switch: connects devices within the same local network, forwarding traffic based on MAC address (Layer 2).
• Router: connects different networks together — most commonly your local network to the wider internet — forwarding traffic based on IP address (Layer 3).
• Access point: extends the wired network wirelessly, letting Wi-Fi devices join the same local network a switch would otherwise serve.

In a small home setup, a single box usually plays all three roles at once. In a business network, they're typically separate, dedicated devices — which is exactly why "restart the router" isn't always the right first move in an office; you need to know which device is actually responsible for the symptom.

TCP and UDP are the two main transport protocols, and the difference matters:

• TCP is connection-oriented and reliable — it confirms delivery and retransmits lost data. Used for web traffic, email, file transfers — anywhere correctness matters more than raw speed.
• UDP is connectionless and fast, with no delivery guarantee. Used for DNS, video streaming, VoIP — where a little loss is acceptable but delay is not.

Ports identify which specific service on a device traffic is meant for. A handful come up constantly: 80/443 (HTTP/HTTPS), 53 (DNS), 22 (SSH), 3389 (RDP), 25 (SMTP). The full reference is in the Cheat Sheet Library and the Engineer Toolkit's port lookup.

A small set of commands covers the vast majority of network troubleshooting:

• ipconfig / ip addr — shows your own device's network configuration
• ping — tests basic reachability and latency to a target
• tracert / traceroute — shows the path traffic takes, hop by hop, useful for finding exactly where a connection breaks
• nslookup / dig — tests DNS resolution specifically

The order matters: check your own config first, then the nearest hop (the gateway), then further out. This is exactly the logic behind the "No Internet" Interactive Troubleshooter — try it after this lesson to see the full decision path in action.