Most users of internetworks don't communicate with routers, they communicate through them. Network administrators, however, must deal directly with individual routers in order to install and manage them.
Routers are purpose-built computers dedicated to internetwork processing. They are important devices that individually serve hundreds or thousands of users-some serve even more. When a router goes down, or even just slows down, users howl and network managers jump. As you might imagine then, network administrators demand foolproof ways to gain access to the routers they manage in order to work on them.
Routers don't come with a monitor, keyboard, or mouse, so you must communicate with them in one of three other ways:
From a terminal that's in the same location as the router and is physically connected to it through a console cable (the terminal is usually a PC or workstation running in terminal mode)
From a terminal that's in a different location as the router and is connected to it through a modem that calls another modem connected to the router with a cable (typically connected on the auxiliary port on the router)
Through the network on which the router sits using terminal emulation software, such as Telnet, SSH, or Web-based management consoles using HTTP or HTTPS
In large networks, network administrators are often physically removed from routers and must access them over a network. However, if the router is unreachable due to a network problem, or if there's no modem attached to the router itself, someone must go to its location and directly log into the router. The three ways to gain administrative access to routers are depicted in Figure 3-5.
Figure 3-5: Administrative access to routers is obtained in three different ways
Even when network administrators manage routers in the same building, they still prefer to access them by network. For many organizations, it doesn't make sense to have a terminal hooked up to each router, especially when there are dozens of them stacked in a data closet or computer room. Also, it's much more convenient to manage them all from a single PC or workstation.
There are several ways to communicate with a router, each made possible by a particular communications protocol. Table 3-2 lists each method, the protocol, and how each is used.
Serial line connection from local terminal.
Serial line terminal connection via modem.
Telnet/Secure Shell (SSH)
Virtual terminal connection via TCP/IP network.
Web browser connection via TCP/IP network.
Simple Network Management Protocol; virtual terminal connection made via a TCP/IP network. (SNMP is covered in Chapter 13.)
Every Cisco router has a console port. It is there to provide a way to hook up a terminal to the router in order to work on it. The console port (sometimes called the management port) is used by administrators to log into a router directly-that is, without a network connection. The console must be used to install routers onto networks because, of course, at that point there is no network connection to work through.
Long term, the console's role is to be there as a contingency in case of emer gency. When a router is completely down-in other words, when it is no longer able to process network packets-it cannot be accessed over the network. If the router is up and processing packets, but the network segment through which the technician must access it is down, going over a network to fix the router is not an option. This is when the console port provides a sure way to log into the router to fix things, or you have a special terminal server configured to allow access remotely.
A stand-alone client, PC, or workstation can be used as a console. Console terminals must run a character-based user interface. They cannot run a graphical user interface (GUI), such as Microsoft Windows, Mac OS, or X-Windows. In order to use a PC or workstation as a console, you must use terminal emulator software. For example, one of the best-known terminal emulators is HyperTerminal from Hilgraeve, Inc., which ships with all versions of Windows. Start up HyperTerminal (or one of the many other terminal emulator products), and log into the router from there.
Console ports in Cisco routers use a variety of connector types (25-pin, RJ-45, 9-pin, and so on), but all provide a single terminal connection. A word of warning: Make sure you have the proper rollover cable-not an Ethernet cable-before trying to hook up a console terminal to work on a router. Many a network administrator has spent a halfhour fiddling with cables to finally find one that could connect to a router just to do 15 minutes of productive work.
Console ports on Cisco devices are usually labeled "Console"-but not always. On some products, console ports are labeled "Admin," and on others they are labeled "Management." Don't be confused by this; they are all console ports.
Most Cisco routers have a second port on the back called the auxiliary port (usually called the AUX port, for short). Like the console port, the AUX port makes possible a direct, non-network connection to the router.
How does the AUX port differ from the console port? The AUX port uses a connector type that modems can plug into (console ports have connectors designed for terminal cables). If a router in a faraway data closet goes down, the network administrator asks somebody in the area to go to the router and plug in a modem so that it can be serviced remotely. In more critical configurations, a modem is often left permanently connected to a router's AUX port. Either way, the AUX port affords console-like access when it isn't practical to send a technician to the site to work on a router through a local console.
Figure 3-6 shows the console and AUX ports on the back of a Cisco 4500 router.
Figure 3-6: Console and AUX ports on a Cisco 4500 router make direct, non-network connections possible
Cisco's smaller routers do not have AUX ports, only console ports. These devices support remote management logins by connecting a modem to the router using an auxiliary/console cable kit.
Once a router is installed on a network, access to it is almost always made through a Secure Shell (SSH) connection or a non-encrypted Telnet session, not through the console or AUX ports. The more security-conscious would prefer an SSH connection, and this should certainly be used when accessing a device over an untrusted network (which is practically any network when it comes to the type of administration one does with a piece of network infrastructure). In this section, we'll use the term Telnet, but everything in the discussion can be applied to SSH, too, since it is essentially a secure form of Telnet. This connectivity is just simply a way to log into a router as a virtual terminal. "Virtual" here means that a real terminal connection is not made to the device through a direct cable or a modem, as with the console or AUX ports. Telnet connections are instead made through the network. In the most basic terms, a real terminal session is composed of bits streaming one by one over a serial line. A virtual terminal session is composed of IP packets being routed over a network, pretending to be bits streaming over a serial line.
Telnet is a network application, not a terminal emulator. It was developed in the early days of the UNIX operating system as a way to log into remote computers to manage them. Later, internetwork pioneers incorporated Telnet directly into the TCP/IP networking protocol as a way to get to and manage internetwork devices. A Telnet client and server ships with every copy of Cisco's IOS software and most computer operating systems.
When using Telnet to access a router, you do so over a virtual line provided by the Cisco IOS software. These are called VTY lines. Don't let the word "line" confuse you. It does not refer to an actual communications circuit; it means a virtual terminal session inside the IOS software. IOS supports up to five virtual terminal lines (numbered VTY 0–4, inclusive), making it possible to have up to five virtual terminal sessions running on a router at the same time. This is probably design overkill, however. It's rare to have more than one virtual terminal session running on a router at the same time. Some routers have even more than five VTY lines, and with the Enterprise version of the IOS, you can even assign more than that.
Cisco's IOS software is used mostly in character-based interface mode, which is to say that it's not a point-and-click GUI environment, such as we've grown accustomed to using on our Microsoft Windows PCs, Apple Macs, or X-Windows UNIX workstations. Whether logging into a router through the console port, AUX port, or Telnet, you are delivered to the character-based IOS software interface. The following shows characterbased IOS output:
! line con 0 exec-timeout 0 0 line aux 0 transport input all line vty 0 2 exec-timeout 0 0 password 7 1313041B login line vty 3 exec-timeout 5 0 password 7 1313041B login line vty 4 exec-timeout 0 0 password 7 1313041B login !
The preceding example is a listing of the seven IOS lines-con for console, aux for auxiliary, and vty for the virtual terminal. The seven lines are:
The console port, accessed through a local cable connection
The AUX port, accessed through a modem connection
Five VTY lines, accessed through TCP/IP network connections
A more recent router access method is HTTP Server. Don't be misled by the name; no computer server is involved in using HTTP Server. The "server" in HTTP Server refers to a small software application running inside the Cisco IOS software. HTTP Server first became available with IOS Release 10.3. HTTP Server makes it possible to interact with the router through a Web browser. Figure 3-7 shows an HTTP Server screen.
Figure 3-7: Cisco IOS can be managed through an HTTP Server screen
Like so many Cisco devices and applications, its user applications tend to change over time. Your device's interface may or may not look like the one in Figure 3-7. That said, the same basic functionality will be present. It will just be accessible through a slightly different interface.
Using HTTP to handle IOS command-line input and output isn't particularly ergonomic. The majority of network administrators still prefer using the IOS software in character-based mode because it's faster and more direct than pointing and clicking. This is not unlike those old hands who jump into Microsoft Windows' MS-DOS prompt window to type system-level commands, but Cisco may gradually move IOS toward a graphical user interface for a couple of reasons. The most obvious reason to at least offer a GUI-based alternative to working with IOS is that Cisco devices are increasingly being tended to by nonexperts. The other is that as complexity increases, the need for system visualization, even inside a single router, grows. Using visualization tools (to show load conditions, isolate errors, and so on) will, of course, require a browser instead of the oldfashioned "green screen" character-based command-line interface.
To use the command-line interface, you must know what commands to type. You may want to use HTTP Server to get started and phase over to character-based mode as you become comfortable with the IOS command structure.
Cisco Router and Security Device Manager (SDM) is the latest embedded devicemanagement tool. Access is handled through an SSL or SSH connection for secure communication between the Web-based user interface and the device being managed. Best of all, it's downloadable for free and works with almost all supported routers. For the newest routers, like the 850/870 and the 1800, 2800, and 3800 models, it's already installed and ready to use, right out of the box.
To make life easier, Cisco Router and Security Device Manager offers what Cisco calls "task-based smart wizards" to help with everything from initial configuration to more complicated WAN/LAN and security configurations. It's a logical step forward in device management for small and medium-sized businesses, and also useful for enterprise branch offices environments, where CiscoWorks might be the primary configuration management tool, and Cisco Router and Security Device Manager is used for troubleshooting or to allow read-only access to the device for local personnel. The download and additional information can be found at http://www.cisco.com/go/sdm.
SDM also employs SSL and SSH connections to allow administrators to easily configure routers remotely.
When you start SDM, you see a screen like the one in Figure 3-8. It gives you a quick snapshot of the status of your router, including:
What features are available for your router (like VPNs, firewall, and so forth)
Interface and connection configuration information
Firewall configuration information
VPN configuration information
Figure 3-8: The SDM home page shows a summary of router information
Smart Wizards are used in SDM to help configure the various features of your Cisco router. These wizards are helpful, because you can configure these features simply pointing and clicking, rather than try to figure out the cryptic command line.
Launching one of the wizards is just like the countless other wizards you've probably used with a Windows system. For example, to configure the serial line, we started the WAN Wizard. Its starting screen is shown in Figure 3-9.
Figure 3-9: SDM aids configuration with a number of Wizards, like the WAN Wizard
Once we've selected the interface we wish to configure–-in this case, the serial line-we are taken to another page, this one asking what type of encapsulation we want to configure. As Figure 3-10 shows, we're given the option between Frame Relay, Pointto-Point Protocol, or High-Level Data Link Control.
Figure 3-10: Choose the encapsulation type that best meets your needs
After choosing our encapsulation type, we're taken to another screen, shown in Figure 3-11, that asks us for the connection's IP address and subnet mask.
Figure 3-11: Enter the connection's IP address and subnet mask
Once the wizard is done gathering information from you, it turns your choices and instructions into a configuration file for the router.
The command line isn't totally out of the picture. The fact of the matter is that once you configure your router or a feature on the router, SDM takes what you've pointed and clicked to and turns it into IOS code.
SDM also lets you monitor your router so that you can observe real-time metrics. For instance, the screen in Figure 3-12 shows a number of useful details. We can examine the CPU usage, total memory used, and flash memory used. Furthermore, we can examine the status of each connection, showing us whether it is up or down and how much bandwidth is being used.
Figure 3-12: SDM allows monitoring of various router details
To get even more in depth on an interface, clicking Interface Status on the left column of icons launches a tracking tool that allows you to monitor such details as:
Bytes in and out
Packets in and out
This tool is shown in Figure 3-13.
Figure 3-13: The Interface Status tool allows you to track interface statistics
SDM also allows you to quickly configure a firewall on your router. The Firewall Wizard can walk you through the steps needed to implement varying levels of security.
Another feature of SDM is the Router Security Audit. When you launch this tool, SDM examines your router's configuration and tells you where security needs to be bolstered. An example is shown in Figure 3-14.
Figure 3-14: The Router Security Audit tool examines the router's security configuration
Once this tool has examined your router and identifies any weaknesses, you can check individual issues, which can then be automatically corrected by SDM.