rability of a single point of failure. The first, of course, is to distribute the routing function. This conflicts with the concept of centralized routing, but only somewhat. Consider the Internet, for example. It uses a sort of hybrid of centralized and distributed routing protocols in its Domain Name Server (DNS) function. A limited number of devices are tasked with the responsibility of maintaining knowledge of the topology of the network and the location of domains, providing something of a AAA trip-planning service for data packets. Another option is to designate a backup machine tasked with the responsibility of taking over in the event of a failure of the primary rout- ing machine. This technique, used in the early Tymnet packet networks, relied on the ability of the primary machine to send a "sleeping pill packet" to the backup machine, with these instructions: "Pay attention to what I do, memorize everything I learn, but just sit in the corner and be a potted plant. Take no action, make no routing decisions-just learn. Let the sleeping pill keep you in a semicomatose state. If for some reason I fail, I will stop sending the sleeping pills, at which time you will wake up and take over until I recover." An ingenious technique, but overly com- plex and far too failure prone for modern network administrators. Dis- tributed routing protocols are far more common today. In distributed routing protocol environments, each device collects information about the topology of the network and makes independent routing decisions based upon the information it accumulates. For exam- ple, if a router sees a packet from source X arrive on port 12, it knows that somewhere out port 12, it will find destination X. It doesn't know how far out there necessarily, just that the destination is somewhere out there over the digital horizon. Thus, if a packet arrives on another port looking to be transmitted to X, the router knows that by sending the packet out port 12 it will at least get closer to its destination. It therefore makes