CCNA 200-301 Command Reference: service timestamps

The service timestamps command has quite a few important options, all of which we’re going to go over here in video and text to make sure you’re ready for CCNA 200-301 exam success.   I also cover an unusual “gotcha” with this command that the Cisco IOS does not explain.

Here’s a video from my CCNA YouTube Channel showing you all of these options.  Have a look before or after you take in all the info below the video on this important command!

Let’s have a look at the default settings for the timestamps service — and yes, there are more than one!     You’ll find the timestamps settings at the very top of the config, even above hostname.    By default, both the timestamps for debugs and the log are on, as verified by this just-initialized Cisco router.  The only commands I’ve put on this device at this point are hostname, ip domain lookup, logging synchronous, and exec-timeout 0 0 .  (Those links go to other CCNA Command References here on the site.)  The msec option is also enabled on both timestamps services.

R2#show run
Building configuration...

Current configuration : 1359 bytes
!
! Last configuration change at 14:30:16 UTC Sat Feb 13 2021
!
version 15.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R2

Let’s have a look at the console message format at this point.

Feb 13 10:31:09.019: %SYS-5-CONFIG_I: Configured from console by console

In production environments, it’s important to have timestamps enabled as well as having time synched between your various network devices; that makes troubleshooting a whole lot easier.   In contrast, in lab environments you may wish to disable timestamps entirely just to make console messages easier to read.    You could also leave them enabled and fine-tune them a bit.  I personally find the millisecond option annoying in labs, but that may just be me.

Besides, knowing how to change the timestamp service settings is a really good idea for your CCNA studies, so let’s have a look at changing the log timestamps.

R2(config)#service timestamps ?

debug Timestamp debug messages
log Timestamp log messages
<cr>

R2(config)#service timestamps log ?

datetime Timestamp with date and time
uptime Timestamp with system uptime
<cr>

The <cr> in that first IOS Help readout tells us that service timestamps is a legal command all by itself.  That’s interesting…. does it change the log timestamps, the debug timestamps, or something else?  We’ll come back to that.  Right now, let’s focus on the log options.   You can set a date and time or have the log timestamp indicate the uptime of the local device.   Let’s see what our options are with the latter.

R2(config)#service timestamps log uptime ?
<cr>

Surprise!  There are no options with log uptime — you get the uptime and that’s that.  We’ll enable that setting and have a look at the new timestamps format.

R2(config)#service timestamps log uptime
R2(config)#^Z
R2#
00:11:57: %SYS-5-CONFIG_I: Configured from console by console

Since we just enabled uptime  that 00:11:57 is not some funky way of expressing the time — it’s the length of time the router has been up.    Eleven minutes and 57 seconds, to be exact.

We’ll return to the land of seemingly never-ending options when we switch this timestamp back to the datetime format.

R2(config)#service timestamps log datetime ?

localtime Use local time zone for timestamps
msec Include milliseconds in timestamp
show-timezone Add time zone information to timestamp
year Include year in timestamp
<cr>

The <cr> indicates that service timestamps log datetime is a legal command on its own, so let’s see what happens when we enter that command with zero options.

R2(config)#service timestamps log datetime
R2(config)#^Z
Feb 13 10:41:03: %SYS-5-CONFIG_I: Configured from console by console

Want to add the year to that output?   Just add the year option to the end of the command.  You can save yourself some typing and use the up arrow to go through your command history and then just type “year” at the end of the desired command.

R2(config)#service timestamps log datetime year ?

localtime Use local time zone for timestamps
msec Include milliseconds in timestamp
show-timezone Add time zone information to timestamp
<cr>

You can add additional options on the same line, but for now, we’ll just add the year to the timestamp.

R2(config)#service timestamps log datetime year
R2(config)#^Z
R2#
Feb 13 2021 10:43:17: %SYS-5-CONFIG_I: Configured from console by console

Success!  Now, what if we wanted to add all of the remaining options to our timestamp?  No need to enter three additional commands.   Just use your up arrow again and enter all four values.   You MUST enter year again, because you’re overwriting the previous service timestamps log year command.  If you entered only the three remaining options, those are the only three that would be enabled:

R2(config)#service timestamps log datetime localtime msec show-timezone
R2(config)#^Z
R2#
Feb 13 10:44:28.511 UTC: %SYS-5-CONFIG_I: Configured from console by console

The three options are added to the timestamps but the year is no longer there.   Let’s try that same command but with all four options.

R2(config)#service timestamps log datetime localtime msec show-timezone year
R2(config)#^Z
R2#
Feb 13 2021 10:46:22.519 UTC: %SYS-5-CONFIG_I: Configured from console by console

That long-winded command gives us one long-winded timestamp!    Now to get rid of the entire timestamp by simply putting the word no in front of service timestamps log.

R2(config)#no service timestamps log
R2(config)#^Z

%SYS-5-CONFIG_I: Configured from console by console

The log timestamp disappears entirely.  Our current running config now looks like this when it comes to the timestamps.

service timestamps debug datetime msec
no service timestamps log uptime

The debug timestamp and log timestamp are totally separate operations.   Disabling the log timestamp has no effect on the debug timestamp, and vice versa.    The debug timestamp is still on, and here’s what that timestamp looks like right now in the output of debug ip packet.

R2#debug ip packet
IP packet debugging is on
R2#
Feb 13 10:52:40.831: IP: s=10.1.1.2 (local), d=224.0.0.5 (GigabitEthernet0/0), len 76, sending broad/multicast
Feb 13 10:52:40.831: IP: s=10.1.1.2 (local), d=224.0.0.5 (GigabitEthernet0/0), len 76, sending full packet

That’s another timestamp you may want to finetune or disable entirely in a lab environment.    The options for the debug timestamp are the same as the log timestamp.

R2(config)#service timestamp debug ?

datetime Timestamp with date and time
uptime Timestamp with system uptime
<cr>

R2(config)#service timestamp debug datetime ?

localtime Use local time zone for timestamps
msec Include milliseconds in timestamp
show-timezone Add time zone information to timestamp
year Include year in timestamp
<cr>

Let’s disable the debug timestamps and verify the disabling with debug ip packet. We trust, but always verify.

R2(config)#no service timestamps debug

R2#debug ip packet
IP packet debugging is on

IP: s=10.1.1.2 (local), d=224.0.0.5 (GigabitEthernet0/0), len 76, sending broad/multicast
IP: s=10.1.1.2 (local), d=224.0.0.5 (GigabitEthernet0/0), len 76, sending full packet

R2#u all
All possible debugging has been turned off

Success!  The debugs have no timestamp.    And as always, when you’re done with a debug, run that good ol’ u all — short for undebug all, that is — before you move on.

With both timestamps off, we’ll revisit a point I raised earlier.  We saw early on that service timestamps is a legal command by itself — but what exactly does it do?    This is very unlikely to show up on your CCNA or CCNP exam, I admit, but it’s worth knowing for lab and production work.

R2(config)#service timestamps ?
debug Timestamp debug messages
log Timestamp log messages
<cr>

I’ll run the command and then have a look at the running config to see what’s what.

R2(config)#service timestamps
R2(config)#do show run
Building configuration...

Current configuration : 1409 bytes
!
! Last configuration change at 11:00:39 UTC Sat Feb 13 2021
!
version 15.4
service timestamps debug uptime
no service timestamps log uptime

Interesting!  By itself, service timestamps enables the debug timestamp while leaving the log timestamps disabled.   I’ll turn the log timestamp service back on and then we’ll see what happens when we run no service timestamps with both timestamps on.

R2(config)#service timestamps log
R2(config)#do show run
Building configuration...

Current configuration : 1406 bytes
!
! Last configuration change at 11:00:39 UTC Sat Feb 13 2021
!
version 15.4
service timestamps debug uptime
service timestamps log uptime

R2(config)#no service timestamps
R2(config)#do show run
Building configuration...

Current configuration : 1412 bytes
!
! Last configuration change at 11:04:04 UTC Sat Feb 13 2021
!
version 15.4
no service timestamps debug uptime
no service timestamps log uptime

Wild!   Running service timestamps when both the debug and log timestamps are off results in only the debug timestamp being enabled, but if you run no service timestamps when they’re both on, it turns both of them off.

Again, this quirk is very unlikely to show up on your exam, but I did want to bring it to your attention.

Thanks for reading and watching this CCNA Command Reference!   Please take a moment to visit my CCNA YouTube Channel and subscribe — I’m posting new Video Practice Exams, CCNA Tip Videos, and all sorts of great stuff to help you thrive in your present job, your future job, and your certification exams.  See you there!

If you have questions or comments about this CCNA Command Reference, reach me on Twitter @ccie12933 or via email at ccie12933@gmail.com.   Thanks for reading!

Chris Bryant

CCIE #12933

“The Computer Certification Bulldog”