by having all the other devices on the network get accurate time from my core switches. This meant that only the core switches needed to take up Internet bandwidth with NTP requests, instead of potentially hundreds of other devices. One day, the time source stopped responding to our requests. However, we never knew of the failure. The core switches (6509s) were still acting as NTP servers, SO everyone appeared to have accurate time. In this case, the devices were all close in time to each other, but not to the real time (Coordinated Universal Time, or UTC). Still, the difference between UTC and the time being reported was minor-perhaps a minute different over the course of a few months. Lesson #1: Always have more than one time source. Not only will NTP failover to another source in the event of a failure, but it will choose the most accurate one available. A minimum of three NTP servers should be configured for core devices. At some point, we needed to reboot the core switches for some maintenance. The next day was a disaster. Somehow, every device in the network-including all servers and workstations-had decided that it was a day earlier than it actually was. Lesson #2: Some Cisco devices have a clock and a calendar. The clock keeps time for the current running session. When the device reboots without an NTP source, it will learn its time from the calendar. Always configure devices that contain calendars to update the calendars auto- matically from NTP. When the core switches rebooted, they loaded time from their internal calendars, and used that time to set their clocks. Because I hadn't configured the calendars, they defaulted to the wrong date and time. When NTP initialized, it would have fixed the time had it been able to establish connectivity with an accurate clock. However, it couldn't. Because every device in the company derived its time from the core switches, they all lost a day. This became a problem when programs that duplicated data to backup servers determined that the last save was invalid, as th