How Your Computer Finds Your Router When You Type 192.168.1.1

You have done this a hundred times. You open a browser, type 192.168.1.1, and the router's admin panel appears. Maybe you want to change the Wi-Fi password, maybe you want to check which devices are connected, maybe you want to forward a port. The page loads in under a second, and you never think about what happened between pressing Enter and seeing the login screen.

But something did happen. Quite a lot, actually. Your browser created a socket, the kernel consulted a routing table, your NIC broadcast an ARP request, a switch forwarded an Ethernet frame, and the router's embedded HTTP server sent back a response. No DNS was involved. No packets left your local network. Every step of this process is confined to a single Ethernet broadcast domain, and yet every step is interesting.

This post traces the full path, from the moment you type an IP address to the moment the router replies, covering every layer of the stack along the way.

1. The Question Nobody Asks

Every developer has read some version of "what happens when you type google.com in your browser." Those articles focus heavily on DNS resolution, TLS handshakes, CDN edge servers, and HTTP/2 multiplexing. They are interesting, but they skip the lower layers because the interesting networking happens across the public internet.

When you type 192.168.1.1, the story is completely different. There is no DNS lookup because you typed a raw IP address, not a hostname. There is no TLS (most router admin panels serve plain HTTP on port 80, though some newer models use self-signed certificates on 443). There is no CDN. The packet never crosses a router in the forwarding sense; it is delivered locally.

What remains is the raw machinery of local networking: socket creation, routing table lookup, subnet mask arithmetic, ARP resolution, Ethernet framing, switch forwarding, and local delivery. These are the building blocks that everything else in networking rests on. Understanding them here, where the path is short and observable, makes the more complex multi-hop scenarios much clearer.

Let us start at the top of the stack.

2. Browser to Operating System: Socket Creation and connect()

When you press Enter after typing http://192.168.1.1 in your browser's address bar, the browser parses the URL. It extracts the scheme (http), the host (192.168.1.1), and the port (implied 80). There is no hostname to resolve, so the resolver is never invoked.

The browser (or, more precisely, its networking library) creates a TCP socket and calls connect(). On Linux, this translates roughly to the following sequence of system calls:

int fd = socket(AF_INET, SOCK_STREAM, 0);
 
struct sockaddr_in addr;
addr.sin_family = AF_INET;
addr.sin_port = htons(80);
inet_pton(AF_INET, "192.168.1.1", &addr.sin_addr);
 
connect(fd, (struct sockaddr *)&addr, sizeof(addr));

The socket() call creates a file descriptor backed by a TCP socket in the kernel. At this point, no network traffic has been generated. The socket exists only as a kernel data structure.

The connect() call is where things get interesting. The kernel must now figure out how to send a TCP SYN packet to 192.168.1.1. To do that, it needs two things:

1. Which network interface to use. Your machine might have eth0, wlan0, a loopback lo, a VPN tunnel tun0, and a Docker bridge docker0. The kernel must pick one.
2. What destination MAC address to put on the Ethernet frame. IP addresses are layer-3 constructs. Ethernet frames, which carry IP packets on a wired LAN, need layer-2 MAC addresses.

The first question is answered by the routing table. The second is answered by ARP. Both happen before a single bit of application data crosses the wire.

3. Routing Table Lookup: How the Kernel Picks the Right Interface

The Linux kernel maintains a routing table, which is a list of rules that map destination IP prefixes to outgoing interfaces and next-hop gateways. You can view it with:

$ ip route show
default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.42 metric 100
169.254.0.0/16 dev eth0 scope link metric 1000

This is a typical routing table for a home Linux machine connected to a single network. Let us break down what each line means.

Line 1: default via 192.168.1.1 dev eth0 This is the default route. Any destination that does not match a more specific entry gets sent to 192.168.1.1 (the router) via the eth0 interface. The proto dhcp means this route was installed by the DHCP client. The metric 100 is the cost; lower is preferred when multiple defaults exist.

Line 2: 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.42 This is the connected route for the local subnet. It says: "for any destination in the range 192.168.1.0 to 192.168.1.255, send directly out eth0 without going through a gateway." The scope link confirms this is a directly-connected network. The src 192.168.1.42 specifies which source IP to use.

Line 3: 169.254.0.0/16 dev eth0 This is the link-local range, used for automatic IP assignment when DHCP fails (APIPA). It is rarely relevant in practice, but the kernel keeps it around.

Longest Prefix Match

When the kernel needs to route a packet to 192.168.1.1, it evaluates every entry in the routing table and picks the most specific match. "Most specific" means the longest prefix length.

The destination 192.168.1.1 matches two entries:

• default (which is shorthand for 0.0.0.0/0, a zero-length prefix)
• 192.168.1.0/24 (a 24-bit prefix)

The /24 prefix is more specific than /0, so the kernel picks line 2. The packet will be sent directly out eth0 with no gateway involved.

This is a critical distinction. If you were trying to reach 8.8.8.8, the only match would be the default route, so the kernel would send the packet to 192.168.1.1 as a gateway. But when the destination IS 192.168.1.1 and it falls within the connected subnet, the kernel sends directly.

You can ask the kernel to show you exactly which route it would pick for a given destination:

$ ip route get 192.168.1.1
192.168.1.1 dev eth0 src 192.168.1.42 uid 1000
    cache

This confirms: the packet goes out eth0, sourced from 192.168.1.42, with no gateway.

Compare this to a public IP:

$ ip route get 8.8.8.8
8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.42 uid 1000
    cache

Notice the via 192.168.1.1. For off-subnet destinations, the kernel routes through the gateway. For on-subnet destinations, there is no via.

Multiple Interfaces

On a machine with both wired and wireless connections, the routing table might look like this:

$ ip route show
default via 192.168.1.1 dev eth0 proto dhcp metric 100
default via 192.168.1.1 dev wlan0 proto dhcp metric 600
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.42 metric 100
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.105 metric 600

Both interfaces are on the same subnet. The kernel picks the route with the lower metric (100 for eth0 vs 600 for wlan0), so the wired connection wins. NetworkManager on most Linux distributions assigns a higher metric to Wi-Fi by default, which is the correct behaviour: wired connections are faster and more reliable.

4. Subnet Mask Arithmetic: How the Kernel Decides On-Link vs Off-Link

The routing table already gives us the answer, but it is worth understanding how the kernel populated that table in the first place. When your machine acquired the IP address 192.168.1.42 with subnet mask 255.255.255.0 (via DHCP or static configuration), the kernel automatically created the connected route for 192.168.1.0/24.

The subnet mask defines which portion of the IP address identifies the network and which portion identifies the host. In binary:

IP address:    192.168.1.42   = 11000000.10101000.00000001.00101010
Subnet mask:   255.255.255.0  = 11111111.11111111.11111111.00000000
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^
                                 network portion (24 bits)  host (8)

To determine the network address, the kernel performs a bitwise AND between the IP and the mask:

IP:     11000000.10101000.00000001.00101010
Mask:   11111111.11111111.11111111.00000000
AND:    11000000.10101000.00000001.00000000  = 192.168.1.0

The result, 192.168.1.0, is the network address. Any destination whose network address (computed the same way) matches 192.168.1.0 is considered on-link, meaning the kernel can send to it directly without a gateway.

Let us verify this for 192.168.1.1:

Dest:   11000000.10101000.00000001.00000001
Mask:   11111111.11111111.11111111.00000000
AND:    11000000.10101000.00000001.00000000  = 192.168.1.0

Same network address. Therefore 192.168.1.1 is on the same subnet as 192.168.1.42, and the kernel can deliver the packet directly.

/24 vs /16 vs /8

The CIDR notation /24 means the first 24 bits are the network portion. Other common masks:

Most home networks use /24, giving 254 usable host addresses (.1 through .254; .0 is the network address and .255 is the broadcast address). Some enterprise networks use /16 or even /8 for the 10.0.0.0 range.

The subnet mask has a direct impact on what the kernel considers "local." On a /16 network, your machine would consider 192.168.0.1 and 192.168.255.254 both on-link. On a /24, anything outside 192.168.1.0 to 192.168.1.255 requires routing through the gateway.

This is important when troubleshooting. If someone accidentally configures their machine with a /16 mask on a network that is actually /24, the machine will try to ARP for hosts on other subnets and never find them, because those ARP broadcasts do not cross routers.

5. ARP Resolution: Finding the Router's MAC Address

At this point, the kernel knows it needs to send a packet to 192.168.1.1 via eth0, and it knows this is a direct delivery (no gateway). But Ethernet frames require MAC addresses, not IP addresses. The kernel needs to discover the MAC address of 192.168.1.1.

This is the job of the Address Resolution Protocol (ARP), defined in RFC 826. ARP is remarkably simple: it broadcasts "who has this IP?" and waits for a unicast reply.

The ARP Request

The kernel first checks its ARP cache (also called the neighbour table on Linux). If it already has an entry for 192.168.1.1, it uses the cached MAC. If not, it constructs an ARP request.

The ARP request is an Ethernet frame with the following structure:

Ethernet Header:
  Destination MAC: ff:ff:ff:ff:ff:ff  (broadcast)
  Source MAC:      aa:bb:cc:dd:ee:01  (our NIC's MAC)
  EtherType:       0x0806            (ARP)
 
ARP Payload:
  Hardware type:   1 (Ethernet)
  Protocol type:   0x0800 (IPv4)
  Hardware size:   6 (MAC = 6 bytes)
  Protocol size:   4 (IPv4 = 4 bytes)
  Opcode:          1 (Request)
  Sender MAC:      aa:bb:cc:dd:ee:01
  Sender IP:       192.168.1.42
  Target MAC:      00:00:00:00:00:00  (unknown, that is what we are asking)
  Target IP:       192.168.1.1

This frame is sent to the broadcast address ff:ff:ff:ff:ff:ff, which means every device on the local Ethernet segment receives it. The switch will flood this frame out of every port (except the one it arrived on), because the destination MAC is the broadcast address.

The ARP Reply

Every device on the network receives this broadcast frame, but only the device with IP 192.168.1.1 responds. The router examines the ARP request, sees that the target IP matches its own, and sends back a unicast ARP reply:

Ethernet Header:
  Destination MAC: aa:bb:cc:dd:ee:01  (our MAC, unicast)
  Source MAC:      00:11:22:33:44:55  (router's MAC)
  EtherType:       0x0806            (ARP)
 
ARP Payload:
  Hardware type:   1
  Protocol type:   0x0800
  Hardware size:   6
  Protocol size:   4
  Opcode:          2 (Reply)
  Sender MAC:      00:11:22:33:44:55  (router's MAC)
  Sender IP:       192.168.1.1
  Target MAC:      aa:bb:cc:dd:ee:01
  Target IP:       192.168.1.42

Our kernel receives this reply, records the mapping 192.168.1.1 -> 00:11:22:33:44:55 in its ARP cache (neighbour table), and can now construct the Ethernet frame for the original IP packet.

Viewing the ARP Cache

On Linux, you can inspect the neighbour table with:

$ ip neigh show
192.168.1.1 dev eth0 lladdr 00:11:22:33:44:55 REACHABLE
192.168.1.105 dev eth0 lladdr aa:bb:cc:11:22:33 STALE
192.168.1.200 dev eth0 lladdr de:ad:be:ef:ca:fe DELAY

The states matter:

• REACHABLE: We have confirmed this mapping recently (either through an ARP reply or through upper-layer confirmation, such as receiving TCP data from this host).
• STALE: The entry is still cached but has not been confirmed recently. The kernel will use it but may re-verify if traffic continues.
• DELAY: The kernel is waiting briefly before re-probing, giving the upper layer a chance to confirm reachability.
• INCOMPLETE: An ARP request has been sent but no reply received yet. If this persists, the destination is unreachable at layer 2.
• FAILED: ARP resolution failed after multiple attempts. The kernel will return "no route to host" or "host unreachable" to the application.

The Linux kernel's neighbour table (managed by the ndisc subsystem for IPv6 and arp for IPv4) is more sophisticated than the simple ARP cache found in older operating systems. It implements a state machine with timers, probes, and garbage collection. Entries age out after a configurable period (typically 30 to 60 seconds for the reachable state), and the kernel probes again if traffic continues.

ARP Cache Poisoning (briefly)

ARP has no authentication. Any device on the network can send an unsolicited ARP reply claiming to be 192.168.1.1 with its own MAC address. Other machines will update their caches and start sending traffic to the wrong host. This is ARP cache poisoning (or ARP spoofing), and it is the basis of many local network attacks, including man-in-the-middle interception. Tools like arpwatch or Dynamic ARP Inspection (DAI) on managed switches can mitigate this, but most home networks have no protection against it.

6. Ethernet Frame Construction: Putting the Packet on the Wire

With the destination MAC address resolved, the kernel can now construct the full Ethernet frame that will carry the TCP SYN packet to the router. Let us trace the entire frame from the outside in.

The Ethernet Frame

+-------------------+-------------------+-----------+--------+-----+
| Dst MAC (6 bytes) | Src MAC (6 bytes) | EtherType | Payload| FCS |
|                   |                   | (2 bytes) |        | (4) |
+-------------------+-------------------+-----------+--------+-----+
| 00:11:22:33:44:55 | aa:bb:cc:dd:ee:01 |  0x0800   |  ...   | ... |
+-------------------+-------------------+-----------+--------+-----+

• Destination MAC (00:11:22:33:44:55): The router's MAC address, obtained via ARP.
• Source MAC (aa:bb:cc:dd:ee:01): Our NIC's MAC address.
• EtherType (0x0800): Indicates the payload is an IPv4 packet. Other common values: 0x0806 (ARP), 0x86DD (IPv6), 0x8100 (802.1Q VLAN tag).
• Payload: The IP packet (header + TCP segment).
• FCS (Frame Check Sequence): A 4-byte CRC32 computed over the entire frame. The receiving NIC verifies this to detect corruption. Frames with bad FCS are silently dropped.

The IP Header

Inside the Ethernet payload sits the IPv4 header:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |    DSCP   |ECN|         Total Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|    Fragment Offset        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  TTL  |  Protocol (6=TCP) |        Header Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Source IP: 192.168.1.42                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Destination IP: 192.168.1.1                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Key fields for our scenario:

• Version: 4 (IPv4).
• IHL: 5 (no options, so the header is 20 bytes).
• Total Length: 40 bytes for a bare TCP SYN (20 bytes IP header + 20 bytes TCP header with no options) or 60 bytes if TCP options are present (MSS, window scale, SACK permitted, timestamps).
• TTL: 64 (the Linux default). This is decremented at each router hop. Since our packet never crosses a router, it arrives with TTL 64.
• Protocol: 6 (TCP).
• Source IP: 192.168.1.42 (our machine).
• Destination IP: 192.168.1.1 (the router).

The TCP SYN

Inside the IP payload sits the TCP header. This is the first packet of the three-way handshake:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port (80)   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset|  Res  |C|E|U|A|P|R|S|F|           Window              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options (MSS, WScale, ...)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The SYN flag (S) is set. The sequence number is a random 32-bit value chosen by the kernel (ISN, initial sequence number). The acknowledgment number is zero since we have not received anything yet. The source port is an ephemeral port chosen by the kernel, typically in the range 32768 to 60999 on Linux (configurable via /proc/sys/net/ipv4/ip_local_port_range).

Modern Linux kernels include TCP options in the SYN: MSS (Maximum Segment Size, usually 1460 for Ethernet), Window Scale (typically 7, allowing a receive window up to 1 MB), SACK Permitted, and Timestamps. These options push the TCP header beyond 20 bytes, typically to 40 bytes.

The Full Stack

So the complete frame, from outermost to innermost, looks like this:

[ Ethernet Header (14 bytes) ]
  [ IPv4 Header (20 bytes) ]
    [ TCP Header (20-40 bytes) ]
      [ (no payload in a SYN) ]
[ FCS (4 bytes) ]

The NIC computes the FCS, prepends a preamble and start-of-frame delimiter (not visible to software), and transmits the frame as a series of electrical signals on the wire (or radio signals if Wi-Fi, which adds its own 802.11 MAC header, but let us stay with Ethernet for simplicity).

7. Switch MAC Table Forwarding: From Port to Port

Between your machine and the router sits a switch. In most home networks, this is built into the router itself (the four LAN ports on the back of a consumer router are an integrated Ethernet switch), but the behaviour is the same as a standalone switch.

The CAM Table

A switch operates at layer 2. It does not examine IP addresses. It looks at the destination MAC address of each frame and forwards the frame to the correct port using its CAM table (Content Addressable Memory table, also called the MAC address table or forwarding table).

The CAM table is a mapping from MAC addresses to switch ports:

MAC Address         Port    Age (seconds)
00:11:22:33:44:55   1       5
aa:bb:cc:dd:ee:01   3       12
aa:bb:cc:11:22:33   4       45
de:ad:be:ef:ca:fe   2       3

When a frame arrives on port 3 with destination MAC 00:11:22:33:44:55, the switch looks up this MAC in its CAM table, finds it on port 1, and forwards the frame exclusively to port 1. No other port sees the frame (unlike a hub, which would repeat the signal on every port).

Learning

The switch populates its CAM table through a process called source MAC learning. When a frame arrives on port 3 with source MAC aa:bb:cc:dd:ee:01, the switch records: "MAC aa:bb:cc:dd:ee:01 is reachable via port 3." This happens for every frame, on every port. The table builds itself automatically.

Unknown Unicast Flooding

What happens if the switch receives a frame with a destination MAC that is not in the CAM table? This is called an unknown unicast. The switch cannot determine which port to use, so it falls back to flooding: it sends the frame out of every port except the one it arrived on. This is the same behaviour as a broadcast frame, but it is a one-time cost. Once the destination replies (and the switch learns its MAC on the return frame), subsequent frames will be forwarded precisely.

Aging

CAM table entries are not permanent. Each entry has an aging timer, typically 300 seconds (5 minutes) on most managed switches. If the switch does not see any frames from a given MAC address within this period, the entry is removed. This prevents the table from filling with stale entries for devices that have been disconnected.

On a managed switch, you can inspect the CAM table with vendor-specific commands. On a Linux bridge (which uses the same logic), you can use:

$ bridge fdb show
aa:bb:cc:dd:ee:01 dev eth0 master br0
00:11:22:33:44:55 dev eth1 master br0

For Our Scenario

Our frame arrives at the switch on whatever port our machine is connected to. The switch looks up 00:11:22:33:44:55 (the router's MAC) in its CAM table, finds the correct port, and forwards the frame there. The router's NIC receives the frame, verifies the FCS, strips the Ethernet header, and passes the IP packet up the stack.

8. Router Receives the Packet: Local Delivery vs Forwarding

Here is a subtlety that is easy to miss. A router is a device that forwards packets between networks. But when you send a packet to 192.168.1.1 and the router's own IP address is 192.168.1.1, the router does not forward the packet. It delivers it locally.

The Two Paths

When the router's IP stack receives an IP packet, it checks the destination IP against its own addresses. Two outcomes are possible:

1. The destination IP matches one of the router's own addresses. The packet is destined for the router itself. It is passed up the stack to the transport layer (TCP, UDP, etc.) and then to whatever application is listening. This is local delivery.

2. The destination IP does not match any of the router's addresses. The packet is destined for somewhere else. The router consults its own routing table, decrements the TTL, recalculates the IP header checksum, and forwards the packet out the appropriate interface. This is forwarding.

When you access 192.168.1.1, you hit case 1. The router treats the packet exactly as your own machine would treat a packet sent to itself: it is delivered to the TCP stack, which processes the SYN, completes the three-way handshake, and passes the connection to the HTTP server.

The Router's HTTP Server

Most consumer routers run a minimal HTTP server (often based on lighttpd, uhttpd on OpenWrt, or a proprietary embedded web server). This server listens on port 80 (and sometimes 443) on the LAN interface. It serves the admin panel as a web application, typically with HTML, CSS, and JavaScript, often backed by CGI scripts or Lua handlers that interact with the router's configuration subsystem (UCI on OpenWrt, NVRAM on many consumer devices).

The HTTP response travels back through the same path in reverse. The router constructs an IP packet with source 192.168.1.1 and destination 192.168.1.42, the router's switch fabric delivers the Ethernet frame to the correct port, and your machine's NIC receives it. The kernel passes the TCP segment up to the browser, which renders the admin page.

Why the TTL Does Not Matter Here

For locally-delivered packets, the TTL is not decremented. The router only decrements TTL when forwarding. Since our packet is destined for the router itself, the TTL arrives at 64 and is consumed at 64. This is also why you cannot use traceroute to see hops on a single-segment LAN. There is only one hop: the direct link to the destination.

9. What Happens When the Destination Is NOT on Your Subnet

To appreciate what happened above, it helps to contrast it with the off-subnet case. Suppose instead of 192.168.1.1, you type 93.184.216.34 (a public IP belonging to a server in Berlin, for the sake of argument).

Routing Table Lookup (Again)

The kernel checks its routing table. 93.184.216.34 does not match 192.168.1.0/24. The only matching entry is default via 192.168.1.1 dev eth0. The kernel now knows: send the packet to the gateway 192.168.1.1, and the gateway will handle forwarding.

ARP for the Gateway, Not the Destination

This is the critical difference. The kernel does NOT ARP for 93.184.216.34. That IP is not on the local network. No device on your Ethernet segment has that address, so an ARP request for it would go unanswered.

Instead, the kernel ARPs for 192.168.1.1, the gateway. The destination MAC on the Ethernet frame is the router's MAC address. The destination IP in the IP header is still 93.184.216.34.

Ethernet Header:
  Dst MAC: 00:11:22:33:44:55  (router's MAC, NOT the remote server's MAC)
  Src MAC: aa:bb:cc:dd:ee:01  (our MAC)
  EtherType: 0x0800
 
IP Header:
  Src IP:  192.168.1.42       (our IP)
  Dst IP:  93.184.216.34      (the remote server, NOT the router)

Notice the asymmetry: the layer-2 destination (MAC) is the router, but the layer-3 destination (IP) is the remote server. This is the heart of IP routing. Each hop changes the Ethernet header (new source and destination MACs) but preserves the IP header (same source and destination IPs, with TTL decremented).

The Router Forwards

The router receives the frame, sees that the destination IP 93.184.216.34 does not match any of its own addresses, and enters forwarding mode. It consults its own routing table, which points to its WAN interface and the ISP's next-hop router. It decrements the TTL from 64 to 63, recalculates the IP checksum, performs NAT (replacing the source IP 192.168.1.42 with the router's public IP), constructs a new Ethernet frame with the ISP router's MAC as the destination, and sends it out the WAN port.

This process repeats at each router along the path, with the Ethernet header being rewritten at every hop but the IP addresses (post-NAT) remaining constant until the packet reaches the destination.

The Contrast

In our original scenario (accessing 192.168.1.1), the ARP target and the Ethernet destination MAC happen to match the final destination. This is a special case, not the norm. For off-subnet traffic, the Ethernet destination is always the gateway, regardless of the final IP destination.

10. Why 192.168.x.x Exists: RFC 1918 and the Private Address Space

You have been typing 192.168.1.1 your entire life without questioning why that particular address. Why not 74.125.24.1? Why not 1.2.3.4?

The answer is RFC 1918, published in February 1996 by Yakov Rekhter, Bob Moskowitz, Daniel Karrenberg, Geert Jan de Groot, and Eliot Lear. This RFC reserved three blocks of IPv4 address space for private use:

10.0.0.0/8       (10.0.0.0    to 10.255.255.255)    16,777,216 addresses
172.16.0.0/12    (172.16.0.0  to 172.31.255.255)     1,048,576 addresses
192.168.0.0/16   (192.168.0.0 to 192.168.255.255)       65,536 addresses

These addresses are guaranteed never to appear in global routing tables. No ISP will route traffic to 192.168.1.1 across the internet. They are "private" in the sense that they are only meaningful within a local network. Multiple networks worldwide can (and do) use the same private addresses simultaneously without conflict, because those addresses never leave the local network.

Why Three Ranges?

The three ranges serve different scales:

• 10.0.0.0/8 is used by large organisations. A single /8 gives you over 16 million addresses, enough for a sprawling corporate network. Amazon Web Services uses 10.0.0.0/8 internally. Many universities use it.
• 172.16.0.0/12 is a middle ground with about a million addresses. Docker uses 172.17.0.0/16 by default for container networking.
• 192.168.0.0/16 is the home network range. Most consumer routers default to either 192.168.0.0/24 or 192.168.1.0/24. A /16 gives 65,536 addresses, far more than any home needs, but the typical /24 subnet yields 254 usable hosts, which is perfectly adequate.

European Router Defaults

Different router manufacturers choose different default subnets within the 192.168.x.x range, and the choice often correlates with ISP and regional practices:

• Fritz!Box (AVM, the dominant home router brand in Germany, Austria, and Switzerland): defaults to 192.168.178.1. AVM chose this unusual subnet to avoid conflicts with other equipment that might use .0.1 or .1.1. If you have ever configured a Fritz!Box in a flat in Berlin or Vienna, you have typed 192.168.178.1.

• Vodafone Station (common in Germany, Italy, Greece, Portugal, and other European markets): typically defaults to 192.168.0.1.

• BT Home Hub / BT Smart Hub (United Kingdom): defaults to 192.168.1.254. Note the .254 instead of .1 for the gateway, an unusual choice.

• Livebox (Orange, France): defaults to 192.168.1.1.

• Cosmote Router (Greece): typically 192.168.1.1.

• KPN Experia Box (Netherlands): defaults to 192.168.2.254.

The variety shows that there is no technical reason the router must be at .1. It can be any address in the subnet. The convention of using .1 as the gateway is just that: a convention.

NAT: The Bridge Between Private and Public

Private addresses created a problem: hosts with private IPs cannot communicate with the public internet, because no router on the internet knows how to route back to 192.168.1.42. The solution is Network Address Translation (NAT), defined in RFC 3022.

When your machine sends a packet to a public IP, the router replaces the private source address with its own public address (assigned by the ISP) and records the mapping in a NAT table:

NAT Table:
  Internal             External              Destination
  192.168.1.42:54321   82.130.45.67:54321    93.184.216.34:80
  192.168.1.105:48812  82.130.45.67:48812    93.184.216.34:443

When the response comes back from 93.184.216.34 to 82.130.45.67:54321, the router looks up the NAT table, finds the corresponding internal mapping, rewrites the destination to 192.168.1.42:54321, and forwards the packet onto the LAN.

NAT is the reason billions of devices can share the limited IPv4 address space. It is also the reason you need port forwarding to host a game server, and why peer-to-peer applications like video calls use STUN/TURN servers to establish connections through NAT.

CGNAT: NAT Upon NAT

In many European markets, IPv4 address exhaustion has pushed ISPs to deploy Carrier-Grade NAT (CGNAT, RFC 6598). Under CGNAT, your router's "public" IP is itself a private address in the 100.64.0.0/10 range, and the ISP performs a second level of NAT at their infrastructure. This means there are two NAT translations between your machine and the internet. If you have ever wondered why your Fritz!Box shows a WAN IP of 100.64.x.x instead of a truly public address, CGNAT is the reason. Deutsche Telekom, Vodafone Germany, Cosmote in Greece, and many other European ISPs use CGNAT for at least some of their subscriber base.

11. Debugging the Path: Tools for Tracing Every Step

When things work, this entire process is invisible. When things break, you need tools that let you inspect each layer independently. Here is a toolkit for debugging the path from your machine to the router.

ip route get: Ask the Kernel Directly

The most underused networking command on Linux. Instead of staring at the routing table and doing mental longest-prefix matching, ask the kernel what it would do:

$ ip route get 192.168.1.1
192.168.1.1 dev eth0 src 192.168.1.42 uid 1000
    cache
 
$ ip route get 10.0.0.1
RTNETLINK answers: Network is unreachable

The second example immediately tells you there is no route to 10.0.0.1. No guesswork needed.

You can also check which source IP the kernel would use, which matters on multi-homed machines:

$ ip route get 192.168.1.1 from 192.168.1.42
192.168.1.1 from 192.168.1.42 dev eth0 uid 1000
    cache

ip neigh: Inspect the ARP Cache

$ ip neigh show dev eth0
192.168.1.1 lladdr 00:11:22:33:44:55 REACHABLE
192.168.1.105 lladdr aa:bb:cc:11:22:33 STALE

If the entry for 192.168.1.1 shows INCOMPLETE or FAILED, ARP resolution is broken. Common causes:

• The router is not connected or powered off.
• You are on the wrong VLAN.
• The cable is unplugged or the Wi-Fi association has dropped.
• A firewall on the router is dropping ARP (unusual but possible with overly aggressive iptables rules).

You can manually trigger ARP resolution:

$ arping -I eth0 192.168.1.1
ARPING 192.168.1.1 from 192.168.1.42 eth0
Unicast reply from 192.168.1.1 [00:11:22:33:44:55]  0.734ms

Or flush a stale entry and force re-resolution:

$ sudo ip neigh del 192.168.1.1 dev eth0
$ ping -c 1 192.168.1.1   # triggers ARP

tcpdump: Watch Packets in Real Time

tcpdump is the single most useful network debugging tool. It captures packets at the network interface and decodes them in real time.

To watch ARP traffic:

$ sudo tcpdump -i eth0 -n arp
15:42:01.234567 ARP, Request who-has 192.168.1.1 tell 192.168.1.42, length 28
15:42:01.235012 ARP, Reply 192.168.1.1 is-at 00:11:22:33:44:55, length 28

To watch the TCP handshake with the router:

$ sudo tcpdump -i eth0 -n host 192.168.1.1 and port 80
15:42:01.236000 IP 192.168.1.42.54321 > 192.168.1.1.80: Flags [S], seq 1234567890, win 65535, options [mss 1460,sackOK,TS val 12345 ecr 0,nop,wscale 7], length 0
15:42:01.236500 IP 192.168.1.1.80 > 192.168.1.42.54321: Flags [S.], seq 987654321, ack 1234567891, win 14600, options [mss 1460,sackOK,TS val 67890 ecr 12345,nop,wscale 6], length 0
15:42:01.236600 IP 192.168.1.42.54321 > 192.168.1.1.80: Flags [.], ack 1, win 512, length 0

The [S] is the SYN. The [S.] is the SYN-ACK. The [.] is the ACK. Three packets, three-way handshake complete.

To capture with full packet detail (useful for inspecting Ethernet headers):

$ sudo tcpdump -i eth0 -n -e host 192.168.1.1
15:42:01.236000 aa:bb:cc:dd:ee:01 > 00:11:22:33:44:55, ethertype IPv4 (0x0800), length 74: 192.168.1.42.54321 > 192.168.1.1.80: Flags [S], seq 1234567890, ...

The -e flag adds the Ethernet header to the output. Now you can verify that the destination MAC is correct.

Saving Captures for Wireshark

For deeper analysis, capture to a file and open in Wireshark:

$ sudo tcpdump -i eth0 -w /tmp/router-access.pcap host 192.168.1.1

Open the .pcap file in Wireshark, and you get full protocol dissection with colour-coded layers, flow graphs, TCP stream reassembly, and the ability to inspect every byte of every header. Wireshark is indispensable for complex debugging.

traceroute on a LAN

Traceroute provides limited insight for single-hop LAN destinations, but it confirms the topology:

$ traceroute -n 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 60 byte packets
 1  192.168.1.1  0.543 ms  0.412 ms  0.389 ms

One hop. The packet goes directly to the router. No intermediate devices. The sub-millisecond latency confirms a local Ethernet connection (Wi-Fi would typically show 1 to 5 milliseconds).

Compare with an internet destination:

$ traceroute -n 93.184.216.34
traceroute to 93.184.216.34 (93.184.216.34), 30 hops max, 60 byte packets
 1  192.168.1.1       0.534 ms   0.421 ms   0.398 ms
 2  10.0.0.1          8.234 ms   7.891 ms   8.012 ms
 3  82.130.45.1      12.456 ms  11.987 ms  12.234 ms
 4  213.46.182.1     18.765 ms  17.543 ms  18.234 ms
 5  93.184.216.34    22.345 ms  21.987 ms  22.123 ms

Now you can see the path: your router, the ISP's CGNAT device (10.0.0.1), the ISP's edge router (82.130.x.x), a transit router (213.46.x.x), and the destination. Each hop is a router that decremented the TTL and sent back an ICMP Time Exceeded message.

ss and netstat: Connection State

Once the TCP connection is established, you can verify it with:

$ ss -tn state established dst 192.168.1.1
Recv-Q  Send-Q    Local Address:Port    Peer Address:Port
0       0         192.168.1.42:54321    192.168.1.1:80

This confirms there is an active TCP connection to the router on port 80.

nmap: Port Scanning the Router

If the router's admin panel is not responding, check which ports are open:

$ nmap -sT 192.168.1.1
Starting Nmap 7.94 ( https://nmap.org )
PORT     STATE  SERVICE
22/tcp   open   ssh
53/tcp   open   domain
80/tcp   open   http
443/tcp  open   https
8080/tcp closed http-proxy

This tells you the router has SSH, DNS, HTTP, and HTTPS services running. If port 80 shows "closed" or "filtered," the admin panel may be disabled, or a firewall rule is blocking access from your subnet.

12. Edge Cases and Failure Modes

Real networks are messier than textbook examples. Here are some scenarios where the process described above breaks or behaves unexpectedly.

Duplicate IP Addresses

If two devices on the same subnet claim the same IP address, ARP becomes ambiguous. Your machine might learn the MAC address of either device, and the mapping might flip-flop as both devices respond to ARP requests. The symptoms are maddening: connections work intermittently, some packets reach the correct host, others go to the wrong one.

Linux systems detect this with Gratuitous ARP (GARP). When a device acquires an IP address, it sends an ARP request for its own IP. If another device responds, there is a conflict. The kernel logs it:

[  42.123456] IPv4: eth0: received packets with own IP address but different MAC

The Router Is on a Different Subnet

If your machine is configured with 192.168.1.42/24 but the router is at 192.168.0.1, the router is off-subnet. The kernel will try to route through the default gateway, but the default gateway IS the router you cannot reach. This creates a chicken-and-egg problem: you cannot ARP for the gateway because it is not on your subnet, and you cannot reach any other subnet without the gateway. The result is total network failure. ip route get 192.168.0.1 would show via 192.168.1.1 (the gateway), and ARP for 192.168.1.1 would fail because no device has that IP.

The fix: correct the subnet mask or the IP address so the router falls within the local subnet.

MTU Mismatches

The default Ethernet MTU is 1500 bytes. If a path involves a segment with a smaller MTU (common with PPPoE, which reduces the MTU to 1492, or VPN tunnels with even smaller MTUs), packets that exceed the reduced MTU need fragmentation or Path MTU Discovery.

For LAN-only traffic to the router, this is rarely an issue. But if the router's LAN interface has been misconfigured with a non-standard MTU, large HTTP responses from the admin panel might get silently dropped. The clue is that the TCP handshake succeeds (small packets) but data transfer stalls (large packets). Checking with ip link show eth0 on both sides reveals the MTU.

Wi-Fi: Same Concepts, Different Framing

Everything described above applies to Wi-Fi with one major difference: the frame format. Wi-Fi uses 802.11 MAC headers, which have three or four MAC address fields instead of Ethernet's two. In infrastructure mode (the common case), the frame includes:

• Address 1: The access point's BSSID (MAC)
• Address 2: The source station's MAC
• Address 3: The final destination MAC

The access point acts as a bridge, converting between 802.11 and Ethernet frames. The ARP process, IP routing, and TCP handshake are identical. Only the layer-2 framing changes.

IPv6: Same Idea, Different Protocol

On IPv6 networks, ARP is replaced by Neighbor Discovery Protocol (NDP), which uses ICMPv6 Neighbor Solicitation and Neighbor Advertisement messages instead of raw ARP frames. The concept is identical (discover the link-layer address for a given network-layer address), but NDP uses multicast instead of broadcast and is integrated with ICMPv6 rather than being a separate protocol. You would use ip -6 neigh show to inspect the IPv6 neighbour table.

13. Putting It All Together: The Complete Timeline

Let us summarise the entire sequence from keystroke to rendered page, with approximate timings on a wired Gigabit Ethernet home network.

T+0.000ms    You press Enter after typing 192.168.1.1 in the browser.
 
T+0.001ms    Browser parses URL: scheme=http, host=192.168.1.1, port=80.
             No DNS lookup needed (raw IP address).
 
T+0.010ms    Browser calls socket(AF_INET, SOCK_STREAM, 0).
             Kernel creates TCP socket data structure.
 
T+0.020ms    Browser calls connect(fd, {192.168.1.1, port 80}).
             Kernel consults routing table:
               192.168.1.1 matches 192.168.1.0/24 dev eth0 (longest prefix)
               No gateway needed (scope link).
               Source IP: 192.168.1.42.
 
T+0.030ms    Kernel checks ARP cache for 192.168.1.1.
             Case A: Cache hit (REACHABLE) -> skip to T+0.050ms.
             Case B: Cache miss -> send ARP request.
 
T+0.031ms    [ARP Request] Ethernet broadcast (ff:ff:ff:ff:ff:ff)
             "Who has 192.168.1.1? Tell 192.168.1.42"
 
T+0.200ms    [ARP Reply] Router responds with its MAC.
             Kernel updates neighbour table:
               192.168.1.1 -> 00:11:22:33:44:55 REACHABLE
 
T+0.250ms    Kernel constructs TCP SYN packet:
             IP:  192.168.1.42 -> 192.168.1.1, TTL=64, proto=TCP
             TCP: port 54321 -> port 80, SYN, seq=x
             Ethernet: our MAC -> router's MAC, type 0x0800
             NIC computes FCS, transmits frame.
 
T+0.260ms    Switch receives frame on port 3.
             Looks up dst MAC 00:11:22:33:44:55 in CAM table.
             Forwards frame to port 1.
 
T+0.270ms    Router NIC receives frame.
             FCS check passes, Ethernet header stripped.
             IP dst (192.168.1.1) matches router's own IP.
             Local delivery to TCP stack.
 
T+0.300ms    Router TCP stack processes SYN.
             Allocates TCB (Transmission Control Block).
             Sends SYN-ACK: seq=y, ack=x+1.
 
T+0.350ms    Our kernel receives SYN-ACK.
             Connection moves to ESTABLISHED.
             Sends ACK: ack=y+1.
 
T+0.400ms    Three-way handshake complete.
 
T+0.500ms    Browser sends HTTP request:
             GET / HTTP/1.1
             Host: 192.168.1.1
             Connection: keep-alive
 
T+0.700ms    Router HTTP server processes request.
             Reads admin panel HTML from flash storage / RAM.
 
T+1.500ms    Router sends HTTP response:
             HTTP/1.1 200 OK
             Content-Type: text/html
             (HTML body with login form)
 
T+2.000ms    Browser receives full response.
             Begins parsing HTML, loading CSS/JS.
 
T+5.000ms    Admin panel login page fully rendered.

The entire process takes under 5 milliseconds for the network portion (handshake + request + response) on a local Gigabit connection. The rest is browser rendering time. Most of the "delay" in accessing your router's admin panel is the router's HTTP server itself, which runs on a low-power embedded processor (often a MIPS or ARM SoC clocked at 500 MHz to 1 GHz with 128 to 512 MB of RAM).

14. Historical Context: How We Got Here

The machinery described in this post was not designed all at once. It accumulated over decades.

Ethernet was invented by Robert Metcalfe and David Boggs at Xerox PARC in 1973, standardised as IEEE 802.3 in 1983. The original Ethernet used a shared coaxial cable (10BASE5 "thick Ethernet") where every device saw every frame. Switches came later, replacing hubs in the mid-1990s and making Ethernet a point-to-point, full-duplex technology.

IP (Internet Protocol) was defined in RFC 791 in September 1981 by Jon Postel. The 32-bit address space seemed enormous at the time (4.3 billion addresses), but by the early 1990s it was clear that the space would run out.

ARP was defined in RFC 826 in November 1982 by David C. Plummer. It is one of the simplest protocols in the entire stack: 28 bytes of payload, two opcodes (request and reply), no authentication, no versioning. It has not changed in over 40 years.

RFC 1918 (private addresses) was published in February 1996, formalising the practice of using reserved address ranges for internal networks. Before RFC 1918, organisations sometimes used arbitrary addresses internally, causing routing conflicts when they connected to the internet.

NAT was described in RFC 1631 in May 1994 (informational) and standardised in RFC 3022 in January 2001. NAT was intended as a short-term workaround until IPv6 was deployed. Twenty-five years later, NAT is still the backbone of home networking, and IPv6 deployment, while growing, has not replaced it.

The combination of private addresses and NAT is what allows billions of devices to share the IPv4 address space. When you type 192.168.1.1, you are interacting with a system that was designed as a temporary hack in the 1990s and became the permanent foundation of consumer networking.

15. Wrapping Up

The next time you type 192.168.1.1 into a browser, consider what just happened. The browser skipped DNS entirely because you gave it a raw IP address. The kernel looked at its routing table, found a directly-connected route for 192.168.1.0/24, and chose eth0. It performed a binary AND between the destination IP and the subnet mask to confirm the destination was on-link. It sent an ARP broadcast asking "who has 192.168.1.1?" and received a unicast reply with the router's MAC address. It constructed an Ethernet frame with the router's MAC as the destination, wrapped around an IP packet, wrapped around a TCP SYN, and handed it to the NIC. The NIC computed a CRC, appended it as the FCS, and transmitted the frame. The switch looked up the destination MAC in its CAM table and forwarded the frame to the correct port. The router's NIC received the frame, verified the FCS, and passed the IP packet to the kernel. The kernel saw that the destination IP matched its own address and delivered the packet locally to the TCP stack. TCP completed the three-way handshake. The HTTP server read the request and sent back the admin panel. The response traversed the same path in reverse.

No packet left the local network. No DNS server was queried. No NAT translation occurred. No TTL was decremented. The entire exchange happened on a single Ethernet segment, mediated by a switch, in under five milliseconds.

This is the foundation that everything else in networking is built on. BGP, OSPF, MPLS, VXLAN, DNS, TLS, HTTP/3: they all depend, at the bottom of the stack, on the ability to resolve a next-hop IP address to a MAC address, construct an Ethernet frame, and forward it to the right port. The path from your laptop to 192.168.1.1 is the simplest possible version of this machinery, and understanding it makes every other networking topic more concrete.

If you want to observe all of this yourself, open two terminal windows. In the first, run:

$ sudo tcpdump -i eth0 -n -e '(arp or (host 192.168.1.1 and port 80))'

In the second, clear your ARP cache and access the router:

$ sudo ip neigh flush dev eth0
$ curl -s -o /dev/null http://192.168.1.1

You will see the ARP request, the ARP reply, the TCP handshake, the HTTP request, and the HTTP response. Every layer, every header, every step of the process described in this post, visible in real time on your own network.