Chapter 6. General IOS Tasks

This chapter covers those tasks that are not really specific to the configuration of a network protocol. Management and troubleshooting tasks fall into that category. We also need to cover in a little more detail the steps necessary to configure interfaces and terminal lines since there are so many types of them.

  1. Simple Management Configuration Tasks
  2. Just like on any other network host, a router needs to certain items that uniquely identify it and make it easier to manage.

    1. Host Name
    2. All IOS-based routers must have a host name. The suggested guidelines were covered in Section 3.2.1; basically you can make the host name anything you want, but we suggest that it conform to the rules for Internet domain names specified in RFC 1035.

      The default host name is Router; however, you should always change it to something unique. Use the global configuration command hostname to change a router's name. The hostname command has a single argument, which is the word the host name should be. Here is an example.

      Dallas(config)#hostname Philadelphia


      By default, IOS puts the first 29 characters of the host name into the command line prompt of all modes. This allows us to tell immediately which router we are logged in to. When we are administering multiple routers in an internetwork, knowing which router we are looking at is extremely important. We would not want to shut down an interface or change an address on the wrong router would we?

      The default prompt can be no longer than 30 characters; this can cause a problem with the configuration mode prompts if the assigned host is more than about 15 characters. For example, let us set the host name to PhiladelphiaRouterNumber1.

      Philadelphia(config)#hostname PhiladelphiaRouterNumber1



      A normal prompt in global configuration mode has the letters config in parentheses. Since the host name is so long, the parentheses now contain only co. The will prevent us from determining our specific configuration mode by just looking at the prompt. The new host name is completely shown in the global configuration mode prompt and the privileged mode prompt. Let us change the host name back to its original value.

      PhiladelphiaRouterNumber1#configure terminal

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

      PhiladelphiaRouterNumber1(co)#hostname Dallas


      Remember to give each router a unique name. Even though Internet domain names are not case sensitive when referenced in Domain Name Service (DNS); the host name is displayed exactly as you typed it.

    3. Banners

An IOS banner is used to give information to users or administrators when they log in to a router via a terminal line. We are going to cover three types of banners.

    • MOTD (Message Of The Day)
    • Login
    • Exec

An MOTD banner is sent to a terminal as soon as the terminal's connection becomes active. A login banner is also sent to a terminal when a terminal becomes active; however, the login banner is displayed after an MOTD banner (if there is one). An exec banner is displayed to a terminal immediately after a person has successfully logged in.

We use the global configuration mode command banner to create a banner; its general form looks like this.

banner {exec | login | motd} dc message dc

The argument dc is a delimiting character. The delimited characters surround the message that is to be displayed to the person logging in. Each instance of dc must be the same within the entry of the banner. The delimiting character can be any character as long as it is not part of the message. The banner command should include one of the arguments exec, login, and motd; however all three types of banners can be created by issuing the banner command three times - one for each type.

Banners can have multiple lines. To create a multiple-line banner, type the command up to and including the first delimiting character, and press <Enter>. You will be given a blank line to type the banner message. When you have finished with the banner message, just type the delimiting character and <Enter> again.

Examples of banner creation are shown below.

FortWorth(config)#banner motd %

Enter TEXT message. End with the character '%'.

This is the motd banner.

System maintenance is scheduled for today at 1700 GMT.


FortWorth(config)#banner login %

Enter TEXT message. End with the character '%'.

This is the login banner.

You have accessed a private system.

Unauthorized access is prohibited.

If you don't belong here, leave.


FortWorth(config)#banner exec %

Enter TEXT message. End with the character '%'.

This is the exec banner.

So, you got in. So what! Who cares!

They're coming to take you away.



We have created each type of banner. The percent sign (%) was used as the delimiting character. Everything between the percent signs is the banner. When the configuration is displayed, IOS uses its own standard delimiter. Figure 6-1 shows the part of the running configuration containing the banners.

    1. FortWorth#show running-config
    2. [text omitted]
    3. !
    4. banner exec ^C
    5. This is the exec banner.
    6. So, you got in. So what! Who cares!
    7. They're coming to take you away.
    8. ^C
    9. banner login ^C
    10. This is the login banner.
    11. You have accessed a private system.
    12. Unauthorized access is prohibited.
    13. If you don't belong here, leave.
    14. ^C
    15. banner motd ^C
    16. This is the motd banner.
    17. System maintenance is scheduled for today at 1700 GMT.
    18. ^C
    19. !
    20. [text omitted]
    21. FortWorth#
    22. <<<Figure 6-1 Banners in Configuration File>>>

      Notice in Figure 6-1 that the banners are shown in an order different than the one in which we typed them. The configuration file order doesn't really matter to the banner function. The delimiting character is shown as the character pair ^C, which is IOS' way of displaying <Ctrl-C>. This could be significant if you get into the habit of typing exactly what you see from a configuration file onto the IOS configuration mode command line. Figure 6-2 shows how the banners look when we telnet from Dallas to Fort Worth.

    23. Dallas>telnet
    24. Trying ... Open
    25. This is the motd banner.
    26. System maintenance is scheduled for today at 1700 GMT.
    27. This is the login banner.
    28. You have accessed a private system.
    29. Unauthorized access is prohibited.
    30. If you don't belong here, leave.
    31. User Access Verification
    32. Password: letmein
    33. This is the exec banner.
    34. So, you got in. So what! Who cares!
    35. They're coming to take you away.
    36. FortWorth>

<<<Figure 6-2 Banner Output at Login>>>

The MOTD banner is displayed first on Line 4. The login banner is sent to the terminal starting on Line 7. We have not logged in yet; however, we have a connection. After typing the correct password (Line 15), the exec banner is displayed on Line 16 before we get a user mode prompt.

Since there is always a chance that an unauthorized person will gain access to your routers, the banners should contain very strong language that allows you to prosecute them. You may want to get your company's legal department involved in writing a banner that will hold up in a court of law.

There is one caveat about the login banner. It is not displayed unless the login command (Section and Section 6.3.1) is part of the terminal line configuration.

      1. Passwords
      2. IOS has many passwords; they are all used to protect IOS from unauthorized entry. We are going to cover the ones used to grant access to user mode and privileged mode.

        IOS passwords are case sensitive and can be no longer than 25 characters. The characters can be any combination of uppercase and lowercase letters, numeric digits, punctuation marks, and spaces; however, the first character cannot be a space.

        1. User Mode Access
        2. Access to user mode is configured on terminal lines such as the console or the VTY's; therefore the command enter passwords for user mode access will be entered in line configuration mode. Each terminal line can have its own password; however, assigning a different password to every terminal line may not be in our best interests.

          Two line configuration mode commands are required to assign a password to a line and have IOS check the password before granting access. The commands are password and login. The login command entered on a terminal line tells IOS to perform authentication (check for a password). The password itself is an argument of the password command. An example is shown below.

          Dallas(config-line)#password letmein



          This example sets a line's password to letmein and tells IOS to authenticate an incoming connection by making the user of the connection type the correct password at a password prompt.

          During the System Configuration Dialog in Chapter 3, only the VTY terminal lines were assigned passwords. All five VTY's (0 through 4) were given the same password, letmein. Usually, all VTY lines are given the same password. VTY's are allocated in random order for incoming telnet connections; therefore, we never know which VTY will be given to us when we telnet to a router. We get three chances to type a VTY line's correct password before IOS terminates our telnet connection. We then have to establish another telnet connection; we will probably be given a different VTY than we had the time before. If all VTY's have different passwords, our password guessing exercise could take a long time. The more VTY's the router has, the longer it could take to type the correct password and get in, even if we know all the passwords.

          If a router's VTY lines are not password protected, no one will be able to telnet to the router. This effectively disables telnet access completely. IOS attempts to save us from ourselves by not leaving the doors to our router wide open.

          The console and auxiliary lines can also be given a password. Protecting a router's console port with a password is a recommended practice, especially if physical access to the router is unsecured. If a modem has been installed on the auxiliary port, the auxiliary port should definitely have a password.

          Configuring locally-assigned passwords is not the only way of granting user mode access. We can also control user mode access using CiscoSecure (TACACS+) or Radius. These access mechanisms require an external server and are not covered here.

        3. Privileged Mode Access

Remember that a person in user mode cannot do must harm to a router; the person can essentially look but not touch. Just about anything except the configuration files can be displayed from user mode. Once someone has been granted access to privileged mode, that person can do whatever he or she wants to do, like shut down an interface, change a password, or reboot the router. For this reason, IOS has passwords for privileged mode access.

There are two passwords for granting access to privileged mode. Both are forms of the enable password. There is the regular enable password, which is by default shown in clear text in a configuration file, and there is the enable secret password, which is always shown as encrypted in a configuration file.

The commands to set the enable passwords are both global configuration commands. The enable password command creates or changes the regular enable password, and the enable secret command creates or changes the enable secret password. Both commands take the actual password as an argument.

The enable secret password overrides the enable password. If an enable secret password is in the running configuration, it is used to get to privileged mode, and the enable password is ignored. The enable password is used only if the enable secret password does not exist or if the IOS image does not support the enable secret password.

If running configuration contains neither type of the enable password, a user on a console terminal will not be prompted for a password after typing the enable command to get to privileged mode. On the other hand, if neither type of enable password exists, a user who has established a telnet session to the router will not be allowed to enter privileged mode unless a password has been assigned to the router's console terminal. In that case, the console password is used to enter privileged mode. If we run the System Configuration Dialog, IOS forces us to set both types of enable passwords but not a console password.

The enable secret and enable passwords should have different values. It does no good to encrypt one of the passwords if you have the unencrypted version of the password right next to it. If you attempt to make the passwords identical, IOS will complain to you and ask you to make them different; however, IOS will allow them to be the same. Look at the following example.

Router(config)#enable secret itsasecret

Router(config)#enable password itsasecret

The enable password you have chosen is the same as your enable secret.

This is not recommended. Re-enter the enable password.


The IOS tells us to re-enter the enable password if we make it the same as the enable secret password, but if we examine the running configuration, we see that the enable password was accepted. Figure 6-3 shows this.

    1. Router#show running-config
    2. [text omitted]
    3. !
    4. enable secret 5 $1$hEby$WJlwC0Vp/VQEC4Hcxc0Dg/
    5. enable password itsasecret
    6. !
    7. [text omitted]
    8. Router#

<<<Figure 6-3 Enable Passwords in Configuration File>>>

Lines 4 and 5 of Figure 6-3 show the password itsasecret in its encrypted form and its unencrypted (clear text) form. The enable secret password cannot be understood by someone who is looking over your shoulder while you are reading the running configuration file.

The three types of passwords that we have talked about so far - line, enable secret, enable - should all have different values.

        1. Encryption

IOS allows us to encrypt all of our passwords in the configuration files. The default is to have only the enable secret password encrypted. The encryption algorithm used for the enable secret password is one-way; IOS cannot decrypt the password.

If we could like the other passwords encrypted in the configuration file, we can start the IOS password-encryption service. We use the global configuration command service password-encryption to start the service. This service will use a two-way encryption algorithm to encrypt the passwords in the configuration file; IOS can decrypt these passwords, and so can you.

We can tell by looking at a password entry in the configuration file which encryption algorithm has been used. Figure 6-4 shows some configuration file passwords.

    1. Dallas#show running-config
    2. !
    3. enable secret 5 $1$S.px$gAcVrJaShGu2x6Rvu/F1C/
    4. enable password 7 121C0B16100709092F
    5. !
    6. [text omitted]
    7. line vty 0 4
    8. password 7 011F0310560E0F01
    9. [text omitted]
    10. Dallas#

<<<Figure 6-4 Encrypted Passwords in Configuration File>>>

The enable and VTY line passwords have been encrypted. The enable secret password maintains is original form; the encryption algorithm is indicated by the numeral that immediately precedes the password. There are several possible values

    • The numeral 7 indicates that the password is encrypted with the two-way algorithm.
    • The numeral 5 indicates that the password is encrypted with the one-way, secret algorithm.
    • The numeral 0 (or no value) indicates that the password is being displayed in its unencrypted form.

If you turn off password encryption with the no service password-encryption command, the passwords will remain encrypted until you enter them again.

      1. Command Prompt

The IOS user mode and privileged mode prompts normally have a router's host name (the first 29 characters of it) and a trailing character that indicate the command mode. You can change the prompt by using the global configuration command prompt.

You can make the prompt whatever you want it to be up to a maximum of about 29 characters. IOS has some escape sequences available for putting special values into the prompt. These are as follows:

    • %h - The router's host name.
    • %n - The absolute line number that is being used by the user.
    • %p - The prompt character that can be either the greater-than sign (>) for user mode or the number sign (#) for privileged mode.
    • %s - The space character.
    • %t - The tab character.

Setting the prompt will change only the user mode and privileged mode command prompts. The configuration mode prompt will not be affected. The configuration mode prompt always has the host name and as much of the configuration mode indicator text (for example, (config) and (config-if)) as possible unless you turn it off completely with the global configuration command no service prompt config. Figure 6-5 shows an example of changing the command prompt.

    1. Dallas#configure terminal
    2. Enter configuration commands, one per line. End with CNTL/Z.
    3. Dallas(config)#prompt %h%sLine%s%n%p
    4. Dallas(config)#<Ctrl-Z>
    5. Dallas Line 0#
    6. Dallas Line 0#configure terminal
    7. Enter configuration commands, one per line. End with CNTL/Z.
    8. Dallas(config)#no prompt
    9. Dallas(config)#<Ctrl-Z>
    10. Dallas#

<<<Figure 6-5 Changing the Command Prompt>>>

Line 1 of Figure 6-5 shows the default, privileged mode prompt. The prompt is changed on Line 3 with the prompt command. After the command is entered, the configuration mode prompt does not change. Upon leaving configuration mode, we see that the privileged mode prompt has changed to the configured value that has the host name (%h), a space (%s), the word Line, another space (%s), the absolute TTY number (%n), and the prompt character (%p). We see from the command prompt on Line 5 that we are using the console terminal (line 0) to configure this router. To set the prompt back to its default value, use the no prompt command as shown on Line 8.

      1. Address Resolution

When you type a single word on the user mode or privileged mode command line; IOS assumes that word to be a command. If the word is not a command, IOS will by default assume that the word is the name of a host to which a telnet session should be established. At the network layer, hosts are not identified by names; they are identified by addresses; therefore, there must be a way to get (lookup) the IP address associated with a given host name.

Address resolution is the process of looking up the IP address of a host given its name. There are two ways to perform address resolution.

    • Domain Name Service (DNS)
    • Local host table

DNS is an application that runs on a server. The server accepts a request containing a host name and looks up the IP address associated with the host name. The server replies to the sender with the IP address of the requested host name. The sender can then use the IP address to build a packet for the destination host.

IOS is capable of sending a request to a DNS server asking for the IP address of a host to which it wants to telnet, ping, or traceroute. DNS lookups are turned on by default. Normally, a host that can send DNS requests for address lookups has the address of a DNS server configured. The default DNS server address for IOS is, the broadcast IP address. So when you reference a host name that should be looked up, IOS will broadcast a request out all interfaces looking for a DNS server to perform the lookup.

Routers block broadcast packets; therefore, if IOS sends an IP broadcast packet looking for a DNS server, the server will not get the packet unless the server is on the local network directly attached to the requesting router. The resulting message looks like this.


Translating ""...domain server (

% Unrecognized host or address, or protocol not running.


The DNS request for the IP address of

was sent to the broadcast address. Since there was no DNS server on a directly-connected network, the DNS request failed. This failed DNS lookup takes about 10 seconds to timeout. This can be annoying if you make a mistake typing a command.


Translating "pong"...domain server (

% Unknown command or computer name, or unable to find computer address


In the above example, we wanted to perform an extended ping, but the word pong was typed instead of ping. Since pong is not a command, IOS assumed that this was the name of a host to which to telnet. The DNS lookup to the broadcast address failed an cost us 10 seconds, which is not very much time unless you are watching and waiting for it to end.

If you are going to depend on DNS for address resolution, you should define the address of a DNS server to which IOS can direct its requests. You can define up to six DNS server addresses. The command to configure them is ip name-server followed by the DNS server address, or addresses. The ip name-server command is a global configuration command. Figure 6-6 shows the use and effect of the command.

    1. Dallas#configure terminal
    2. Enter configuration commands, one per line. End with CNTL/Z.
    3. Dallas(config)#ip name-server
    4. Dallas(config)#ip name-server
    5. Dallas(config)#<Ctrl-Z>
    6. Dallas#ping
    7. Translating ""...domain server ( [OK]
    8. Type escape sequence to abort.
    9. Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
    10. !!!!!
    11. Success rate is 100 percent (5/5), round-trip min/avg/max = 80/80/80 ms
    12. Dallas#pong
    13. Translating "pong"...domain server ( ( (
    14. % Unknown command or computer name, or unable to find computer address
    15. Dallas#
    16. <<<Figure 6-6 DNS Server Assignment and Effect>>>

      Lines 3 and 4 of Figure 6-6 show the assignment of three DNS servers for lookups. IOS puts these into the running configuration in the order that they are entered. The order that they are entered is also the order in which they are tried. The ping to on Line 6 causes a DNS lookup, which succeeds as shown on Line 7. The first DNS server replied with the IP address, which was then pinged on Line 9. On Line 12 is the erroneous entry of the word pong instead of ping. IOS attempts to find the IP address of the host pong by sending requests to each of the DNS servers in order. All of the requests for pong fail.

      If you have a DNS server that you want IOS to use, then you should configure IOS with the address of the server. However, if you do not want to use DNS lookups for address resolution, then you should disable the process to stop IOS from sending the requests to the default DNS server address of The entry of the command that disables DNS lookups is shown below.

      Dallas(config)#no ip domain-lookup


      To turn DNS lookups back on (the default), use the command ip domain-lookup.

      A local host table can be used for address resolution, too. A local host table is just a table containing entries for the names and addresses of hosts that you frequently access. You can put entries into the host table in global configuration mode with the ip host command. Here are some examples of host table entries.

      Dallas(config)#ip host FortWorth

      Dallas(config)#ip host pong


      The ip host command's first argument is the name that you use to reference the host. After that, you can put up to eight IP addresses that the host has. When you attempt to telnet to the host by name, IOS will try the IP addresses in order until it finds one that works or they all fail. When you ping or traceroute by name, IOS will use only the first address from the table.

      IOS always tries to lookup a name in the host table before it tries DNS, if DNS lookups are enabled. To see the contents of the host table, use the user mode command show hosts as shown in Figure 6-7.

    17. Dallas>show hosts
    18. Default domain is not set
    19. Name/address lookup uses domain service
    20. Name servers are,,
    21. Host Flags Age Type Address(es)
    22. (temp, OK) 0 IP
    23. (temp, OK) 8 IP
    24. FortWorth (perm, OK) 0 IP
    25. pong (perm, OK) 0 IP
    26. Dallas>

<<<Figure 6-7 Show Hosts Command Output>>>

The table shows the hosts that IOS knows about along with their addresses (up to eight). The Flags column shows temp if the entry was made by a DNS lookup or perm if the entry was made with the ip host command. IOS caches host names and their DNS-derived addresses in the host table so it does not have to perform another DNS lookup the next time that the host name is referenced. The Age column shows how many hours have passed since an entry was last referenced.

If you would like to clear the host table, you can issue the privileged mode command clear host. You can clear a single host table entry by name as shown below

Dallas#clear host pong


Or you can clear the entire host table as shown next.

Dallas#clear host *


The clear host pong command removes pong from the host table, and the clear host * command removes all entries from the table.

Configuring a host table entry for each of the routers in your network will allow you to access those routers easily by name without having to memorize their addresses.

    1. Interface Tasks
    2. The configuration of individual interfaces is done from either interface configuration mode or subinterface configuration mode. The global configuration mode command interface is used to get to these modes. The interface command has two arguments: the interface type and the interface (or subinterface) number. The interface type and number can be separated by a space or typed together. The following sections provide plenty of examples.

      1. Interface Types
      2. The types of interfaces available on a Cisco router come in two major classifications: physical and logical. Physical interfaces have connections on the outside of a router, and logical interfaces exist only in router memory. A subinterface is a special type of logical interface. These three types of interfaces are covered in the next sections.

        1. Physical Interfaces

Physical interfaces are pretty easy to recognize. They are the ones that you plug cables in to on the outside of a router. All routers have at least two of them. Examples of physical interfaces are as follows:

    • Ethernet
    • Fast Ethernet
    • Token Ring
    • Fiber Distributed Data Interface (FDDI)
    • Serial
    • Basic Rate Interface (BRI)
    • High-Speed Serial Interface (HSSI)

The presence of these interfaces depends on the router model and how it is configured. If a router has a physical interface, the interface's configuration commands exist in the running configuration even if you are not using the interface. The commands for configuring physical interfaces must be entered in interface configuration mode. You use the global configuration mode command interface to specify which interface you wish to configure, and IOS will put your terminal session into interface configuration mode. Figure 6-8 shows an example of physical interface configuration.

    1. Dallas(config)#interface ethernet0
    2. Dallas(config-if)#ip address
    3. Dallas(config-if)#interface serial1
    4. Dallas(config-if)#ip address
    5. Dallas(config-if)#

<<<Figure 6-8 Physical Interface Configuration>>>

In Figure 6-8, we configured IP addresses on Ethernet0 and Serial1. Since we wanted to configure Ethernet0 first, we typed the command interface ethernet0 to get into interface configuration mode for Ethernet0. Notice that the prompt changed to contain (config-if). Once there, we could enter commands specific to Ethernet0 such as the ip address command on Line 4. Next we wanted to configure Serial1 so we typed the command interface serial1 (Line 5). Remember that interface is a global configuration mode command and global configuration mode commands can be typed in any of the configuration modes. The interface serial1 command puts us into interface configuration mode, for Serial1, where we can enter commands specific to Serial1.

IOS does not show us, on the command line, what interface we are configuring. It is up to us to keep track of it.

Usually interfaces are reference by their abbreviated types. Abbreviating the interface type save time and typographical errors. For example, Ethernet can be abbreviated with the letter E. This would allow us to reference the first Ethernet interface on the router in Figure 6-8 as E0 (or e0). Serial can be abbreviated with the letter S; so the second serial interface of the Figure 6-8 router is S1 (or s1).

Occasionally, we will see interface abbreviations in the output of show commands, and we will use them in some command line examples.

        1. Logical Interfaces

Logical interfaces are special-purpose interfaces that we create as we need them. They have no external connections, and they exist only within router memory. Logical interfaces are neither LAN interfaces nor WAN interfaces. IOS treats logical interfaces just like physical interfaces in that they are configured using the same steps, once they are created. The major, common characteristic of logical interfaces is that they do not go down unless someone shuts them down. Here are some examples of logical interfaces:

    • Loopback
    • Tunnel
    • Dialer
    • Null
    • Bridge-Group Virtual Interface (BVI)

A loopback interface is used when we need a dummy interface to reference; it does not connect to anything. A loopback interface can be used for monitoring the router from a network management application, like one that uses SNMP. If you monitor a router based on a single interface and that interface goes down, the network management application will assume that the entire router is down; this may not be true. If you monitor a router based on a loopback interface, which never goes down, the network management application, which was monitoring the physical interface that went down, will now report that the interface, rather than the router, is down as long as the application has any path to the router.

A tunnel interface is used when we need to pass protocol traffic across a network that does not normally support the protocol. For example, you might use a tunnel to get IPX traffic across a network that supports only IP traffic. When building a tunnel, there must be two routers with tunnel interfaces referencing each other.

Dialer interfaces are used in dial-on-demand routing (DDR). They can be used to create rotary groups for interfaces that support DDR.

The null interface is a special interface that leads nowhere. You can think of it as the bit bucket, the place to throw traffic we do not want.

A BVI is used for integrated routing and bridging (IRB). IRB allows IOS to both route and bridge the same protocol; something it cannot normally do.

We create a logical interface by referencing it with the interface command. The exception to this is the null interface; we do not have to manually create the null interface. Once we've created a logical interface, the steps to configure are the same ones used to configure a physical interface. Figure 6-9 shows the creation and configuration of a loopback interface.

    1. Router(config)#interface loopback0
    2. %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
    3. Router(config-if)#ip address
    4. Router(config-if)#ipx network badd00d
    5. Router(config-if)#

<<<Figure 6-9 Loopback Interface Configuration Example>>>

Logical interfaces can have any number from 0 to 2,147,483,647 (231-1). Most administrators pick small numbers to make it easy on themselves. On Line 1 of Figure 6-9, we made the loopback interface number zero (0). Since this was the first time that the Loopback0 interface was referenced, IOS created it and immediately brought it up. Just for this example, we assigned an IP address and an IPX network number to the interface. Logical interface configuration is done from interface configuration mode.

        1. Subinterfaces

A subinterface is a special logical interface that is bound to a physical interface, yet referenced as a separate interface. It is kind of a hybrid interface, and it is either a LAN interface or a WAN interface depending on the physical interface from which it was created. A subinterface takes some of its properties from its physical interface, but it can have its own layer-3 properties such as IP address and IPX network number.

The most prevalent use of subinterfaces is found in the configuration of frame relay connections. On a frame relay connection, we typically have many logical (or virtual) connections coming into the router through a single physical serial interface. The frame relay logical connections are called Permanent Virtual Circuits (PVC) and are created by our frame relay service provider to give us a communications channel through the frame relay network to another device. Subinterfaces can be created to service the PVC's coming into a physical interface. In frame relay, there are two kinds of subinterfaces - point-to-point and multipoint. The point-to-point subinterface services one PVC, and the multipoint subinterface services multiple PVC's.

Another use of subinterfaces is found in Novell networks. In Novell networks running IPX, LAN interfaces can use multiple encapsulations (layer-2 header formats). For example, Ethernet_II and Ethernet_802.2 are two Novell encapsulations. For each encapsulation on a LAN interface, there must be a unique IPX network number. We can create a subinterface for each encapsulation type since we can give each subinterface its own layer-3 address (IPX network number).

The state of a subinterface follows its associated physical interface down, but not necessarily up. If a physical interface goes down, all of its subinterfaces also go down. A subinterface can be shut down individually even if the physical interface is up. When a subinterface is servicing a single frame relay PVC and the PVC goes down, the subinterface will also go down regardless of the physical interface status.

We create subinterfaces by referencing them with the interface command. When we reference a subinterface with the interface command, IOS puts us into subinterface configuration mode where we can enter commands specific to the subinterface.

Subinterfaces are named with the physical interface type and number followed by a period (.) and another number. The period is pronounced as "dot." For example, Serial0.1 (serial zero dot one) is a subinterface of Serial0. The number after the period can be anything from 0 to 4,294,967,296 (232-1). The number 0 refers to the physical interface; therefore, the first available number for a subinterface is 1. Figure 6-10 shows the configuration of a frame relay subinterface.

    1. Router(config)#interface serial0.1 point-to-point
    2. Router(config-subif)#ip address
    3. Router(config-subif)#ipx network badf00d
    4. Router(config-subif)#frame-relay interface-dlci 222
    5. Router(config-subif)#

<<<Figure 6-10 Frame Relay Subinterface Configuration Example>>>

The example of Figure 6-10 assumes that the Serial0 physical interface is running attached to a frame relay network and is running frame relay encapsulation. On Line 1, Serial0.1 is created as a point-to-point subinterface. This places us into subinterface configuration mode where we can enter the subinterface's IP address (Line 2), IPX network number (Line 3), and PVC to service (Line 4). PVC's are addressed with Data-Link Connection Identifiers (DLCI).

      1. Interface Numbering
      2. Interface numbering was introduced in Section 3.1.3. We will review that information now that we are configuring individual interfaces. Probably the biggest difference in IOS configuration across Cisco router platforms is the numbering of interfaces due to hardware configuration. The full specification of an interface is its type followed by its number designation. The type and number designation may, optionally, be separated by a space when referencing an interface.

        On the low-end routers (1000 series and 2500 series) to the mid-range routers (4000 series), physical interfaces are numbered with a single value, the port number. The first interface of each type is numbered 0, and the numbers for the rest of the same-type interfaces increment from there. For example, the first token ring interface on a 4000 series router is TokenRing0, and the second one is TokenRing1.

        On the high-end routers (7000 series) that support Online Insertion and Removal (OIR), a physical interface's number designation must include a slot number and a port number separated by a forward slash (/). Slot and port numbering begins with 0. OIR allows us to swap the cards containing interfaces (interface processors) in and out of a router chassis without shutting down the router. For example, the first serial interface in the second slot of a 7507 is Serial1/0, and the second serial interface in the second slot is Serial1/1.

        On the high-end routers that have a Versatile Interface Processor (VIP) installed, the interfaces on the VIP have a number designation may contain a slot number, a port adapter number, and a port number all separated by forward slashes (/). Port adapter numbers start at 0. For example, on a 7513, the second Ethernet interface on the first port adapter in the tenth slot is Ethernet9/0/1.

        Logical interfaces have a number designation that contains only the single number that we assigned to it. Logical interfaces have no slot number or port adapter number. For example, Tunnel46 could be a tunnel interface on any IOS-based Cisco.

        Subinterface number designations consist of the entire physical interface designation followed by a period (.) and the number that we assigned to the subinterface. For example, Serial1/0.88 could be a subinterface of Serial1/0 on the 7507 mentioned above.

      3. Setting the Encapsulation
      4. The concept of encapsulation was covered throughout Chapter 2. The encapsulation method on an interface determines the format of the layer-2 header and trailer in which a packet is encapsulated before it is transmitted out an interface and in which the router expects data to arrive when it is received on an interface.

        A LAN interface can support multiple encapsulations, and the encapsulations used are usually protocol specific. On an Ethernet interface for example, IP traffic uses ARPA encapsulation (ARPA is the IOS keyword for Ethernet_II.), and Appletalk uses SNAP encapsulation, and IPX can use from one to four different encapsulations. Since LAN interface encapsulations is protocol specific, we will cover them in the protocol configuration chapters.

        A WAN interface can support only one encapsulation, and the encapsulation is dependent on the device that the interface communicates with at the data link layer. If the interface communicates with a frame relay switch, the encapsulation must be frame relay. If the interface communicates with an X.25 switch, the encapsulation must be X.25. If the interface communicates directly with another router at layer 2, the encapsulation can be HDLC, PPP, or LAPB.

        HDLC is the default encapsulation for all serial interfaces. As a general rule, if your WAN is dedicated leased line, like a T1, and the router on the other end of it is a Cisco router, you can leave the encapsulation as HDLC. However, since Cisco's implementation of HDLC is proprietary (so is everyone else's), you should use PPP if the router on the other end is a non-Cisco router.

        We use the interface configuration mode command encapsulation to change an interface's encapsulation.

        Router(config)#interface serial0

        Router(config-if)#encapsulation ppp


        Some of the keywords that can be accepted by the encapsulation command are hdlc, ppp, frame-relay, and x25. We will come back to a few of these as we progress through the book.

        To set an interface's encapsulation back to its default value, even if you do not know the default, issue the command no encapsulation in interface configuration mode for the interface.

      5. Setting the Bandwidth
      6. Setting the bandwidth on an interface has nothing to do with the speed of the interface. The bandwidth setting is used to communicate the bandwidth of an interface to upper layer protocols and applications. For example, the EIGRP routing protocol uses the bandwidth to calculate a route's metric, and an SNMP-based network management application may use an interface's bandwidth setting to calculate network utilization. If you are using a protocol or application that uses the bandwidth setting, you should verify that the bandwidth has the correct value.

        The interface bandwidth setting is given in kilobits per second (kbps). All interfaces have a default bandwidth setting; however, setting the bandwidth is usually an issue only on WAN interfaces, like serial interfaces.

        The default bandwidth of a fast serial interface is 1544. That is 1544 kbps, or 1.544 Mbps; this is the bandwidth of a T1. IOS assumes that all fast serial interfaces are connected to T1 unless we tell it something different. Use the interface configuration mode command bandwidth to change the bandwidth setting. An example is shown below.

        Router(config)#interface serial0

        Router(config-if)#bandwidth 56


        This bandwidth 56 command in this example tells IOS that Serial0 is connected to a 56 kbps WAN. If the bandwidth setting on an interface is not the same as the actual bandwidth of the directly-connected network, you should use the bandwidth command to change the setting.

      7. Setting a Description

We can put a text description on each interface. The description can be used to tell, or remind, a network administrator something about an interface. This interface description is the only text documentation that IOS saves in the configuration file. We can use the interface configuration mode command description to put a descriptive comment on each interface.

Dallas(config)#interface serial1

Dallas(config-if)#description T1 to FortWorth. Installed 10-Oct-1998. DHEC123456.

Dallas(config-if)#interface ethernet0

Dallas(config-if)#description Call John at x1 immediately to report problems.


You can put any information you want in a description. Some useful things to include are a network's location and contact person. For WAN's, the interface description is a great place to put circuit ID's and technical support contact information. You can put over 240 characters of text in an each interface's description. The description is displayed when the show interfaces command is issued. Figure 6-11 shows an example output with an interface description.

    1. Dallas#show interfaces serial1
    2. Serial1 is up, line protocol is up
    3. Hardware is HD64570
    4. Description: T1 to FortWorth. Installed 10-Oct-1998. DHEC123456.
    5. Internet address is
    6. MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
    7. Encapsulation HDLC, loopback not set, keepalive set (10 sec)
    8. Last input 00:00:04, output 00:00:06, output hang never
    9. Last clearing of "show interface" counters never
    10. Input queue: 0/75/0 (size/max/drops); Total output drops: 0
    11. Queueing strategy: weighted fair
    12. Output queue: 0/1000/64/0 (size/max total/threshold/drops)
    13. Conversations 0/1/256 (active/max active/max total)
    14. Reserved Conversations 0/0 (allocated/max allocated)
    15. 5 minute input rate 0 bits/sec, 0 packets/sec
    16. 5 minute output rate 0 bits/sec, 0 packets/sec
    17. 13953 packets input, 946610 bytes, 0 no buffer
    18. Received 13952 broadcasts, 0 runts, 0 giants, 0 throttles
    19. 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
    20. 13954 packets output, 957096 bytes, 0 underruns
    21. 0 output errors, 0 collisions, 2 interface resets
    22. 0 output buffer failures, 0 output buffers swapped out
    23. 2 carrier transitions
    24. DCD=up DSR=up DTR=up RTS=up CTS=up
    25. Dallas#

<<<Figure 6-11 Show Interfaces Output with Description>>>

The description we entered appears on Line 4 of Figure 6-11. Now a network administrator can use the show interfaces command to get the circuit ID of this WAN in case problem that involves the service provider.

      1. Clearing
      2. Figure 6-11, Line 8, shows that the counters at the bottom of the show interfaces output have never been cleared. We can use the privileged mode command clear counters to force the counters back to zero. If we issue the clear counters command without any arguments, IOS will clear the counters for all interfaces after it get a confirmation from us that we really want to do it. To clear the counters of an individual interface, put the interface type and number designator as the arguments of the clear counters command. For example, clear counters serial1 will clear the show interface counters for the Serial1 interface shown in Figure 6-11.

        Sometimes, not very often, we may have a use for resetting the hardware of an interface. The privileged mode command clear interface will accomplish this purpose. The clear interface command takes as its arguments the interface type and number designator for the interface we wish to reset. For example, the command clear interface serial1/0 will reset the hardware for Serial1/0. Use this command with caution since it will cause any traffic flowing through the interface to be lost while the hardware reinitializes.

      3. Shutting Down

To shut down an interface and place it into administratively down state, use the interface configuration mode command shutdown.

Dallas(config)#interface ethernet0


%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to down

%LINK-5-CHANGED: Interface Ethernet0, changed state to administratively down

The console messages indicate that Ethernet0 has been shut down. To take an interface out of administratively down state and have IOS attempt to bring it up, issue the no shutdown command. (Just say no.)

Dallas(config-if)#no shutdown

%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to up

%LINK-3-UPDOWN: Interface Ethernet0, changed state to up

The console messages now indicate that Ethernet0 is again active with an up/up state.

    1. Terminal Line Tasks
    2. Section 5.2.4 explains the types of terminal lines, the way that they are numbered, and the show line command for examining them. To configure a terminal line, we must be in line configuration mode. We use the global configuration command line to get there.

      We can configure lines by their absolute line number or their relative number. Using the relative number is the most straight-forward. When referencing a terminal line by its relative number, we must include the line type such as con or vty. An example of getting into line configuration mode for the console is shown below.

      Dallas(config)#line con 0


      There is only one console; therefore, its relative number is always 0. Actually, its absolute number is always 0, too. The (config-line) indicates that we are in line configuration mode. We can now enter commands to configure the console.

      When configuring a line type that has multiple instances, such as VTY's, we can configure individual lines or a range of lines. Normally, we want all of a router's VTY's to have identical configurations; therefore, we can use range of relative line numbers to get to line configuration mode. Then the commands we type will affect all of the VTY's in the range. The relative line numbers in the range are separated by a space. Here is an example.

      Dallas(config)#line vty 0 4


      A Cisco router has, by default, five VTY's. Their relative numbers are 0, 1, 2, 3, and 4. To configure all of the VTY's simultaneously, we issue the line vty 0 4 command. The 0 and the 4 represent the range 0 through 4. All of the line configuration mode command typed at the prompt will now affect all five of the VTY's.

      We can create more VTY's by referencing new numbers on the line vty command. For example, the command line vty 9 will create five more VTY's with relative numbers 5, 6, 7, 8, and 9.

      1. Setting a Password
      2. Terminal line passwords are set in line configuration line mode. After typing a terminal line password, a user is put into user mode. Enabling the use of terminal line passwords with the password command and the login command was covered in Section

      3. Setting the Timeout
      4. After 10 minutes of inactivity, IOS will automatically disconnect a terminal line session. This means that if you log in on the console and you do not press any keys for 10 minutes, IOS will log you out. We can change this timeout interval by using the line configuration mode command exec-timeout. The exec-timeout command has two arguments - minutes and seconds. The example below removes the console timeout and reduces the VTY timeout.

        Dallas(config)#line con 0

        Dallas(config-line)#exec-timeout 0 0

        Dallas(config-line)#line vty 0 4

        Dallas(config-line)#exec-timeout 5 0


        Setting the timeout to 0 minutes and 0 seconds disables the timeout; with this setting, the console session will never be disconnected unless someone manually disconnects it. The timeout for all five VTY's has been shortened to 5 minutes and 0 seconds. If someone telnets to this router and leaves their session idle for 5 minutes, IOS will clear the line to disconnect the session.

      5. Clearing

      If you want to manually clear a line that does not belong to you, the privileged mode command clear line can be used. Figure 5-14 has the output of a show users command. Suppose that the user, from host, with the telnet session on VTY 3 (absolute line 5) has no business in your router. You can disconnection the session with the clear line 5 command.

    3. Managing Configuration Files

Managing the two IOS configuration files, startup and running, is essential to the administration of a router-based internetwork. Here is a quick review of the files.

The running configuration contains the configuration that is currently active on the router. When we enter commands from a configuration mode command line during a terminal line session, they are placed into the running configuration file. Since the running configuration is kept in RAM, it disappears when a router goes down.

The startup configuration is stored in NVRAM. The commands from the startup configuration are read and entered into the running configuration when a router boots.

All configuration file management must be done from privileged mode. The operations that we can perform on the configuration files are as follows:

    • Display the running configuration.
    • Update the running configuration.
    • Backup the running configuration.
    • Display the startup configuration.
    • Replace the startup configuration.
    • Backup the startup configuration.

The IOS commands for performing these operations are covered in the next few sections.

      1. Displaying the Running Configuration
      2. IOS displays the running configuration to us when we issue the following command in privileged mode:

        show running-config

        The active configuration will be sent in ASCII text format to our terminal line session. If we are running terminal emulation software, capturing the running configuration to a log file is useful. When examining the running configuration file, remember that IOS typically will not display default settings; therefore the configuration file normally contains only those commands that change IOS defaults.

        The show running-config command was first documented in IOS version 11.0, even though it was available in earlier releases. The original IOS command for displaying the running configuration is:

        write terminal

        The write terminal command is available in all IOS releases, and both commands perform the same operation.

      3. Updating the Running Configuration

The only way to actually replace the running configuration is to reboot the router; however, we can update the running configuration with new commands. These commands must be entered in ASCII text, and they can be entered from the following sources:

    • Terminal Line
    • NVRAM
    • TFTP Server
    • rcp Server
    • Flash Memory

TFTP (Trivial File Transfer Protocol) is an application that allows the transfer of files to and from a server without any authentication. TFTP runs over User Datagram Protocol (UDP); therefore, it has no windowing or sequencing of packets. It is for use over reliable networks that are not subject to dropped packets. To use TFTP, we must have a host running the server process; IOS by default runs the client process that sends file transfer requests to a server. TFTP server software is available for just about any host operating system.

rcp (Remote Copy) is another application that allows the transfer of files to and from a server; however, rcp runs over Transmission Control Protocol (TCP) and requires authentication. rcp is more reliable and secure than TFTP. We can use rcp over networks that are subject to dropped packets, such as frame relay. rcp server software is not as widely available as TFTP server software, but if you look hard enough, you can probably find it for your host operating system.

        1. From a Terminal Line
        2. To enter commands from a terminal line session, we must be in configuration mode. The command for getting to configuration mode has already been covered and should be familiar by now. It is:

          configure terminal

          The configuration terminal command will put us into global configuration mode where we can type configuration commands that affect the IOS running configuration.

          In addition to typing individual commands at the configuration mode prompt, we can enter commands through the transmit and paste functions of our terminal emulation software. If we have a text file of configuration commands stored on a local disk drive, we can transmit the file to the router by performing an ASCII file transmit operation if our terminal emulator supports it. The commands in the file will be executed just as if they were typed. If our terminal emulator supports the copy and paste functions, we can paste text commands directly onto the IOS command line after we have selected and copied them into our copy buffer.

        3. From NVRAM
        4. NVRAM, hopefully, contains a startup configuration file, which is a text file of commands that can be entered into the running configuration. The command for updating the running configuration with the commands from the startup configuration is as follows:

          copy startup-config running-config

          This command will take the lines of the startup configuration from NVRAM and enter them into the running configuration one at a time just as if we were typing them on a configuration mode command line. The operation is not really a copy as the command suggests; some people call it a merge.

          The copy startup-config running-config command was first documented in IOS version 11.0, even though it was available in earlier releases. The original IOS command for updating the running configuration from NVRAM is:

          configure memory

          The configure memory command is available in all IOS releases, and both commands perform the same operation.

        5. From a TFTP Server

TFTP servers can have text files of commands or running configuration backup files on them. The lines of these files can be entered into a running configuration with the following command:

copy tftp running-config

The copy tftp running-config command will take the lines of a text file from a TFTP server and enter them into the running configuration one at a time just as if we were typing them on a configuration mode command line. Like the other copy operations that have the running configuration as the destination, this operation is more of a merge rather than a copy as the command suggests. Figure 6-12 shows the dialog of the copy tftp running-config command. Default answers are given in brackets ([ ]).

    1. Dallas#copy tftp running-config
    2. Host or network configuration file [host]? host
    3. IP address of remote host []?
    4. Name of configuration file [Dallas-confg]? dallas-1.txt
    5. Configure using dallas-1.txt from [confirm] y
    6. Loading dallas-1.txt from (via Ethernet0): !!!!!
    7. [OK - 2035/32723 bytes]
    8. Dallas#

<<<Figure 6-12 Copy TFTP Running-Config Dialog>>>

The question on Line 2 can be answered with either host or network. For the purpose of a configuration file copy, a file is a host file if it contains commands that are specific to an individual router, and a file is a network file if it contains commands common to multiple routers. The answer is used in the generation of the files default name (Line 4). A host file has a default name that contains the router's host name followed by -confg, and a network has the default name network-confg.

The next question (Figure 6-12, Line 3) asks for the IP address of the TFTP server. This could be an actual address of a host name if we have DNS enabled or we have a host file entry for the name.

The question on Line 5 just asks for confirmation. If the answer is affirmative, IOS attempts to perform the copy. Line 6 shows the status of the configuration file load; the exclamation points (!) indicate blocks of text that have been successfully copied. Periods (.) indicate failed block copies. Some versions of IOS display the word "Booting" instead of "Loading"; this operation is not a boot; it is merely a merge.

To avoid an error at the end of the copy, we need to make sure that the last command in the text file is the single word end. Since IOS is treating the text file commands just like they were being typed into configuration mode, the end command is needed to exit configuration mode when the copy is finished.

The copy tftp running-config command was first documented in IOS version 11.0, even though it was available in earlier releases. The original IOS command for updating the running configuration from a TFTP server is:

configure network

The configure network command is available in all IOS releases, and both commands perform the same operation.

        1. From an rcp Server

TFTP servers can also have text files of commands or running configuration backup files on them. The lines of these files can be entered into a running configuration with the following command:

copy rcp running-config

This command will take the lines of a text file from an rcp server and enter them into the running configuration one at a time just as if we were typing them on a configuration mode command line. The last line of the text file should be the command end. Similar to the other commands for copying files to the running configuration, this operation is more of a merge rather than a copy. The dialog for the copy rcp running-config command is similar to that shown for the TFTP copy in Figure 6-12.

Since rcp requires authentication to perform a copy, there are some additional steps that we must perform to allow the router to access the rcp server's files. There are many variations of the rcp process, but here are the steps for one of the ways to prepare for the copy.

    • On the router, define a username, which the router will use to log in to the rcp server. The username for rcp can be defined with the ip rcmd remote-username command.
    • On the rcp server, define a user with the same username and give the user a home directory. Text files of commands should be stored in the home directory.
    • On the rcp server, build a .rhosts file in the user's home directory. The .rhosts file is a text file that contains a line entry for each host and username that is allowed to access the directory. Add an entry for the router and its username.

You may have to experiment with rcp to get it to work; it's not the most intuitive application to use. It is, however, very reliable.

        1. From Flash Memory

Text files that have been stored on in flash memory can also be merged with the running configuration. When copying a text file from flash, we should reference the exact flash device and file name on the command line. The command is as follows:

copy flashdev:filename running-config

In the command, flashdev: is the name of a flash device such as flash: or slot0:, and filename is the name of the text file, for example, dallas-1.txt.

      1. Backing Up the Running Configuration

We should always maintain backup copies of router configuration files, preferably in multiple locations. From privileged mode, we can backup a router's running configuration to the following locations:

    • NVRAM
    • TFTP Server
    • rcp Server
    • Flash Memory
    • Local Disk Drive

When performing a backup of the running configuration file, IOS builds the configuration and formats it as ASCII text; it then copies the entire file to the specified destination. The commands for backing up the running configuration are just the reverse of those used to update the running configuration, but we will go over them anyway.

        1. To NVRAM
        2. The command to backup the running configuration to NVRAM is as follows:

          copy running-config startup-config

          When this command is executed, IOS replaces the startup configuration with the contents of the running configuration. This operation should always be performed after changes to a router's running configuration have been made and verified to be working properly.

          The copy running-config startup-config command was first documented in IOS version 11.0, even though it was available in earlier releases. The original IOS command for copying the running configuration to NVRAM is:

          write mrmory

          The write memory command is available in all IOS releases, and both commands perform the same operation.

        3. To a TFTP Server

The command used for backing up the running configuration to a TFTP server is:

copy running-config tftp

The copy running-config tftp command will copy the running configuration to a specified text file on a specified TFTP server. Figure 6-13 shows the dialog of the copy running-config tftp command. Default answers are given in brackets ([ ]).

    1. Dallas#copy running-config tftp
    2. Remote host []?
    3. Name of configuration file to write [Dallas-confg]? dallas-2.txt
    4. Write file dallas-1.txt on host [confirm] y
    5. Building configuration...
    6. Writing dallas-2.txt !!!!! [OK]
    7. Dallas#

<<<Figure 6-13 Copy Running-Config TFTP Dialog>>>

The dialog begins (Figure 6-13, Line 2) by asking for the address of the TFTP server. This can be either an address or a host name as long as the address associated with the name can be resolved using DNS or a host table.

The default file name (Line 3) is the router's host name followed by the characters -confg. We have changed the file name to meeting our naming standard. There is already a file named dallas-1.txt (see Figure 6-12) so we used dallas-2.txt.

Some TFTP server implementations require that a file exist on the server before a TFTP client can write to it. If your server has this restriction and the server is running unix, you can use the unix command touch to create an empty file with the desired name.

After the affirmative confirmation on Line 4, IOS compiles the configuration into text format and attempts to write the file. On Line 7, the exclamation points (!) indicates successful writes of text blocks.

The copy running-config tftp command was first documented in IOS version 11.0, even though it was available in earlier releases. The original IOS command for backup up the running configuration to a TFTP server is:

write network

The write network command is available in all IOS releases, and both commands perform the same operation.

        1. To an rcp Server
        2. Use the following command to backup the running configuration to an rcp server:

          copy running-config rcp

          The copy running-config rcp command will copy the running configuration to a specified text file on a specified rcp server. The dialog for the rcp copy is similar t that shown for the TFTP copy in Figure 6-13.

          An example of the preparation steps for performing an rcp operation is given in Section

        3. To Flash Memory
        4. The command for making a backup of the running configuration in flash memory has the following form:

          copy running-config flashdev:filename

          In the command, flashdev: is the name of a flash device such as flash: or slot0:, and filename is the name of the text file, for example, dallas-3.txt.

          IOS cannot write to flash memory that has a read-only status. We can use the show flash or show version command to verify that flash is not read-only.

        5. To a Local Disk Drive

To backup the running configuration to a local disk drive, set your terminal emulation software to log screen output to a text file and issue the show running-config command.

This technique can be used to save other IOS output to a text file, also. You will find it useful for documenting the configuration and operation of your routers if you save the output of your show commands in text files.

      1. Displaying the Startup Configuration
      2. IOS displays the startup configuration to us when we issue the following command in privileged mode:

        show startup-config

        The startup configuration will be sent in ASCII text format to our terminal line session. On a stable, production router, the startup configuration should contain the same commands as the running configuration.

        The show startup-config command was first documented in IOS version 11.0, even though it was available in earlier releases. The original IOS command for displaying the startup configuration is:

        show config

        The show config command is available in all IOS releases, and both commands perform the same operation.

      3. Replacing the Startup Configuration

The commands for replacing the startup configuration are similar to those that in Section 6.4.2 for updating the running configuration. Just replace the keyword running-config with the keyword startup-config to make the command operate on the startup configuration. The startup configuration can be replaced with the following:

    • Running Configuration File
    • TFTP Server File
    • rcp Server File
    • Flash Memory File
    • Nothing

The commands that perform startup configuration operations have one major operational difference with those that perform running configuration operations. Where the running configuration commands entered command lines into a pre-existing running configuration, the commands that operate on the startup configuration actually replace the contents of NVRAM with the specified source file.

The most common maintenance operations that administrators perform on the startup configuration are replacing it with the running configuration after changes have been made and verified and erasing it (replacing it with nothing) to start from scratch with a router's configuration.

        1. With the Running Configuration File
        2. The command to replace the startup configuration with the running configuration is the same one used to backup the running configuration to NVRAM covered in Section

          copy running-config startup-config

          This command will replace the contents of NVRAM with the entire running configuration file, assuming that there is enough NVRAM to hold the file.

          Remember that the original IOS command for replacing the startup configuration with the running configuration is:

          write mrmory

          Both commands perform the same operation.

        3. With a TFTP Server File
        4. Use the following command to replace the NVRAM contents with a file from a TFTP server:

          copy tftp startup-config

          This command has a dialog similar to that shown in Figure 6-12. We need to tell IOS the IP address of the TFTP server and the name of the file to copy from the server.

          IOS will allow any file, even if it does not contain configuration commands, to be copied directly to NVRAM. If you put a file in NVRAM other than a configuration file, IOS will fail during its boot sequence when it tries to load the contents of NVRAM into the running configuration. Therefore, we better have a backup copy of the configuration on a server, in flash memory, or on a local disk drive.

          The copy tftp startup-config command was first documented in IOS version 11.0, even though it was available in earlier releases. The original IOS command for backup up the running configuration to a TFTP server is:

          configure overwrite-network

          The configure overwrite-network command is available in many IOS releases (even though it was undocumented until recently), and both commands perform the same operation.

        5. With an rcp Server File
        6. Use the following command to replace the startup configuration with a file from an rcp server:

          copy rcp startup-config

          This command has a dialog that asks for the IP address of the rcp server and the name of the file that is to be copied to NVRAM. Any file can be copied since IOS does no checking of file contents for this copy. See Section for some of the things that should be done to allow rcp copies from a server.

        7. With a Flash Memory File
        8. We can move a file from flash memory to NVRAM with the following command:

          copy flashdev:filename startup-config

          In the command, flashdev: is the name of a flash device such as flash: or slot0:, and filename is the name of the text file, for example, dallas-3.txt.

          As in any other file copy to NVRAM, IOS does not check the contents of a file during the copy.

        9. With Nothing

Sometimes it is necessary to start over. When a router boots without a startup configuration, IOS assumes that the router is new, and it asks if we want to enter the System Configuration Dialog. Therefore, if we remove the startup configuration from a router and then reboot the router, we can start from scratch with IOS configuration.

The command used to erase the contents of NVRAM is as follows:

erase startup-config

A router that rebooted after this command is issued is just like a brand new router as far as IOS is concerned. The erase startup-config command is not often used in production; however, it is very useful in a lab environment.

The erase startup-config command was first documented in IOS version 11.0, even though it was available in earlier releases. The original IOS command for erasing NVRAM is:

write erase

The write erase command is available in all IOS releases, and both commands perform the same operation.

      1. Backing Up the Startup Configuration

We do not normally have a need to backup the startup configuration, but just in case, here are the commands.

The command for backing up the startup configuration to a TFTP server is:

copy startup-config tftp

The command for backing up the startup configuration to an rcp server is:

copy startup-config rcp

Both of the above commands have a dialog that requests the IP address of a server and the name of the backup file on the server.

The command for backing up the startup configuration to flash memory is:

copy startup-config flashdev:filename

where flashdev: is the flash device and filename is the name of the file on the flash device.

    1. Accessing Remote Routers

Accessing routers across a network, or internetwork, can be done using telnet to establish a session to one of the remote router's VTY. Telnet can be done only across networks running IP. When you want to start a telnet session to a host, use the telnet command followed by the host's name or IP address. The telnet command can be issued in either user mode or privileged mode. Figure 6-14 shows a telnet session being established and cleared.

    1. Dallas#telnet fortworth
    2. Trying FortWorth ( Open
    3. User Access Verification
    4. Password: letmein
    5. FortWorth>quit
    6. [Connection to fortworth closed by foreign host]
    7. Dallas#
    8. <<<Figure 6-14 Telnet Session Establishment Example>>>

      On Line 1 of Figure 6-14 a telnet session is being requested to the host fortworth. To use host names, we must have some form of address resolution. Dallas' configuration contains a host table entry that associates the name FortWorth to the IP address The address that resulted from the lookup is shown on Line 2. If we had remembered the address, we could have used it in place of the host name. Host names in DNS files and host tables are not case sensitive when they are referenced from a command line. In this example, we just logged in and then, immediately, logged out. Note that the password is not really displayed on our terminal when we log in, and we would not be allowed to log in at all if FortWorth did not have a password configured on the VTY that it allocated for the incoming telnet connection.

      If we telnet to a router and want to return to our source and perhaps perform some function or telnet to another router, we can suspend our current telnet session with the standard IOS escape sequence followed by the letter x. Suspending a telnet session leaves it active and allows us to resume the connection without have to log in again. The IOS default escape sequence is <Ctrl-Shift-6>; therefore the full sequence of commands to suspend a telnet session is <Ctrl-Shift-6><x>. This sequence is two keystrokes and requires three fingers. Press the <Ctrl>, <Shift>, and <6> keys simultaneously; then release them, and press the <x> key.

      Figure 6-15 shows a telnet example with an event sequence that seems illogical; however, we will use it to illustrate several things including a session being established, suspended, resumed, and forcefully disconnected.

    9. Dallas#fortworth
    10. Trying FortWorth ( Open
    11. User Access Verification
    12. Password: letmein
    13. FortWorth><Ctrl-Shift-6><x>
    14. Dallas#show sessions
    15. Conn Host Address Byte Idle Conn Name
    16. * 1 fortworth 0 0 fortworth
    17. Dallas#<Enter>
    18. [Resuming connection 2 to fortworth ... ]
    19. <Enter>
    20. FortWorth><Ctrl-Shift-6><x>
    21. Dallas#disconnect 1
    22. Closing connection to fortworth [confirm]y
    23. Dallas#

<<<Figure 6-15 Telnet Session Suspension Example>>>

On Line 1 of Figure 6-15, we requested a telnet session to fortworth. Remember that IOS assumes a non-command word (or address) typed in user mode or privileged mode is the name (or address) of a host to which a telnet session should be established. If you do not like this behavior, you can turn it off on a terminal line with the line configuration mode command transport preferred none. Doing this will cause IOS to interpret everything you type as a command, never a host; therefore, when you want to telnet to a host, we must use the telnet command.

On Line 2 the address of the host name as been resolved and the telnet session is started. After logging in, we got a command prompt (Line 7) and suspended the telnet session. We were immediately placed back on Dallas (Line 8). The show sessions command is used to display suspended telnet connections. Line 10 shows that there is one telnet session, and it is connected to fortworth. The connection number is 1.

In the show sessions command output, the asterisk to the left of the connection number indicates the next active session. If we press <Enter> on an empty command line of the original router, the session with the asterisk is resumed (Lines 12 and 13). When a session is resumed, we usually do not get a command prompt immediately; therefore, we may need to type something like <Enter> to get to a prompt. Be careful about typing <Enter> when you are not sure about what is on the command line. Suppose that the session to FortWorth had been suspended at the end of a typed command but before <Enter> was pressed to execute the command. Resuming the session would put you back at the end of the original command line, and pressing <Enter> would execute the command that you can no longer see. If you are unsure about the contents of a command line in such a case, consider pressing <Ctrl-U> to erase the command line or <Ctrl-R> to redisplay the command line before pressing <Enter>.

If we had multiple sessions and did not want to resume the one with the asterisk, we could issue the resume command followed by the desired connection number, or we could just issue the connection number itself, as a command, on the command line.

On Line 15 of Figure 6-15, the telnet session to FortWorth is again suspended to get back to Dallas (Line 16). The command to clear a suspended telnet session, without having to return to the destination host and log out, is disconnect. Typing disconnect alone on a command line will disconnect the next active session (the one with the asterisk in the show sessions output). On Line 16, we elected to reference the specific connection number 1 for disconnection. The session is cleared after an affirmative confirmation.

    1. Cisco Discovery Protocol

The Cisco Discovery Protocol (CDP) is a Cisco-proprietary, data link protocol that runs by default on most Cisco devices, including routers. Cisco devices use CDP to advertise their presence and basic configuration information to neighboring Cisco devices and to learn about the presence and basic configuration of neighboring Cisco devices. Neighboring devices refers to those devices that are on directly-connected networks. As noted above, CDP is a data link protocol; therefore, CDP communication cannot be routed; it must stay on a device's local networks.

CDP runs on any network (LAN or WAN) that supports SNAP encapsulation; these networks include Ethernet, token ring, FDDI, HDLC, PPP, and frame relay (not X.25). At periodic intervals, Cisco devices send a CDP message out each interface which has CDP enabled. The default update interval is 60 seconds. Neighboring Cisco devices hear the CDP messages and update a CDP neighbor table in their RAM. The CDP neighbor table contains the information that each neighbor has advertised and a hold timer. The hold timer is used to tell how much time has elapsed since information about a neighbor device was heard. The default hold timer starts at 180 seconds and counts down. If a device's hold timer reaches zero (0), the device is removed from the table.

A CDP message includes information about the transmitting device and information about the interface from which the message was transmitted. The IOS command to display a summary of the CDP neighbor table is show cdp neighbors. Figure 6-16 shows an example of the show cdp neighbors command output on Dallas.

    1. Dallas#show cdp neighbors
    2. Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
    3. S - Switch, H - Host, I - IGMP, r - Repeater
    4. Device ID Local Intrfce Holdtme Capability Platform Port ID
    5. FortWorth Ser 1 150 R 2520 Ser 0
    6. Dallas#
    7. <<<Figure 6-16 Show CDP Neighbors Command Output>>>

      As shown on Line 6 of Figure 6-16, Dallas has one neighbor device, FortWorth. FortWorth's CDP messages are being received on Dallas' Serial1 interface (see Local Intrfce column). Since the hold timer started at 180 seconds and is now at 150 seconds (see Holdtime column), 30 seconds have elapsed since the last CDP message was received from FortWorth. According to the Platform and Capability columns, FortWorth is a 2520 router. FortWorth is sending its CDP message, being received by Dallas, out its Serial0 interface (see Port ID column). From this display we can deduce that FortWorth's Serial0 interface is directly-connected to the same network as Dallas's Serial1 interface.

      To view the full contents of the CDP neighbor table, issue the show cdp neighbors detail command. Figure 6-17 show an example output from Dallas.

    8. Dallas#show cdp neighbors detail
    9. -------------------------
    10. Device ID: FortWorth
    11. Entry address(es):
    12. IP address:
    13. Novell address: AC100B00.0010.7b3a.d4af
    14. Appletalk address: 1001.200
    15. Platform: cisco 2520, Capabilities: Router
    16. Interface: Serial1, Port ID (outgoing port): Serial0
    17. Holdtime : 151 sec
    18. Version :
    19. Cisco Internetwork Operating System Software
    20. IOS (tm) 2500 Software (C2500-JS-L), Version 11.3(5), RELEASE SOFTWARE (fc1)
    21. Copyright (c) 1986-1998 by cisco Systems, Inc.
    22. Compiled Tue 11-Aug-98 04:06 by phanguye
    23. Dallas#
    24. <<<Figure 6-17 Show CDP Neighbors Detail Command Output>>>

      From the table details, we can gather more information about FortWorth. On Lines 5 through 7, we get the IP address, IPX address, and AppleTalk address for FortWorth's Serial0 interface (see Port ID on Line 9). Line 14 shows that FortWorth is running IOS version 11.3(5). The interface addresses comes in handy when we need to access a neighboring Cisco router, but we do not know its address. They can also be used to discover the layout of an internetwork that consists of Cisco devices.

      To look at an individual entry in the CDP neighbor table, use the command

      show cdp entry name

      where name is the name of a device from the neighbor table. The name is case sensitive. This command is useful if the neighbor table is large and you want to get detailed information about a single neighbor without have to view the details of all neighbors.

      CDP can be enabled and disabled either on individual interfaces or globally. If you want to turn off CDP on an individual interface, use the interface configuration mode command no cdp enable. To turn it back on, issue the cdp enable command. To turn off CDP on all interfaces simultaneously, issue the global configuration command no cdp run. Issue the cdp run command to turn CDP back on.

      The CDP timers (update interval and hold time) are global parameters. When they are changed, all interfaces running CDP are changed. The command to change the periodic update interval is

      cdp timer seconds

      where seconds is the length of the interval. The default value is 60. The command to change the hold timer is

      cdp holdtime seconds

      where seconds is the starting value of the hold timer. The default value is 180. When timers are changed on one device, they should be changed on all the rest of the devices to help prevent neighbor-table synchronization problems.

      The status of CDP on a router can be viewed with the commands show cdp and show cdp interface. Figure 6-18 shows a sample output of these two commands on Dallas.

    25. Dallas#show cdp
    26. Global CDP information:
    27. Sending CDP packets every 60 seconds
    28. Sending a holdtime value of 180 seconds
    29. Dallas#show cdp interface
    30. BRI0 is administratively down, line protocol is down
    31. Encapsulation HDLC
    32. Sending CDP packets every 60 seconds
    33. Holdtime is 180 seconds
    34. BRI0:1 is administratively down, line protocol is down
    35. Encapsulation HDLC
    36. Sending CDP packets every 60 seconds
    37. Holdtime is 180 seconds
    38. BRI0:2 is administratively down, line protocol is down
    39. Encapsulation HDLC
    40. Sending CDP packets every 60 seconds
    41. Holdtime is 180 seconds
    42. Ethernet0 is up, line protocol is up
    43. Encapsulation ARPA
    44. Sending CDP packets every 60 seconds
    45. Holdtime is 180 seconds
    46. Serial0 is administratively down, line protocol is down
    47. Encapsulation HDLC
    48. Sending CDP packets every 60 seconds
    49. Holdtime is 180 seconds
    50. Serial1 is up, line protocol is up
    51. Encapsulation HDLC
    52. Sending CDP packets every 60 seconds
    53. Holdtime is 180 seconds
    54. Serial2 is administratively down, line protocol is down
    55. Encapsulation HDLC
    56. Sending CDP packets every 60 seconds
    57. Holdtime is 180 seconds
    58. Serial3 is administratively down, line protocol is down
    59. Encapsulation HDLC
    60. Sending CDP packets every 60 seconds
    61. Holdtime is 180 seconds
    62. Dallas#

<<<Figure 6-18 Show CDP Command Output>>>

The show cdp command shows the values of the timers (Lines 3 and 4). The show cdp interface command shows the interfaces that have CDP enabled; in this example, all of the interfaces have CDP enabled. We also get the status and encapsulation of each interface. The timers are shown, but they are not interface-specific.

    1. Sending Messages

We can send text messages from our terminal line session to other terminal line sessions with the privileged mode send command. The show users command will show us which terminal lines have active sessions and, for VTY's, from where the connections originated. Figure 6-19 shows the use of the two command together.

    1. Dallas#show users
    2. Line User Host(s) Idle Location
    3. * 0 con 0 idle 04:14:36
    4. 5 vty 0 idle 00:00:05
    5. Dallas#send 5
    6. Enter message, end with CTRL/Z; abort with CTRL/C:
    7. Who are you?
    8. Go away!<Ctrl-Z>
    9. Send message? [confirm]y
    10. Dallas#

<<<Figure 6-19 Send Command Example>>>

Line 4 of Figure 6-19 indicates that someone has a telnet connection to our router. The person originated the connection from the host at address To send a message to this user, we can reference the connection's absolute line number, 5, on the send command (Line 6). We are presented with a blank line (Line 8) for entering the text message. After entering the message, pressing <Ctrl-Z>, and confirming the operation, the message is sent to the specified line. The user with the session receives a message like this:



*** Message from tty0 to tty5:


Who are you?

Go away!

The send command also accepts a relative line number along with the terminal line device type. For the example in Figure 6-19, the command send vty 0 would have accomplished the same purpose. If you want to send a message to all active terminal lines, issue the command send *.

    1. Debugging

The debug command allows us to see what IOS is doing as things happen, and it is normally used for troubleshooting and experimenting. We can turn on many different types of debug activities. Each one shows us something different about what is going on inside a router. To see the possible variations of the debug command, use the online, context-sensitive help. Start by typing debug ?, and extend the command from there.

Debug output, by default, is logged to the console line and to terminal lines that have the monitor capability turned on. See Section 5.3.6 for coverage of message logging. When we want to view debug output in a telnet session, we can give our VTY the monitor capability by issuing the command terminal monitor in privileged mode.

Debug output can also be excessive and can overload, and crash, a busy router when the router spends so much trying to tell us what it is doing that it stops doing what it is supposed to be doing - forwarding packets. For this reason, the debug command should be used with caution. Figure 6-20 and Figure 6-21 give sample outputs from debug commands.

    1. Dallas#debug ip rip
    2. RIP protocol debugging is on
    3. Dallas#
    4. RIP: sending v1 update to via Ethernet0 (
    5. subnet, metric 2
    6. subnet, metric 1
    7. RIP: sending v1 update to via Serial1 (
    8. subnet, metric 1
    9. RIP: received v1 update from on Serial1
    10. in 1 hops
    11. Dallas#no debug ip rip
    12. RIP protocol debugging is off
    13. Dallas#
    14. <<<Figure 6-20 Debug IP RIP Output>>>

      The debug ip rip command instructs IOS to log the output and input of the IP RIP process. We see on Line 4 of Figure 6-20 that an update is being sent out the Ethernet0 interface; Lines 5 and 6 show the contents of the update. Line 9 shows an update being received on Serial1, presumably from FortWorth. Line 10 shows that the update contains the subnet address of FortWorth's Ethernet network.

    15. Dallas#debug ipx routing activity
    16. IPX routing debugging is on
    17. Dallas#
    18. IPXRIP: update from AC100B00.0010.7b3a.d4af
    19. AC101400 in 1 hops, delay 7
    20. IPXRIP: positing full update to AC100B00.ffff.ffff.ffff via Serial1 (broadcast)
    21. IPXRIP: Update len 40 src=AC100B00.0010.7b3a.d4bf, dst=AC100B00.ffff.ffff.ffff(453)
    22. network AC100A00, hops 1, delay 7
    23. IPXRIP: positing full update to AC100A00.ffff.ffff.ffff via Ethernet0 (broadcast
    24. )
    25. IPXRIP: Update len 48 src=AC100A00.0010.7b3a.d4bf, dst=AC100A00.ffff.ffff.ffff(453)
    26. network AC101400, hops 2, delay 8
    27. network AC100B00, hops 1, delay 2
    28. Dallas#no debug ipx routing activity
    29. IPX routing debugging is off
    30. Dallas#

<<<Figure 6-21 Debug IPX Routing Activity Output>>>

The debug ipx routing activity command shows the information that the IPX routing protocol process (IPX RIP) is transmitting and receiving. Line 4 of Figure 6-21 shows that an IPX RIP update was received on the interface with IPX network number AC100B00 (Serial1), and Line 5 shows that contents of the update (the IPX network number of FortWorth's Ethernet network). Line 11 shows that an update has been transmitted out the Ethernet0 interface, and Lines 12 and 13 show the contents of the update.

We can turn off debug activity by typing the word no followed by the command that we used to turn on debug activity. (Just say no.) Examples are shown on Line 11 of Figure 6-20 and Line 14 of Figure 6-21.

We could have run both of the examples' debug activities at the same time; as a matter of fact, we can run as many simultaneous debug activities as we believe we, and our router, can handle. As we turn on more debug activities, the output generated by an individual activity gets interlaced with the output from the other activities, and it becomes hard to read and interpret. The easiest way to turn off multiple debug activities is to issue the following command:

no debug all

The no debug all command will turn off all debug activities that have been started. Since the command no debug all exists, the opposite command, debug all, must also exist. The debug all command will turn on all debugging and is practically guaranteed to crash a very busy router and sometimes a not-so-busy router.

    1. Rebooting

There are two ways to reboot a router.

    • Turn it off and back on.
    • Issue the privileged mode command reload.

Turning a router off and back on is the rather obvious way to reboot a router; however, most of the time, the power switch on a router is not accessible to us. Perhaps we want to reboot a router that is in another location. To do that, we have to use the reload command. If a power-cycle is a cold boot, then a reload is a warm boot.

When the reload command is issued, IOS always asks for confirmation before proceeding. See the following example.


Proceed with reload? [confirm]y

Some IOS releases require that we press <Enter> after we answer the confirm question; however, most do not.

If the reload command is issued after a configuration command, but the running configuration has not been copied to NVRAM, IOS will ask if it should save the running configuration for us. The example below shows this.


System configuration has been modified. Save? [yes/no]: y

Building configuration...

Proceed with reload? [confirm]y

If we tell IOS to save the configuration, the startup configuration will be replaced with the running configuration (just like the copy running-config startup-config command was issued) so the router will come back up with the same configuration it is currently running.

If we tell IOS not to save the configuration, it will proceed with the reload, and the router will boot with the current startup configuration that may not include our latest changes.

Previous | Content | Next