Category: CCNA Study Guide Chapter 07

Configuring IPX addresses and related settings isn’t really any more difficult than IP, although there are a few extra steps involved.

The first step in configuring a router to use IPX involves enabling IPX routing globally. This is done from global configuration mode, using the ipx routing command.

cisco2501#config t
Enter configuration commands, one per line. End with CNTL/Z.
cisco2501(config)#ipx routing

The next step is configuring an interface with an IPX network number. Remember that IPX addresses are 80 bits in length. The first 32 bits represent the network, and the last 48 bits are assigned automatically as per the interface MAC address. Because of this, we actually don’t need to specify the complete address – only the network number, which will ultimately have the interface MAC address appended to it. In this case, we’ll configure interface Ethernet 0 to be part of IPX network 101A. Recall that IPX addresses are listed in hexadecimal, and that any leading 0s can be left off the address.

cisco2501(config)#int ethernet 0
cisco2501(config-if)#ipx network 101A

The interface is now configured to run IPX. However, you may recall from Chapter 4 that IPX can be configured to use different incompatible frame types. Table 7-3 outlines the four IPX frame types used in Ethernet environments. The default is novell-ether (the Ethernet 802.3 frame type), unless you specify otherwise.

Novell Ethernet frame types and their Cisco IOS encapsulation names:

Ethernet 802.3: novell-ether
Ethernet 802.2: sap
Ethernet II: arpa
Ethernet SNAP: snap

In order to set the frame type for an interface, add the encapsulation command when configuring the interface network number, as shown below.

cisco2501(config-if)#ipx network 101A encapsulation sap

In this case, we set the interface encapsulation to Ethernet 802.2, or sap. An IPX interface can actually be configured for multiple frame types. However, different frame types use different network numbers, since they cannot communicate with one another. To add an additional IPX frame type to an interface, use the ipx network command, followed by the secondary keyword.

cisco2501(config-if)#ipx network 101B encapsulation arpa secondary

In this case, we configured interface Ethernet 0 to use arpa (Ethernet II) encapsulation for another IPX network, 101B.

One other interface configuration command that you’ll need to be familiar with is the bandwidth command. The bandwidth command is used to specify the configured bandwidth of an interface, such as serial 0. It’s worth noting that this command doesn’t change the actual bandwidth of a physical interface, but instead communicates the bandwidth available on an interface to upper-layer protocols. For example, serial interfaces have a default bandwidth of 1.544 Mbps on a Cisco router. However, if the interface has only a 64 Kbps circuit attached, you would issue the bandwidth command on the interface specifying this. This number would then be used by certain routing protocols (such as IGRP) that use bandwidth as one of their metrics in determining the best route to a destination. While IGRP will be looked at in more detail in Chapter 8, for now it’s important to simply know how to configure the bandwidth value for a serial interface. The bandwidth command is always followed by a value expressed in kilobits per second (Kbps). This is important to remember, since it is easy to confuse the bandwidth and clock rate commands.

Router1(config)#int s1
Router1(config-if)#bandwidth 64

In the example above, the bandwidth on the interface S1 has been set to 64 Kbps.

In a real-life network, your serial interfaces will almost certainly be configured as DTE interfaces. Recall that a CSU/DSU usually handles the clocking for a synchronous serial interface. If you’re working in your own lab, however, you may be connecting the serial ports of two routers directly using what is known as a DCE-to-DTE crossover cable. These cables allow you to simulate a serial WAN connection without requiring a CSU/DSU or similar device.

Figure: Connecting the serial ports of two routers using a DCE to DTE crossover cable.

The main issue with connecting your serial interfaces in this manner is the fact that one of the devices will need to be configured as DCE in order to provide the timing mechanism required. The DCE-to-DTE crossover cable will have two different DB-60 interfaces – one marked DTE, and the other marked DCE. The router connected to the DCE end of the cable will need its serial interface configured as a DCE device.

For the sake of argument, we’re going to assume that we are simulating a WAN link between two routers, Router1 and Router2. Their serial interfaces have already been configured with relevant IP address settings. On the DCE device, we need to configure the serial interface using the clock rate command.

Router2(config-if)#clock rate 56000
%Error: This command applies only to DCE interfaces

Notice what just happened. I accidentally attempted to configure the clock rate on Router2 (the DTE device) instead of Router1. Router2 makes me aware of my mistake by letting me know that I have attempted to configure the wrong device – it recognizes its cable connection as DTE. Attempting the configuration again on Router1 yields the following results.

Router1(config-if)#clock rate 56000
Router1(config-if)#

Because we didn’t get an error message, the command completed successfully. Notice that we set the clock rate to 56000, a value represented in bits per second. A variety of clock rates are possible, and can be viewed by entering the question mark after the clock rate command.

If you’re looking for a quick way to check whether a serial interface is connected to the DCE or DTE end of a crossover cable, use the show controllers command. The first few lines of output are shown below.

Router2#show controllers serial 0
HD unit 0, idb = 0x710CC0, driver structure at 0x716140
buffer size 1524 HD unit 0, V.35 DTE cable

In order to get our router to do anything truly useful, we’ll need to configure its interfaces. Recall that on a Cisco 2501, we have one Ethernet interface and two serial interfaces. We’ll start off by configuring these interfaces with IP addresses, and follow up by configuring IPX addresses.

Ethernet and serial interfaces are configured from the interface level of global configuration mode. In order to configure interface Ethernet 0, we’ll need to access that interface.

cisco2501#config t
Enter configuration commands, one per line. End with CNTL/Z.
cisco2501(config)#int e0

Our next step will be assigning interface Ethernet 0 an IP address. This couldn’t be easier – we’ll simply use the ip address command.

cisco2501(config-if)#ip address 192.168.1.46
% Incomplete command.

After entering the ip address command along with the address we want to configure, we’re faced with the incomplete command message. Obviously that means that we’ve forgotten something. Use the question mark to figure out what that something is.

cisco2501(config-if)#ip address 192.168.1.46 ?
A.B.C.D IP subnet mask

It’s now clear that we’re supposed to also add a subnet mask value following the IP address. In this case, we’ll use a mask of 255.255.255.0.

cisco2501(config-if)#ip address 192.168.1.46 255.255.255.0

The address is now set, but even if you tried to ping it from another system, you wouldn’t receive a reply. Why not? Because even though it has been configured, the interface is still not “turned on”. In order to make the interface active, you will need to enter the no shutdown command.

cisco2501(config-if)#no shutdown

Assuming that you have a straight cable connecting the Ethernet 0 interface to a hub or switch, you should now be able to ping it from other systems.

Tip: As a best practice, issue the show interface command after configuring an interface to be sure that it is functioning correctly.

Configuring our router’s serial interfaces is really no different – access the serial interface that you wish to configure, and allocate an IP address and subnet mask using the same command. Remember that the no shutdown command will also need to be issued. The output below shows the configuration of IP address 192.168.2.1 on interface serial 0.

cisco2501(config)#int serial 0
cisco2501(config-if)#ip address 192.168.2.1 255.255.255.0
cisco2501(config-if)#no shutdown

A variety of other properties can be configured for interfaces beyond their addresses and shutdown properties. To get a listing on the commands available, use the question mark from the router(config-if)# prompt.

It’s usually a good idea to also add a description to interfaces. For example, we could add a description to the serial 1 interface, mentioning that it connects the Toronto router to our Montreal location. This is also accomplished from the interface level of global configuration mode.

cisco2501(config)#int s1
cisco2501(config-if)#description WAN link Toronto to Montreal
cisco2501(config-if)#^Z
cisco2501#show run
Building configuration...
Current configuration:
interface Serial1
description WAN link Toronto to Montreal
ip address 192.168.2.1 255.255.255.0

I once again truncated the output from the show run command, limiting it to the pertinent information about the serial 0 interface. Notice the description is now included in the interface section. This provides a quick and easy way to reference what a given interface connects to.

If you have used Windows or other operating systems in a corporate environment, you are likely familiar with the concept of a login message or banner. This is a message presented to users, usually before they attempt to log in. The main reason for these banners is to provide users with information, perhaps a warning message that makes them aware of security restrictions on this particular equipment. While this message won’t do anything to actually stop them from attempting to log in, it does help to cover things from a legal perspective.

Many operating systems and applications provide users with a “welcome” prompt. Believe it or not, there are precedents where hackers have claimed that they were “in the right” for hacking into private systems – the message did welcome them, after all.

Regardless of how ridiculous you may think this is, it’s still a good idea to set up banner messages on your systems. At the very least, you are making people who attempt to connect aware that unauthorized users should not be accessing the system.

A variety of different banners can be created on a Cisco router, but the most popular is the “message of the day” or MOTD banner. Users will be presented with this banner every time they attempt a connection via the console port, auxiliary port, or a telnet session. MOTD banners are configured from global configuration mode. In the example below, we’re going to configure our router to display a simple message that states that only authorized users are allowed access.

toronto-1#config t
Enter configuration commands, one per line. End with CNTL/Z.
toronto-1(config)#banner motd ?
LINE c banner-text c, where 'c' is a delimiting character
toronto-1(config)#banner motd #Authorized Access Only!#

The command used to configure a MOTD banner is banner motd. Notice that we followed the command with a question mark, in order to determine how to complete it. In this case, the output tells us that we need to start and end the banner message with a “delimiting character”. A delimiting character is one that cannot be used within the actual message. For example, you might choose to use the $ or # signs, with the same character appearing at the beginning and end of the message. Logging out and attempting to access the router again presents us with the MOTD banner.

Authorized Access Only!
User Access Verification
Password:

Normally, passwords other than enable secret will appear in our configuration files in plain text. Even though you need to be in privileged mode to view the configuration files, encrypting all passwords is still a good idea. Eventually we’ll back up the configuration files to a network server, which means that other people may have the ability to access and view them.

The command used to manually encrypt passwords is service password-encryption. You can encrypt any password manually by first issuing this command from global configuration mode, and then changing passwords as you normally would. Once complete, enter the no service password-encryption command. In the example below, we have encrypted both the auxiliary and console port passwords.

toronto-1(config)#service password-encryption
toronto-1(config)#line con 0
toronto-1(config-line)#login
toronto-1(config-line)#password cisco1
toronto-1(config-line)#line aux 0
toronto-1(config-line)#login
toronto-1(config-line)#password cisco1
toronto-1(config-line)#exit
toronto-1(config)#no service password-encryption

After completing the steps listed, you can view the encrypted versions of the passwords by using the show running-config command. I have again truncated the output to show only the pertinent information.

toronto-1#show run
Building configuration...
Current configuration:
line con 0
password 7 01100F17580457
login
transport input none
line aux 0
password 7 03075218050070
login
transport input all
line vty 0 4
password cisco1
login
!
end

Notice that both the console and auxiliary passwords have been encrypted. The vty password has not, since we didn’t specify it while configuring the encrypted passwords. Viewing the startup configuration at this point would still show unencrypted versions of all these passwords. Why? Because we haven’t saved our changes to the startup-configuration, of course!

toronto-1#sh star
Using 790 out of 32762 bytes


line con 0
password cisco1
login
transport input none
line aux 0
password cisco1
login
transport input all
line vty 0 4
password cisco1
login
!
end

Remember that in order to save our changes, we need to save the running configuration to the startup configuration. In simple to remember shorthand, you can simply enter the command copy run star.

A console password is configured from global configuration mode, at the console line level. The output below outlines each step from privileged EXEC mode forward.

toronto-1#config t
Enter configuration commands, one per line. End with CNTL/Z.
toronto-1(config)#line console 0
toronto-1(config-line)#login
toronto-1(config-line)#password cisco1

Notice the series of commands above. First, global configuration mode was accessed, and followed by entering the line console 0 level. The command login specifies that we are requiring users to be authenticated to access this port. If we later changed our mind, we could remove the requirement by using the no login command. Finally, the password was set using the password command along with the password itself – in this case, cisco1. When setting passwords, they appear on the screen in plain text. During the login process, they are not visible.

Setting an auxiliary password follows the same steps, with the exception that the auxiliary line must be accessed.

toronto-1#config t
Enter configuration commands, one per line. End with CNTL/Z.
toronto-1(config)#line aux 0
toronto-1(config-line)#login
toronto-1(config-line)#password cisco1

In this case, I went back to shorthand and used aux 0 instead of typing out auxiliary 0. You should make a point of using shorthand where possible to save time and avoid typing errors.

Configuring virtual terminal passwords for telnet sessions works a little differently. If you do not set vty passwords on the router, you will not be able to make a telnet connection to it – this is obviously a security feature. In order to set telnet passwords, you will need to follow the configuration listed below. In this example, we are going to configure all 5 virtual terminals to use the same password. Note the syntax used.

toronto-1#config t
Enter configuration commands, one per line. End with CNTL/Z.
toronto-1(config)#line vty 0 4
toronto-1(config-line)#login
toronto-1(config-line)#password cisco1

Pay particular attention to the third line of output above. The line level accessed was for all five virtual terminal lines, numbered 0 through 4. By accessing the line level for all 5 simultaneously, we have made 5 telnet sessions possible using the password cisco1. To allow only a single telnet session, the command would be line vty 0. The 4 other sessions would then not be accessible.