CiscoWorks Routed WAN Management Solution (RWAN)

The CiscoWorks Routed WAN Management Solution (RWAN) is a suite of applications meant to help administrators configure, manage, and troubleshoot routed WANs. The suite is used for functions like identifying performance bottlenecks, utilization on WAN links, and so forth. Beside the two core applications listed below, this suite also includes CiscoWorks Resource Manager Essentials, which was looked at in the CiscoWorks LAN Management Solution section.

  • CiscoWorks Access Control List Manager. This application works in conjunction with Resource Manager Essentials and provides a web-based graphical interface to manage access lists on Cisco routers.
  • CiscoWorks Internetwork Performance Monitor. This application provides network response time and availability information, allowing engineers to diagnose network performance issues using a combination of real-time and historical data.

CiscoWorks LAN Management Solution (LMS)

The CiscoWorks LAN Management Solution (LMS) is a suite of applications aimed at maintaining, monitoring, and troubleshooting LAN environments, especially those based on Cisco’s AVVID architecture. The suite is made up of the core applications listed below, along with Device Fault Manager, which was looked at in the previous section.

  • Cisco nGenius Real Time Monitor. This application provides a multi-user web-accessible interface to network RMON data collected by switches in Cisco’s Catalyst line.
  • CiscoWorks Campus Manager. This application is used to administer, monitor, and configure Cisco Catalyst Layer 2 switching on campus networks. The tool provides information about both the logical and physical layouts of the network, which can become unwieldy in large, complex environments.
  • CiscoWorks Resource Manager Essentials. This is a suite of applications used to manage the configuration of Cisco switches, routers, and access servers, as well as handle inventory management of Cisco devices. For example, this suite includes utilities to manage software images, audit changes, and device configurations.

The CiscoWorks Product Line

The CiscoWorks product line is just that – not a single product, but rather a suite of many different network management products based on Internet standards. These products are bundled into common network management “solutions”, typically targeted at enterprise organizations. While the current version runs from a web-based platform, past versions have been provided as applications for both Windows NT and UNIX. Products in the line can be installed in a stand-alone fashion, or integrated with other third-party NMSs. Some of the more popular CiscoWorks bundles are described below. All of the CiscoWorks “bundles” also include CiscoView, which was described in the previous section. It’s worth noting that besides being integrated with CiscoWorks, CiscoView can also be integrated into other NMS platforms such as HP OpenView.

CiscoWorks for Windows

CiscoWorks for Windows is also part of the CiscoWorks product line, but is specifically a suite of applications designed to help simplify the administration and maintenance of small to medium sized networks using Cisco equipment. The suite includes a variety of applications that provide the ability to configure, manage, and monitor Cisco network devices, while providing extensive reporting capabilities.

CiscoWorks for Windows is SNMP-based, and was recently released in a new, web-based version. The current version is made up of 4 main applications, each with different network management capabilities.

  • CiscoView. CiscoView is an SNMP-based device management tool that provides a graphical view of the front and rear of Cisco devices. It provides a consistent graphical display of Cisco devices, providing dynamic on-screen monitoring, statistics, and configuration capabilities.
  • WhatsUp Gold. This NMS product by Ipswitch provides SNMP-based monitoring, mapping, alert, and network discovery capabilities for all network devices.
  • Threshold Manager. This tool allows you to define alert thresholds on Cisco RMON-enabled devices, such as the Catalyst line of switches.
  • Show Commands. This tool provides a graphical interface to the show commands available on Cisco devices. This gives users who may not be familiar with IOS syntax the ability to view detailed system configuration and performance information.

CiscoWorks Blue

CiscoWorks Blue is a product line aimed at companies managing networks that include consolidated Systems Network Architecture (SNA) and IP traffic. As such, the product is really only relevant to companies whose environments include IBM mainframes or AS/400s running the SNA protocol. The CiscoWorks Blue suite is made up of three main applications that provide the ability to map network resources, activate and deactivate devices, measure performance, and more. Internetwork Status Monitor allows router monitoring, configuration, and reporting to be managed from a mainframe console. SNA View provides the ability to troubleshoot SNA connectivity problems by provided visual representations of all active and inactive SNA connections. CiscoWorks Blue Maps provides graphical view of how SNA traffic relates to a routed TCP/IP network.

Remote Monitoring (RMON)

Remote Monitoring (RMON) is an extension to the SNMP MIB, and includes two versions – RMON and RMON 2. While SNMP relies on a regular polling and response mechanism between an NMS and individual managed devices to gather and collect information in real-time, the RMON protocol implements its monitoring capabilities using a batch-type method.

A typical RMON implementation consists of two major elements – a Network Management Station (NMS) and RMON probes. An RMON probe is a network device that collects information according to the traffic that passes through it, providing information about the health of the network itself, rather than a particular device. Unlike a traditional SNMP implementation, an RMON probe collects and stores this information, passing it to the NMS (via SNMP) when requested. As such, using RMON helps to avoid some of the network traffic issues associated with regular SNMP management. A typical RMON-enabled network will have one configured probe per segment.

RMON’s primary goal is to provide information relating to network errors and utilization. RMON data is gathered as part of nine different monitoring groups. Each of these provides information relevant to a different area of network monitoring such as gathering statistics, capturing packets, generating alerts, historical trend analysis, and so forth. While the original version of RMON was only capable of providing information up to the MAC level, RMON 2 is capable of monitoring traffic up to the application level. This allows information flows relating to particular applications to be assessed and analyzed.

RMON relies on being able to “see” all network traffic, which presents an issue in switched environments. As such, many network vendors now implement RMON probes as a feature within their switch products. For example, Cisco provides RMON probe capabilities within its Catalyst workgroup switches.

Configuring SNMP on a Cisco Router

The configuration of SNMP on Cisco devices is fairly straightforward, and is handled from global configuration mode. For the purpose of this illustration, I’m going to assume that we’re using a Cisco 2500 router.

The command to enable SNMP on the router is snmp community, followed by the community name. This command also allows you to configure the SNMP agent as read only or for both read and write access. If not specified, the agent will be configured as read only by default. In this case, we’ll set the community name to public, allowing both read and write access. This will allow an NMS to both configure and gather information from our managed device. SNMP settings are configured from global configuration mode.

Router#config t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#snmp ?
chassis-id String to uniquely identify this chassis
community Enable SNMP; set community string and access privs
contact Text for mib object sysContact
enable Enable SNMP Traps or Informs
host Specify hosts to receive SNMP notificationbs
location Text for mib object sysLocation
packetsize Largest SNMP packet size
queue-length Message queue length for each TRAP host
system-shutdown Enable use of the SNMP reload command
tftp-server-list Limit TFTP servers used via SNMP
trap-source Assign an interface for the source address of all traps
trap-timeout Set timeout for TRAP message retransmissions
view Define an SNMPv2 MIB view

Router(config)#snmp community public ?
<1-99> Std IP accesslist allowing access with this community string
<1300-1999> Expanded IP accesslist allowing access with this community
ro Read-only access with this community string
rw Read-write access with this community string
view Restrict this community to a named MIB view

Router(config)#snmp community public rw

Now that the router has been configured with a community name, SNMP is enabled. An NMS could now gather information from this managed device with Get commands.

Our next step is configuring our agent with the address of an NMS, such that it knows where to forward trap messages when errors occur, or once defined thresholds are exceeded. The first step involves enabling the agent to send traps using the snmp-server enable traps command. The next step is supplying the address of the NMS that will receive these traps, using the smnp-server host command.

Router(config)#snmp-server enable traps
Router(config)#snmp-server host ?
WORD SNMP community string
informs Send Inform messages to this host
traps Send Trap messages to this host
version SNMP version to use for notification messages

Router(config)#snmp-server host public
For the purpose of equipment identification, it is always a good idea to also configure SNMP agents with contact and location information, as shown below.
Router(config)#snmp contact Dan
Router(config)#snmp location Toronto Location A, Main Server Room

To view SNMP statistics for a given system, use the show snmp command.

Router#show snmp
Chassis: 02265778
0 SNMP packets input
0 Bad SNMP version errors
0 Unknown community name
0 Illegal operation for community name supplied
0 Encoding errors
0 Number of requested variables
0 Number of altered variables
0 Get-request PDUs
0 Get-next PDUs
0 Set-request PDUs
2 SNMP packets output
0 Too big errors (Maximum packet size 1500)
0 No such name errors
0 Bad values errors
0 General errors
0 Response PDUs
2 Trap PDUs

SNMP logging: enabled
Logging to, 0/10, 2 sent, 0 dropped.

Notice that the logging option at the end of the show snmp command output shows what appears to be an invalid IP address. In this case, the trailing “162” represents the UDP port number to which trap messages will be sent on the NMS. Like all configuration information, the SNMP settings on a router can be viewed using the show run command. A truncated version of the output is displayed below.

Router#show run
Building configuration...

Current configuration:
snmp-server community public RW
snmp-server location Toronto Location A, Main Server Room
snmp-server contact Dan DiNicolo
snmp-server enable traps
snmp-server host traps public
line con 0
transport input none
line aux 0

SNMP Management Information Base (MIB)

If there’s one area that’s certain to get people confused when it comes to SNMP, it would have to be the understanding the purpose of a Management Information Base (MIB). The concept isn’t so difficult if you tear away most of the techno-jargon. Every SNMP managed device includes an MIB. Think of an MIB as a database that stores management information about a device. This database is made up of different manageable objects that have properties. For example, one standard MIB object is known as “sysName”. This object can hold a value – the name of the managed device. If an NMS were to query the device for its “sysName”, the value stored in that MIB object would be returned. Similarly, another standard MIB object called “sysUpTime” stores a value that outlines how long a device has been running since its last boot. The MIB stored within a managed device controls how it can be managed via SNMP.

RFC 1213 defines what is known as the standard MIB, which contains 171 manageable objects. All SNMP-manageable devices implement this MIB, which includes various objects capable of measuring and monitoring protocol activity, providing name and description information, and so forth. Furthermore, registered organizations like Cisco can also define their own private MIB extensions that provide additional management capabilities for their particular equipment. Cisco has defined hundreds of manageable objects within their private MIB.

MIBs are defined as part of a tree-like structure. Every MIB object is defined according to a name and associated object identifier (OID) number. The standard SNMP MIB, known as MIB-II, is identified by the OID It can also be identified by its name – Private organizations (like Cisco) are allocated a branch in the “private” portion of the tree. In particular, Cisco’s OID branch begins at Beneath this portion of the MIB tree, Cisco can define its own private MIB objects, having said that, all objects privately defined by Cisco will start with the OID Similarly, those defined by Microsoft will start with

As mentioned earlier, an MIB is stored within a managed device. While this makes the device capable of being managed by SNMP, an NMS still needs to be configured to know about the particular MIB used by a device, since it probably includes private extensions. Think of it this way. Since vendors can create their own MIB extensions specific to their devices, there are literally thousands of possible MIB objects defined for different products, by different vendors. For an NMS to know about them all would first and foremost be almost impossible, and secondly, a huge waste of resources. To account for this, most NMS products support only the standard SNMP MIB by default. However, vendors usually supply MIB files with their products, and make then available by download from their websites. These MIB files can subsequently be compiled into an NMS, thus making it capable of managing the custom MIB settings of a particular device.

SNMP Version 3

SNMP is a protocol dedicated to gathering network information with as little overhead as possible; SNMP was never designed with security in mind. For example, in SNMPv1 and SNMPv2, the only true security element was the community string. In effect, if a device was enabled for SNMP write access and someone knew the community string, they could make configuration changes to the equipment. In many cases, guessing the community string wasn’t very hard, since many companies never took the time to change it from its default value – public. Obviously this presents a huge security risk, which in turn has led many companies to restrict SNMP access to read only, and in many cases, not enable it at all.

To overcome these limitations, SNMPv3 implements a true security model that provides for message integrity, authentication, and encryption. Each of these concepts is considered below:

  • Message integrity. Used to ensure that an SNMP message has not been tampered with in transit by a third party.
  • Authentication. Used to ensure that the source of the SNMP message is from a valid source. SNMPv3 is capable of using a common username, as well as MD5 or SHA algorithms to provide secure authentication between SNMPv3 devices.
  • Encryption. Used to securely scramble the contents of SNMP messages to ensure secure transmission between an NMS and a managed device. SNMPv3 is capable of using 56-bit DES encryption for transmitted packets.

Ultimately, SNMPv3 represents a significantly improvement over previous versions from a security standpoint. However, it’s still important to remember that in order to use SNMPv3, you will require both an NMS and managed devices that support it. Depending upon the IOS version installed on your router, you may or may not be capable of supporting it at the current time. Cisco has supported SNMPv3 in their routers since IOS version 12.0.3T.