Posted on

Cisco IOS Essential Capabilities Paper

The history behind the Cisco router and how it became the industry standard

[This article was an accompanying technical document that was printed in the SAGE-AU conference journal for 2003. I delivered this paper at the SAGE-AU conference in Hobart, Tasmania on August 7, 2003.]

In modern times, only Leonard Bosack and Sandy Lerner have been commonly credited with the development of the Cisco router. Certainly, many credible sources have reported the Cisco story inaccurately.

The company that we know as Cisco today, owes its origins to work conducted at Stanford University more than twenty years ago. In the early 1980’s, the Xerox Corporation allowed Stanford, MIT and Carnegie Mellon University access to their new Ethernet technology. Ethernet was a general-purpose solution to existing connectivity problems between computing systems at the time (primarily PDP-10 and PDP-11 systems).

At Stanford, it soon became apparent that a system would be required to channel data between Ethernet segments on campus, and also to move data between local networks and the national Internet.

Bill Yeager at Stanford was assigned the task, producing a working PDP-11-based router within a year. His efforts then turned to producing a Motorola-86000-based router utilising custom circuit boards produced by Andy Bechtolsheim in the Computer Science Department (Andy later went on to found Sun Microsystems). Yeager built the software that the system ran, allowing the router to move data between networks over several protocols.

In 1985 Stanford initiated a project to network the entire campus. Leonard Bosack worked on the project, improving upon the code from the original router. Optimising the code for an IP-only network, the project team also added and refined other features. The routers (known as “blue boxes” clearly because of the colour of their chassis) were popular across the Stanford campus, as well as several other academic institutions before long.

Leonard Bosack and his wife Sandy Lerner eventually both left Stanford and founded Cisco, along with a number of other project members. In 1997, after extensive legal deliberations, Stanford licensed the use of the router software and a number of circuit board designs to Cisco in exchange for technology developed after the developers left Stanford. For the software, Cisco gave Stanford $19,300 in cash and agreed to royalties of $150,000 and product discounts. Bill Yeager (the original software developer) apportioned the royalties, giving his 80 percent share to his department.

Stanford was offered equity in Cisco, but the licensing office turned it down as a matter of policy.

Leonard Bosack and Sandy Lerner both left Cisco in 1990.

Origins of some other Cisco technologies

Throughout the mid-nineties Cisco made a number of key acquisitions. Their entry into high-end LAN switching was guaranteed a success thanks to technology developed by Crescendo Communications, in the form of the Cisco Catalyst 5000 switch. The port-dense Catalyst 1900/2820 and Catalyst 2900 series switches from Grand Junction Networks, campus ATM technology from Lightstream, Token Ring switching technology from Nashoba and Gigabit Ethernet from Granite systems all further established Cisco as a one-stop vendor for all LAN connectivity requirements.

Acquisition of Combinet and the subsequent availability of the Cisco 700 and 800 series Routers, along with the PIX from Network Translation satisfied a number of niche markets that Cisco could previously not compete in.

Cisco has since continued the acquisition trend, selecting and further developing key technologies such as content caching and wireless connectivity.

Product families and capabilities

Cisco has undergone massive diversification in its product range. As such, it is not practical –- or interesting –- to discuss each product area and platform. However, I shall follow with a summary of the major platforms most likely to be in use in day-to-day operations for sysadmins.

3.1 Routers

  • 800 series – The Cisco 800 series desktop router is designed predominantly for the home, small business or branch office customer. A number of models are available, offering various WAN interface types.
  • 1700 series – A slightly more powerful and modular desktop router of interest to SMEs (Small to Medium Enterprises) and larger branch offices. Available in various fixed configurations and can also accept WICs (WAN Interface Cards) for other network types.
  • 2500 series – Lower-end rack mountable units that are mostly end-of-life now, but are still extremely popular and abundant. 2500-series access routers (such as the AS2511) are not end-of-life. Limited by CPU and Flash/DRAM.
  • 2600 series – Basically, the replacement for the 2500. Modular design with varying CPU speeds and Flash/DRAM.
  • 3600 series – Similar generation to the 2600, but scaled higher for the Central Office. Again, it is available in varying CPU speeds and interface/DRAM configurations.
  • 7200 series – Modular router of most interest to large enterprise customers and service providers.

3.2 Switches

  • 2950 series – The 2950 series is a *relatively* low-cost access-layer switch for 10/100 nodes. Port-dense models (48+2 interfaces) are available, down to 24, 16, and 12 port models with varying uplink media support (e.g., 100FX-MTRJ, 1000TX-RJ45, and GBIC interface). The new 2955 series is specifically designed for industrial installations, or anywhere else that the environmental conditions exceed the recommendations for the traditional 2950.
  • 3550 series – The 3550’s are fixed-configuration gigabit switches intended to aggregate multiple access layer switches is larger network implementations, or perhaps form the core/backbone in smaller networks. Available primarily in different combinations of 10/100/1000TX-RJ45 and GBIC interface configurations.
  • 4000/4500 series – Modular enterprise switches (up to 7 line cards and as few as 3 at the time of writing) intended for core networking services. Can switch layer 2/3/4 up to 48 MPPS. Interfaces obviously depend on the line cards installed.
  • 6500 – Premier modular multilayer switches providing up to 576 gigabit interfaces, support for hundreds of millions of packets per second, and 10-gigabit trunks.

3.3 PIX Firewalls

  • 500 series – The 500 series includes models appropriate for home users and enterprise customers. As expected, all models include mandatory features such as stateful inspection, protocol and application data inspection, and VPN support for a large operating system client base (no, not just Windows) as well as other hardware devices (e.g., dedicated Cisco VPN devices, other PIX units and 800/1700 series routers).

Differences between the modern router IOS, switch IOS and set-based switch IOS

Obviously, some fundamental differences exist between differing Cisco devices. In many cases these changes are simply due to the differing ways that interfaces are addressed. In the case of a Catalyst switch, an interface is typically configured for layer2 operation only by default, whereas a router interface is expected to be layer 3.

However, in a number of cases the IOS (Internetworking Operating System) command set is almost entirely different. This is typically because the device was part of an acquisition of another company and the software has not been re-written to be entirely IOS-like. One good example is the Catalyst 5000/5500 which used a “set-based” command language and the 700 series router which had an entirely different interface to any other series router. The Cisco PIX currently also exhibits a few “un-IOS-like” characteristics but is generally able to be navigated using knowledge of the typical IOS.

Generally, most new generation Cisco devices (including the PIX and Catalyst switches such as the 2950 and 3550’s) are very much like the classic Cisco router IOS.

Initial configuration: Setting hostname/passwords, Interface addressing, SNMP

When a device is powered on without an existing configuration – either because it is new or because the configuration has been deleted – the device enters the Initial Configuration Mode. This is a text-mode wizard that prompts for various basic global configuration parameters and offers the opportunity to configure interfaces and enable such things as a routing protocol or SNMP.

Not appropriate for advanced implementations. May automatically configure undesirable features, but can sometimes speed up initial configuration.

Basic architecture of the modern IOS and the varying command modes

The Cisco Internetworking Operating System (IOS) operates in a number of different modes. Each mode allows configuration of a specific aspect of the device. Following is a short outline of a subset of these modes as found on many of Cisco’s platforms.

User mode

Upon initially connecting to an already configured device the user is placed into User Exec mode. User mode allows limited access to router configuration and system information. User mode must be entered before any other mode can be accessed. User mode is commonly password-protected via remote access only (with unprotected access via the console port in trusted environments).

The user mode prompt looks similar to this: Router>

Privileged mode

Privileged mode allows access to additional IOS commands. Administrative tasks such as copying configuration info in/out can be performed here.

Privileged mode can be accessed via the enable command.

Router> enable
Password: <enter password here>

Global configuration mode

Global Configuration mode is where most day-to-day work is performed. Config Mode must be entered before any function that alters the router configuration can be run. Global configuration commands are run here such as setting the router hostname, logon banners, password configuration, static routes etc.

Global Configuration Mode is entered from Privileged Mode.

Router> enable
Password: <enter password here>
Router# config terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# ip routing
Router(config)# ip route
Router(config)# end
%sys-5-CONFIG_I: Configured from console by console

Interface configuration mode

This mode is accessed from Global Configuration mode. Configuration specific to a physical or logical interface is entered in this mode, such as IP addressing. On a switch we might set speed or duplex on a VLAN, Etherchannel or Port-Channel interface. On a router we could be configuring encapsulation such as Frame Relay. On an async serial interface (e.g. AUX) on a router or terminal server we might configure serial comms info such as baud rate, stop bits etc, or PPP configuration

Router> enable
Password: <enter password here>
Router# config terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# int VLAN 17
Router(config-if)# ip address
Router(config-if)# no shutdown
Router(config-if)# end
%sys-5-CONFIG_I: Configured from console by console

Routing protocol configuration mode

This mode is entered to configure a routing protocol. Most modern Cisco routers and switches support one or more of: RIPv1, RIPv2, OSPF, IGRP, EIGRP, IS-IS and BGP. This example configures an OSPF routing process and assigns a routing process number of 123. Any interfaces on this router in the range have their networks advertised via OSPF.

Router> enable
Password: <enter password here>
Router# config terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# router ospf 123
Router(config-router)# network area 17
Router(config-router)# end
%sys-5-CONFIG_I: Configured from console by console


There are only a few common ways that routes can be added to the route table in a switch or router.

Connected Routes

When an IP address is assigned to a virtual or physical interface, a route is automatically added to access the network specified by the IP/subnet pair.

Static routes

Static routes can be added in Global Configuration mode. This can be useful on small networks that change infrequently.

Dynamically-learned routes

Routes can be learned dynamically through protocols such as RIPv2, OSPF, EIGRP, IS-IS, BGP etc. Individual protocols advertise, learn and determine destination routes according to various algorithms then insert them into the routing table.

Disaster recovery

Fortunately Cisco device configurations are encapsulated within simple configuration files that can be copied out of production hardware and backed up. Replacing a failed device can be as simple as building a basic configuration (e.g., consisting of an IP address) on the new hardware and TFTP’ing the backed-up configuration into it. Some Cisco management software also has the facility to backup and restore device configurations remotely or via a serial (console port) connection.

The IOS software image itself can also be backed up and restored in a somewhat similar manner to ensure that the recovered environment operates exactly like the original.


Cisco provides a number of mechanisms and technologies to assist in building redundancy into modern internetworks. For the most part, WAN redundancy is accomplished via the provisioning of additional network connections (e.g. backup ISDN, asynchronous modem dialup) and possibly standby hardware, all at an increased cost. LAN redundancy however can often be built into a network at very little additional expense (although one may argue that you are paying for redundancy anyway with increased hardware costs whether you need it or not).

Cisco also provides a number of hardware redundancy solutions:

  • Higher-end equipment can be fitted with internal redundant power supplies
  • Lower-end equipment may support an external RPS (Redundant Power Supply)
  • Redundant supervisor engines for chassis-based switches.

An in-depth discussion of WAN redundancy is beyond the scope of this introductory paper, but an overview of the major LAN redundancy protocols is in order.


The Spanning-Tree Protocol (STP) is a layer 2 switching protocol that provides redundancy in network paths whilst preventing network loops. STP automatically calculates a loop-free network topology and “blocks” (disables) interfaces that connect redundant links. In the event of a topology change (adding new links or the failure of an existing link) STP recalculates the topology relatively quickly.

STP is an open protocol implemented widely. The Cisco implementation allows a separate spanning-tree topology per VLAN.


Etherchannel (Fast Etherchannel or Gigabit Etherchannel) allows multiple physical links between switches to be bonded into a larger-bandwidth virtual link (Port-Channels) thereby increasing available bandwidth. Once configured on appropriate interfaces the Etherchannel technology allows channels to be added and removed dynamically with only a minor disruption to service. Therefore, if a link in the Etherchannel bundle fails, the traffic will automatically failover to the remaining channels.


HSRP is Cisco’s proprietary method of providing first hop redundancy in campus routing, effectively allowing a set of routers to work together and provide a single virtual router interface. A mechanism exists for one of the physical routers (the “active router”) in the group to masquerade as the virtual router until such time that it becomes unavailable, at which time a standby router will assume the MAC and IP address of the virtual router and carry out the necessary operations. If the active router subsequently becomes available again it will take over the routing role.


Most Cisco hardware supports the industry-standard SNMP protocol for management and monitoring via a Network Management System (NMS) such as CiscoWorks or OpenView.

Below is a simple read-only SNMP configuration with a community name of “sage-au” and no access-list applied.

Router# config terminal
Router(config)# snmp-server community sage-au ro

We could enable all traps, specify the NMS address and community name thus:

Router(config)# snmp-server enable traps
Router(config)# snmp-server host public

Further Reading

[The links to other websites have been removed, due to them mostly no longer being active]

Biography of Presenter:

[This bio is from the past. I’m all grown up now.]

Paul Lawrie is a Senior Systems Engineer with Data#3, one of Australia’s largest IT Solutions companies. He holds a number of industry certifications including an NT4 MCSE+I, Windows 2000 MCSE, Citrix CCEA and Cisco CCNP. His day-to-day duties involve the design and integration of Enterprise solutions into Corporate and Industrial environments, building volumes of frequent flyer points, and trying to fit all those letters onto business cards.

Paul has worked in similar roles for various other employers including Com Tech (now Dimension Data), Unisys and Dialog, and invests his spare time avoiding IT as much as possible and spending time with friends and family.