IT News, Softwares, Exam Notes & Dumps

Network Time Protocol (NTP) is a vital service not only for Cisco devices but almost every network device. Any computer-based device needs to be accurately synchronised with a reliable time source such as an NTP server.

When it comes to Cisco routers, obtaining the correct time is extremely important because a variety of services depend on it. The logging service shows each log entry with the date and time - very critical if you're trying to track a specific incident or troubleshoot a problem.

Generally, most Cisco routers have two clocks (most people are unaware of this!): a battery-powered hardware clock, referenced as the 'calendar' in the IOS CLI, and a software clock, referenced as the 'clock' in the IOS CLI.

The software clock is the primary source for time data and runs from the moment the system is up and running. The software clock can be updated from a number of sources:

Because the software clock can be configured to be updated from an external source, it is considered more accurate in comparison to the hardware clock. The hardware clock can be configured to be updated from the software clock.

Example Scenario

This article will show you how to configure your Cisco router to synchronise its software clock from external sources such as NTP servers. We will also show you how to configure your router to act as an NTP server for your internal network devices, ensuring all devices are synchronised.

First example involves setting up the router to request NTP updates and synchronise itself from a public NTP server. This will ensure the router's time is constantly synchronised, however it will not act as an NTP server for internal hosts:

We'll need to configure the router to resolve FQDN using our ISP's name server:

Now we instruct our Cisco router to obtain its updates from the public NTP server.

As soon we issue the command, the router will resolve the FQDN into an ip address and begin its synchronisation. Right after issuing the command, we can verify the router is correctly configured and awaiting synchronisation:

The 'show ntp associations' command shows that the system is configured (~) to synchronise with our selected NTP server, however, it is not yet synchronised. When it is, expect to see the star (*) symbol in front of the tilde (~). The 'ref. clock' column shows the IP address of the NTP server from which our public server (1.gr.pool.ntp.org) is synchronising.

It is also worth noting the column named 'st' which is equal to two (2). This represents the stratum level. The higher the stratum, the closer to the Atomic clock source we are. As a general rule, always try to synchronise with a server that has a low stratum.

The 'show ntp status' command confirms that we are yet to be synchronised with the NTP server as it clearly states that the 'clock is unsynchronised' and also shows us the current system time: 1st of Jan. 1900.

After a couple of minutes, we re-visit the CLI prompt and re-issue the commands with the following results:

Looking at the new output, we can see that our Cisco router is now synchronising with the configured peer (*) - public NTP server. Polling of the public NTP server will occur every 64 seconds, as shown in the command output.

The 'show ntp status' command also confirms the synchronisation, however, notice that the router has set its stratum level to 3. This is expected as the reference is stratum 2. The time is now correctly shown (01:17:15.562 Athens Sun Apr 19 2009).

Synchronising Software clock and Hardware clock

Here we'll see how in fact the software and hardware clocks on a Cisco router can have different times and how we can synchronise them between each other.

The following two commands show the difference in time between the two clocks on our Cisco router:

While the difference is small, we want to keep everything in our network synchronised as precisely as possible.

Keep in mind that 'show clock' refers to the software clock and 'show calendar' refers to the hardware clock.

To synchronise the two clocks all we need to do is issue the following command:

The 'ntp update-calendar' forces the hardware clock to synchronise with the system's software clock. After a couple of minutes, we check to see if the two clocks have synchronised:

We can see now that both clocks are accurately synchronised.

Configuring The System as an Authoritative NTP Server

If you want your system to become an authoritative NTP server from which other internal routers or machines can synchronise, you can achieve this with the following command:

The router now acts as an NTP server and is able to respond to internal clients NTP requests. Checking the 'ntp association' will reveal that the router is obtaining its time synchronisation from itself:

Troubleshooting and Monitoring NTP Status

Troubleshooting NTP messages and events is important when you are trying to verify everything is working correctly. You might notice that your Cisco router is not able to create a peer connection with a configured NTP server or your internal LAN clients might not be able to synchronise with your Cisco router; In any case, knowing how to troubleshoot NTPs is something every engineer must be aware of.

Thankfully Cisco provides a number of options that allow you to troubleshoot many aspects of your NTP service.

The most useful debug commands are the 'debug ntp events', 'debug ntp adjust' and 'debug ntp core'. These three commands provide enough debugging to help you troubleshoot problems you might encounter.

Closing, if you would like more information on the ntp associations created by your router you can try the following command:

The 'show ntp associations detail' command will provide much information on the association created with the NTP servers. This is most helpful when you see you are unable to create an association with an NTP server.

Hosting your own webserver or email server would normaly require a static IP address from your ISP. This ensures that your services are always reachable using the same IP address or domain name.

If you had a domain name, e.g firewall.cx, you would then map your static IP address to your domain (via DNS) so when you hit your domain name, you would be directed to your statically assigned IP address and access the resources you need.

While this is the recommended setup for most companies doing serious business, it doesn't really apply to home users or small branch offices because of the increased cost for static IP addresses.

Luckily, a few years back, a couple of new DNS providers came up with Dynamic DNS or DDNS. DDNS providers essentially allow you to register and create a Fully Qualified Domain Name (FQDN) without cost and, by using their clients (usually programs installed on a PC in your local network), you can instanteously update your FQDN every time your ISP changes your IP address. This eliminates the need for a static IP address, since your DDNS provider will automatically update its DNS records with your dynamic IP address every time it changes.

From Cisco IOS version 12.4 onwards, Cisco routers have built-in support for a variety of DDNS providers, making it much easier and more reliable as you no longer require a PC in your network that will run the DDNS provider's client.

This article aims to teach you how you can configure your Cisco router so it can support DDNS with a variety of DDNS providers.

Example Scenario

Consider the following network diagram. It shows the simple logic of how DDNS works:

Firstly we need to configure our Cisco router to register and send its periodical updates to the DDNS provider. Once received, the DDNS provider updates the relevant DNS records, in our example, firewallcx.no-ip.info.

When an Internet host queries the DDNS provider for the domain firewallcx.no-ip.info, it will then point the host towards the public IP addresses currently assigned to the router, that is, 195.162.29.1. As the ISP changes the IP address it assigned to the Cisco router, the router in turn will also update its DDNS provider. This way, the domain firewallcx.no-ip.info is always updated no matter how many times its IP address changes.

So, without further delay, here's how you can configure your Cisco router to register with the following DDNS providers:

1) No-ip.com

2) Dyndns.com

Case No.1: No-ip.com

First step is to enable the DNS service and configure an IP name server (public DNS server) so it can successfully resolve Internet domain names. For our example, we are using Public DNS servers.

Next, we need to enable the DDNS update service and give it a name (no-ip), and then select the update method to be used, for this example, it's HTTP:

Now we add the authentication details. The router will use this information to authenticate to the DDNS provider so it can then update the necessary hostname. We should note that each DDNS provider uses its own authentication method & parameters. In No-ip.com's case, it makes use of a login name & password, where the login name is your registered email address.

The command will look something like this:

add http://email:password@dynupdate.no-ip.com/nic/update?hostname=&myip=

As we said, the login name is your registered email address. This means that the full syntax above will contain two '@' characters, which can create a problem with the URL sent to the DDNS provider. Also, the '?' character cannot be inserted straight into the command as the router will think you're asking for help and give you errors!

In order to overcome all possible problems, we've replaced these characters with their equivalent HTML codes, so the @ becomes %40, and the ? becomes %3F:

The will be substituted with the FQDN that needs to be updated (firewallcx.no-ip.info) which we will configure next, and the will be substituted with the IP address of the interface we have enabled for the DDNS updates.

In the next step, we set the update interval, to ensure the FQDN is updated as frequently possible, but without causing problems to the DDNS provider:

The above command sets the update interval to 0 Days, 0 Hours, 5 Minutes and 0 Seconds.

All that's left now is to set the FQDN we'll be updating and enable the DDNS service on our public interface (usually your Dialer 0 or public Ethernet interface):

This completes the setup and your router should start sending its updates to the DDNS provider.

If you see that your FQDN hasn't been updated after 5-10 minutes, then you can also use the following debug commands (hit CTRL-Z first) to get an idea of what's happening in the background:

Here are the results of our debug:

Case No.2: Dyndns.com

Dyndns.com requires a similar configuration as our previous DDNS provider, however, the HTTP authentication string is slightly different, and you'll need to adjust your update interval to once a day rather than every 5 minutes. The interval adjustment is very important as Dyndns.com is unfortunately less forgiving than No-ip.com and will lock your account if multiple updates occur without your IP address having been changed!

The following cli code is the actual configuration required up till the authentication method:

The HTTP authentication string required for Dyndns.com will look something like this:

add http://username:password@members.dyndns.org/nic/update?system=dyndns&hostname=
&myip=

Notice that the authentication string is slightly different. As with our previous example, to ensure we overcome all possible problems, we'll replace the '@' and '?' characters with the HTML equivalent codes, so the @ becomes %40, and the ? becomes %3F. Here's the full picture:

Again, the will be substituted with the FQDN that needs to be updated (firewallcx.dyndns.info) which we will configure next, and the will be substituted with the IP address of the interface we have enabled for the DDNS updates.

In the next step, we set the update interval to ensure the FQDN is updated as frequently as possible, but without causing problems to the DDNS provider, for Dyndns.com, that's once a day:

The above command sets the update interval to 1 Days, 0 Hours, 0 Minutes and 0 Seconds.

All that's left now is to set the FQDN we'll be updating and enable the DDNS service on our public interface (usually your Dialer 0 or public Ethernet interface):

This completes the setup and your router should start sending its updates to the DDNS provider.

If you see that the your FQDN hasn't been updated after 5-10 minutes, then you can also use the following debug commands (hit CTRL-Z first) to get an idea on what's happening in the background:

Here are the results of our debug:

Article Summary

In this article we've covered how to enable and configure Dynamic DNS for popular no-ip.com and dyndns.com. We've seen the process in great depth and analysed all commands required to get the service up and running, but also debug it in case of problems.

Closing, we hope the article comes in handy and answers your questions regarding the configuration of DDNS on Cisco routers.

Password recovery is a fairly frequently used procedure for administrators and engineers. Even though we usually stack our passwords in some word, excel or text file, it's very easy to forget to update them when changes occur. The end result is you find yourself locked out of the device, wondering what on earth could be the password.

Accessing a Cisco router requires certain privileges. Depending on the router's configuration, you might be required to firstly log into the router and then enter the popular 'enable' password to elevate your access to privileged mode, from where you can issue configuration commands.

This article will show you how you can gain full administrator access to a Cisco router, bypassing all security passwords. The password recovery process, however, can be rendered useless if the administrator has previously configured the router not to allow this process to take place. In this case, the router will warn the user and, if he proceeds, all configuration will be erased, so there will be nothing to recover!

Example Scenario

Consider we have a Cisco router (2610 for our example - this procedure is the same for all routers) and we are unable to access it due to a lost password. Console and VTY (telnet) sessions ask for a password which we do not have:

Even if we were able to successfully log into the router, but couldn't provide the router with the correct 'enable' password, we would still need to perform a password recovery procedure.

To initiate the password recovery procedure, connect the rollover cable to the console port, then power the router off and back on. As soon as you receive a prompt showing the boot process, hit Ctrl-Break:

You'll immediately see the 'rommon' prompt, indicating we are in 'rom monitor' mode. This is a mini-IOS that allows you to perform very specific tasks in order to recover your router.

Now, to skip our password-protected configuration, we instruct the router to by-pass the configuration located in NVRAM during bootup, and reset the router:

The router will now reset and start its normal bootup process, however, the current configuration will be ignored. When the bootup is complete, you will be prompted to 'enter the initial configuration dialog', answer 'no':

Next step is to enter 'Privileged Mode' and load the router's configuration from nvram. Then reset the 'enable' or 'secret' password. To be sure, we're showing how to reset both, but we'll only need to use the 'secret' password. In addition, we are going to reset the console port's password:

If you use the 'login local' command you'll need to reset the user account of the password you have lost (in our example, it's 'admin').

Lastly, we need to change the 'configuration register' so the router will load the newly modified configuration next time it reboots, save our settings and reboot the router:

The router will now reload and use the new configuration that contains the newly set passwords.

When the router reboots, log in and check your configuration. If you find any interfaces in the 'shutdown' state, you'll need to use the 'no shutdown' command to bring them back up. Again, don't forget to save your configuration!

NAT (Network Address Translation) is a method that allows the translation (modification) of IP addresses while packets/datagrams are traversing the network. Dynamic NAT enables multiple internal hosts access to the Internet by assigning each host a unique real (Public) IP address for the duration of the session.

Once the internal host stops sending and receiving packets from the Internet, the router's NAT timeout will clear the Dynamic NAT entry from its NAT table, making the real IP address available to the next internal host.

The following steps explain basic Cisco router Dynamic NAT configuration. If you would like to read more on the NAT theory, be sure to read our popular NAT articles, which explain in great depth the NAT functions and applications in today's networks. Lastly, if you're only interested in Dynamic NAT, you can simply follow this link and read up on our theoretical example covered on Firewall.cx.

Example Scenario

The diagram below represents our example network, which consists of a number of internal clients trying to access the Internet via our router. The router is connected to the ISP via its serial interface. The company has been assigned the following Class C subnet: 200.2.2.0/29 (255.255.255.248). This translates to the following usable Public IP addresses: 200.2.2.1 - 200.2.2.6.

As one would expect, we need to sacrifice two IP addresses: one for the router's serial interface and one for the ISP's router. This leaves us with the following pool of usable Public IP addresses: 200.2.2.2 - 200.2.2.5.

The goal here is to configure the router to dynamically allocate the pool of Public IP addresses to our internal network.

Configure Dynamic NAT

Dynamic NAT configuration is a pretty straightforward process and is almost identical to other types of NAT configurations. The first step in any NAT configuration is to define the inside and outside interfaces. It is imperative that we define these interfaces for the Dynamic NAT service to function.

Set the fast ethernet 0/0 interface as the inside interface:

Next step is to set the serial interface S0/0 as the outside interface:

Next step is to create our pool of Public IP addresses that will be handed out by the router to our internal hosts trying to connect to the Internet. Each time a host sends a packet destined for the Internet, the router will automatically allocate one of the Public IP addresses for the length of that session.

When the session is over, the NAT entry will timeout and the Public IP address is released, making it available once again to the Dynamic NAT pool. Let us define the NAT Pool:

We now need to create an Access Control List (ACL) that will include local (private) hosts or network(s), depending on how large the internal network is.

This ACL will be applied to the NAT pool named 'Public-IPS', effectively controlling the hosts that will be assigned a Public IP address and therefore able to access the Internet.

You can use standard or extended access lists depending on your requirements:

The above command instructs the router to allow the 192.168.0.0/24 network to use the NAT Pool and provide each host with a unique Dynamic Public IP address. Note that Cisco router standard and extended ACLs always use wildcards (0.0.0.255).

Verifying Dynamic NAT operation

By viewing the Dynamic NAT table you can easily verify that the internal hosts are correctly being assigned a Dynamic IP address from the configured pool:

As shown, two internal hosts (192.168.0.6 & 192.168.0.8) have each been assigned an external IP address from the pool we previously created.

These translations will eventually timeout if no activity is present from the internal hosts, however, if you need to forcibly clear them this can be easily done by entering the following command:

Assuming no request has been sent right after the command was entered, the NAT translation table should be empty:

Lastly, you can obtain statistics on the Dynamic NAT service. This will help you monitor the usage of your Dynamic NAT pool and available public IP addresses:

Article Summary

In this article we've covered the configuration of Dynamic NAT on Cisco routers. We also saw how you can control the Dynamic NAT service using ACLs and obtain detailed statistics on the NAT service. The configuration and commands presented here are compatible with all Cisco router models and IOSs.

DHCP (Dynamic Host Configuration Protocol) is the protocol used by network devices (such as PCs, network printers, etc) to automatically obtain correct network parameters so they can access network and Internet resources such as IP Address, Default Gateway, Domain Name, DNS Servers and more.

A DHCP Server is considered necessary in today's networks. Devices usally found providing this service are Windows servers, routers and layer 3 switches.

This article describes how to configure basic DHCP parameters on a Cisco router, enabling it to act as a DHCP server for your network.

Example Scenario

For the sake of this article, suppose we have the network shown in the following diagram, for which we would like to enable the DHCP service on our Cisco router.

The router will act as a DHCP server for the 192.168.1.0/24 network. IP Addresses already assigned to our switch (192.168.1.2) and File Server (192.168.1.5) will be excluded from the DHCP pool, to ensure they are not given out to other hosts and cause an IP address conflict.

First step is to enable the DHCP service on our router, which by default is enabled.

Next step is to create the DHCP pool that defines the network of IP addresses that will be given out to the clients. Note that 'NET-POOL' is the name of the DHCP IP Pool we are creating.

This tells the router to issue IP addresses for the network 192.168.1.0, which translates to the range 192.168.1.1 - 192.168.1.254. We will have to exclude the IP addresses we want later on.

We now define the DHCP parameters that will be given to each client. These include the default gateway (default-router), dns servers, domain and lease period (days).

The 'domain-name' and 'lease' parameters are not essential and can be left out. By default, the lease time for an IP address is one day.

All we need now is to exclude the IP addresses we don't want our DHCP server giving out. Drop back to 'global configuration mode' and enter the following:

This excludes IP addresses 192.168.1.1 - 192.168.1.5 & 192.168.1.10. As you can see, there's an option to exclude a range of IP addresses or a specific address.

The above configuration is all you need to get the DHCP server running for your network. We'll provide a few more commands you can use to troubleshoot and ensure it's working correctly.

The following command will allow you to check which clients have been served by the DHCP:

Notice that IP addresses 192.168.1.5 & 192.168.1.10 have not been given out to the clients.

Article Summary

In this article we've covered how a Cisco router can be used as a basic DHCP server and the various options available. We also saw how you can obtain general information about the service. There are more options available with the DHCP service, however this basic article should cover most of your network needs.

Future DHCP articles will explore advanced options and debugging for more complex networks containing VLANs and IP Telephony.