Output of Cisco Equipment
This page is largely about using Cisco equipment that is designed for businesses, which may often be equipment that is designed to be mounted on a standard rack. (See: rack unit.) Such equipment may commonly be thought of as designed for “professional” use, rather than “home” use.
There may be various methods of seeing the IOS terminal.
- In-band Management
The term “in-band” simply refers to the fact that this connection method uses up some communication bandwidth one on of the device's main methods of communication. For instance, adjusting the configuring of a Cisco device by using an Ethernet cable will use up some of the bandwidth of the network port being used.
- Key upside to using in-band management
In practice, this can be very nice (and may even be generally preferred) because it allows use of existing physical connections (generally referring to wiring, although in theory the term “connections” could also refer to wireless “connectivity”). In a classroom setting, multiple administrators can easily view the settings of a device simultaneously, each by sitting at their own computer workstation that is connected to the device being worked on. In contrast, with a single console cable using out-of-band management, two students by two computers may need to move the cable from one computer to the other computer, or switch computers (meaning that a student moves from being by one computer to being by the other computer). So, using in-band management just ends up being more convenient.
- Downsides to in-band management
Now, there are some potential downsides to using in-band connection for interacting with the device.
- Initial setup requires out-of-band
One major downside is that this style of method may require pre-configuration. Cisco IOS documentation on Configuring Terminal Operating Characteristics for Dial-In Sessions has a “Note” stating:
Cisco routers do not accept incoming network connections to asynchronous ports (TTY lines) by default. You must specify an incoming transport protocol before the line will accept incoming connections. For example, if you are using your router as a terminal server to make console-port connections to routers or other devices, you will not be able to use Telnet to connect to these devices. You will receive the message "Connection Refused."
What this means is that out-of-band connectivity is required when initially working on the device. (However, the out-of-band connectivity may then be used to setup the in-band connectivity, which may be more convenient afterwards. That may be a course of action that enables a much higher level of convenience, and therefore can be highly recommended as long as security is sufficient.)
MCMCSE guide discussing Telnet on Cisco devices shows Telnet being unavailable on an unconfigured router, and notes, “This seems like a problem, but it's a problem we're happy to have.” ... “That's a good thing”.
- Security concerns
One downside to in-band connectivity is that in-band connectivity can can allow remote administration, which may provide a larger opening and so may be a greater security risk (compared to using an out-of-band method that relies on a physical connection which is able to be physically secured).
This problem can be substantially reduced, to the point of being a non-concern, if security is properly handled. Most notably, one proper measure is to disable the Telnet server and to rely on SSH instead.
- Bandwidth usage
Technically speaking, yet another downside is that this does use up some of the bandwidth. However, the amount of bandwidth used is typically negligible, so this isn't really an issue in practice. (This problem is more theoretical, rather than being truly important.)
There are some different ways to configure devices.
- In-band command lines
Some protocols use up bandwidth on the main communication connections (like Ethernet ports), and provide the remote user with a “command line interface”. The user can then type commands which can provide information about a device and alter behavior of the device.
(This topic was noted as being covered by “Discovery 3” slide “22.214.171.124”. That information may be helpful for anybody with current access to Cisco's CCNA training material, which has been made available to people who signed up for college courses that use official Cisco training material.)
An excellent choice, although this is generally disabled by default. So, SSH needs to be set up first (before it can be used).
A supporting device, including a computer, could then run an SSH client. (See: SSH terminal clients.)
(This topic was noted as being covered by Cisco Network Academy CCNA training “Exploration 3” slide “126.96.36.199”. That information may be helpful for anybody with current access to Cisco's CCNA training material, which has been made available to people who signed up for college courses that use official Cisco training material.)
If a person has access to using a CLI, the device's SSH server could be enabled by following the instructions listed at starting an SSH server with Cisco IOS.
A choice that is far less preferred for managing a Cisco IOS device compared to using SSH, except that setting up a Telnet server on a Cisco IOS device is a bit easier than setting up an SSH server on a Cisco IOS device. Therefore, for quick test/academic scenarios, using this make sense. This may also be a poor alternative if SSH is not supported by the IOS image being used, although for serious/production use the recommendation is to use SSH (even at the cost of changing to a different IOS version).
For details on using a Telnet client, see: Telnet.
- Web-based options
At least historically, Cisco has expected certified professionals (and those who completed Cisco's training) to be familiar with using command line options. Command line interfaces were deemed to be more important for professionals to be trained in, rather than just relying on (meaning: the options that use software protocols similar to what is most commonly used on the world wide web). A key reason was that the web-based options were described as being inferior. If they even existed, and if they even worked (being installed onto a device), they still might not be able to perform all of the tasks that could be done from a command line.
Presumably Cisco has improved their web based offerings over the years, so some of that might not still be true. For people who have not completed training in using the command line, using a web-based approach might be a way that some people can successfully use, more quickly, rather than figuring out how to do something from a Cisco command line interface.
This guide is not trying to promote the usage of the web-based interfaces over using the command line, but is simply mentioning them as a possible option that may be technically feasible for some people to use, at least on some equipment.
This might not provide access to the command line, but Cisco Router and Security Device Manager (SDM), or variations (SDM Express) may be an option for configuring a device. This may require that the client supports running Java web applications. The good news is that the software may be pre-installed. The even better news is that if the software isn't pre-installed, Cisco has made some software be freely downloadable. The SDM download site may offer a free download of SDM Express, although that may simply direct to a generalized download page.
An option called “Cisco Configuration Professional” (“CCP”) may allow usage of HTTP or, much better, HTTPS.
This option might not have been covered extensively by Cisco Discovery or Cisco Exploration training material (perhaps because the version of that training material which was used was simply older than when Cisco started promoting/pushing CCP as a viable option for people to know about).
This is likely an option; details are not currently provided here.
- Out-of-band Management
- Traditional Console Cable
The classic method is to use a cable using Cisco's “Rollover” wiring. A famous variety of this cable has a DE-9 (often called “DB-9”) connection, a flat middle where the cable is light blue in color, and an “RJ-45”-style end (which does mean that it can physically plug into an Ethernet jack). Although the RJ-45 end means that the cable should be able to physically fit very nicely into an Ethernet port, that is not the intended use. Instead, the “RJ-45”-style end is meant to plug into a port labelled “Console”. The other end plugs into a computer's DE-9 ports.
Communication may then be done with a “dumb terminal” “communications” software program designed to communicate with a serial port, using communications settings of 9600 bps 8N1.
- Modern variation for using a console cable
Newer computers do not typically support DE-9 ports. One approach has been to purchase a USB converter that allows the computer to connect to a DE-9 connector. (As noted by the glossary section for DE-9, many products supporting DE-9 identify themselves with DB-9.) Unfortunately, when discussing this matter with multiple technicians, the general feedback received (by the author of this text) is that some of these adapters work painlessly, while others do not work easily/reliably.
Currently, this guide does not have any recommendations regarding an adapter that is known to work easily/reliably, so some research or experimentation (gambling) may be required.
- Packet Tracer interface
Packet Tracer is a piece of software released by Cisco. This software doesn't help work with physical devices, but the software can contain emulated devices that are accessible from within the software.
Cisco has confused things a bit by offering a feature called “Packet Tracer” built into some osftare, such as the Cisco Configuration Professional (“CCP”) software. This feature can be accessed by selecting a menu option, and it shows how a certain type of packet is expected to be handled by a device. That simple “Packet Tracer” feature is basically unrelated to this more full “Packet Tracer” software which has support for running virtual appliances.
Within the full Packet Tracer software, there may be different “labs”. (A lab corresponds to a data file that the software can use.) If a lab permits the ability, then seeing the configuration is generally an available action that can be taken by clicking on the virtual device, and then choosing the tab called “CLI”. However, a lab can lock down that ability.
- Auxiliary port
Some documentation indicates that using a PSTN (Public Switched Telephone Network, a.k.a. dial-up connection using a traditional telephone landline) may be able to connect to an auxiliary port.
Dedicating an entire telephone line/number to remotely configure a device may seem like a rather expensive way to provide convenience of remote access. However, before high speed Internet access was quite as wide-spread, and before war-dialing became quite as popular of a technique for attackers, this option probably seemed to make more sense for some organizations. Paying for a phone line may be less pricey than needing to pay an experienced technician to drive to a location which might be quite some distance away, and this could provide faster resolution to some types of problems. As a result, some devices (perhaps particularly older devices) would have the physical hookup for this type of option.
Further details, on setting this up, are not currently available here. Some commentary follows this paragraph, but is not meant to reflect any actual verified experience, tests, or documentation that has been followed. (Some of it may be guesswork.)
Support for this probably involves using terminal software. Once such a connection is enabled on a device, see the section on Client-side terminal software, and perhaps POTS modem, dial-up modem speed, Cisco IOS documentation on Configuring Terminal Operating Characteristics for Dial-In Sessions
Once such a connection is made, a computer can be used to interact with a device. This computer will need to run some appropriate software. Many of the “out-of-band” maangement options will require using client-side communications “terminal” software.
There is some various software that can be used to interact with Cisco devices.
- Client-side terminal software
This may often involve “communications/terminal” software, allowing a computer to simulate the functionality of a “dumb terminal”. Software options may be discussed by TOOGAM's Software Archive: Terminal Software (especially the section TOOGAM's Software Archive: Serial Port terminal software). (Some further discussion may be provided by Remote Access, in the sub-section called “Interacting as a dumb terminal”.)
- Cisco-specific software
See: Cisco software.
For in-band maangement, some other software may be needed. See the section on Client-side terminal software (e.g. for remote access command line methods, the sections for the secure shell (SSH) protocol or the Telnet protocol. Or web browsers.)
That concludes this section of Cisco-related material, which is mostly about using the hardware. Another aspect that is crucial for actually making use of the hardware is to master using some software to set up the device. Such details may be part of additional Cisco-related material available here: see Introduction to using Cisco equipment for some further details about what to do. (In other words: that guide contains details about how to interact further with the equipment.)