OSPF_Base_Topology_NTP

After quite a few days out of the study game due to illness and actually giving myself time to recover from it this time, I am back, and I am already sick of going over NTP – So this is the last but important concepts for NTP.

One oddity I have noticed working with NTP on my routers over the NBMA, is that R1 for some reason does not save the time after I “wr mem” so I have to use the “clock set …” command every time for it, however R2 and R3 never catch up after I reset the clock and get their time:

R3#sh clock
*00:33:12.545 UTC Sat Mar 2 2002
R3#sh ntp assoc

      address         ref clock     st  when  poll reach  delay  offset    disp
 ~172.12.123.1     0.0.0.0          16    45    64    0     0.0    0.00  16000.
 * master (synced), # master (unsynced), + selected, – candidate, ~ configured
R3#
ASR#2
[Resuming connection 2 to r2 … ]

R2#sh clock
*00:32:47.895 UTC Sat Mar 2 2002
R2#

That is, unless I reload them, I let them sit for 10 minutes after resetting R1 but still nothing. So, given the frame switch is a NON-BROADCAST MultiAccess network between all of them, I am going to change this up a bit to see if I can wake R2 and R3 up:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int s0/0
R1(config-if)#ntp ?
  broadcast  Configure NTP broadcast service
  disable    Disable NTP
  multicast  Configure NTP multicast service

R1(config-if)#ntp multicast ?
  A.B.C.D  Multicast group IP address
  client   Listen to NTP multicasts
  key      Configure multicast authentication key
  ttl      TTL of the multicast packet
  version  Configure NTP version
  <cr>

R1(config-if)#ntp multicast
R1(config-if)#
ASR#2
[Resuming connection 2 to r2 … ]

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int s0/0
R2(config-if)#ntp multicast
R2(config-if)#
ASR#3
[Resuming connection 3 to r3 … ]

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int s0/2
R3(config-if)#ntp multicast
R3(config-if)#
ASR#1
[Resuming connection 1 to r1 … ]

R1(config-if)#^Z

I am leaving R4 out of this lab, because it is late, and I want to play with a few of the extended command highlighted in red – specifically version # to see if NTP will jive between different version numbers.

So I threw on some debugging to see what we have going on with R2 and R3:
R1#debug ntp pack
NTP packets debugging is on
R1#
.Mar 29 20:43:46.821: NTP: rcv packet from 172.12.123.2 to 172.12.123.1 on Serial0/0:
.Mar 29 20:43:46.821:  leap 3, mode 3, version 3, stratum 0, ppoll 64
.Mar 29 20:43:46.821:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 20:43:46.825:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 20:43:46.825:  org DC869AC2.D297792B (20:42:42.822 UTC Wed Mar 29 2017)
.Mar 29 20:43:46.825:  rec C02A9DA9.4FAC7075 (00:39:05.311 UTC Sat Mar 2 2002)
.Mar 29 20:43:46.825:  xmt C02A9DE9.42276D52 (00:40:09.258 UTC Sat Mar 2 2002)
.Mar 29 20:43:46.825:  inp DC869B02.D2BFA7C5 (20:43:46.823 UTC Wed Mar 29 2017)
R1#
.Mar 29 20:43:46.829: NTP: stateless xmit packet to 172.12.123.2:
.Mar 29 20:43:46.829:  leap 3, mode 4, version 3, stratum 0, ppoll 64
.Mar 29 20:43:46.829:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 20:43:46.829:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 20:43:46.829:  org C02A9DE9.42276D52 (00:40:09.258 UTC Sat Mar 2 2002)
.Mar 29 20:43:46.829:  rec DC869B02.D2BFA7C5 (20:43:46.823 UTC Wed Mar 29 2017)
.Mar 29 20:43:46.829:  xmt DC869B02.D41D2E3F (20:43:46.828 UTC Wed Mar 29 2017)
R1#
.Mar 29 20:43:54.894: NTP: rcv packet from 172.12.123.3 to 172.12.123.1 on Serial0/0:
.Mar 29 20:43:54.894:  leap 3, mode 3, version 3, stratum 0, ppoll 64
.Mar 29 20:43:54.894:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 20:43:54.894:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 20:43:54.898:  org DC869ACA.E5739DBB (20:42:50.896 UTC Wed Mar 29 2017)
.Mar 29 20:43:54.898:  rec C02A9DE2.574AB8D3 (00:40:02.340 UTC Sat Mar 2 2002)
.Mar 29 20:43:54.898:  xmt C02A9E22.46D2D084 (00:41:06.276 UTC Sat Mar 2 2002)
.Mar 29 20:43:54.898:  inp DC869B0A.E5776373 (20:43:54.896 UTC Wed Mar 29 2017)
R1#
.Mar 29 20:43:54.898: NTP: stateless xmit packet to 172.12.123.3:
.Mar 29 20:43:54.902:  leap 3, mode 4, version 3, stratum 0, ppoll 64
.Mar 29 20:43:54.902:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 20:43:54.902:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 20:43:54.902:  org C02A9E22.46D2D084 (00:41:06.276 UTC Sat Mar 2 2002)
.Mar 29 20:43:54.902:  rec DC869B0A.E5776373 (20:43:54.896 UTC Wed Mar 29 2017)
.Mar 29 20:43:54.906:  xmt DC869B0A.E6CF23AF (20:43:54.901 UTC Wed Mar 29 2017)
R1#

So as can be seen, it shows their old time, and the new time, but we have seen this with the switch that stays insane on the Ethernet segment so let us check R2 and R3:

R2(config-if)#do sh clock
*00:47:10.551 UTC Sat Mar 2 2002
R2(config-if)#
ASR#3
[Resuming connection 3 to r3 … ]

R3(config-if)#do sh clock
*00:48:09.668 UTC Sat Mar 2 2002
R3(config-if)#do sh ntp assoc

      address         ref clock     st  when  poll reach  delay  offset    disp
 ~172.12.123.1     0.0.0.0          16    44    64    0     0.0    0.00  16000.
 * master (synced), # master (unsynced), + selected, – candidate, ~ configured
R3(config-if)#do sh ntp assoc det
172.12.123.1 configured, authenticated, insane, invalid, unsynced, stratum 16
ref ID 0.0.0.0, time 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
our mode client, peer mode unspec, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.00, reach 0, sync dist 0.000
delay 0.00 msec, offset 0.0000 msec, dispersion 16000.00
precision 2**5, version 3
org time DC869CCA.E3EA868D (20:51:22.890 UTC Wed Mar 29 2017)
rcv time C02A9FE2.56ACF13C (00:48:34.338 UTC Sat Mar 2 2002)
xmt time C02A9FE2.45D78CAD (00:48:34.272 UTC Sat Mar 2 2002)
filtdelay =     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filtoffset =    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filterror =  16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0

R3(config-if)#

So it has the same issue as the switch, I’m having a hard time grasping what this issue is, however thinking upon it if you configure an interface for “ntp broadcast” or “ntp multicast” you don’t actually don’t have to have a server command pointing to R1 as it will listen on that interface for NTP broadcasts regardless.

So I am going to make a change to R1 and throw it into broadcast mode, as it should actually before forwarding broadcasts with given the ‘broadcast’ options on my frame relay statements, reload both of them to see what we get:

R3(config-if)#exit
R3(config)#no ntp server 172.12.123.1

R3(config)#int s0/2
R3(config-if)#ntp broadcast
R3(config-if)#^Z
R3#wr
*Mar  2 00:58:24.845: %SYS-5-CONFIG_I: Configured from console by console
R3#wr
Building configuration…
[OK]
R3#reload
Proceed with reload? [confirm]

ASR#2
[Resuming connection 2 to r2 … ]

R2(config-if)#ntp broadcast
R2(config-if)#exit
R2(config)#no ntp server 172.12.123.1
R2(config)#exit
R2#wr
Building configuration…

*Mar  2 00:58:18.581: %SYS-5-CONFIG_I: Configured from console by console[OK]
R2#reload
Proceed with reload? [confirm]

*Mar  2 00:58:35.857: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.
ASR#1
[Resuming connection 1 to r1 … ]

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int s0/0
R1(config-if)#ntp broadcast
R1(config-if)#exit
R1(config)#exit
R1#debug
.Mar 29 21:02:31.933: %SYS-5-CONFIG_I: Configured from console by console
R1#debug ntp pack
NTP packets debugging is on
R1#

So now Serial0/0 on R1 is rocking broadcast mode, along with the serial interfaces of R2 and R3, and as they reload I have a debug running to see what output we get upon them coming up, lets see NTP come through for us just one more time so I can move on to a new topic:

(An off topic note, the slowness of a 2600 series router booting, mixed with a serial link speed to bring up an OSPF adjacency makes me want to jump off a roof. Fortunately my roof is only high enough to break my leg or something, so I won’t jump off it quite yet)

R1#debug
.Mar 29 21:02:31.933: %SYS-5-CONFIG_I: Configured from console by console
R1#debug ntp pack
NTP packets debugging is on
R1#
.Mar 29 21:03:38.574: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
R1#
.Mar 29 21:04:14.165: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
R1#sh access-list
Standard IP access list 10
    10 permit 172.12.123.0, wildcard bits 0.0.0.255 (149 matches)
    20 permit 172.12.34.0, wildcard bits 0.0.0.255 (26 matches)
    30 permit 172.12.23.0, wildcard bits 0.0.0.255 (73 matches)
R1#
.Mar 29 21:09:38.997: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial0/0 from LOADING to FULL, Loading Done
R1#
.Mar 29 21:10:14.483: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0/0 from LOADING to FULL, Loading Done
R1#

So after 6 or so minutes of staring at the CLI, my adjacencies finally creaked their way out of their coffin to say Hello to R1, however no NTP debug output at all?

And as soon as I typed that, of course I DID get some output from the debug:

R1#
.Mar 29 21:12:07.224: NTP: rcv packet from 172.12.23.1 to 172.12.123.1 on Serial0/0:
.Mar 29 21:12:07.224:  leap 3, mode 3, version 3, stratum 0, ppoll 64
.Mar 29 21:12:07.224:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 21:12:07.228:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 21:12:07.228:  org DC869F27.39F0071C (21:01:27.226 UTC Wed Mar 29 2017)
.Mar 29 21:12:07.228:  rec AF3BE488.1E7958AA (01:25:28.119 UTC Mon Mar 1 1993)
.Mar 29 21:12:07.228:  xmt AF3BE708.11A18045 (01:36:08.068 UTC Mon Mar 1 1993)
.Mar 29 21:12:07.228:  inp DC86A1A7.3A1C931F (21:12:07.226 UTC Wed Mar 29 2017)
R1#
.Mar 29 21:12:07.232: NTP: stateless xmit packet to 172.12.23.1:
.Mar 29 21:12:07.232:  leap 3, mode 4, version 3, stratum 0, ppoll 64
.Mar 29 21:12:07.232:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 21:12:07.232:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 21:12:07.232:  org AF3BE708.11A18045 (01:36:08.068 UTC Mon Mar 1 1993)
.Mar 29 21:12:07.232:  rec DC86A1A7.3A1C931F (21:12:07.226 UTC Wed Mar 29 2017)
.Mar 29 21:12:07.232:  xmt DC86A1A7.3B65703B (21:12:07.232 UTC Wed Mar 29 2017)
R1#

So now the only debug information I am seeing is coming from the Ethernet segment which we did not alter, so I’m afraid to look at R2 and R3 but given they are configured only on the interface level to listen for NTP broadcasts maybe they just silently take the time and go with it like NTP ninjas?

Lets see:

R2>en
Password:
R2#sh clock
*01:05:28.941 UTC Sat Mar 2 2002
R2#

I did a “sh run” and forgot one of my cardinal rules, I’m already getting rusty – remove old configurations before entering new configurations for a command:

!
interface Serial0/0
 ip address 172.12.123.2 255.255.255.0
 encapsulation frame-relay
 ip ospf priority 0
 ntp broadcast
 ntp multicast
 frame-relay map ip 172.12.123.3 221
 frame-relay map ip 172.12.123.1 221 broadcast
 no frame-relay inverse-arp
 frame-relay lmi-type cisco

So I’ll save the output, but I removed NTP Multicast from all routers, and it didn’t make a difference.

And I just figured out what I goofed here:

R2(config-if)#ntp broadcast ?
  client       Listen to NTP broadcasts
  destination  Configure broadcast destination address
  key          Configure broadcast authentication key
  version      Configure NTP version
  <cr>

R2(config-if)#ntp broadcast client ?
  <cr>

R2(config-if)#ntp broadcast client

And just a few moments later:

R2(config-if)#do sh clock
.23:32:32.694 UTC Wed Mar 29 2017

So one big note worth mentioning on here that I completely derp’d, on the server you only need to set “broadcast”, however with clients listening on their interfaces you must add that “client” to the end as you are not pointing it to a master making it a client by default so you must configure it as a client. Clear as mud? Good, lets move on.

What a huge oversight, that is what facepalms are made of. However, lets see if the same works for multicasts as well then eh?

Again, after making the change on both clients to “ntp multicast client” on the serial interface I am surprisingly seeing no output from R1, and I’ve set it’s Serial0/0 interface as “ntp multicast” before configuring the others. Lets look at times around the network and see what we have:

R2(config-if)#do sh clock
.23:43:12.229 UTC Wed Mar 29 2017
R2(config-if)#do sh ntp assoc det

R2(config-if)#exit
R2(config)#exit
R2#sh n
.Mar 29 23:43:47.383: %SYS-5-CONFIG_I: Configured from console by console
R2#sh ntp ?
  associations  NTP associations
  status        NTP status

R2#sh ntp status
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 249.5901 Hz, actual freq is 249.5907 Hz, precision is 2**16
reference time is DC86C1C0.16D0FDAD (23:29:04.089 UTC Wed Mar 29 2017)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 7875.02 msec, peer dispersion is 7875.02 msec

So it has the time that it’s probably held on to from the broadcast configuration, but as can be seen there is no ntp assoc, no reference clock, notta.

So I’m going to set everything back into broadcast mode, and see if we can get everything at least in order again, and again I’ll spare the output of the commands to keep this post that should be brief, as brief as possible.

Also, I’m just leaving “debug ntp pack” on R1 the entire time, I want to see every 1 and 0 that passes through that dang NTP Master to see if I can spot a clue as to what is going on here:

R2(config)#
R2(config)#int s0/0
R2(config-if)#no ntp multicast client
R2(config-if)#ntp broadcast client
R2(config-if)#exit
R2(config)#exit
R2#wr
Building configuration…

.Mar 29 23:49:25.404: %SYS-5-CONFIG_I: Configured from console by console[OK]
R2#
ASR#3
[Resuming connection 3 to r3 … ]

R3(config-if)#no ntp multicast client
R3(config-if)#ntp broadcast client
R3(config-if)#^Z
R3#wr
Building configuration…

*Mar  2 01:42:09.543: %SYS-5-CONFIG_I: Configured from console by console[OK]
R3#
R3#reload
Proceed with reload? [confirm]

*Mar  2 01:42:33.590: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.
ASR#2
[Resuming connection 2 to r2 … ]

R2#reload
Proceed with reload? [confirm]

.Mar 29 23:50:47.210: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.
ASR#1
[Resuming connection 1 to r1 … ]

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int s0/0
R1(config-if)#no ntp multicast
R1(config-if)#ntp broadcast
R1(config-if)#^Z
R1#
.Mar 29 21:52:28.573: %SYS-5-CONFIG_I: Configured from console by console
R1#debug ntp pack
NTP packets debugging is on
R1#

I did that in kind of a weird order, as I wanted R2 and R3 to reload at relatively the same time, then reset R1 for broadcast mode as they re-cook, and now that I have 6 minutes to wait I put on my debug on R1 and going to start my PS4 and get food ready, run a marathon, and go sky diving so when I get back it should finally be back up and cooking.

So I literally cleaned my kitchen, did dishes, and came back to this:

R1#debug ntp pack
NTP packets debugging is on
R1#
.Mar 29 21:53:54.190: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
R1#
.Mar 29 21:54:03.565: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
R1#
.Mar 29 21:59:32.168: NTP: rcv packet from 172.12.34.4 to 172.12.123.1 on Serial0/0:
.Mar 29 21:59:32.168:  leap 3, mode 3, version 4, stratum 0, ppoll 256
.Mar 29 21:59:32.172:  rtdel 0000 (0.000), rtdsp 2095 (127.274), refid 41555448 (65.85.84.72)
.Mar 29 21:59:32.172:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 21:59:32.172:  org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 21:59:32.172:  rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 21:59:32.172:  xmt DC870C00.8A152270 (04:45:52.539 UTC Thu Mar 30 2017)
.Mar 29 21:59:32.172:  inp DC86ACC4.2BCC2DF4 (21:59:32.171 UTC Wed Mar 29 2017)
R1#
.Mar 29 21:59:32.176: NTP: stateless xmit packet to 172.12.34.4:
.Mar 29 21:59:32.176:  leap 3, mode 4, version 4, stratum 0, ppoll 256
.Mar 29 21:59:32.176:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 21:59:32.176:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 21:59:32.176:  org DC870C00.8A152270 (04:45:52.539 UTC Thu Mar 30 2017)
.Mar 29 21:59:32.176:  rec DC86ACC4.2BCC2DF4 (21:59:32.171 UTC Wed Mar 29 2017)
.Mar 29 21:59:32.176:  xmt DC86ACC4.2D26835D (21:59:32.176 UTC Wed Mar 29 2017)
R1#
.Mar 29 21:59:54.624: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial0/0 from LOADING to FULL, Loading Done
R1#
.Mar 29 22:00:03.884: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0/0 from LOADING to FULL, Loading Done
R1#

The seemingly never ending OSPF Adj reform, but also again no NTP messages between R1 and either spoke, so lets take a look at the spokes here:
R2>en
Password:
R2#sh clock
*23:57:14.213 UTC Wed Mar 29 2017
R2#
ASR#3
[Resuming connection 3 to r3 … ]

System Bootstrap, Version 12.2(8r) [cmong 8r], RELEASE SOFTWARE (fc1)
Copyright (c) 2003 by cisco Systems, Inc.
C2600 platform with 131072 Kbytes of main memory

R3>en
Password:
R3#sh clock
*01:50:15.588 UTC Sat Mar 2 2002
R3#

I just don’t get some of these behaviors, and yes that clock does show its actually now past midnight, and this is one of those things that will drive me up a freegin wall if I do not figure out this behavior (Although as seen in other lab posts, there are bugs (and screenshots of Cisco’s webpage describing the bug) for some of these IOS’s, so it very well may be a bug.

So lets get to troubleshooting here and figure out what in the world is going on. So first, I want to stare and compare any conflicts on the “sh run” of all 3 routers which I’ll display here:

R1:

R1#sh run int serial0/0
Building configuration…

Current configuration : 258 bytes
!
interface Serial0/0
 ip address 172.12.123.1 255.255.255.0
 encapsulation frame-relay
 ntp broadcast
 frame-relay map ip 172.12.123.3 123 broadcast
 frame-relay map ip 172.12.123.2 122 broadcast
 no frame-relay inverse-arp
 frame-relay lmi-type cisco
end

R1#

R2:
R2#sh run int s0/0
Building configuration…

Current configuration : 275 bytes
!
interface Serial0/0
 ip address 172.12.123.2 255.255.255.0
 encapsulation frame-relay
 ip ospf priority 0
 ntp broadcast client
 frame-relay map ip 172.12.123.1 221 broadcast
 frame-relay map ip 172.12.123.3 221
 no frame-relay inverse-arp
 frame-relay lmi-type cisco
end

R2#

R3:

R3#sh run int s0/2
Building configuration…

Current configuration : 247 bytes
!
interface Serial0/2
 ip address 172.12.123.3 255.255.255.0
 encapsulation frame-relay
 ip ospf priority 0
 ntp broadcast client
 frame-relay map ip 172.12.123.2 321
 frame-relay map ip 172.12.123.1 321 broadcast
 no frame-relay inverse-arp
end

R3#

These all look good, how about pings, I guess what has burnt me in the past is Layer 3 connectivity:

R1#ping 172.12.123.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.123.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/66/69 ms
R1#ping 172.12.123.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 65/67/68 ms
R1#

Nope. So to try to force some action, I have set “debug ntp pack” on R2 and R3, and will do so now and remove the ntp broadcast command and switch it to a version number not used by the other routers that are using NTPv3 from what I see in past output, and see what happens:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int s0/0
R1(config-if)#no ntp broadcast version 2
R1(config-if)#^Z
R1#deb
.Mar 29 22:20:34.140: %SYS-5-CONFIG_I: Configured from console by console
R1#debug ntp pack
NTP packets debugging is on
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int s0/0
R1(config-if)#ntp broadcast version 2
R1(config-if)#
ASR#2
[Resuming connection 2 to r2 … ]

R2#sh clock
*00:12:33.711 UTC Thu Mar 30 2017
R2#
ASR#3
[Resuming connection 3 to r3 … ]

R3#sh clock
*02:05:31.201 UTC Sat Mar 2 2002

Across the NBMA this gets all sorts of buggy, I must have gotten cursed code for my routers when it comes to NTP, however lets point back to a master so I can sleep tonight knowing my clocks are in sync:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int s0/0
R2(config-if)#no ntp broadcast client
R2(config-if)#exit
R2(config)#ntp server 172.12.123.1
R2(config)#
ASR#3
[Resuming connection 3 to r3 … ]

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int s0/2
R3(config-if)#no ntp broadcast client
R3(config-if)#exit
R3(config)#ntp server 172.12.123.1
R3(config)#
ASR#1
[Resuming connection 1 to r1 … ]

.Mar 29 22:25:05.950: NTP: rcv packet from 172.12.34.4 to 172.12.123.1 on Serial0/0:
.Mar 29 22:25:05.950:  leap 3, mode 3, version 4, stratum 0, ppoll 1024
.Mar 29 22:25:05.950:  rtdel 0000 (0.000), rtdsp 2679 (150.284), refid 41555448 (65.85.84.72)
.Mar 29 22:25:05.950:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 22:25:05.954:  org DC86AEC3.1A2B1433 (22:08:03.102 UTC Wed Mar 29 2017)
.Mar 29 22:25:05.954:  rec DC870DFF.9B9DF69E (04:54:23.607 UTC Thu Mar 30 2017)
.Mar 29 22:25:05.954:  xmt DC8711FE.89175915 (05:11:26.535 UTC Thu Mar 30 2017)
.Mar 29 22:25:05.958:  inp DC86B2C1.F3D1CFC4 (22:25:05.952 UTC Wed Mar 29 2017)
R1(config)#0F7FD7A (22:25:29.066 UTC Wed Mar 29 2017)
.Mar 29 22:25:30.057: NTP: rcv packet from 172.12.123.2 to 172.12.123.1 on Serial0/0:
.Mar 29 22:25:30.057:  leap 3, mode 3, version 3, stratum 0, ppoll 64
.Mar 29 22:25:30.057:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 22:25:30.057:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 22:25:30.057:  org DC86B2D9.10F7FD7A (22:25:29.066 UTC Wed Mar 29 2017)
.Mar 29 22:25:30.062:  rec DC86CCEF.534DC1DA (00:16:47.325 UTC Thu Mar 30 2017)
.Mar 29 22:25:30.062:  xmt DC86CCF0.43AD06C4 (00:16:48.264 UTC Thu Mar 30 2017)
.Mar 29 22:25:30.062:  inp DC86B2DA.0F1B0C1B (22:25:30.059 UTC Wed Mar 29 2017)
.Mar 29 22:25:30.062: NTP: stateless xmit packet to 172.12.123.2:
.Mar 29 22:25:30.062:  leap 3, mode 4, version 3, stratum 0, ppoll 64
.Mar 29 22:25:30.062:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 22:25:30.066:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 22:25:30.066:  org DC86CCF0.43AD06C4 (00:16:48.264 UTC Thu Mar 30 2017)
.Mar 29 22:25:30.066:  rec DC86B2DA.0F1B0C1B (22:25:30.059 UTC Wed Mar 29 2017)
.Mar 29 22:25:30.066:  xmt DC86B2DA.10675AC7 (22:25:30.064 UTC Wed Mar 29 2017)
.Mar 29 22:25:31.059: NTP: rcv packet from 172.12.123.2 to 172.12.123.1 on Serial0/0:
.Mar 29 22:25:31.059:  leap 3, mode 3, version 3, stratum 0, ppoll 64
.Mar 29 22:25:31.059:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 22:25:31.059:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 22:25:31.059:  org DC86B2DA.10675AC7 (22:25:30.064 UTC Wed Mar 29 2017)
.Mar 29 22:25:31.059:  rec DC86CCF0.52B2A86D (00:16:48.323 UTC Thu Mar 30 2017)
.Mar 29 22:25:31.063:  xmt DC86CCF1.44195CA6 (00:16:49.266 UTC Thu Mar 30 2017)
.Mar 29 22:25:31.063:  inp DC86B2DB.0F712205 (22:25:31.060 UTC Wed Mar 29 2017)
.Mar 29 22:25:31.063: NTP: stateless xmit packet to 172.12.123.2:
.Mar 29 22:25:31.063:  leap 3, mode 4, version 3, stratum 0, ppoll 64
.Mar 29 22:25:31.063:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 22:25:31.063:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 22:25:31.067:  org DC86CCF1.44195CA6 (00:16:49.266 UTC Thu Mar 30 2017)
.Mar 29 22:25:31.067:  rec DC86B2DB.0F712205 (22:25:31.060 UTC Wed Mar 29 2017)
.Mar 29 22:25:31.067:  xmt DC86B2DB.10BC944D (22:25:31.065 UTC Wed Mar 29 2017)
.Mar 29 22:25:32.061: NTP: rcv packet from 172.12.123.2 to 172.12.123.1 on Serial0/0:
.Mar 29 22:25:32.061:  leap 3, mode 3, version 3, stratum 0, ppoll 64
.Mar 29 22:25:32.061:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 22:25:32.061:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 22:25:32.061:  org DC86B2DB.10BC944D (22:25:31.065 UTC Wed Mar 29 2017)
.Mar 29 22:25:32.061:  rec DC86CCF1.530371D5 (00:16:49.324 UTC Thu Mar 30 2017)
.Mar 29 22:25:32.065:  xmt DC86CCF2.4483F9C0 (00:16:50.267 UTC Thu Mar 30 2017)
.Mar 29 22:25:32.065:  inp DC86B2DC.0FE71261 (22:25:32.062 UTC Wed Mar 29 2017)
.Mar 29 22:25:32.065: NTP: stateless xmit packet to 172.12.123.2:
.Mar 29 22:25:32.065:  leap 3, mode 4, version 3, stratum 0, ppoll 64
.Mar 29 22:25:32.065:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 22:25:32.065:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 22:25:32.069:  org DC86CCF2.4483F9C0 (00:16:50.267 UTC Thu Mar 30 2017)
.Mar 29 22:25:32.069:  rec DC86B2DC.0FE71261 (22:25:32.062 UTC Wed Mar 29 2017)
.Mar 29 22:25:32.069:  xmt DC86B2DC.1136D29C (22:25:32.067 UTC Wed Mar 29 2017)
.Mar 29 22:25:33.058: NTP: rcv packet from 172.12.123.2 to 172.12.123.1 on Serial0/0:
.Mar 29 22:25:33.058:  leap 3, mode 3, version 3, stratum 0, ppoll 64
.Mar 29 22:25:33.058:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 22:25:33.058:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 22:25:33.058:  org DC86B2DC.1136D29C (22:25:32.067 UTC Wed Mar 29 2017)
.Mar 29 22:25:33.058:  rec DC86CCF2.5387E2A1 (00:16:50.326 UTC Thu Mar 30 2017)
.Mar 29 22:25:33.062:  xmt DC86CCF3.43E9BCB7 (00:16:51.265 UTC Thu Mar 30 2017)
.Mar 29 22:25:33.062:  inp DC86B2DD.0F48A96F (22:25:33.059 UTC Wed Mar 29 2017)
.Mar 29 22:25:33.062: NTP: stateless xmit packet to 172.12.123.2:
.Mar 29 22:25:33.062:  leap 3, mode 4, version 3, stratum 0, ppoll 64
.Mar 29 22:25:33.062:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 22:25:33.062:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 22:25:33.066:  org DC86CCF3.43E9BCB7 (00:16:51.265 UTC Thu Mar 30 2017)
.Mar 29 22:25:33.066:  rec DC86B2DD.0F48A96F (22:25:33.059 UTC Wed Mar 29 2017)
.Mar 29 22:25:33.066:  xmt DC86B2DD.1094F81A (22:25:33.064 UTC Wed Mar 29 2017)
.Mar 29 22:25:37.818: NTP: rcv packet from 172.12.123.3 to 172.12.123.1 on Serial0/0:
.Mar 29 22:25:37.818:  leap 3, mode 3, version 3, stratum 0, ppoll 64
.Mar 29 22:25:37.818:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 22:25:37.818:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 22:25:37.818:  org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 22:25:37.818:  rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 22:25:37.818:  xmt C02AB2EA.4A4B18B3 (02:09:46.290 UTC Sat Mar 2 2002)
.Mar 29 22:25:37.822:  inp DC86B2E1.D1AC185A (22:25:37.819 UTC Wed Mar 29 2017)
.Mar 29 22:25:37.822: NTP: stateless xmit packet to 172.12.123.3:
.Mar 29 22:25:37.822:  leap 3, mode 4, version 3, stratum 0, ppoll 64
.Mar 29 22:25:37.822:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 22:25:37.822:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 22:25:37.822:  org C02AB2EA.4A4B18B3 (02:09:46.290 UTC Sat Mar 2 2002)
.Mar 29 22:25:37.826:  rec DC86B2E1.D1AC185A (22:25:37.819 UTC Wed Mar 29 2017)
.Mar 29 22:25:37.826:  xmt DC86B2E1.D2F33CAE (22:25:37.824 UTC Wed Mar 29 2017)
.Mar 29 22:25:38.820: NTP: rcv packet from 172.12.123.3 to 172.12.123.1 on Serial0/0:
.Mar 29 22:25:38.820:  leap 3, mode 3, version 3, stratum 0, ppoll 64
.Mar 29 22:25:38.820:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 22:25:38.820:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 22:25:38.820:  org DC86B2E1.D2F33CAE (22:25:37.824 UTC Wed Mar 29 2017)
.Mar 29 22:25:38.820:  rec C02AB2EA.593EA3B9 (02:09:46.348 UTC Sat Mar 2 2002)
.Mar 29 22:25:38.824:  xmt C02AB2EB.4AB74497 (02:09:47.291 UTC Sat Mar 2 2002)
.Mar 29 22:25:38.824:  inp DC86B2E2.D215FB3E (22:25:38.820 UTC Wed Mar 29 2017)
.Mar 29 22:25:38.824: NTP: stateless xmit packet to 172.12.123.3:
.Mar 29 22:25:38.824:  leap 3, mode 4, version 3, stratum 0, ppoll 64
.Mar 29 22:25:38.824:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 22:25:38.824:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 22:25:38.824:  org C02AB2EB.4AB74497 (02:09:47.291 UTC Sat Mar 2 2002)
.Mar 29 22:25:38.828:  rec DC86B2E2.D215FB3E (22:25:38.820 UTC Wed Mar 29 2017)
.Mar 29 22:25:38.828:  xmt DC86B2E2.D36249E9 (22:25:38.825 UTC Wed Mar 29 2017)
.Mar 29 22:25:39.817: NTP: rcv packet from 172.12.123.3 to 172.12.123.1 on Serial0/0:
.Mar 29 22:25:39.817:  leap 3, mode 3, version 3, stratum 0, ppoll 64
.Mar 29 22:25:39.817:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
.Mar 29 22:25:39.817:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Mar 29 22:25:39.817:  org DC86B2E2.D36249E9 (22:25:38.825 UTC Wed Mar 29 2017)
.Mar 29 22:25:39.817:  rec C02AB2EB.5BF27F97 (02:09:47.359 UTC Sat Mar 2 2002)
.Mar 29 22:25:39.822:  xmt C02AB2EC.4A1B24F3 (02:09:48.289 UTC Sat Mar 2 2002)
.Mar 29 22:25:39.822:  inp DC86B2E3.D189A67E (22:25:39.818 UTC Wed Mar 29 2017)

Woah! That is what I needed to see, some life from my spokes!! If this does not show the correct time on my NTP routers now, I might just throw my rack off the roof instead of myself. I did check R2 which has the correct time, but no NTP association.

The part that drives me crazy, and as seen below, I will do a “wr” with the new ntp master on their and the interface configs removed, and it will come back up as it should. I may revisit this on an Ethernet only segment to cut out the oddities NBMA might be throwing in there.

R3#wr
Building configuration…

*Mar  2 02:15:21.301: NTP: xmit packet to 172.12.123.1:
*Mar  2 02:15:21.301:  leap 3, mode 3, version 3, stratum 0, ppoll 64
*Mar  2 02:15:21.301:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
*Mar  2 02:15:21.301:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
*Mar  2 02:15:21.305:  org DC86B3F0.D0EA111D (22:30:08.816 UTC Wed Mar 29 2017)
*Mar  2 02:15:21.305:  rec C02AB3F9.57D528A6 (02:14:17.343 UTC Sat Mar 2 2002)
*Mar  2 02:15:21.305:  xmt C02AB439.4DA1B594 (02:15:21.303 UTC Sat Mar 2 2002)
*Mar  2 02:15:21.506: NTP: rcv packet from 172.12.123.1 to 172.12.123.3 on Serial0/2:
*Mar  2 02:15:21.510:  leap 3, mode 4, version 3, stratum 0, ppoll 64
*Mar  2 02:15:21.510:  rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
*Mar  2 02:15:21.510:  ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
*Mar  2 02:15:21.510:  org C02AB439.4DA1B594 (02:15:21.303 UTC Sat Mar 2 2002)
*Mar  2 02:15:21.510:  rec DC86B430.D46F260E (22:31:12.829 UTC Wed Mar 29 2017)
*Mar  2 02:15:21.510:  xmt DC86B430.D472979E (22:31:12.829 UTC Wed Mar 29 2017)
*Mar  2 02:15:21.514:  inp C02AB439.8260000E (02:15:21.509 UTC Sat Mar 2 2002)[OK]
R3#
R3#

This is what is driving me crazy, is it is receiving the correct time, but then reverts itself back to its old time.

So I will maybe revisit this quickly between R1 and R5 directly connected over a FastEthernet connection to see if it works any better on there, otherwise a few take aways from NTP:

  • Authentication doesn’t really force authentication, so use ACL’s to limit access
  • ACL command to apply to ntp is “ntp access-group #” from global config
  • On the interface level, at this point theoretically, you shouldn’t need to configure an NTP Server but just an interface level command “ntp (broadcast/multicast) client” to listen for NTP broadcasts from a master on that interface
  • NTP can also be disabled (which I did not get to) on the interface level in place of where you configure it to be broadcast or multicast
  • For all intensive purposes, over an NBMA, the server/client model is the way to go

I am going to go blink a few times before bed now, I am not sure exactly the subject matter of the next section, however I really would like to go over this subject again on just an Ethernet segment between R1 and R5 to show how it actually works.

I did want to keep this post up, just to show behaviors of ntp (configurations and command variables of course), but also its odd behaviors for me on my home lab, I assume in the Cisco exam environment they won’t have a shoddy 2621XM Frame Switch serving as their NBMA (I hope) 🙂 That is all for now!