Friday, June 10, 2016

Setting up an NTP Server... Revisited

Setting up an Ubuntu NTP Server in preparation for creating a syslog-ng server. 

topo

I’m working on creating a syslog-ng server on UbtSvr2 to capture events from routers in my GNS3 environment. The first step is having correct time on all devices; this isn’t important for syslog to function but its nice to associate syslog events with the current date and time – which my devices don’t have:

R1#show clock
*00:18:27.559 UTC Fri Mar 1 2002
R1#
!
R2#show clock
*00:25:00.611 UTC Fri Mar 1 2002
R2#
!
R3#show clock
*00:00:22.875 UTC Fri Mar 1 2002
R3#
!
R4#show clock
*00:00:31.843 UTC Fri Mar 1 2002
R4#

A while back I did another NTP post using a Windows XP machine as the NTP server. That was a bit messy so, instead, I’m going to use an Ubuntu Server (/w desktop) to send out NTP messages to my GNS3 routers.

I’ve already installed ntp on my Ubuntu Sever (UbtSvr2) by running sudo apt-get install ntp and have started it up:

ubtsvr starting ntp

For the routers, see the topological diagram for additional information. I’m running OSPF in several different areas with area 13 being an OSPF virtual link (so areas 3 and 34 can connect to area 0; this is also known as a transit area; R4’s loopback is included in area 34).

I’m also using each router number for the last octet in each respective network (this isn’t really important but I’m mentioning it for reference). I’ve created this topology to add just a tiny bit of complexity; if there’s any issues it will probably be with R4 getting network time via NTP.

One last thing that isn’t shown in the topo is I have loopbacks on each device with their R# as the full address and acting as the OSPF RID (i.e. on R1 I have L0 1.1.1.1/32 in area 1; R2 has L0 2.2.2.2/32 in area 2, etc.). The exception is the loopback on R4 which, as mentioned above, I’ve included into Area 34 (can’t have a transit area hop more than one area). Again, not important but I’m adding this just for reference.

Blah! This is getting to be too much OSPF and not enough NTP! But, before we get back to NTP, let’s look at an issue:

Below are the OSPF configs for each device:

R1#show run | sec ospf

router ospf 1

 log-adjacency-changes

 area 13 virtual-link 3.3.3.3

 network 1.1.1.1 0.0.0.0 area 1

 network 192.168.1.0 0.0.0.255 area 0

 network 192.168.12.0 0.0.0.255 area 0

 network 192.168.13.0 0.0.0.255 area 13

R1#

!

R2#show run | sec ospf

router ospf 1

 log-adjacency-changes

 network 2.2.2.2 0.0.0.0 area 2

 network 192.168.12.0 0.0.0.255 area 0

R2#

!

R3#show run | sec ospf

router ospf 1

 log-adjacency-changes

 area 13 virtual-link 1.1.1.1

 network 3.3.3.3 0.0.0.0 area 3

 network 192.168.13.0 0.0.0.255 area 13

 network 192.168.34.0 0.0.0.255 area 34

R3#

!

R4#show run | sec ospf

router ospf 1

 log-adjacency-changes

 network 4.4.4.4 0.0.0.0 area 34

 network 192.168.34.0 0.0.0.255 area 34

R4#

All routers can ping each other along with their loopbacks; in other words, there is complete OSPF convergence. But there is a problem - R1 can ping UbtSvr2 (192.168.1.2) but R2, R3 and R4 cannot. Below is R4’s routing table and it can ping R1’s fa0/1 interface connecting to UbtSvr2 (192.168.1.1) but cannot ping 192.168.1.2 (UbtSvr2 eth1 interface) even though there’s a route in its table:

R4#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

 

Gateway of last resort is not set

 

O IA 192.168.12.0/24 [110/84] via 192.168.34.3, 00:09:37, FastEthernet0/0

     1.0.0.0/32 is subnetted, 1 subnets

O IA    1.1.1.1 [110/75] via 192.168.34.3, 00:09:37, FastEthernet0/0

O IA 192.168.13.0/24 [110/74] via 192.168.34.3, 00:09:37, FastEthernet0/0

     2.0.0.0/32 is subnetted, 1 subnets

O IA    2.2.2.2 [110/85] via 192.168.34.3, 00:09:37, FastEthernet0/0

     3.0.0.0/32 is subnetted, 1 subnets

O IA    3.3.3.3 [110/11] via 192.168.34.3, 00:09:37, FastEthernet0/0

     4.0.0.0/32 is subnetted, 1 subnets

C       4.4.4.4 is directly connected, Loopback0

C    192.168.34.0/24 is directly connected, FastEthernet0/0

O IA 192.168.1.0/24 [110/84] via 192.168.34.3, 00:09:38, FastEthernet0/0

R4#

R4#ping 192.168.1.1

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/9/12 ms

R4#

R4#ping 192.168.1.2

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

R4#

Same with R2

R2#ping 192.168.1.2

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

R2#

R2#show ip ospf rib 192.168.1.0

 

OSPF local RIB for Process 1

Codes: * - Best, > - Installed in global RIB

 

*>  192.168.1.0/24, Intra, cost 20, area 0

     flags 0x1, SPF Instance 6, age 01:03:32

      via 192.168.12.1, FastEthernet0/0

       flags 0x4, LSA: 1/1.1.1.1/1.1.1.1

R2#

Lets look at the routing table on UbtSvr2:
Ubtsvr Route

Okay, there’s a default route for 10.0.2.2 (using iface eth0 which we don’t care about) and a route for 192.168.1.0. This last route is why R1 can get echo reply’s back - UbtSvr knows how to get back to R1 via the 192.168.1.0 route in its table.

Eh, so... there’s the problem. UbtSvr2 doesn’t have a valid route back to 192.168.12.0 or .13.0 or .34.0/24 networks. R2, R3 and R4 know how to get to UbtSvr but UbtSvr doesn’t know how to get back to them.

Lets add a generic 192.0.0.0/8 route into UbtSvr2’s table:
route added

And now we can ping successfully

R4#ping 192.168.1.2

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 20/49/72 ms

R4#

!

R3#ping 192.168.1.2

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 16/39/64 ms

R3#

!

R2#ping 192.168.1.2

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/46/68 ms

R2#

!

R1#ping 192.168.1.2

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 12/31/40 ms

R1#

And from UbtSvr2 I can ping R4’s fa0/0 interface:

root@root:~# ping 192.168.34.4

PING 192.168.34.4 (192.168.34.4) 56(84) bytes of data.

64 bytes from 192.168.34.4: icmp_seq=1 ttl=253 time=25.6 ms

64 bytes from 192.168.34.4: icmp_seq=2 ttl=253 time=27.0 ms

64 bytes from 192.168.34.4: icmp_seq=3 ttl=253 time=26.7 ms

64 bytes from 192.168.34.4: icmp_seq=4 ttl=253 time=24.4 ms

^C

--- 192.168.34.4 ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 3005ms

rtt min/avg/max/mdev = 24.465/25.964/27.007/1.022 ms

root@root:~#

And I’ll omit pings from UbtSvr2 to R2 & R3 just to keep this moving along (they were successful).

Okay, back to NTP!!!

There’s only one thing I added / changed in the ntp.conf file on UbtSvr2. Before doing this, I backed up the original file (for practice because I keep using “copy” instead of “cp” – blah):
ntpconfbackup

Then, on UbtSvr2, I used vim to comment out the default broadcast and then add a new broadcast in for the 192.168.1.0 network:

# If you want to provide time to your local subnet, change the next line.

# (Again, the address is an example only.)

#broadcast 192.168.1.1

broadcast 192.168.1.255


A screen shot showing the same:
ntpbroadcast

And restarted the ntp service:
restartntp 

Now, on to the routers. On R1 I added the following:

R1(config)#clock timezone PDT -7

R1(config)#

*Mar  1 02:02:14.203: %SYS-6-CLOCKUPDATE: System clock has been updated from 00:02:14 UTC Fri Mar 1 2002 to 19:02:14 PDT Thu Feb 28 2002, configured from console by console.

R1(config)#ntp server 192.168.1.2

R1(config)#end

R1#

Jun 10 07:29:45.428: %SYS-5-CONFIG_I: Configured from console by console

R1#show ntp ass

 

      address         ref clock     st  when  poll reach  delay  offset    disp

*~192.168.1.2      104.131.53.252    3     8    64  377    11.9  -15.89     7.4

 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

R1#show ntp status

Clock is synchronized, stratum 4, reference is 192.168.1.2

nominal freq is 250.0000 Hz, actual freq is 250.0002 Hz, precision is 2**18

reference time is DB04EAE7.0D96BD02 (00:29:43.053 PDT Fri Jun 10 2016)

clock offset is -15.8928 msec, root delay is 85.46 msec

root dispersion is 166.64 msec, peer dispersion is 7.45 msec

R1#show clock

00:29:59.232 PDT Fri Jun 10 2016

R1#

And the clock on R1 synced up immediately! I need to add one more thing to R1 and that’s NTP broadcast only on interfaces I want to broadcast ntp time. I’m doing this on an interface level and not global for many reasons that I’m not going to go into here (a quick google search is recommended for that). On that note, authentication should also be used since a broadcast server can be impersonated and inject false times. But that’s beyond the scope of this (we just want correct times in our syslog-ng files).

R1(config)#inter fa0/0

R1(config-if)#ntp broadcast version 3

R1(config-if)#inter s0/0

R1(config-if)#ntp broadcast version 3

R1(config-if)#

I’m using version 3 as that’s the newest this IOS has. Now, for R2, R3 and R4:

R2#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

R2(config)#do show clock

*02:57:04.831 UTC Fri Mar 1 2002

R2(config)#

R2(config)#inter fa0/0

R2(config-if)#ntp broadcast client

R2(config-if)#exit

R2(config)#clock timezone PDT -7

R2(config)#

Jun 10 07:39:28.826: %SYS-6-CLOCKUPDATE: System clock has been updated from 07:39:28 UTC Fri Jun 10 2016 to 00:39:28 PDT Fri Jun 10 2016, configured from console by console.

R2(config)#

!

R3#show clock

*02:29:41.087 UTC Fri Mar 1 2002

R3#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

R3(config)#clock timezone PDT -7

R3(config)#

*Mar  1 02:29:51.811: %SYS-6-CLOCKUPDATE: System clock has been updated from 02:29:51 UTC Fri Mar 1 2002 to 19:29:51 PDT Thu Feb 28 2002, configured from console by console.

R3(config)#inter s0/0

R3(config-if)#ntp broadcast client

R3(config)#inter fa0/0

R3(config-if)#ntp broadcast

R3(config-if)#end

R3#

*Mar  1 02:30:49.863: %SYS-5-CONFIG_I: Configured from console by console

R3#show clock

*19:31:04.031 PDT Thu Feb 28 2002

R3#show clock

00:42:28.648 PDT Fri Jun 10 2016

R3#

!

R4#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

R4(config)#clock timezone PDT -7

R4(config)#

*Mar  1 02:32:51.147: %SYS-6-CLOCKUPDATE: System clock has been updated from 02:32:51 UTC Fri Mar 1 2002 to 19:32:51 PDT Thu Feb 28 2002, configured from console by console.

R4(config)#inter fa0/0

R4(config-if)#do show clock

*19:32:59.715 PDT Thu Feb 28 2002

R4(config-if)#ntp broadcast client

R4(config-if)#end

R4#

!...!

R4 took about 10 minutes to synchronize. As you can see below, it’s stratum is now 6 (compared to R1’s stratum which is 4, or two hops away):

R4#show clock

*19:33:28.995 PDT Thu Feb 28 2002

R4#show clock

*19:37:02.403 PDT Thu Feb 28 2002

R4#

R4#show clock

.00:49:26.284 PDT Fri Jun 10 2016

R4#

R4#show ntp status

Clock is synchronized, stratum 6, reference is 192.168.34.3

nominal freq is 250.0000 Hz, actual freq is 249.9999 Hz, precision is 2**18

reference time is DB04F2D4.9CAE5AE4 (01:03:32.612 PDT Fri Jun 10 2016)

clock offset is -16.1305 msec, root delay is 117.92 msec

root dispersion is 183.93 msec, peer dispersion is 15.69 msec

R4#

!

R1#show ntp status

Clock is synchronized, stratum 4, reference is 192.168.1.2

nominal freq is 250.0000 Hz, actual freq is 250.0023 Hz, precision is 2**18

reference time is DB04F288.FA4D7564 (01:02:16.977 PDT Fri Jun 10 2016)

clock offset is -17.5911 msec, root delay is 85.77 msec

root dispersion is 112.11 msec, peer dispersion is 10.21 msec

R1#

But wait! There’s more!!! Take a look at this:
R1(config)#end
R1#
Jun 10 08:20:32.871: %SYS-5-CONFIG_I: Configured from console by console
R1#show clock
01:20:37.839 PDT Fri Jun 10 2016
R1#

It doesn’t appear the –7 from UTC is taking hold on syslog messages – they’re 7 hours ahead of the system clock! Lets fix that by adding the following to each device:
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#service timestamps log datetime localtime
R1(config)#end
R1#
Jun 10 01:24:33: %SYS-5-CONFIG_I: Configured from console by console
R1#show clock
01:24:38.247 PDT Fri Jun 10 2016
R1#

That’s better. We should now have accurate time stamps on syslog messages going to UbtSvr syslog-ng service.

And that’s that!
---------------------------------------------
On a side note, It seems the PDT (in: clock timezone PDT –7) is just something you add for visual reference. From the little research I did (or cared to do at this… time), “timezone”: “sets the time zone for display” according to Cisco. The “-7” corrects from UTC time. So, feel free to expand horizons to 4 letter or even a 5 letter word for technical giggles in your home lab. If I’m wrong, leave a post explaining. Ex:

R1(config)#clock timezone DUMB -7

R1(config)#end

R1#

Jun 10 08:15:17.414: %SYS-6-CLOCKUPDATE: System clock has been updated from 01:15:17 PDT Fri Jun 10 2016 to 01:15:17 DUMB Fri Jun 10 2016, configured from console by console.

R1#

Jun 10 08:15:18.406: %SYS-5-CONFIG_I: Configured from console by console

R1#show clock

01:15:25.662 DUMB Fri Jun 10 2016

R1#

Eh, unless DUMB is an actual time zone?!? Meh.

Also… If, say, a Dandy or Fancy-pants was looking to configure summer-time offset, I'd recommend taking a look at: http://www.cisco.com/c/en/us/td/docs/ios/12_2/configfun/command/reference/ffun_r/frf012.html

I'm not going there as I have a ton of other things to work on at this time. But the link above is explanatory enough on the many options Mr. Clock can accommodate.
-------------
Prost!

 

 

No comments:

Post a Comment