Hi there and welcome back to this series on the Cisco Configuration Professional. Up to this point, we have gone through five labs; this is the sixth lab, which focuses on the network time protocol (NTP). This lab will set the path for the upcoming VPN labs.

Our network diagram is as shown below, although it will change after this article:

CCP-Series

 

The configuration tasks for Lab #6 are:

  • Add a new router, RTR3, to the topology, connected to RTR2’s Fa0/1 interface. The link between RTR2 and RTR3 should be on the subnet 192.168.23.0/24. Also, create a loopback (Lo0) on RTR3 with IP address 3.3.3.3/32. Add this new router to the EIGRP network.
  • Synchronize the clock of RTR2 with your local PC clock through CCP.
  • Configure NTP on the other routers using RTR2’s Lo1 IP address (22.22.22.22) as the master NTP server. Authenticate NTP using a key of “cisco.” NTP traffic should be sourced off RTR1’s and RTR3’s Fa0/0 addresses, i.e., 10.0.0.1 and 192.168.23.3, respectively.
  • Test: The clocks of RTR1 and RTR3 should be synchronized through NTP with that of RTR2. Fix the configuration if necessary.

Configuration Solutions

Task #1

I have added a new router to the GNS3 topology with the following initial configuration:

hostname RTR3
!
username ccp privilege 15 secret cisco
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
 ip address 192.168.23.3 255.255.255.0
!
router eigrp 10
 network 3.3.3.3 0.0.0.0
 network 192.168.23.0
 no auto-summary
!
ip http server
ip http authentication local
ip http secure-server
!
line vty 0 4
 login local
!

Also, on RTR2, I have added the following configuration:

interface FastEthernet0/1
 ip address 192.168.23.2 255.255.255.0
router eigrp 10
 network 192.168.23.0

Finally, I have discovered this device through CCP.

Task #2

NTP gives us the opportunity to sync the times on all our devices, which is especially useful when dealing with digital certificates. One of the cool features of CCP is that we can synchronize the clock of our device with our local PC’s clock settings. To do this, I’d select RTR2 as the community member and navigate to Configure > Router > Time > Date and Time.

Clicking on the Change Settings button, we are presented with a Date and Time Properties dialog box, where we can either configure the date and time settings of our device manually, or we can use the local PC clock synchronization option.

After the synchronization, notice that my device time has now been synched with my laptop’s time.

Task #3

Before we move on to the other routers, we need to mark RTR2 as an NTP master. It seems that this cannot be done through CCP, so I will do it via the console.

ntp authentication-key 1 md5 00071A150754 7
ntp authenticate
ntp trusted-key 1
ntp master

Hint: After you make a change via console, remember to press the Refresh button in CCP so that it fetches the new configuration.

We can now move on to the other routers, RTR1 and RTR3, to configure NTP on them, using RTR2 as the NTP master. Let’s begin with RTR1. I will select it as the community member. navigate to Configure > Router > Time > NTP and SNTP, and click on the Add button.

The task specifies that we should use RTR2’s Lo1 IP address (22.22.22.22) as the server IP address and also source our NTP traffic from the Fa0/0 interface. I have done this below:

Notice that I have also specified the authentication key of “cisco.” The configuration to be sent to the device is shown below:

ntp authentication-key 1 md5 *****
ntp authenticate
ntp trusted-key 1
ntp server 22.22.22.22 key 1 source FastEthernet0/0

We can go ahead and perform the same steps for RTR3 (not shown).

Task #4

One of the best ways to confirm that NTP is synchronized is to use the show ntp status command. We can use the IOS Show Commands utility on the CCP interface. Let’s first check it for RTR1.

Hmm, clock is unsynchronized. Let’s check RTR3 and see what that is reporting.

The clock is synchronized on RTR3 and we did exactly the same configuration on both of them.

Note: I have noticed that NTP on GNS3 (or Cisco in general?) devices can be a bit unstable: sometimes, it may work once it is configured; other times, it could take a few minutes; and still other times, it may not work at all. If you are sure your configuration is correct and NTP still doesn’t work, give it a few minutes.

In our case however, it is not a configuration issue. I purposely did this to introduce some troubleshooting into this lab. *grin* Can you find where the problem is?

Usually, the first thing you want to do is to ensure that your configuration is correct. We will view NTP configurations on both RTR1 and RTR2.

We can be certain that the authentication keys are correct because RTR3 is also using the same authentication key and is syncing just fine. If in doubt, change it for both of them. The next thing we want to ensure is that RTR1 can ping that NTP server.

Unreachable messages can give you a hint that some sort of filtering (firewall, ACL, etc.) is taking place. One way to go is to check if the ping traffic is reaching RTR2 at all by debugging ICMP traffic.

It is indeed reaching RTR2 but RTR2 is sending unreachable messages back to RTR1, so RTR2 must be filtering that traffic. Let’s look at the access-list on RTR2.

Can you see the offending ACE? deny ip any host 22.22.22.22. The reason RTR3 was not affected by this ACL is because we applied this ACL (OUTSIDE_IN) to the Fa0/0 interface of RTR2.

If we had sourced the NTP traffic off RTR1’s Lo0 interface (1.1.1.1), we would not have had any issues. Now let’s fix the configuration. We will select RTR2 and navigate to Configure > Router > ACL > ACL Editor and click on the Edit button. Remember to place the new ACE above the deny statement.

The configuration to be delivered to the device is as shown below:

no ip access-list extended OUTSIDE_IN
ip access-list extended OUTSIDE_IN
 remark filter inbound traffic on Fa0/0
 remark CCP_ACL Category=1
 remark permit 1.1.1.1 to access 22.22.22.22
 permit ip host 1.1.1.1 host 22.22.22.22
 permit tcp host 112.112.112.112 host 22.22.22.22 eq telnet
 remark permit NTP from RTR1
 permit udp host 10.0.0.1 host 22.22.22.22 eq ntp
 remark deny all other connections to 22.22.22.22
 deny ip any host 22.22.22.22
 remark permit all unmatched traffic
 permit ip any any
exit

And now, if we check the NTP status of RTR1, it should be synchronized.

Great!

Summary

This brings us to the end of this lab, where we have looked at NTP. We began by adding a new router to our topology and then configuring time settings on our routers. We synchronized the clock of RTR2 with the local PC’s clock and configured RTR2 to serve as our NTP master for RTR1 and RTR3. We discovered that, while RTR3 successfully synchronized its clock with RTR2 via NTP, RTR1 did not synchronize. We then ran a troubleshooting session and discovered that the ACL we had previously applied on RTR2 was blocking the NTP connection from RTR1. We fixed this and RTR1 was able to successfully synchronize with RTR2.

The fact that we are building labs upon labs means that some of our new (or old) configurations may not work. This gives room for troubleshooting and I’m of the opinion that good troubleshooting skills makes one a better engineer. I hope this article has indeed moved you toward the path of becoming a better engineer.

Further Reading

Basic System Management Configuration Guide, Cisco IOS Release 12.4T: Setting Time and Calendar Services: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/bsm/configuration/12-4t/bsm-12-4t-book/bsm-time-calendar-set.html