Internet Exchange Points — the physical facilities where internet service providers, content delivery networks, and large content providers connect their networks directly to each other — handle a significant fraction of all internet traffic while remaining almost entirely invisible to the people generating that traffic, and understanding them reveals why video streaming from a major platform to a home in the same city may never leave that city's network
Traceroute output contains a layer of information that most network diagnostic guides stop short of explaining: the autonomous system numbers and IXP names embedded in router hostnames tell a story about the actual economic and physical structure of the internet — who owns which networks, where they connect to each other, and why traffic takes the paths it does.
What an Internet Exchange Point actually is
An IXP is a physical network facility — typically a building or data centre floor — where multiple networks connect their routers to a common switching fabric. By connecting at an IXP, networks can exchange traffic directly (peering) rather than paying a transit provider to carry it.
The economic motivation: without IXPs, if ISP A wants to exchange traffic with Content Provider B, one or both must pay a transit provider (a Tier 1 network like AT&T, NTT, or Lumen) to carry the traffic between them. Peering at an IXP eliminates this transit cost for exchanged traffic — instead of paying per-byte, both parties pay a fixed fee for the IXP port.
The scale: major IXPs are among the highest-traffic switching points on Earth:
- DE-CIX Frankfurt: frequently reports peak traffic above 15 Tbps — one of the world's highest-traffic IXPs
- AMS-IX Amsterdam: consistently above 10 Tbps peak
- LINX London: above 5 Tbps
- Equinix IXes: a series of IXPs across multiple cities, handling significant combined traffic
The concentration effect: large content providers (Google, Netflix, Meta, Cloudflare) connect to dozens of IXPs globally, placing their content as close as possible to end-user ISPs. This reduces both their transit costs and the latency experienced by users.
Reading autonomous system numbers in traceroute output
Every IP address on the internet belongs to an Autonomous System (AS) — a network operated by a single entity under a common routing policy, identified by an Autonomous System Number (ASN):
Example traceroute hop hostnames that reveal ASN context:
xe-1-0-0.cr1.lon1.de-cix.net ← DE-CIX London IXP
ae-1.mpr1.ams4.nl.lumen.net ← Lumen (CenturyLink) transit router, Amsterdam
google-cach.linx.net ← Google connected at LINX IXP
1.1.1.1 ← Cloudflare's resolver
Where to look up ASNs: whois 8.8.8.8 reveals that Google's public DNS runs in AS15169 (Google LLC). The BGP looking glass tools at major IXPs show current routing tables and peering relationships.
What IXP hostnames tell you about traffic path:
- If traceroute hops show IXP router hostnames, your traffic is crossing an internet exchange
- The IXP city reveals where your ISP is peering with the destination network
- If the traffic leaves your country for an IXP before coming back, the destination network has no peering presence in your country
BGP and why traffic doesn't always take the shortest path
Border Gateway Protocol (BGP) is the routing protocol that governs how ASes announce which IP prefixes they can reach. Traffic routing decisions in BGP prioritise:
- Network reachability announcements: can this AS reach the destination?
- AS path length: how many autonomous systems does traffic traverse?
- Local preference: which exit point does the local network prefer?
- MED (Multi-Exit Discriminator): hints from the destination network about preferred entry points
Hot potato routing: an ISP passes traffic to the next AS as quickly as possible, letting the destination AS carry it most of the way — minimising the transit distance within the ISP's own network (and thus their costs). This can produce surprising traffic paths: New York traffic destined for London may exit through a New York IXP rather than being carried to a European PoP first.
Cold potato routing (route optimisation): the source network carries traffic closest to the destination before handing it off — typically producing lower latency but higher transit costs for the source network.
How CDNs use IXP presence to reduce latency
Content Delivery Networks (Cloudflare, Fastly, Akamai, AWS CloudFront) derive much of their value from IXP presence. By connecting at hundreds of IXPs globally, a CDN can:
- Receive traffic from an ISP directly at the IXP in the same city as the user
- Serve the content from cache at that PoP
- Return the response to the user through the same direct connection
The traceroute evidence: a traceroute to a Cloudflare-proxied website typically shows the traffic reaching Cloudflare's network within 1-2 hops and arriving at a Cloudflare server in the same city or region — rather than traversing multiple transit networks to a single origin server.
Without CDN/IXP presence: a user in Warsaw accessing content from an origin server in San Francisco might traverse: Warsaw ISP → Tier 1 transit in Frankfurt → transatlantic cable → Tier 1 transit in New York → West Coast transit → San Francisco origin. Roundtrip latency: 150-200ms. With Cloudflare's Warsaw IXP presence: Warsaw ISP → Cloudflare at Warsaw IXP → cached content served. Roundtrip latency: 5-15ms.
What traceroute doesn't show: ECMP and asymmetric paths
ECMP (Equal-Cost Multi-Path) is a routing technique where multiple paths with the same BGP cost are used simultaneously, with traffic split across them by flow hash. A traceroute represents only one sampled path — a second traceroute to the same destination may traverse entirely different routers.
Asymmetric routing: the forward path (your packet going to the server) and the return path (the server's response coming back) often traverse different AS paths. Traceroute only shows the forward path — it doesn't reveal return path routing, which may be significantly different.
MPLS tunnelling: many ISP backbone networks use MPLS (Multi-Protocol Label Switching) to forward traffic through tunnels. Traceroute probes may disappear mid-path (hops show * * *) when MPLS tunnel endpoints don't respond to ICMP TTL-exceeded messages. The traffic is still being forwarded; the hops are simply invisible to traceroute.
How to use the Traceroute tool on sadiqbd.com
- For IXP identification: note hop hostnames containing known IXP names (de-cix, linx, ams-ix, equinix-ix) — these indicate your traffic is crossing an internet exchange at that geographic location, revealing the peering relationship between your ISP and the destination network
- For latency anomaly diagnosis: compare expected latency (based on geographic distance and speed-of-light floor) against actual traceroute latency at each hop — a jump of more than 50-100ms beyond the speed-of-light expectation suggests suboptimal routing through an unexpected geographic detour
- For CDN presence verification: compare traceroute to a CDN-hosted domain vs the same content without CDN — the CDN version should show significantly fewer hops and reach a nearby IP rather than traversing to a distant origin
Frequently Asked Questions
Why do some traceroute hops show * * * (no response) while later hops respond normally?
Because some routers are configured to not respond to ICMP TTL-Exceeded messages (or rate-limit them aggressively) while still forwarding packets normally. Traceroute works by sending packets with incrementing TTL values. When a router receives a packet with TTL=1, it decrements TTL to 0, discards the packet, and sends an ICMP "Time Exceeded" message back to the source — which is what traceroute displays as a hop. If a router is configured to not generate these ICMP messages (a common security configuration to avoid being fingerprintable), traceroute shows * * * for that hop. The packet was still forwarded correctly — the router simply didn't announce its presence. Later responding hops prove traffic made it through the silent router.
Is the Traceroute tool free? Yes — completely free, no sign-up required.
Try the Traceroute tool free at sadiqbd.com — map the network path to any host and identify latency at each hop.
