Routing, the Internet Path and NAT

By the end of this lesson you will be able to

• Explain the difference between routing (choosing the next hop) and NAT (rewriting addresses).
• Read a routing table and pick the route for any destination with longest-prefix match and the default route.
• Say exactly which header fields change at each hop: MAC addresses, TTL, and IP addresses only at a NAT.
• Describe how routers learn routes: static routes, OSPF inside a network, BGP between networks, and what goes wrong (loops, hijacks, leaks).
• Walk through how BGP picks one best path (local preference, AS-path length, MED and the tie-breakers) and what happens when a route is withdrawn.
• Tell unicast, broadcast, multicast and anycast apart, and say where each one is really used.
• Trace a connection through NAT and back, and explain port forwarding, mapping timeouts, CGNAT, hairpinning and why peer-to-peer is hard.
• Use these ideas in system design: NAT gateways, egress IPs, port exhaustion, anycast and asymmetric paths.

#Two different jobs: routing and NAT

When your browser sends a packet to a server on the other side of the world, two separate things happen to it on the way. People often mix them up, so keep them apart from the start:

• Routing decides where the packet goes next. Every router looks at the destination IP address and picks the next hop. It does not change the addresses.
• NAT (Network Address Translation) rewrites addresses (and often ports). Your home router uses it so that many devices with private addresses can share one public IP address. When ports are rewritten too, it is called NAPT (Network Address and Port Translation) or PAT.

Three more players appear in this lesson:

The packet’s journey from your laptop looks like this:

1. Local network (router + NAT). Your computer has a private IP. It sends anything outside the local network to its default gateway, the home router. The router routes it toward the ISP and, on IPv4, applies a NAT mapping.
2. ISP and internet routers. Each router forwards the packet one hop closer to the destination, using its own routing table.
3. The destination network (for example Google’s edge) receives the request, hands it to the right service and sends a response.
4. The response comes back, possibly along a different route, and the home router uses its NAT mapping to deliver it to the right device.

#How your computer decides where to send a packet

Before any router is involved, your own computer makes the first routing decision. It knows its IP address and its subnet, for example 192.168.1.10/24, which means “every address starting with 192.168.1 is on my local network”.

• Destination on the local network (say 192.168.1.11, your phone): send it directly. The computer finds the phone’s MAC address with ARP and delivers the frame itself.
• Destination outside (say 198.51.100.20, a web server): send it to the default gateway, the router at 192.168.1.1. The computer finds the router’s MAC address with ARP and puts it in the frame, while the IP header still says 198.51.100.20.

That is the whole idea of a default gateway: “if it is not local, give it to the router”. Your computer has a tiny routing table of its own with exactly these two rows (plus a few special ones), and the gateway usually arrives automatically by DHCP.

#The routing table

Every router (and every computer) holds a routing table: a list of destination networks and where to send packets for each.

On Linux, ip route shows your computer’s table:

$ ip route
default via 192.168.1.1 dev wlan0 proto dhcp metric 600
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.10 metric 600

The first line is the default route (to the gateway); the second says the whole 192.168.1.0/24 network is directly connected on wlan0.

#Longest-prefix match

A destination address often matches several rows. The router then follows one rule: the most specific match wins, meaning the row with the longest prefix (the most matching bits). Take this table on a company router R1:

• 10.20.30.7 matches 10.20.0.0/16, 10.20.30.0/24 and 0.0.0.0/0. The /24 is longest, so it goes to R3.
• 10.20.99.4 matches the /16 and the /0 (the third number is 99, not 30). The /16 wins: R2.
• 198.51.100.20 matches only 0.0.0.0/0, so it goes to the ISP.
• 192.168.10.25 matches the directly connected row: R1 delivers it on the LAN itself.

The metric only matters between routes with the same prefix length, for example a primary and a backup path to the same network.

#The default route

0.0.0.0/0 (and ::/0 in IPv6) has zero fixed bits, so it matches every address, and because it is the least specific it only wins when nothing else matches. It means “if you know nothing better, send it here”. Your home router has essentially one real route: a default route to the ISP. Routers in the core of the internet have the opposite: no default route at all, but a full table of roughly a million IPv4 prefixes learned through BGP. If a router has no matching row and no default route, it drops the packet and usually sends back ICMP Destination Unreachable.

#Hop by hop: what changes and what stays the same

This is where IP addresses and MAC addresses play different roles:

• IP address: identifies the packet’s network-level source and final destination. Without NAT it stays the same end to end.
• MAC address: delivers a frame across one local link. It only has meaning on that link.

When your computer sends to the router, the destination IP is the server’s, but the destination MAC is the router’s local interface. When the router forwards the packet onto the next link, it builds a new link-layer frame, so the MAC addresses change at every hop. Every IPv4 router also decrements the TTL by one. In IPv6 the same field is called Hop Limit.

#TTL and routing loops

TTL (Time To Live) is an 8-bit field, so it starts at most at 255; operating systems usually start at 64 (Linux, macOS) or 128 (Windows). When a router decrements it to 0, it drops the packet and sends ICMP Time Exceeded back to the source. Its purpose is to kill packets caught in a routing loop, where two routers each think the other is the way to the destination. Without TTL, looping packets would pile up until the links collapsed. The tool traceroute uses this behaviour deliberately; that is covered in the diagnostics lesson.

#Routers do not know the whole path

No router knows the end-to-end path. Each one only chooses the next hop based on the destination IP. Two consequences:

• The path can change from one packet to the next if a link fails or a policy changes.
• The request and the response can take different paths (asymmetric routing). Each network chooses how to send traffic out of itself, and networks often hand traffic over at the nearest exit (“hot-potato routing”). This is normal. It causes trouble mainly when a stateful firewall sees only one direction of a connection.

Where a company uses a CDN, “the destination” may be a server in a nearby city rather than the origin, and how a particular resource is delivered depends on that company’s infrastructure. Large content networks such as Google bring traffic into their own private network at the closest edge location.

#How routers learn their routes

A routing table has to come from somewhere. There are three sources:

1. Connected routes: networks the router is directly plugged into. Added automatically when an interface comes up.
2. Static routes: typed in by an administrator. Simple, predictable and free of protocol traffic, but they never react to failures.
3. Dynamic routes: learned from neighbouring routers through a routing protocol, which adapts automatically when links fail or come back.

Routing protocols come in three families. Distance-vector protocols (the old RIP, and Cisco’s EIGRP) only tell their neighbours “network X is N hops away from me”, so every router knows the network by rumour. Link-state protocols such as OSPF flood a description of every link, so every router holds the full map. Path-vector BGP carries the whole list of networks a route passes through. The first two are interior protocols; BGP is the one between networks.

#Inside one network: OSPF

Inside a single organisation (one autonomous system) routers run an interior gateway protocol (IGP), most often OSPF (Open Shortest Path First). Each router tells all the others about its links and their costs, so every router builds the same map of the network and computes the shortest path to every destination. When a link fails, the news spreads and routers recalculate, typically within a second. When several paths have the same cost, routers can spread traffic across them (ECMP).

#Between networks: BGP and autonomous systems

The internet is made of more than 70,000 autonomous systems: ISPs, cloud providers, universities, large companies. Each has a number, its ASN (Google is AS 15169, Cloudflare AS 13335). IANA does not hand ASNs to companies directly: it gives blocks of ASNs (and of IP addresses) to the five Regional Internet Registries (RIRs), and each RIR assigns them to networks in its region. A Bangladeshi ISP gets its ASN from APNIC, the registry for the Asia-Pacific. ASNs are 32-bit numbers today, so there is no shortage; 64496–64511 are reserved for documentation, which is why the examples here use them.

Inside an AS, the operator runs whatever IGP it likes. Between autonomous systems everyone speaks BGP. Two routers run BGP over an ordinary TCP connection on port 179, called a BGP session. A session between two different autonomous systems is eBGP; iBGP sessions inside one AS share the routes learned from outside with all of that AS’s border routers, so they agree. Strictly speaking BGP is an application on top of TCP that steers layer 3; OSPF, in contrast, runs directly on IP.

• An AS announces the prefixes it owns: “198.51.100.0/24 is reachable through me”.
• Each neighbour adds its own AS number to the front of the AS path and passes the announcement on. So a route might arrive at your ISP as 64501 64496: through AS 64501 to AS 64496, the origin.
• A router that sees its own AS number already in the path rejects the route. That simple rule prevents loops between networks. Note what is dropped: the route announcement, not a data packet. BGP never touches user traffic; it only decides which routes get installed.
• BGP picks one best path per prefix. Policy comes first: a network prefers routes learned from customers (who pay it), then from peers (free), then from transit providers (whom it pays). Only after that does a shorter AS path win. The full ladder is below.

Networks connect in two commercial ways:

Peering usually happens at an IXP (Internet Exchange Point), a building where many networks plug into a shared switch.

#How BGP chooses the best path

When several routes reach the same prefix, a BGP router compares their attributes in a fixed order and stops at the first one that differs. Routes it cannot use (next hop unreachable, filtered by policy, rejected by RPKI) are thrown out before the race starts.

Three things to take away. First, BGP knows nothing about latency, bandwidth or load: it follows policy and path length, so the “best” path is the preferred one, not necessarily the fastest. Second, you control your outbound traffic well (local preference) but can only ask others about inbound traffic (prepending, MED, or announcing a more specific prefix on the link you want used). Third, when a session fails, its routes are withdrawn and the race runs again over what is left: that is BGP failover.

#Unicast, broadcast, multicast and anycast

Every packet so far had one sender and one receiver. The destination address can also say “everyone here”, “everyone who asked for this” or “whichever copy of me is nearest”. These four delivery patterns are called cast types.

#Unicast and its cost

Unicast is simple and private: routers forward towards one address, and only that host receives the data. Its cost appears when many people want the same thing at the same moment. If 10,000 people watch the same live match by unicast, the source sends 10,000 copies of every packet. Big services handle that with CDNs: copies are made at edge servers close to the viewers, but every viewer still gets their own unicast stream.

#Broadcast stays on the LAN

A broadcast reaches every device on the local network, and each one has to stop and look at it. Routers never forward broadcasts, so a broadcast domain ends at the first router. That is why a device asking for an address by DHCP on one subnet cannot reach a DHCP server on another unless the router runs a DHCP relay. Broadcasts also have a dangerous failure: Ethernet frames have no TTL, so if two switches are joined by two cables without the Spanning Tree Protocol (STP), one broadcast circulates and multiplies forever, a broadcast storm that stops the whole LAN. IPv6 has no broadcast at all; it uses multicast groups, such as all-nodes ff02::1, for the same jobs.

#Multicast: one stream, copied only where needed

The source sends one stream to a group address. A host that wants it sends an IGMP join to its router (IPv6 does the same with its own messages); routers build a distribution tree with PIM and copy packets only at branch points, and switches doing IGMP snooping deliver them only to the ports that asked. When the last member leaves, the branch is pruned. The source’s bandwidth stays the same whether 2 or 20,000 homes watch.

The catch: multicast does not cross the public internet, because ISPs do not route multicast between each other. So it lives where one operator controls the whole network: IPTV inside an ISP, stock exchanges sending market data to brokers in the same data centre, and routing protocols on a LAN (OSPF routers talk to 224.0.0.5). YouTube Live, Netflix, Zoom and Google Meet are all unicast, through CDN servers or a media server that sends one copy per viewer.

#Anycast: one address, many sites

Several sites use the same IP address and all announce its prefix with BGP. Each router simply follows its best BGP path, so every user ends up at whichever site is nearest in routing terms. If a site fails, it withdraws its announcement and the same address now leads to the next site. That makes anycast the backbone of public DNS resolvers, the root servers, CDNs and DDoS protection (a flood is split across every site instead of hitting one).

Three details matter in practice:

• “Nearest” means preferred by BGP, which follows policy and AS-path length, not measured latency. Sometimes a user lands on a farther site.
• A sick site must withdraw its route. If its router keeps announcing while the servers are dead, everyone routed there hits a black hole. Anycast sites tie their announcements to health checks.
• Route changes can break long connections. If routing shifts mid-connection, packets reach a site that never saw the TCP handshake, and it resets the connection. Anycast suits short UDP exchanges like DNS best; CDNs keep routes stable to make it work for TCP too.

#NAT: sharing one public address

IPv4 has about 4.3 billion addresses, far fewer than the devices in the world, and the regional registries ran out of fresh blocks during the 2010s. The fix that kept IPv4 alive is private addresses plus NAT. Three ranges are reserved for private use (RFC 1918) and are never routed on the public internet:

Anyone can use these inside their own network, so millions of homes all have a 192.168.1.10. To reach the internet, the router translates them to its one public address.

Count it in an ordinary home: four phones and two laptops are six private addresses, but the ISP gives the router one public IP. Each device may have dozens of connections open at once, and every connection gets its own row in the router’s NAT table, told apart by its public port. Six devices with 100 connections each use 600 of the roughly 64,000 ports, so one address is plenty.

#A home network, before and after NAT

Suppose your home looks like this:

The computer opens an HTTPS connection to a server:

The router changed the source IP from 192.168.1.10 to 203.0.113.25 and, in this example, the source port from 53000 to 62001. It stores the connection in its NAT mapping table:

#How the response finds its way back

The response arrives at the public address and port. The router looks up port 62001 in its mapping table, rewrites the destination back to 192.168.1.10:53000 and delivers it on the LAN. On the computer, TCP puts the data in order, TLS decrypts it and the browser renders the page.

Some details matter in practice:

• NAT does not always change the port. If the device’s source port is free on the public side, many routers keep it (port preservation). The router changes it only when two inside connections would otherwise collide, like the computer and the mobile both using port 53000.
• Ports are the reason this works. One public IP has about 64,000 usable ports per protocol, so one address can carry tens of thousands of simultaneous connections.
• Mappings expire. UDP has no “close” message, so routers delete idle UDP mappings after a timeout, often 30 seconds to a few minutes; established TCP mappings last much longer (often hours) and are removed when the connection closes. Apps that hold long-lived connections send small keepalive packets so their mapping does not vanish.

#Types of NAT

By direction, people also speak of SNAT (source NAT: rewrite the source of outgoing traffic, as above) and DNAT (destination NAT: rewrite the destination of incoming traffic, as in port forwarding and load balancers).

#Port forwarding: letting traffic in

NAT only creates mappings for connections started from inside. A packet that arrives from outside with no matching mapping cannot be delivered, because the router does not know which device it is for. To run a server at home (a game server, a security camera, a home server), you add a port forwarding rule: a permanent DNAT entry such as “public port 8080 → 192.168.1.20:80”. Apps can create such rules automatically with UPnP, which is convenient and a security risk. Each forwarded port exposes an inside device directly to the internet.

#Where NAT causes trouble

#Inbound connections and peer-to-peer

Because NAT blocks unsolicited inbound packets, two devices that are both behind NAT cannot simply connect to each other. Video calls, online games and file sharing work around this:

1. Each side asks a STUN server on the internet “what public address and port do you see me as?”.
2. They exchange those addresses through the app’s server.
3. Both send packets to each other at the same moment. Each outgoing packet creates a mapping in its own NAT, so the other side’s packets now match and get in: hole punching.
4. If a strict (“symmetric”) NAT picks a new port for every destination, the predicted port is wrong and hole punching fails. Then both connect outward to a TURN relay server, which forwards the traffic, at the cost of latency and bandwidth.

WebRTC does all of this automatically.

#Hairpinning

If you forward port 8080 to your home server and then, from inside your home, open your own public address 203.0.113.25:8080, the packet goes to the router and has to turn straight back inside. Routers that support hairpinning (NAT loopback) rewrite both the destination and the source so this works; many cheap routers do not, and the service works from outside but not from home. The usual fix is to use the local address at home or “split DNS” that gives inside users the private IP.

#CGNAT: NAT at the ISP too

Many ISPs, and nearly all mobile networks, do not have enough public IPv4 addresses to give one to every customer. They run CGNAT (Carrier-Grade NAT): your router’s “public” address is actually from the shared range 100.64.0.0/10, and the ISP translates a second time to a real public address shared by hundreds of customers. The results:

• Double NAT: two mapping tables and two timeouts on every connection.
• No inbound connections: port forwarding on your own router is useless, because the ISP’s CGNAT has no rule for you.
• Shared reputation: a website sees hundreds of people as one IP. If one of them is abusive and the IP is blocked or rate-limited, everyone behind it suffers.
• Logging: the ISP must record which customer used which port at what time, to trace abuse.

To check: if your router’s WAN address is in 100.64.0.0/10 (100.64.x.x to 100.127.x.x) or another private range, but a “what is my IP” website shows a different address, you are behind CGNAT.

#IPv6 and NAT

IPv6 has so many addresses (2¹²⁸) that every device can have its own globally routable address, so IPv6 normally uses no NAT. Addresses stay the same end to end, inbound connections and peer-to-peer become simple again, and protection comes from a stateful firewall that blocks unsolicited inbound traffic by default. Translation still appears at the edges: NAT64 lets IPv6-only phones on mobile networks reach servers that only have IPv4.

#Routing and NAT in system design

• Private subnets and NAT gateways. In AWS, Azure or Google Cloud, servers in a private subnet have only private IPs. To download updates or call external APIs they go out through a NAT gateway, which gives them outbound access while nothing on the internet can connect in. NAT gateways charge per gigabyte, so heavy outbound traffic (or traffic to cloud services that could use a private endpoint) can become a real cost.
• Egress IPs and allowlists. Partners often allowlist the IP addresses your requests come from. Behind a NAT gateway, all your servers share a small set of public IPs, which makes that easy. Behind random serverless or CGNAT addresses, it is impossible.
• Port exhaustion. One public IP gives about 64,000 ports per destination. A service making huge numbers of short outbound connections to one API through one NAT address can run out of ports and see connection failures. Fixes: connection pooling and keep-alive, more NAT IPs, or private endpoints.
• Load balancers are NAT too. A load balancer does DNAT (the public virtual address → a backend’s private IP), and often SNAT as well, so backends see the balancer’s address. That is why proxies add the X-Forwarded-For header with the real client IP.
• Anycast and BGP. CDNs and public DNS resolvers announce the same prefix from many locations, and BGP delivers each user to the nearest one. The same mechanism lets them withdraw a failing site in seconds, as long as the withdrawal is tied to health checks.
• Multicast stays inside. You cannot multicast to users on the internet, so live video at scale is unicast fan-out through a CDN. Inside one data centre or one operator’s network (market data, IPTV), multicast saves a lot of bandwidth.
• Asymmetric paths and stateful devices. Firewalls and NAT must see both directions of a connection. With two internet links or multiple regions, make sure return traffic comes back through the same stateful device.

#Try it yourself

# Your routing table and default gateway
ip route                    # Linux
netstat -rn                 # macOS
route print                 # Windows

# Which route would be used for one destination?
ip route get 8.8.8.8        # Linux: shows next hop, interface, source address

# The MAC addresses your computer has learned on the local link (ARP cache)
ip neigh                    # Linux
arp -a                      # Windows / macOS

# Your public IP as the internet sees it (compare with the router's WAN IP to spot CGNAT)
curl https://ifconfig.me

# Watch TTL drop and the path unfold, hop by hop
traceroute example.com      # Linux / macOS
tracert example.com         # Windows

Log in to your home router’s admin page (usually http://192.168.1.1) and find the WAN address, the NAT or port-forwarding page and the list of connected devices. If the WAN address starts with 100.64 to 100.127, your ISP uses CGNAT.

#Summary

Key takeaways

• Routing chooses the next hop from the destination IP; NAT rewrites addresses and ports. They are different jobs that often happen in the same box.
• A routing table has destination prefix, next hop, interface and metric. Longest-prefix match decides; the metric breaks ties; 0.0.0.0/0 is the default route; no match means drop plus ICMP Destination Unreachable.
• At every hop the MAC addresses change and the TTL (IPv6: Hop Limit) drops by one; IP addresses stay the same unless a NAT rewrites them. TTL kills packets caught in routing loops.
• No router knows the whole path, and the return path can differ (asymmetric routing).
• Routes are connected, static or dynamic: OSPF inside a network, BGP between autonomous systems, with AS paths, peering and transit. ASNs come from the regional internet registries. BGP hijacks and leaks are real; RPKI and filtering defend against them.
• BGP best path: highest local preference (your policy), then shortest AS path, origin, lowest MED, eBGP over iBGP, nearest exit, tie-breakers. A failed session withdraws its routes and the race runs again. BGP drops routes, never packets.
• Unicast (one to one) carries almost everything; broadcast (all on the LAN) stops at the router and can storm in a switching loop; multicast (one stream to joined receivers, IGMP + PIM) works only inside one operator’s network; anycast (one address, nearest site by BGP) powers DNS resolvers and CDNs.
• NAT/PAT lets many private devices share one public IP using a mapping table; replies are translated back, unsolicited inbound traffic is dropped, port forwarding opens deliberate holes, and idle mappings time out.
• NAT complicates peer-to-peer (STUN, hole punching, TURN), hairpinning and, with CGNAT, any inbound connection at all. NAT is not a firewall, and IPv6 normally needs no NAT.

Self-check: routing, NAT and cast types30 questions