Skip to main content

Documentation Index

Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Module 4: Network Layer

The Network Layer (Layer 3) is responsible for routing packets across different networks. The primary protocol is Internet Protocol (IP). If Layer 2 is the local mail carrier who delivers within your neighborhood, Layer 3 is the national postal service that routes mail between cities. Layer 2 uses MAC addresses (local significance only), while Layer 3 uses IP addresses (global significance). A packet might pass through dozens of Layer 2 hops to reach its destination, but the Layer 3 IP addresses remain the same from source to destination (except when NAT is involved — covered in Module 10).
IP Routing Fundamentals

​
4.1 IP Addressing (IPv4)

An IPv4 address is a 32-bit number, typically written in dotted-decimal notation (e.g., 192.168.1.1). Every device on a network needs a unique IP address within that network, just like every house needs a unique street address for mail delivery. Under the hood, 192.168.1.1 is actually the binary number 11000000.10101000.00000001.00000001. We write it in dotted decimal because humans are bad at reading 32-bit binary strings.

​
Classes (Legacy — mostly historical)

  • Class A: 0.0.0.0 - 127.255.255.255 (Large networks — up to 16 million hosts)
  • Class B: 128.0.0.0 - 191.255.255.255 (Medium networks — up to 65,534 hosts)
  • Class C: 192.0.0.0 - 223.255.255.255 (Small networks — up to 254 hosts)
Why “legacy”? Classful addressing wasted enormous numbers of IPs. A company needing 300 addresses would get a Class B (65,534 addresses) because Class C (254) was too small. CIDR (Classless Inter-Domain Routing) replaced this rigid system in the 1990s, allowing flexible subnetting like /23 (510 hosts) — covered in detail in Module 9.

​
Private IP Addresses (RFC 1918)

These ranges are reserved for internal use and are not routable on the public internet. Your home network, your office, and AWS VPCs all use these ranges internally.
  • 10.0.0.0/8 — 16.7 million addresses, used by large enterprises and cloud VPCs
  • 172.16.0.0/12 — ~1 million addresses, used by medium organizations
  • 192.168.0.0/16 — 65,536 addresses, the range your home router almost certainly uses
Millions of networks around the world use 192.168.1.0/24 simultaneously without conflict. NAT (Module 10) translates these private addresses to unique public IPs before packets reach the internet.

​
4.2 Subnetting

Subnetting divides a network into smaller, manageable sub-networks. It is the networking equivalent of dividing a large office floor into departments — each department (subnet) has its own space, and traffic between departments must go through a door (router).
  • Subnet Mask: Determines which part of the IP is the Network ID and which is the Host ID. It is a 32-bit number where all the 1s are on the left (network) and all the 0s are on the right (host).
  • Example: 255.255.255.0 (/24) means first 24 bits are Network ID, leaving 8 bits (256 - 2 = 254 usable host addresses).

​
Quick Example

Network:      192.168.1.0/24
Subnet Mask:  255.255.255.0

Network part: 192.168.1   (first 24 bits -- identifies the network)
Host part:    .0 to .255  (last 8 bits -- identifies devices)

Usable hosts: 192.168.1.1 through 192.168.1.254
Reserved:     192.168.1.0 (network address), 192.168.1.255 (broadcast)
Why subnet? Without subnetting, broadcast traffic from every device reaches every other device on the network. In a network with 10,000 hosts, that is a lot of noise. Subnetting creates smaller broadcast domains, improving both performance and security. It also lets you apply different security policies to different subnets (e.g., “database servers cannot be reached from the guest Wi-Fi subnet”).
For in-depth subnetting calculations and practice problems, see Module 9.

​
4.3 Routing

Routers operate at Layer 3. They connect different networks and decide the best path for packets. A switch says “I know which port this MAC address is on.” A router says “I know which network this IP address belongs to and which direction to forward the packet.” Every router maintains a routing table — a set of rules like “to reach network 10.0.0.0/8, forward to 192.168.1.254.” When a packet arrives, the router looks at the destination IP, consults its routing table, and forwards the packet toward the next hop. This process repeats at every router along the path until the packet reaches its destination.

​
How routing decisions work at the packet level

Packet arrives at Router with Destination IP: 10.1.2.50

Routing table lookup:
  10.0.0.0/8    via 192.168.1.254  (matches -- 8 bits)
  10.1.0.0/16   via 172.16.0.1     (matches -- 16 bits, more specific)
  10.1.2.0/24   via 172.16.0.5     (matches -- 24 bits, most specific!)

Winner: 10.1.2.0/24 → forward to 172.16.0.5
The longest prefix match rule always picks the most specific route. This is fundamental to how the internet works.

​
Routing Protocols

  • IGP (Interior Gateway Protocol): Used within an autonomous system — a single organization’s network (e.g., OSPF, EIGRP, RIP). Think of it as the internal navigation within a company campus.
  • EGP (Exterior Gateway Protocol): Used between autonomous systems (e.g., BGP). Think of it as the navigation between different companies’ networks — this is how ISPs, cloud providers, and large organizations exchange routes to form the global internet.
See Module 11 for a deep dive into OSPF, BGP, and how the internet’s routing actually works.

​
Next Module

Module 5: Transport Layer

TCP vs UDP and reliability.

​
Interview Deep-Dive

Strong Answer:
  • Longest prefix match is the algorithm routers use to select the best route when multiple routing table entries match a destination IP. The route with the most specific prefix (longest network mask) always wins. For example, if a router has routes for 10.0.0.0/8, 10.1.0.0/16, and 10.1.2.0/24, a packet destined for 10.1.2.50 matches all three, but the /24 route wins because it matches 24 bits — the most specific.
  • This is fundamental because it enables hierarchical aggregation of routes. The global internet routing table has over 900,000 entries. Without longest prefix match, you could not have summary routes alongside more specific ones. An ISP can advertise a /16 summary to the internet while internally maintaining /24 routes for individual subnets. Traffic arrives at the ISP via the /16 and is then routed internally via the more specific /24.
  • In practice, this means a misconfigured more-specific route can “steal” traffic from a broader route. This is exactly what happened in the 2008 Pakistan/YouTube incident: Pakistan Telecom advertised a more-specific /24 for YouTube’s IP range (to block it domestically), and that advertisement leaked to the global internet. Because /24 is more specific than YouTube’s /22, routers worldwide preferred the Pakistani route, effectively black-holing YouTube traffic globally.
  • In cloud environments like AWS VPC, the same principle applies. If your route table has 10.0.0.0/16 pointing to “local” and a more specific 10.0.2.0/24 pointing to a Transit Gateway, traffic to 10.0.2.x will go to the Transit Gateway while everything else in 10.0.x.x stays local.
Follow-up: What is the default route (0.0.0.0/0) and why is it always the last resort?The default route 0.0.0.0/0 has a prefix length of 0, meaning it matches zero bits — so it matches every possible destination. But because longest prefix match always prefers the most specific route, any other route in the table will beat it. The default route only wins when nothing more specific matches. This makes it the “route of last resort.” On your home computer, the default route points to your router (192.168.1.1). On an AWS private subnet, it points to a NAT Gateway. If you accidentally delete the default route, the device can still reach anything it has a specific route for (like the local subnet) but cannot reach the rest of the internet. This is a common troubleshooting scenario: “I can ping machines on my subnet but nothing else” almost always means the default route is missing or pointing to an unreachable gateway.
Strong Answer:
  • Public IP addresses are globally unique and routable on the internet. They are allocated by IANA to regional internet registries (ARIN, RIPE, APNIC, etc.) and then to ISPs, who assign them to customers. Because IPv4 only has 4.3 billion addresses and they are nearly exhausted, public IPs are a scarce and valuable resource.
  • Private IP addresses (RFC 1918) are reserved ranges — 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — that are not routable on the public internet. Any organization can use them internally without coordination. Millions of home routers use 192.168.1.0/24 simultaneously with zero conflict because these addresses never leave the local network.
  • You use public IPs for anything that must be directly reachable from the internet: web servers, API endpoints, DNS servers, load balancers. You use private IPs for internal resources: databases, application servers, internal microservices. The security benefit is significant — a database on a private IP behind a NAT Gateway is unreachable from the internet by design, regardless of firewall misconfigurations.
  • In cloud environments like AWS, best practice is to put everything in private subnets by default. Only load balancers and bastion hosts get public IPs. Application servers and databases use private IPs and access the internet (for updates) through a NAT Gateway. This is defense in depth — even if a security group is misconfigured, the lack of a public IP means the internet still cannot reach the resource directly.
Follow-up: With IPv6 providing enough addresses for every device, does the concept of private IPs and NAT go away?In theory, yes. IPv6 provides 2^128 addresses — enough for every grain of sand on Earth to have trillions of unique addresses. The original vision is that every device gets a globally unique address, restoring the end-to-end principle that NAT broke. In practice, the transition is incomplete. As of 2025, roughly 40-45% of internet traffic is IPv6. Many corporate networks and smaller ISPs remain IPv4-only. IPv6 does have Unique Local Addresses (fc00::/7) which are the equivalent of RFC 1918 private addresses, and some organizations use them. But the primary security model in IPv6 shifts from “hide behind NAT” to “use firewalls and host-based security to control access.” This is arguably cleaner architecturally — NAT was never intended as a security mechanism, it just happened to block unsolicited inbound connections as a side effect.
Strong Answer:
  • The most common cause is that the application is binding to 127.0.0.1 (localhost) instead of 0.0.0.0 (all interfaces). When bound to localhost, only processes on the same machine can connect. When deployed to a different subnet, external clients cannot reach it because the application is not listening on the network interface.
  • Second possibility: routing. If the application on Subnet A needs to reach a database on Subnet B, there must be a route between the two subnets. In cloud environments, this means the route tables for both subnets must include routes to each other’s CIDR ranges. A missing route means packets to the database IP are sent to the default gateway and potentially dropped.
  • Third: firewall or security group rules. The source subnet might not be permitted to reach the destination port. In AWS, the security group on the database must allow inbound traffic from the application’s subnet CIDR or security group. If the developer was testing with everything in one subnet, the “local” route handled it and security groups may have been more permissive.
  • Fourth: DNS resolution differences. If the application uses a hostname like “db-server” that resolved via /etc/hosts or a local DNS zone on the original machine, that resolution will fail on the new subnet unless the same DNS configuration exists there.
  • My debugging sequence would be: (1) check what IP and port the application is listening on with ss -tuln, (2) test connectivity from the client with nc -zv target-host port, (3) check route tables with ip route, (4) check firewall rules and security groups.
Follow-up: In AWS specifically, what is the difference between a security group and a NACL, and how do they interact when debugging this kind of issue?Security groups are stateful, instance-level firewalls that only support allow rules. If you allow inbound TCP on port 5432, the return traffic is automatically permitted. NACLs (Network Access Control Lists) are stateless, subnet-level firewalls that support both allow and deny rules, evaluated in order. Because NACLs are stateless, you must explicitly allow both inbound traffic on port 5432 and outbound traffic on ephemeral ports (1024-65535) for the return path. Traffic must pass both the NACL and the security group. In practice, most teams leave NACLs at their default (allow all) and rely on security groups for access control. The gotcha is when someone adds a NACL deny rule and forgets to allow ephemeral ports for return traffic — the connection appears to work in one direction but responses never come back. My troubleshooting order: check security groups first (they are the most commonly misconfigured), then NACLs, then route tables.