China Telecom’s 2010 Route Leak: When Tens of Thousands of Prefixes Took a Detour
China Telecom's 2010 routing anomaly caused tens of thousands of foreign prefixes to appear through its network, revealing both BGP policy weakness and the limits of public routing evidence.
China Telecom’s AS23724 suddenly originated tens of thousands of foreign prefixes
On April 8, 2010, route-monitoring systems saw AS23724, a China Telecom data-center network, announce an enormous set of prefixes normally originated by other networks. BGPmon reported roughly 37,000 unique prefixes in its observation window, while later academic analyses using different collectors identified still larger sets.[1] The safest description is therefore not one magic number but a large routing anomaly involving tens of thousands of prefixes. The event lasted only minutes, yet it spread far enough to trigger alerts across multiple vantage points.
Prefix counts are not traffic percentages
A route prefix can represent vastly different amounts of address space and traffic. Saying that tens of thousands of prefixes were affected does not prove that the same fraction of Internet traffic was diverted.
Later research found evidence consistent with a route leak rather than simple subprefix hijacking
Hiran, Carlsson, and Gill analyzed control-plane and data-plane measurements from the incident and concluded that there was little evidence of subprefix hijacking; their results supported the hypothesis that existing routes had been leaked or re-originated through China Telecom.[2] This distinction matters because BGP incidents are often called ‘hijacks’ before intent or mechanism is known. A route leak can be accidental and still redirect traffic. Failure analysis should describe the observable routing behavior separately from claims about motive.
Control-plane evidence has limits
Public BGP collectors see only part of the Internet. Different observers can record different route sets and path choices, which is why later reconstructions report different counts.
Some data-plane traces showed traffic entering China Telecom and still reaching its destination
The academic study found examples in which traceroutes that normally avoided China Telecom passed through its network during the event and then continued onward to the correct destination.[2] That behavior is better described as potential traffic interception or detouring than as universal blackholing. It also complicates impact measurement: a user may experience normal application behavior even though the network path has changed significantly. Routing security therefore cannot rely only on outage detection.
Reachability does not prove path correctness
A packet can arrive at the right server after traversing an unexpected autonomous system. Monitoring needs to examine route provenance and path changes, not merely whether the destination responds.
Customer-route preference helped the leaked paths spread
Citizen Lab’s summary of the research explains that provider policies can prefer customer-learned routes for economic reasons, making a leaked customer route attractive even when another route has a shorter-looking global history.[3] BGP is not simply shortest-path routing. Business relationships shape local preference before AS-path length is considered. That means an incorrect route arriving through the wrong commercial relationship can beat a correct route for reasons that make perfect sense to the receiving network’s policy.
Economic policy is part of routing correctness
A route’s acceptance and preference reflect contracts as well as topology. Security mechanisms must understand those relationships instead of assuming path length alone determines behavior.
The incident later became a reference case in the route-leak standards literature
RFC 7908 cites the China Telecom event in its discussion of large-scale route leaks and the difficulty of defining abnormal interdomain propagation.[4] The document formalizes route leaks as propagation beyond an intended scope, which is a more useful framework than assuming every anomaly is a hostile origin hijack. This language helps operators reason about policy violations even when prefixes are legitimate and packets still reach their destinations.
Basic BGP hygiene can limit how far this class of mistake travels
RFC 7454 recommends filtering routes received from customers and peers, setting maximum-prefix protections, and constraining outbound advertisements.[5] No single filter would necessarily describe every legitimate transit relationship of a network as large as China Telecom, but the principle is clear: neighbors should not automatically accept an implausible jump from dozens of normal originations to tens of thousands of foreign prefixes. Volume anomalies can be a safety signal even when route registries are incomplete.
The political controversy outpaced what public routing evidence could prove
The 2010 event later became entangled in claims that China Telecom had redirected a fixed percentage of the entire Internet or intentionally intercepted sensitive traffic. Public measurement supports a major routing anomaly and shows that some traffic paths changed, but it does not establish a universal traffic percentage or motive. Good failure history should preserve that uncertainty. The engineering lesson is strong without speculation: a large provider propagated abnormal reachability information far enough that independent networks accepted it.
Why the 2010 China Telecom leak belongs in software-failure history
The China Telecom event belongs in software history because it demonstrates how ambiguous a global routing failure can be. Tens of thousands of prefixes appeared with unexpected origins, some routes propagated widely, and some traffic took surprising detours, yet the available public data does not justify every dramatic claim made afterward. That ambiguity is itself a lesson. Internet routing needs stronger provenance, better anomaly detection, and more complete measurement so operators can distinguish mistakes, leaks, and attacks quickly. A resilient control plane must not only resist bad routes; it must make bad routes easier to explain.
Works Cited
- 01BGPmon — Chinese ISP Hijacks the Internet bgpmon.net
- 02Hiran, Carlsson, and Gill — Characterizing Large-Scale Routing Anomalies people.cs.umass.edu
- 03Citizen Lab — Case Study of the China Telecom Incident citizenlab.ca
- 04
- 05RFC 7454 — BGP Operations and Security rfc-editor.org
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.