 a holiday weekend. No one could be reached on-site until the following Tuesday. For three days, the glo- bal financial institution was unable to access any of its servers in Australia due to (my) human error. I like to chalk events like this up to "experience." A neat way to prevent this sort of disaster is with the reload command. With this command, you can make a router reboot in a set amount of time. Because the configuration that caused the router to become unavailable will not have been saved, having the router reboot automatically will bring the router back to life. To reboot the router in 15 minutes, issue the reload in command, as shown here: TS-1# reload in 15 Reload scheduled in 15 minutes Proceed with reload? [confirm] Alternatively, you can specify a specific time at which to reload the router with the reload at command: TS-1# reload at 12:05 July 10 Reload scheduled for 12:05:00 UTC Mon Jul 10 2006 (in 566 hours and 33 minutes) Proceed with reload? [confirm] Be warned that if you've already started to make your changes, the router will prompt you to save them before you reload. Remember to cancel the reboot when you've successfully made your change! To cancel an impeding scheduled reload, execute the reload cancel command: TS-1# reload cancel TS-1# SHUTDOWN ABORTED Multiple Component Failure Many networks are designed to avoid single points of failure. What usually brings these networks down is multiple component failure. Multiple component failure can be triggered by a root cause such as dirty or unreliable power, or it can just be a fluke. One device can also sometimes cause failures in other devices. Sun servers used to be programmed to halt when a break character was sent to them. Many people used Cisco routers as terminal servers that allowed remote connections to the consoles of these servers. One of the issues that was discovered with this com- bination was that when the Cisco routers were powered off and on, break signals were sent out all of the serial lines connecting the Sun consoles. So,