Routing

An Internet prefix may come out of a data center in Shanghai today and switch to Beijing or Hong Kong tomorrow. The same public address may follow very different paths for users on different carriers. A data center may already be healthy again, yet external traffic still detours around it. When you see this kind of behavior, the problem is usually no longer in one router’s forwarding table. It is higher up, in how autonomous systems tell each other which prefixes are reachable.

When the same service is deployed in many places, the usual approach is to give each node a different address and let DNS, a configuration center, or an upper-layer scheduler decide which one the user should connect to. That can work, but it has a clear cost: the access decision happens outside the network, so very often the name has already been resolved before the user discovers that they were sent somewhere suboptimal.

The packets that go on the road first are not HTTP, TLS, or TCP abstractions. They are individual packets that have to cross subnets, routers, carrier paths, and middleboxes before they can reach the destination host. The first thing that decides whether they can keep moving is not the transport layer or the application layer. It is IP.

IP is often described as a list of address and header fields, but the real high-frequency questions in engineering are different: why a packet was lost, rerouted, fragmented, dropped at one hop, or still could not reach the service even though the service itself was healthy. To answer those questions, the boundaries of IP’s responsibility have to be kept sharp.

If you think of IPv6 as “changing IPv4 addresses from 32 bits to 128 bits”, this article would not need to exist. What actually makes IPv6 a different network model is not just that the address got longer. It also rewrites several default assumptions that had been bothering IPv4 networks for a long time: address scarcity, widespread NAT, separate ARP, messy fragmentation boundaries, and host configuration that depends heavily on centralized assignment.

When a packet goes out, the hard part is not whether there is a destination address. The hard part is why so many routers in the network all seem to agree, at that moment, to send it in one direction. Links fail, exits change, prefixes get summarized, default routes act as fallback, and policy may deliberately avoid the path that looks shortest. If one of those decisions disagrees with the others, packets disappear into black holes, detour, flap, or fall into a loop.

When the same data has to go to many receivers, there are usually only two extremes: send a separate copy to each one, or broadcast it to the whole network. The first is simple, but once the number of receivers grows, the sender and the network get buried under duplicate traffic. The second looks convenient, but it also disturbs devices that should never have received that data in the first place. Live video, market data distribution, service discovery, routing neighbor announcements, and many local-link control messages all need something different from either extreme.

In a campus network, if one uplink fails, traffic should quickly switch to the other path. If a distribution switch reboots, access-layer devices should not keep sending traffic to it for a long time. If a new subnet is added, the rest of the domain should soon know where to send that prefix. The hard part in cases like these is not whether there is a static route. It is how many devices inside one autonomous system can quickly form a consistent judgment after the topology changes.