Catalyst 1300 syslog date/time

[clape]

So I might have found a bug with the c1300 4.1.0.76 firmware, but I wanted to get yalls opinion before I report a bug.

Heres the issue:

I am sending syslogs to rsyslog so that they can be ingested into grafana loki via promtail, but the messages are getting rejected at rsyslog because of the timestamp on the syslog message. The time stamp on the syslog message is WAY off!

sh clock: 12:58:37 May 29 2024

terminal logging timestamp: 29-May-2024 12:58:30 (sh clock was run right after this log message)

Here is where it get crazy

syslog timestamp: 2160-07-05T19:26:46-4:00 (this syslog output is with the origin-id set to ip,(same result with host), this is the only way to get a timestamp on the syslog message)

I cannot find this value anywhere! I have triple checked all of the clock setting (pretty sure), I generated diag. tech-support info, and cannot find that date anywhere. I have even run it through wireshark and looked through the hex/dec to try and find where that date/time is coming from, no joy.

Does anyone have any thoughts of a possible fix action or any other locations where I might be able to see where that date is coming from? I'm really starting to dislike this c1300. lol

tech-support info will be coming (on air gapped network) soon. 

Thanks

Charlie

[balaji.bandi]

the one you show on the syslog server when the receive message from the device.

what you see on the device when you issue show logging.

[clape]

logging enabled

origin_id: ip

console/buffer/file logging level info

AAA enabled, file sys copy - enabled, file sys delete-rename - enabled, mngt acl deny - enabled

aggregation - disabled

logging cbd level informational

logging cbd module: all

All of the log messages under "show logging" have the correct date/time bases on the clock of the switch.

also I see in the logs where the system clock is updated by ntp

Charlie

[balaji.bandi]

other opensource claims cisco do not use standards - so they need mimic the logs. (but not that difference you show your log)

what Log Server you sending to ? ask them to normalize the logs when they receive from device.

example :

https://community.graylog.org/t/timestamp-vs-timestamp/26728/5

[MHM Cisco World]

https://www.cisco.com/c/en/us/td/docs/routers/access/wireless/software/guide/SysMsgLogging.html

I see this issue maybe two months ago but I dont remember the solution'

But sure the solution is using 

One of thesr command 

service sequence-numbers, service timestamps log datetime, service timestamps log datetime [localtime] [msec] [show-timezone], or service timestamps log uptime 

MHM

[MHM Cisco World]

https://community.cisco.com/t5/network-management/time-stamps-wrong-in-log/td-p/777236

This what I found it not what I was looking for but it same issue as your

Goodluck friend 

MHM

[robo764]

I know this is almost a year old, but I'm hoping you were able to find a solution to this issue.  I'm seeing the same thing, with the same offset (approximately 136 years and 1 month) Aside from the huge discrepancy with the date, it's also 6.5 hours off.  
show clock: 10:55:43 EDT Apr 21 2025
Local buffer: 21-Apr-2025 10:55:57
Syslog timestamp for the above entry: 5/28/2161, 5:24:13 PM.000

[Jens Albrecht]

Looking at the huge delta this appears to be the result of an arithmetic overflow of a 32-bit value.

If I convert the current time to unix time I get a value of 1745251038.
Adding 2**32 to this value results in a value of 6.040.218.334.
Converting this back from unix time gives a date of 28-May-2161 22:25:34 which is exactly the delta that you and Clape reported.

In order to find out where this conversion error occurs I would use Wireshark at your syslog server to check the incoming packets.

If Wireshark does not display the year, then you have probably not set the "service timestamps log <parameters>" command to include this information.
In this case check again after setting e.g. "service timestamps log datetime localtime show-timezone year msec".

HTH!