During network operations an administrator needs to manage configuration files (save, modify and reload) as well as operating system files (backup, update, recover). In Packet Tracer we can do many things which can be applied in real life, so in this article we’ll review them.
CCNA Training – Resources (Intense)
We’ll use a simple topology for the various scenarios:
The server can contain files and will be used as a TFTP and FTP server. The laptop will be the administrator’s machine. The subnet is 10.0.0.0/24 and the last octet of the address is shown at every device.
Our first mission is to make a basic configuration on the switches, which contain almost the same commands to enter except the hostname and the IP address of the VLAN1 management interface. We can start on SW1 and enter the following configuration:
Before we save this as the startup configuration, let’s look at the Flash drive of the switch issuing the show flash: command (or we can use the dir command as well):
We can see the IOS image file (on some switches this is in a subdirectory). Now save the configuration with the copy running-config startup-config command and let’s look at the Flash again. Do you notice anything new? Yes, a new file called config.text is created. But what can it be?
Let’s look into it, issue: more flash:config.text. As we can recognize, this is the saved startup configuration. But it’s odd: this should be in NVRAM, shouldn’t it? Well, on the real 2950 and 2960 series switches we can list the NVRAM content and there we can find the startup-config as well, but this file is mapped to the Flash also. Let’s try to delete this file, but before we do, make a copy of it somewhere.
One easy way to do this is to select the Config tab on the switch, and click the Export… button near the Startup Config label. This will open a file saving dialog box which can be used to save the configuration file on the host machine under the name SW1_startup-config.txt.
Now we can issue the delete flash:config.text command, and check the effect through the show startup-config command: it states that startup-config is not present. So we now know another method besides erase startup-config to reset the startup configuration. But there’s a third method as well.
Let’s load the saved configuration back to the device under the Config tab; the startup-config is here again. Modify something in the running-config, for example turn on the RSTP protocol, and then we’ll save the configuration in another way. There’s the write command in privileged EXEC mode which can be used for that.
First try the write terminal command: it lists the running configuration. The write memory (or wr for short) command does the same as copy running-config startup-config, but Cisco recommends the latter and in some cases it cannot be used on exams, so be prepared! On real devices, on the other hand, it’s much easier to enter the wr command.
The last parameter we can use along with the write command is erase, which causes the deletion of the startup configuration. Finally, we can use two buttons from the Config tab to do these activities very easily: the Erase and Save buttons near the NVRAM label.
Now we know many ways to save and delete startup configurations, but to configure the second switch the easiest way, we need to transfer it to the device, with some modification. In order to do this, edit the saved file and replace the hostname and IP address parameters, then open the Config tab of the second switch and choose the Load… button, or if you want the configuration to take effect immediately, choose the Merge… button. It means that you can do some modification in the running configuration, and you can load a saved configuration after this, but then these two data sources will be merged. For example, if you set a hostname, and the saved configuration contains the same value, that will be the actual one.
If you have many switches that need to be configured with almost identical settings, it can be a good practice to create the configuration “offline”. It means that we write the necessary commands into a text editor, and paste the text into the console window. This has several advantages:
We can save the command list for future use and reference.
Many times we just need some minor modifications to apply to the configuration for a new device and it can be set up very quickly.
Some disadvantages are that we have to know the commands by heart (is it really a disadvantage? J), and we cannot use the CLI shortcuts.
In real life, pasting text from the clipboard depends on the terminal emulator you use. For example, in PuTTY it’s enough to right click into the text window, and in TeraTerm we can use Paste or Paste<CR> from the Edit menu. In Packet Tracer this method works by clicking on the Paste button on the lower right corner of the CLI window.
Another important task related to configuration files is to save them to external devices in order to prevent their loss in case of hardware (or other) failure. This can be achieved several ways. The most common method is by using TFTP. Trivial File Transfer Protocol is a simple UDP based service, and is ideal for transferring small files quickly.
First make a simple text file with the base configuration commands for the three routers, for example:
Now copy this text to the clipboard, go to the CLI of Router1, press Enter to access user mode and then click Paste – and the device is now configured! Now modify the hostname and IP address for R2 and R3 and repeat the steps. For the 1941 type router we should modify the interface name also, from f0/0 to g0/0!
Now, still on Router3, try to ping the server to check connectivity, then look at the Services tab on the server and click on TFTP. We don’t have to configure too many things, just check if the service status is On and look at the file list: these files can be downloaded from the server (all of them are various IOS images). Next go back to Router3, enter privileged mode and issue the following command:
copy running-config tftp
This means that we want to copy the actual configuration to a TFTP server. By pressing Enter, the device will ask the IP address or name of the remote host (10.0.0.1 in this case) and the destination filename (it offers the name R3-confg, and if it’s acceptable, just press Enter), copies the data and outputs some statistics about the process. On a real device we can use the following syntax also:
copy running-config tftp://10.0.0.1/R3-config.txt
When we look at the TFTP file list again on the server, the R3-confg file is there. We can remove the file but not edit it, although sometimes it can be convenient to do so.
Let’s now look at a scenario where a firewall protects the server, but we still want TFTP to work. Go to the Desktop of the server and locate the Firewall. Turn the service on, and put a rule which blocks all inbound traffic:
By clicking the Add button, the rule comes alive and blocks any traffic from any source. As we can see, the logic and the syntax is very similar to that of the IOS ACLs. Now we need to put a new rule that allows TFTP traffic from the 10.0.0.0/24 subnet. The necessary information is that TFTP uses UDP protocol and port number of 69, so we can create the rule:
When we add the rule, it’ll be inserted after the “deny all” rule, so it won’t work. Unfortunately Packet Tracer doesn’t support the ordering of rules, so we need to delete the “deny all” rule first, and then add it again; this way that will be the last one.
Interestingly, the TFTP copy still doesn’t work. This is because TFTP uses arbitrary ports during data transfer: only the first packet uses the fixed destination port 69. So we need to open all the local UDP ports, which is not so good for security, but in this way TFTP will work.
The second file-related task is managing the IOS image files on Cisco routers and switches. The compressed image files reside in Flash, and we can do various things with them. First of all, it’s good practice to back them up to external servers just like the configuration files. For example, go to Router2 and issue the following commands:
So after we query the actual name of the image file, we can copy it from the Flash to a remote TFTP server. During the copy process we can see many exclamation marks stating that everything goes well.
Upgrading the IOS is technically the reverse process. First we need to check which IOS version we are using, for example with the help of show version command. Then we need to search for a new version and check if the hardware requirements (memory, Flash size) are met. If yes, then we have a decision to make: do we have to delete the old one, or can we try the new IOS while the old still remains on the Flash drive? Let’s try both situations.
Our R2 router is an 1841 type, and if we search for another IOS on the server, we can find an IPBASE and an IPBASEK9 version. If we use them, this will be a downgrade, but the process is the same in the case of an upgrade too. Suppose that we want to delete the old IOS and use just the new IPBASEK9 code set. Do the following:
The commands are self-explanatory. The image file name on the server can be copied to the clipboard with CTRL-C, fortunately. After issuing the reload command, the router should boot with the new IOS.
Now let’s try to find out what to do when we want to preserve the old IOS too. In this case we need enough space on the Flash, and we need to specify which image to boot. The first thing cannot be checked easily in PT as the file list doesn’t indicate the size of the file, but both the IPBASE and IPBASEK9 image will fit next to the ADVIPSERVICESK9 image. So go to R1 and download the image with the copy tftp flash command. At this step we have two IOS images, but which of them will boot? We can specify this using the boot system command, specifically:
R1(config)#boot system flash c1841-ipbasek9-mz.124-12.bin
After saving the configuration and reloading the router, the IPBASEK9 version should boot, but if you’re not satisfied with it, just delete the image from the Flash and the boot system command from the configuration.
With this command we can boot the system from TFTP as well. This is a good practice to try a new IOS without disturbing the Flash content. All we have to do is the following:
R1(config)#boot system tftp c1841-ipbase-123-14.T7.bin 10.0.0.1
So we need to specify the method (TFTP), the image filename and optionally the IP address of the server. If we don’t add this, the system will use the 255.255.255.255 broadcast address. Try it also, but one more important thing: we need to have the FastEthernet0/0 interface connected for this to work, as we cannot specify which one to use and this is used automatically as the first interface.
Besides TFTP we can also use FTP to transfer files. The main difference is that FTP uses authentication, so we need to specify a username and a password. This can be achieved by issuing the following commands:
R1(config)#ip ftp username cisco R1(config)#ip ftp password cisco
From now on we can use “ftp” keywords instead of “tftp” in every command we’ve seen so far. If we’re behind a firewall, we need to use one more command: ip ftp passive, which turns on the passive mode.
Finally we’ll do some disaster recovery. If the IOS image was accidentally deleted from Flash and there’s no boot system tftp command, the system cannot find an IOS and enters ROM monitor mode. We can easily simulate this by deleting the IOS from R2 and reloading it. In this situation we still have several methods to put an IOS into the Flash; in PT we can use the tftpdnld command. First of all we need to specify some settings through environment variables. When we issue the tftpdnld command, we can see what should be entered, in our case the following:
The settings can be listed through the set command, and if everything seems to be OK, then issue the tftpdnld command again. Now it can download the specified file from the TFTP server, and after this we can enter the reset command to reboot the device normally. I experienced an issue though: in the current version of PT (6.2) the device didn’t boot as expected, even after power off, so I had to save the file, close PT then open it again.
On real devices there are some more interesting things related to configuration and IOS management, so check them out too!