Cisco IOS Usage

This guide once contained more information on this page, but as information grew, this information was re-organized to go onto separate pages. Some details about changes are located in the Cisco guide: moved info section.

Later, a shortened guide has been created. The shorted guide has been designed for people who might not be starting a full-scale training program designed for full Cisco Certified Network Associate (“CCNA”) certification, but just want a more minimal list of commands that enables a user to start accomplishing some tasks. To see that shortened guide, check out: Cisco: Beginning Steps.

Early Text

Handling configurations

Once the system is started, and the system output can be seen, if not even earlier, there may be some interest in getting the equipment to be interacting with the network.

When the system starts up, the device will check the “configuration” being used. The configuration can cause a device to not communicate as some people might expect. In perhaps the most severe case, an ISR (“Integrated Services Router”) will typically default to having all of the network ports be “administratively down” until they are configured. Switches may typically forward traffic by default, but the presense of a VLAN configuration file can cause traffic to not be forwarded to other network ports.

Even if a person approaches a running device and finds the device is configured well enough for network traffic to start to be useful, the device may forget the configuration as soon as it loses power. So, some understanding of files is useful so the device can work again after it is turned off and then back on.

Note that some of the topics discussed in the file-handling section may involve using network traffic. Such abilities may not be functional until after the network interfaces are configured.

Cisco IOS file handling

This documentation provides a reference to Cisco IOS file handling early on.

Official Cisco training may often cover this piece by piece, teaching about the startup-config file early on, and not covering details like TFTP support, or memory locations (like flash and NVRAM) until much later. However, such details may be on the CCNA Routing and Switching certification examination, and are details that couild be quite helpful for somebody who wishes to backup existing data (including not only a configuration file, but also the operating system boot image). The author of this text thinks this is a good task for somebody to be able to do early on. So, while the author of this text does acknowledge that some of the details, like connecting to a remote TFTP server, may not be implementable early on (before a person has the details for setting up an IP address), these details seem worthwhile. This way, as changes are made (like setting up an IP address), people can have a good concept of where changes are getting made.

So, this guide does recommend seeing a Cisco (IOS) File Handling for a primer/introductory tutorial.

Finally, it is hereby acknowledged that many other guides, including official Cisco training material, may take a different approach and may not cover such details until some of the more advanced segments. Well, different guides are entitled to take different approaches.

Main Start

See: Setting up an interface.

Further Info

Another useful command
The do command

Cisco IOS's “do command”, documented by “aaronm in Cisco networking”, found on tech-recipes.com and archived by the Wayback Machine @ Archive.org mentioned using do when using Cisco IOS 12.2(8) or newer.

This allows a user “to run privileged commands in global config mode”. So, when the prompt shows “config or config-if”, using the do command “will save you the trouble of exiting to privileged mode to check your work”.

After the word do, another command is typed. However, from arronm's guide, it seems like there may be a limited number of commands that can come right after the word do. Apparently these should work well:

  • do show
  • do ping
  • do clear
  • do debug

One example was being at a (config-if)# prompt and running: “do show run”.

Adding Routing

The previous instructions provide the basics for being able to communicate with a device on the same subnet. Perhaps paritcularly for routers, there may be a desire to communicate with other subnets.

There are various ways of handling routing. Manually setting up a “default gateway” is a fairly easy and straightforward method, and is likely a very common task, particularly for network setups that are created by beginners, or which are simply still in a beginning stage of implementation.

The recommended places to check out are details covered by the routing section. To view routing tables, see:

Disabling Default Behaviors

This is recommended, and details (about disabling Cisco Discovery Protocol (“CDP”)) used to be located here. Now, information has been moved: see: disabling default behaviors.

Config wrap-up

If things are working well, consider saving the configuration.

View running-config. (See: Cisco OS: IOS: file handling: viewing files.)

One key thing to note from that documentation on viewing files: If there is just a section of the running-config, piping may be useful. See: Cisco OS: IOS: file handling. For instance, the following may work:

show running-config | begin line vty

If everything is great, then copy the running configuration over the startup configuration. Cisco OS: IOS: file handling discusses this in various locations.

Another option is to use “secure boot” to protect this startup configuration. (Taht is also discussed by Cisco OS: IOS: file handling.)

Misc Notes

(Some of the following material may be less basic; it is material that has been documented, and is useful information. The documentation has been placed here for now, but may be moved at a later time.)

Auto Secure

Some devices come with a script that adjusts a lot of default settings to... other settings. Since this comes with the devices, both the defaults and the resulting alternative bunch of settings are available from the box. Presumably this means that Cisco has learned what some of the better settings are, but Cisco decided to leave certain settings to the well-known default values anyway, even if those are considered to be less secure. Presumably there may be some advantages to the default settings, like concerns about compatibility or simplicity for people who use documentation or training that may already be created.

warning/backup

Note that this may change multiple settings, and there may not be an automated way to simply reverse only the changes that are made by this command. So, in case any of the effects are undesirable, make sure to back up any existing configuration before running this command. (Backing up the configuration isn't needed if the configuration is already sufficiently saved, like if the device hasn't been customized at all since settings were loaded from the default configuration stored on the router (presumably in the operating system's boot image? Or maybe ROM?) Effective backups can generally be made by asking a terminal program to capture ASCII text, and then showing the configuration, or by saving a configuration and backing up the file. See: Cisco IOS file handling.

Anyways, one simple command might make multiple changes for security. The command is:

auto secure

On other devices, this command might be unknown, and so trying to run the command is unlikely to do any harm.

On some devices, that may be rather interactive. There may be another parameter that performs less steps, but is less interactive.

Secure Boot

The “secure boot” feature makes it so that certain data should be protected from being able to be changed using the command line interface over a remote connectin. Changes can still be made by using the command line interface over a “console cable”, but something like an SSH connections over a VTY line should be unable to change the data.

The data that can be protected with “secure boot” is the IOS image and the Startup configuration. The idea is that if a device protects those files, and if the device is then rendered into a non-operational state, hopefully a reset is all that will be needed for the device to return to a state that allows an administrator to easily control the device. Without this feature, if an attacker somehow gained remote access to the device, the device could be placed into a non-operational state simply deleting a key file and telling the router to reload. Even worse, after the device reloads, the device would not be returned into a state what easily allows the administrator to control the device.

Speeding Up The Spanning-Tree Waits

Instead of enduring the 50 second wait caused by the Spanning-Tree Protocol calculation/re-configuration process, there are two variations of an alternative. The alternative is to specify an “edge port”.

One of the variations is to enable the use of “Rapid Per-VLAN Spanning-Tree Plus (“rapid-PVST+”), which has some speed enhancements over the standard “Rapid Spanning-Tree Protocol (“RSTP”). The other method is to use an older enhancement called PortFast, which is a Cisco proprietary enhancement offered by Cisco's “Per-VLAN Spanning-Tree Plus (“PVST+&rdquol;). Like “rapid-PVST+” when compared to “RSTP”, “PVST+” was a variation that offered some proprietary speed enhancements compared to the older, but more open, standardized “Spanning-Tree Protocol (“STP”).

To enable the speedup, the following may be tried:

(Note: this is based on some documentation that may or may not be complete. Testing is recommended.)

deviceName>enable 15
deviceName#config terminal
deviceName(config)interface Fa0/0
deviceName(config-if)#spanning-tree portfast edge

Cisco: documentation: “Understanding Rapid Spanning Tree Protocol (802.1w)” notes, “The Cisco implementation maintains that the PortFast keyword be used for edge port configuration.”

There may be variations. Some related documentation may show up at: Cisco documentation: section titled “Enabling PortFast on a Layer 2 Port”.

Note this is designed to only be done on a port that is guaranteed to not relay traffic back. In other words, this is meant to be used for ports that never communicates to another switch. This basically disables some of the protections that Spanning-Tree Protocol offers to prevent switching loops, so violating this rule does run the possibility of creating a switching loop.

If the switch has a network interface port that is configured as an RSTP edge port, and that port receives a Bridge Protocol Data Unit, then the Cisco device will override the command that specified the port was an RSTP edge port. In this case, the port stops acting like an RSTP edge port, and starts acting like a port that performs the regular steps of supporting spanning tree protection. This doesn't happen with PVST+ Portfast ports, but just RSTP edge ports. For those who are unfamiliar with STP, this will probably be more familiar after learning about STP details like communications that use a Bridge Protocol Data Unit. In the meantime, just know that setting a port to an edge port could potentially be overridden by network traffic. (It may be interesting to see how this works.... Does the running-config stop showing the line that specifies that the port should be an edge port, or does the switch just ignore that configuration line and treat the port specially?)

PPP

The first thing to do is to create a user account. This uses the local username configuration/database, and so relies on the same username command.

Specify the encapsulation method, as shown in the following example:

deviceName>enable
deviceName#conf t
deviceName(config)#int serial0/0/0
deviceName(config-if)#ip address 192.0.2.1 255.255.255.0
deviceName(config-if)#encapsulation ppp

(This topic was noted as being covered by Cisco Network Academy CCNA training “Discovery 3” slide “7.2.5.1”. 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.)

Cisco Network Academy CCNA training Discovery 3 7.2.5.1 seems to skip mentioning this encapsulation ppp line in the directions, but then shows the line in the example syntax.

Next, PPP must have authentication method specified. This is done using one of the following four commands. (Choose just one of these.)

deviceName(config-if)#ppp authentication CHAP PAP
deviceName(config-if)#ppp authentication PAP CHAP
deviceName(config-if)#ppp authentication CHAP
deviceName(config-if)#ppp authentication PAP

If two authentication methods are provided, then the second one is used as a fallback method if the first one isn't working.

Additional requirements for PAP

Next, PAP won't really work at this point unless the user's name and password are broadcast. Rrepeatedly broadcasting a username and a password in plaintext, all just in case a remote server might be listening for it, seems like it is almost the worst network security imaginable (worsenable only by more extreme problems like posting sensitive information onto the public Internet). Newer Cisco devices actually won't do this unless they are clearly told to, which means that PAP authentication won't work unless some more configuration is performed. This needs to be done per user:

deviceName(config-if)#ppp PAP sent-username myUsrNam password userPw

The myUsrNam and userPw, as shown in the previous example, should be customized. This information must match the information that is set up on the local user configuration/database of the other router.

HTTP authentication

Cisco Network Academy CCNA training Exploration 3 slide 2.3.6.3 shows a bit about web auth

(This topic was noted as being covered by Cisco Network Academy CCNA training “Exploration 3” slide “2.3.6.3”. 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.)

deviceName>enable
deviceName#config terminal

Then, based on the example shown at Cisco Network Academy CCNA training “Exploration 3” slide “2.3.6.3”, the following is one way:

deviceName#ip http authentication enable

In the documentation right by the example on the Cisco Network Academy CCNA training “Exploration 3” documentation slide “2.3.6.2”, alternatives to come after the word “ authentication ” would be any one of the following:

Further, the text on the left side of Cisco Network Academy CCNA training “Exploration 3” slide “2.3.6.3” discussed possibilities include using TACACS and AAA, so AAA may be an option?

Finally, after using the “ ip http authentication someThing ” command, the end of Cisco Network Academy CCNA training “Exploration 3” slide “2.3.6.3” enabled the HTTP server. The two commands shown were:

deviceName(config)#ip http server
deviceName(config)#end
Some more password notes

Can add passwords, e.g. Cisco Network Academy CCNA training Discovery 3 8.3.6.2 (but this doesn't show usernames).

(This topic was noted as being covered by Cisco Network Academy CCNA training “Discovery 3” slide “8.3.6.2”. 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.)

Can combine with ACLs (Cisco Network Academy CCNA training Discovery 3 slides 8.3.6.2 and 8.3.6.1)

(This topic was noted as being covered by Cisco Network Academy CCNA training “Discovery 3” slides “8.3.6.2” and “8.3.6.1”. 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.)

Want to more about using Cisco equipment? The introduction to Cisco material may have some more details. The section about Cisco Certified Network Associate (“CCNA”) Routing and Switching also may have some more details.

[#ccomvinf]:

Site Changes

Site Changes

The following sections used to be part of this guide, right here, but have since been moved to separate sub-sections.