Summary

  • On 25 April 1997, an AS7007 router received roughly 23,000 routes without an inbound prefix boundary and emitted tens of thousands of more-specific routes as if AS7007 originated them.
  • The bad routes spread because neighboring networks accepted and propagated them. More-specific prefixes then beat legitimate aggregates in forwarding, while repeated withdrawals and damping complicated recovery.
  • The durable repair was a separation of roles: routing registries could publish evidence, but operators had to compile filters, define relationship scope and remain accountable for what their routers admitted.

The morning one AS appeared to originate the Internet

At about 11:30 EST on Friday, 25 April 1997, MAI Network Services’ border router in autonomous system 7007 received what its operator later called a nearly full routing view: about 23,000 routes from a downstream customer. There was no inbound distribute list limiting that customer to routes it was expected to announce.

What followed was stranger than a customer simply passing along a table. In MAI’s published apology, the router deaggregated the view and removed the existing AS paths. Another MAI border router saw more than 73,000 entries. To distant networks, many narrower prefixes now appeared to originate at AS7007.

The numbers are not one clean measurement. Avi Freedman reported seeing roughly 60,000 routes in core routers; another contemporaneous figure put the load at 72,000; MAI reported more than 73,000 at its own observer. They describe different views and moments. They should not be averaged into a false global total.

The cause is also unresolved. MAI stressed that no interior routing protocol was running on the AS7007 router and suspected a router defect. Other operators discussed redistribution mistakes, software behavior and configuration knowledge. The surviving record proves the transformation and the missing filter more firmly than it proves why the device performed it.

That distinction matters. The event was accidental, according to the operator, and its exact trigger remains disputed. The system-level failure does not depend on settling blame inside one box. An error crossed several administrative boundaries because those boundaries did not reject a claim that exceeded the relationship.

Why more-specific routes overruled valid aggregates

AS7007 did not erase every legitimate route. It announced narrower alternatives. Internet forwarding gives priority to the longest matching prefix before considering later preferences. If a valid provider advertises an aggregate covering a destination while another path advertises a more-specific piece, packets matching the narrower piece follow it.

This rule is essential. It lets an operator steer parts of an address block, support multihoming and preserve reachability when networks have different topologies. On that Friday, the same rule multiplied the damage. Thousands of bogus more-specifics attracted traffic even while legitimate aggregates remained visible.

BGP’s AS path normally records the sequence through which a route has travelled. MAI said the generated routes had lost their prior paths and appeared with AS7007 as origin. Path-length preferences could not reveal the real source behind the customer session. More important, an AS path is not proof that the origin is authorised to announce the prefix. It is a propagation record supplied by the routing system.

The incident therefore did not reveal a database granting AS7007 title to everyone’s addresses. It revealed routers acting on reachability information that their owners had chosen to accept. The power was distributed, but the safeguards were incomplete.

A local failure became a chain of acceptance

MAI’s timeline says it disabled the affected session at about 11:45, rebooted the router at noon, installed distribute filters and disconnected its equipment at about 12:15. Yet operators continued seeing AS7007 paths arrive through other providers. Removing the original speaker did not instantly remove every copy already circulating.

Contemporaneous accounts describe engineers clearing BGP sessions, installing emergency filters and announcing more-specific routes for their own customers to recover reachability. Route-flap damping added memory to the system. Repeated changes could suppress a path for a period after it had stabilised; manual clearing could be needed where operators had credible evidence that the fault was fixed.

This was not one control room failing to press a global stop button. No such button existed. Each network could reject the routes at its own edge, withdraw its own propagation, contact a neighbor or disconnect a session. Some did so rapidly; others did not.

Curtis Villamizar’s 15 May account supplied a revealing comparison. Some providers had filters in place within 15 to 20 minutes. Some never installed them. He reported that the upstream took more than two and a half hours to block the announcements at source. A single originating error became a variable set of outages because every accepting operator had a different control state.

Turning an apology into filters

MAI accepted one concrete responsibility: it had not bounded the downstream’s inbound advertisements. After the event it imposed full distribute lists on peers. That is a more useful institutional act than pretending the accident could never recur.

Later best-current-practice language made the rule explicit. On a customer BGP session, an operator should accept only the customer’s prefixes and discard the rest, with carefully understood exceptions. Maximum-prefix limits can stop a sudden table explosion. AS-path and bogon filters add other boundaries. Monitoring must compare received routes with the contract and expected topology, not merely confirm that a session remains up.

These controls are local. A provider does not need authority over the customer’s company to refuse an out-of-scope route. It needs a defined service relationship, an accurate prefix set, a tested configuration and someone answerable for exceptions.

That is the narrow legitimacy of routing enforcement. The operator controls its router and bears the external cost if it propagates an implausible claim. The power is real because the configuration executes. Its mandate is bounded because it stops at the operator’s own acceptance and advertisement decisions.

The useful but incomplete routing ledger

The 1997 response also strengthened interest in the distributed Internet Routing Registry. Route and autonomous-system objects could describe which prefixes an AS meant to originate and which policies it meant to apply. Tools could turn those records into router filters.

ANS announced that it would filter using registered route objects across the ANS, CANET, MCI, RIPE and RADB databases. But its audit exposed a serious dependency. It found 2,829 announced prefixes that were neither registered nor covered by an aggregate. Notices reached 312 origin ASes covering 2,108 prefixes; contacts could not be found for 151 origin ASes covering another 721.

After corrections, 2,096 unregistered prefixes from 333 origin ASes remained. Strictly filtering against an incomplete ledger could therefore remove legitimate reachability along with false claims. Refusing to filter left the network exposed. The problem was not solved by calling the registry authoritative.

RPSL later provided a richer language for route, origin and policy objects. RFC 2622 said accurate population could help generate configurations that resist inaccurate routing information. Its wording was disciplined: accuracy could help, and registration procedure was outside the specification.

RFC 2725 strengthened authorization for adding and changing records. It also documented why records went stale: CIDR aggregates replaced old specifics, networks disappeared, and customers changed providers without updating origin data. Authentication could protect a ledger transaction. It could not make the ledger complete or cause a router to use it.

The useful architecture is therefore layered. Address registries support evidence about allocations. Routing-policy repositories record operational intent. Tooling compiles candidate filters. Network operators review and install them. Observers measure actual announcements. None of those layers should impersonate all the others.

From inferred relationships to explicit roles

For decades, leak prevention largely depended on operators configuring the commercial role of each BGP neighbor correctly. A route learned from a provider should not be offered to another provider as if the middle network were transit. A customer should not send arbitrary global routes upstream. These relationships existed in contracts and configurations, but BGP speakers did not necessarily verify that both ends agreed on the role.

RFC 9234 addressed that missing handshake in 2022. BGP Roles allow neighbors to state provider, customer, peer, route-server or route-server-client relationships. The Only-to-Customer attribute carries a propagation boundary so some leaks can be rejected locally or detected farther away.

This is a strikingly late answer to the lesson of 1997. It does not mean every network has deployed the feature, and it does not catch every false origin or policy failure. It does show the direction of travel: trust becomes safer when its scope is explicit in the protocol and testable at the point of execution.

AS7007’s historical importance lies here. The Internet did not require a global official to approve every route. It required each participant to stop treating an open session as unlimited authority. Distributed operation works only when local freedom includes local responsibility.

Sources and evidence limits

The timed incident account comes from MAI Network Services’ explanation and apology. Avi Freedman’s same-day operational account supplies an outside view, while Curtis Villamizar’s ANS filtering notice documents the immediate registry response and its missing records.

The forwarding mechanism is grounded in RFC 1812, damping in RFC 2439, policy description in RFC 2622, repository authorization in RFC 2725, filtering practice in RFC 7454, and later relationship signalling in RFC 9234.

No complete global impact denominator survives. Device cause, route totals and recovery time vary by observer. The evidence supports a widespread accidental leak, an admitted missing filter and a distributed repair; it does not support one exact worldwide outage count or universal adoption of the later safeguards.