Time is critical in networking—not just for log accuracy, but for protocols like NTP, logging, and debugging. The Cisco IOS clock and calendar system is the foundation for all time-sensitive operations on your router or switch. For the CCNA 200-301 exam (objective 4.4), you need to understand how to set, verify, and synchronize the system clock, including the difference between the software clock and hardware calendar. Misunderstanding these basics can lead to incorrect timestamps in logs, failed NTP synchronization, and even security certificate validation errors.
Jump to a section
Imagine you're the manager of a large office building. You have two timekeeping devices: a wall clock in the lobby that everyone looks at (the system clock, or software clock), and a high-quality wristwatch you wear (the hardware calendar). The wall clock is easy to read and can be adjusted quickly, but it's not very accurate—it might drift by several seconds a day. The wristwatch is much more precise and keeps time even when the power goes out (battery backup).
When you arrive in the morning, you check your wristwatch and set the wall clock to match it. That's like using the clock read-calendar command to copy the hardware calendar time to the system clock. If you notice the wall clock is wrong later, you might adjust it directly (like clock set). But if you want the most accurate time, you call the National Institute of Standards and Technology (NIST) time service—that's your NTP server. You then set both your wristwatch and wall clock to match NIST's time. This is like configuring NTP to synchronize both the system clock and the hardware calendar.
The key point: the wall clock (system clock) is used by all software processes—logging, debugging, routing protocols. The wristwatch (hardware calendar) keeps time when the router is off, so when it boots, the system clock can be initialized from the calendar. If you only set one, you'll have problems. For example, if you set the system clock but forget the calendar, after a reboot the clock will be wrong until you manually fix it or NTP kicks in.
What Are the Cisco IOS Clock and Calendar?
Cisco IOS devices maintain two separate timekeeping mechanisms: the system clock (software-based) and the hardware calendar (hardware-based). The system clock is used by the IOS for all time-stamped events—logging messages, debug output, timestamps in show commands, and for protocols like NTP, EIGRP, and OSPF (which use timestamps for route aging and authentication). The hardware calendar is a battery-backed real-time clock (RTC) on the device's motherboard. It keeps running even when the router is powered off, maintaining time across reboots.
How They Interact
When a Cisco device boots, the system clock is initially set to a default time (often 00:00:00 UTC on March 1, 1993—the birth of the commercial Internet). Then, the system clock can read the hardware calendar using the clock read-calendar command, or it can be set manually with clock set. Alternatively, if NTP is configured, the system clock synchronizes to an NTP server, and optionally the hardware calendar can be updated from the system clock with clock update-calendar.
Default Behavior
By default, the system clock does NOT read the hardware calendar at boot. You must explicitly configure clock calendar-valid (deprecated) or use ntp update-calendar to sync the calendar.
The system clock uses Coordinated Universal Time (UTC) by default. You can set the time zone and daylight saving time with clock timezone and clock summer-time.
NTP is the recommended way to maintain accurate time. If NTP is configured, the system clock is synchronized periodically (default poll interval is 64 seconds, but can be adjusted).
Key Commands and Verification
Setting the system clock manually:
Router# clock set 14:30:00 15 March 2025This sets the system clock to 2:30 PM UTC on March 15, 2025. Note: you must be in privileged EXEC mode.
Reading the hardware calendar to the system clock:
Router# clock read-calendarThis copies the hardware calendar time to the system clock. Useful if you know the calendar is accurate (e.g., it was set by NTP previously).
Updating the hardware calendar from the system clock:
Router# clock update-calendarThis copies the system clock time to the hardware calendar. Use after setting the clock manually or after NTP sync.
Setting the time zone:
Router(config)# clock timezone EST -5
Router(config)# clock summer-time EDT recurringThis sets the time zone to Eastern Standard Time (UTC-5) and enables automatic daylight saving adjustment.
Verifying the clock and calendar:
Router# show clock
*14:31:00.123 UTC Mon Mar 15 2025The asterisk (*) indicates the system clock is not synchronized to an authoritative time source (like NTP). If NTP is synced, you'll see a '.' (period) instead.
Router# show calendar
14:31:05 UTC Mon Mar 15 2025Displays the hardware calendar time.
Interaction with NTP
NTP (Network Time Protocol) is the primary method for keeping accurate time. When NTP is configured, the system clock synchronizes to an NTP server. The NTP process can also update the hardware calendar if you configure ntp update-calendar. This is critical: without this command, the hardware calendar may drift even if the system clock is accurate via NTP. After a reboot, the system clock will read the calendar (if you have clock read-calendar in startup config or manually issued), but if the calendar was never updated, the time will be wrong.
Exam-Relevant Details
The system clock and hardware calendar are independent. Changing one does not automatically change the other.
The show clock command shows the system clock; show calendar shows the hardware calendar.
The asterisk (*) next to the time in show clock means the clock is not synchronized. A period (.) means it is synchronized via NTP.
The clock timezone command is configured globally; it affects the display of time in logs and commands.
The clock summer-time command configures automatic daylight saving adjustments.
To make time settings persistent across reboots, you must either use NTP or ensure the hardware calendar is correct and the system clock reads it at boot (via startup config or manual intervention).
Check Current Time Settings
First, verify the current system clock and hardware calendar. Use `show clock` to see the system clock and `show calendar` to see the hardware calendar. Note whether the system clock shows an asterisk (not synchronized) or a period (synchronized). Also check the time zone setting with `show running-config | include clock`. This baseline helps you understand what needs adjustment.
Set Time Zone and Summer Time
Configure the correct time zone and daylight saving rules. Enter global configuration mode and use `clock timezone CST -6` for Central Standard Time (UTC-6). Then `clock summer-time CDT recurring` to enable automatic DST adjustment. The `recurring` keyword uses US rules (spring forward on second Sunday of March, fall back on first Sunday of November). You can specify custom dates if needed.
Manually Set System Clock (If No NTP)
If NTP is not available, set the system clock manually using `clock set HH:MM:SS DAY MONTH YEAR`. For example: `clock set 10:30:00 20 March 2025`. You must be in privileged EXEC mode. The time is in 24-hour format. After setting, verify with `show clock`. Note that this setting is lost on reboot unless you also update the hardware calendar.
Update Hardware Calendar
To make the time persist across reboots, copy the system clock to the hardware calendar with `clock update-calendar`. Then verify with `show calendar`. The hardware calendar is battery-backed and retains time when the device is off. If you later use NTP, the system clock will be accurate, but the calendar may drift. To keep the calendar updated, configure `ntp update-calendar` in global config.
Configure NTP (If Available)
For accurate and automatic time synchronization, configure NTP. Use `ntp server <ip-address>` (e.g., `ntp server 192.0.2.1`). Optionally add `ntp update-calendar` to sync the hardware calendar. Verify with `show ntp status` and `show ntp associations`. The system clock will now show a period (.) instead of an asterisk, indicating synchronization.
Verify and Troubleshoot
Use `show clock detail` to see the time source (e.g., NTP, user configuration). Use `debug ntp events` (with caution) to see synchronization events. If the clock shows the wrong time, check NTP reachability, time zone configuration, and whether the calendar was updated. Common issues: wrong time zone, calendar not updated, NTP server unreachable.
In enterprise networks, accurate time is not just a nice-to-have—it's a security and operational necessity. Consider a network of 500 routers and switches. Security logs from all devices are sent to a SIEM system. If the clocks are off by even a few seconds, correlating events across devices becomes impossible. An attacker's actions might appear out of order or be missed entirely.
Scenario 1: Log Correlation
A network engineer sets up syslog servers to collect logs from all devices. They configure NTP on all devices to synchronize to internal NTP servers. They also add ntp update-calendar on each device so that after a power outage, the hardware calendar has the correct time. Without this, after a reboot, the system clock would read the old calendar time, and logs would show timestamps from the past until NTP re-syncs (which could take minutes). This misconfiguration leads to confusion during incident response.
Scenario 2: Certificate Validation
Modern network devices use certificates for HTTPS management, 802.1X authentication, and VPNs. Certificates have validity periods. If the device clock is wrong, certificates may appear expired or not yet valid. For example, a switch with a clock set to 2010 will reject a certificate issued in 2025. Engineers must ensure NTP is working correctly before enabling certificate-based authentication. They often use show clock and show ntp status during initial setup to verify.
Scenario 3: Routing Protocol Authentication
OSPF and EIGRP can use MD5 authentication with time-based key chains. If the clocks on neighboring routers are not synchronized, authentication may fail, causing adjacencies to drop. Engineers configure NTP on all routers and use the same time zone to avoid issues. They also set clock timezone consistently across the network.
Common Scale Considerations:
- For large networks, use a hierarchy of NTP servers: stratum 1 servers (GPS-based) at the core, stratum 2 servers at distribution, and clients at access.
- Use ntp access-group to restrict which devices can query your NTP servers.
- Monitor NTP synchronization with SNMP or logging.
Misconfiguration Consequences:
- Forgetting ntp update-calendar leads to time errors after reboot.
- Wrong time zone causes logs to show incorrect local times, confusing troubleshooting.
- Not setting summer time results in one hour offset during DST periods.
The CCNA 200-301 exam objective 4.4 specifically covers "Configure and verify Cisco IOS clock and calendar." Expect questions that test your understanding of the difference between the system clock and hardware calendar, how to set them, and how NTP interacts with them.
Most Common Wrong Answers:
1. "The `clock set` command also updates the hardware calendar." Wrong! clock set only sets the system clock. You must explicitly use clock update-calendar to copy to the hardware calendar. Candidates assume the two are linked, but they are independent.
2. "After configuring NTP, the hardware calendar is automatically updated." Wrong! By default, NTP only updates the system clock. You need the ntp update-calendar command to sync the hardware calendar. Many candidates miss this.
3. "The `show clock` command shows the hardware calendar time." Wrong! show clock shows the system clock. show calendar shows the hardware calendar. Confusing these is a common trap.
4. "The asterisk in `show clock` means the clock is synchronized." Wrong! The asterisk means NOT synchronized. A period (.) means synchronized via NTP. Candidates often misremember the symbol.
Specific Values and Commands:
- The default time on a Cisco device at boot is 00:00:00 UTC on March 1, 1993.
- clock timezone command format: clock timezone <name> <offset> where offset is hours from UTC (e.g., -5 for EST).
- clock summer-time command: clock summer-time <name> recurring or with specific dates.
- ntp update-calendar is a global configuration command.
- clock read-calendar is an EXEC command, not a config command.
Decision Rule for Scenario Questions:
If a question asks how to ensure the correct time is maintained across reboots without NTP, the answer is: set the system clock with clock set, then clock update-calendar to save to hardware calendar, and optionally include clock read-calendar in startup config (though this is rarely needed as the system clock reads calendar at boot if configured via clock calendar-valid which is deprecated). The key is to update the calendar. If NTP is available, the best answer is to configure NTP and use ntp update-calendar.
Elimination Strategy:
- If an answer suggests clock set alone for persistence, eliminate it.
- If an answer suggests NTP alone without ntp update-calendar for calendar persistence, eliminate it.
- If an answer confuses show clock with show calendar, eliminate it.
Cisco IOS has two time sources: system clock (software) and hardware calendar (battery-backed).
Use `show clock` for system clock; `show calendar` for hardware calendar.
An asterisk (*) in `show clock` means not synchronized; a period (.) means synchronized via NTP.
`clock set` only sets the system clock; use `clock update-calendar` to copy to hardware calendar.
NTP updates the system clock; add `ntp update-calendar` to also update the hardware calendar.
Configure time zone with `clock timezone` and daylight saving with `clock summer-time`.
The default boot time is 00:00:00 UTC on March 1, 1993.
These come up on the exam all the time. Here's how to tell them apart.
System Clock
Software-based, maintained by IOS.
Used by all time-stamped processes (logs, debug, protocols).
Lost on reboot unless saved to calendar or NTP re-syncs.
Set via `clock set` or NTP.
Viewed with `show clock`.
Hardware Calendar
Hardware-based, battery-backed RTC.
Not directly used by IOS processes.
Retains time across reboots.
Set via `clock update-calendar` from system clock.
Viewed with `show calendar`.
Mistake
The `clock set` command updates both the system clock and the hardware calendar.
Correct
`clock set` only updates the system clock. To update the hardware calendar, you must explicitly use `clock update-calendar`.
Candidates assume a single command updates both, but they are independent.
Mistake
Configuring NTP automatically updates the hardware calendar.
Correct
NTP only synchronizes the system clock. To update the hardware calendar, you must add the `ntp update-calendar` command.
Candidates think NTP handles everything, but the calendar is separate.
Mistake
`show clock` displays the hardware calendar time.
Correct
`show clock` displays the system clock. Use `show calendar` for the hardware calendar.
The command name 'clock' is ambiguous; candidates confuse the two.
Mistake
An asterisk (*) in `show clock` indicates the clock is synchronized via NTP.
Correct
An asterisk means the clock is NOT synchronized. A period (.) indicates synchronization via NTP.
Candidates misremember the symbols; asterisk is often associated with 'active' in other contexts.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The system clock is a software clock used by IOS for timestamps, logging, and protocols. It is volatile and resets on reboot unless saved. The hardware calendar is a battery-backed real-time clock that maintains time even when the device is off. The system clock can read from or write to the calendar using `clock read-calendar` and `clock update-calendar`.
Set the system clock with `clock set`, then copy it to the hardware calendar with `clock update-calendar`. On subsequent reboots, the system clock will read the calendar if you have `clock calendar-valid` (deprecated) or you can manually issue `clock read-calendar`. For exam purposes, remember that `clock update-calendar` is the key to persistence.
The asterisk (*) means the system clock is not synchronized to any authoritative time source. If you see a period (.) instead, the clock is synchronized via NTP. If no symbol, the clock is not set or is using the default time.
Add the global configuration command `ntp update-calendar`. This tells NTP to copy the synchronized system clock time to the hardware calendar periodically. Without it, only the system clock is updated.
The default system clock time is 00:00:00 UTC on March 1, 1993. This is the date the Internet was commercially launched. The hardware calendar may have a different time if it was set previously.
Use the global configuration command `clock timezone <name> <offset>` where offset is the number of hours from UTC (e.g., -5 for EST). Then optionally use `clock summer-time <name> recurring` to enable automatic daylight saving adjustment.
No, `clock set` is a privileged EXEC command, not a configuration command. You must be in enable mode to use it. For example: `Router# clock set 10:00:00 20 March 2025`.
You've just covered Cisco IOS Clock and Calendar — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?