cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1502
Views
4
Helpful
12
Replies

Cannot set hardware clock/hardware clock does not retain time

btang
Level 1
Level 1

Hello,

I'm having an issue with some switches where the hardware clock either does not set at all, or does not retain the set time after reload. 

This issue is present on two switches:

  • C1000-8P-2G-L, IOS 15.2(2)E7
  • WS-C2960X-48FPD-L, IOS 15.2(2)E7

On the 1000 the hardware clock does not set, period:

 

Spoiler

Switch#sh cal

06:22:45 CDT Sat Apr 20 1946
Switch#cal set 09:15:00 August 1 2023
Switch#sh cal

06:22:45 CDT Sat Apr 20 1946
Switch#conf t
Switch(config)#clo cal
Switch(config)#^Z
Switch#clo rea
Mar 1 00:00:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 09:16:03 CDT Tue Aug 1 2023 to 18:00:00 CST Sun Feb 28 1993, configured from console by [username] on console.
Switch#clo set 09:15:00 August 1 2023
Aug 1 14:15:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 18:00:00 CST Sun Feb 28 1993 to 09:15:00 CDT Tue Aug 1 2023, configured from console by [username] on console.
Switch#sh clo det
09:15:00.000 CDT Tue Aug 1 2023
Time source is hardware calendar
Summer time starts 02:00:00 CST Sun Mar 12 2023
Summer time ends 02:00:00 CDT Sun Nov 5 2023

Switch#clo upd
Switch#sh cal

06:22:45 CDT Sat Apr 20 1946

 

On the 2960-X the calendar set command takes effect and the software clock can be read/updated from there, but then if the switch is reloaded it loses the time. As mentioned, on the 1000 it just never sets at all.

I've tried downgrading/upgrading IOS, downgrading/upgrading ucode/bootloader, clean install (format flash) IOS, but it doesn't fix the issue. I didn't try NTP sync as suggested because these are not connected to the internet/assigned IP (in closed lab environment), but I assume it would not fix anything, if the hardware clock cannot even be set in the first place!

Perhaps it's a hardware failure but if it is the issue doesn't seem to be well-documented. It also doesn't work on most IOS-based switches that I've seen (various 2960-X/-CX/-L), probably about 1 in 10 will actually have the command work, and have it stick on reload.

Maybe I am fundamentally misunderstanding the purpose/functionality of the hardware clock but I'm just very confused as to what's going on. 

Any assistance is appreciated, thank you!

3 Accepted Solutions

Accepted Solutions

Hi @btang 

As per your description and looking the Cisco doc for Calendar, I assume that this devices you have does not have battery to hold time configuration.

 Cisco refers to some devices contain, which means not all.  For those with no battery the solution would be external time source. 

"Hardware Clock

Some devices contain a battery-powered hardware clock that tracks the date and time across system restarts and power outages. The hardware clock is always used to initialize the software clock when the system is restarted."

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/bsm/configuration/15-2mt/bsm-time-calendar-set.html

 

View solution in original post

"Probably the best solution here is just to not reload the switches or just manually set the soft clock after reset."

 I think so.

Have a great day yourself.

View solution in original post

Then in that case, likely hardware just doesn't have what it needs.

Again, I mention, in the past, it seemed the more expensive Cisco network equipment supported this, and less expensive equipment did not.

However, for this century's equipment, and as "same capability" hardware, over time, decreases in price, one could wonder why newer/current Cisco network equipment doesn't support this.

Only Cisco could answer that, but I wonder, if the thinking is, with Internet connectivity the "norm" and/or the capability to easily obtain a clock signal from GPS, who really "needs" such a feature, a booting system can likely have an accurate clock/calendar shortly after booting, or perhaps even while booting.

In ancient times, like last century, I remember many stand alone computer systems didn't have networks, and those that did, were a far cry from what we have today, for example, their WAN might only be dedicated p2p links with other same business sites.  I.e. they did not acquire the current time/data automatically, you had to manually enter such when the system booted (such a PIA).  Then, embedded battery powered calendars started to become the norm, and then the only problem was how such clocks would "drift" (see my earlier reply's "aside" comment) but if the system was within a minute or two of the correct time, you might only bother correcting it, twice a year, when and if you manually adjusted for daylight savings time (yea, once upon a time, that wasn't automatic, either [or leap years, or . . . -laugh).

All I can end is by saying - this wasn't a problem when using card punch machines, and if they were good enough for Herman (Hollerith), by cracky, you might not have this issue today!  ; )

View solution in original post

12 Replies 12

Hi @btang 

As per your description and looking the Cisco doc for Calendar, I assume that this devices you have does not have battery to hold time configuration.

 Cisco refers to some devices contain, which means not all.  For those with no battery the solution would be external time source. 

"Hardware Clock

Some devices contain a battery-powered hardware clock that tracks the date and time across system restarts and power outages. The hardware clock is always used to initialize the software clock when the system is restarted."

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/bsm/configuration/15-2mt/bsm-time-calendar-set.html

 

I appreciate your response and clarification!

It is weird how I have a WS-C2960X-48LPS-L that retains hardware clock information even after unplugging it (whereas a 2960X-48FPD-L with a more recent mfg date does not), it just seems completely random. 

Probably the best solution here is just to not reload the switches or just manually set the soft clock after reset. 

Thanks again, have a great rest of your day.

"Probably the best solution here is just to not reload the switches or just manually set the soft clock after reset."

 I think so.

Have a great day yourself.

Each SW have  Battery' if not how it can safe firmware.

But for clock what you need excatly?

Thank you for your response!

To answer your question, I want to have the date/time I set while the switch is running persist through reloads, and also if I unplug the switch. 

  1. Switch 1: C1000-8P-2G-L, I cannot even set the hardware clock while the switch is on, the calendar set command just does nothing.
  2. Switch 2: WS-C2960X-48FPD-L V07, I can set the hardware clock while the switch is on with the calendar set command, but after reloading the switch or unplugging it the date/time is lost.
  3. Switch 3: WS-C2960X-48LPS-L V05, I can set the hardware clock while the switch is on with the calendar set command, and the set date/time is retained even after the switch is reloaded or unplugged.

I want to replicate the behavior of switch 3 (hardware clock can be set, and retains set date/time even if the switch is reloaded or unplugged) on switch 1 and 2.

Does that make sense? Let me know if I can clarify something. 

Thanks!

clock read-calendar <<- use this after reload 

Hi, thanks for the suggestion. Unfortunately, that did not work, as the hardware clock (calendar) itself loses the date/time assignment on reload.

BTW, with your software clock set to the correct time, you've also tried the command "clock update-calendar"?

Thanks for the suggestion, I have tried that, unfortunately it does not work:

  1. On 1000 the command doesn't do anything, it doesn't update the calendar at all.
  2. On 2960X the command takes effect and updates the calendar, but that calendar time is lost after reload.

Then in that case, likely hardware just doesn't have what it needs.

Again, I mention, in the past, it seemed the more expensive Cisco network equipment supported this, and less expensive equipment did not.

However, for this century's equipment, and as "same capability" hardware, over time, decreases in price, one could wonder why newer/current Cisco network equipment doesn't support this.

Only Cisco could answer that, but I wonder, if the thinking is, with Internet connectivity the "norm" and/or the capability to easily obtain a clock signal from GPS, who really "needs" such a feature, a booting system can likely have an accurate clock/calendar shortly after booting, or perhaps even while booting.

In ancient times, like last century, I remember many stand alone computer systems didn't have networks, and those that did, were a far cry from what we have today, for example, their WAN might only be dedicated p2p links with other same business sites.  I.e. they did not acquire the current time/data automatically, you had to manually enter such when the system booted (such a PIA).  Then, embedded battery powered calendars started to become the norm, and then the only problem was how such clocks would "drift" (see my earlier reply's "aside" comment) but if the system was within a minute or two of the correct time, you might only bother correcting it, twice a year, when and if you manually adjusted for daylight savings time (yea, once upon a time, that wasn't automatic, either [or leap years, or . . . -laugh).

All I can end is by saying - this wasn't a problem when using card punch machines, and if they were good enough for Herman (Hollerith), by cracky, you might not have this issue today!  ; )

Don't know state of all of Cisco's recent/current hardware, but it used to be some Cisco devices had a battery powered calendar/clock, and some did not.  (I recall, the "more expensive", higher end devices used to more likely to have the battery powered calendar/clock.)

I recall (?) that NTP can update the clock on a booting system pretty quickly, but until it does, without the battery powered version, devices boot with the "default" date/time.

I also recall (?) when you had a battery powered calendar/clock, when using NTP, it was good to specifically configure it to sync up with NTP (ntp update-calendar).  Otherwise, overtime (pun not intended), the calendar/clock would drift from running/system clock, resulting in, during a reload, the system time might be off by a few minutes until NTP resynced the running/system clock.

As an aside, I've always been surprised by how most computer based system "clocks" don't keep accurate time.  This because they rely upon their own "clock" for counting time (much as a wrist watch does), but even without NTP or GPS, I've understood (incorrectly?) that, generally, when public electric utilities generate an AC signal of so many cycles per second, they mean it.  (Ever notice how well your cheap electric clock keeps accurate time?)  Since lots of computer based devices use AC, always wondered why they also didn't keep accurate/consistent time like an electric clock (counting the AC's cycles per second).

Leo Laohoo
Hall of Fame
Hall of Fame

Anyone can build a Stratum-1 NTP server cheaply.  

The Raspberry Pi as a Stratum-1 NTP Server

Review Cisco Networking for a $25 gift card