{"UUID":"0df4b886-70fc-4365-a7a3-1d93f4936dd0","URL":"https://datatracker.ietf.org/doc/html/rfc789.html","ArchiveURL":"","Title":"ARPANET network-wide outage of October 1980","StartTime":"1980-10-27T00:00:00Z","EndTime":"0001-01-01T00:00:00Z","Categories":null,"Keywords":["arpanet","imp","routing","network outage","hardware","checksum","sequence numbers","control protocols"],"Company":"ARPANET","Product":"ARPANET IMP routing","SourcePublishedAt":"0001-01-01T00:00:00Z","SourceFetchedAt":"2026-05-04T17:45:09.678649Z","Summary":"A malfunctioning IMP ([Interface Message Processor](https://en.wikipedia.org/wiki/Interface_Message_Processor)) corrupted routing data, software recomputed checksums propagating bad data with good checksums, incorrect sequence numbers caused buffers to fill, full buffers caused loss of keepalive packets and nodes took themselves off the network. From 1980.","Description":"On October 27, 1980, the ARPANET experienced a network-wide outage lasting several hours. During this period, most Interface Message Processors (IMPs) were unable to communicate reliably, resulting in \"net trouble\" error messages for users and broken existing connections. The problem appeared to affect virtually every IMP across the country, making the network unusable.\n\nThe core issue was that IMPs were unable to maintain their line up/down protocols, indicating severe resource contention. Examination of core dumps revealed that most, if not all, IMP buffers were filled with routing updates awaiting processing. All these updates originated from a single IMP, IMP 50, which had been malfunctioning and was off the network during the outage.\n\nA \"freakish hardware malfunction\" in IMP 50, possibly exacerbated by issues in neighboring IMP 29, caused IMP 50 to retransmit a routing update (sequence number 44) with corrupted sequence numbers (40 and 8) due to bit-dropping. The ARPANET's routing protocol, specifically its definition of \"LATER\" for sequence numbers, allowed these three sequence numbers (8, 40, 44) to form a cycle where each was considered more recent than another. This led to the updates circulating indefinitely, consuming excessive CPU and buffer resources in all IMPs.\n\nThe system's checksumming mechanism for routing updates was insufficient. While update packets were checksummed, retransmitted updates were recreated from tabled information, which was not frequently checksummed, allowing corrupted data to persist. Existing parity checking hardware was often disabled due to spurious errors and its tendency to halt IMPs, requiring manual intervention.\n\nTo restore service, a patch was broadcast to all IMPs, instructing them to disregard updates from the malfunctioning IMP 50. This procedure, though time-consuming due to the network's degraded state, successfully brought the network back online. A long-term fix involved modifying the routing algorithm's \"LATER\" definition to prevent such sequence number cycles. Future IMP hardware was also designed with improved error detection and correction capabilities."}