CNC Logo

CiscoWorks 2000

Peter J. Welcher


Introduction

This month represents a change of pace. We've considered the advanced QoS (Quality of Service) options you can configure in the Cisco routers. Let's now shift gears and talk about CiscoWorks 2000 -- and as you'll see, there's a tie-in back to QoS. CiscoWorks 2000 has been much on my mind lately, as I've been teaching the MCRI class, covering both legacy CiscoWorks and the new CiscoWorks 2000.

What is CiscoWorks 2000?

CiscoWorks 2000 (CW2000) is a bundle of network management products from Cisco. Cisco isn't saying it very loudly, but CW2000 contains better versions of the major features of the old CiscoWorks, and is easier to use. I'll be somewhat undiplomatic and say that it sounds like a replacement for CiscoWorks.

The discounted product bundle includes the following  software packages, which are also available separately:

We'll talk (briefly) about each of these in turn.

Resource Manager Essentials (RME)

RME has various major areas, including Admin (for chores) and some nice Web based help and handy links back to CCO. But the real applications that ship with it are listed above, found under Tasks in the Web frame. These include: The first purpose of RME appears to be to provide a base tool kit for internal and external use. It manages both routers and LAN switches, with WAN (former StrataCom) switches expected at some point in the future. It's a pretty nifty tool kit.

RME includes a SQL database (later to be Microsoft Active Directory with NT 5.0 or the Cisco port thereof to UNIX) and Java User Interface. It comes with a large number of canned views (selections of devices by type, etc.), and you can define your own static (unchanging lists of devices) or dynamic (lists of devices meeting certain criteria) views as well. It uses these views to report on the information in its database. The database will presumably eventually migrate to CIM, and become a common repository of object-oriented data for possibly multiple applications. Or at least a common way to exchange information between network management applications. (Wouldn't it be nice to solve the common network management problem of multiple devices and multiple applications, all loading the network up with their own individualized discovery and polling? I'm not holding my breath, however). Finally, RME also includes role-based security, with pre-defined roles, for simple administration.

To get started with RME, you go under Admin->Inventory Management, and you either input a file or individual devices (quicker than it sounds), or import from HP OpenView, CiscoWorks classic (sounds better than legacy, doesn't it), or CWSI (2.1 or 2.2). This is a case of not re-inventing the wheel: let the other tools provide discovery. (In general, Cisco seems to have divided up various network management tasks among various tools and tool groups, to make sure there's little or no redundant effort. These seem to be pulling back together now in Web and Java form as a longer-term improvement strategy).

The next step in getting going with RME is to tell it (under Admin) to poll in a couple of places (Inventory, Availability, Configuration). You're then set. Over time, the various reports become available.

The Inventory Management tools track and report on the hardware and software in each device. You don't appreciate this until you have to upgrade the IOS. If you've ever manually had to check NVRAM, flash memory, boot code version, etc. across more than a few routers, you'll know what I mean. The inventory information is also accessed by the Software Image Manager tools, so that when you try to upgrade a bunch of routers, you get warnings or errors if they don't meet the various pre-conditions for the upgrade. Neat!

There's also a little Y2K tool. It refreshes itself from CCO if your management station is connected to the Internet (something that bothers me a little bit from the security point of view). Then it uses the inventory information to provide you with a web Y2K report, on Y2K compliant devices and IOS versions, which ones aren't, whether they can be upgraded, and a suggestion as to how to fix the Y2K problems on those that can be remedied. All in less time that it takes to read this article!

This highlights another bright idea in RME. It assumes Internet connectivity, and then exploits it by sometimes interacting with CCO-based tools. This allows Cisco to keep info or tools on CCO current, saving you from having to frequently update RME with the latest info. If your network management station isn't online for security (banks, military, etc.), well, the tools seem to work pretty well, with some minor degradation in convenience.

Change audit spots hardware (inventory), IOS version, and configuration changes to devices. And reports on it, so you can get some idea of what's happening out there.

Device Configuration Manager tracks configuration files. It keys off SNMP traps (if you arrange for them to be sent), also syslog messages or periodic collection. It acts as automated repository of configuration files. And it has a very nice difference reporting tool, showing changes in side-by-side configuration files. It also parses them into sections, and breaks them out with a MS Explorer-like outline for viewing the various sections of the configuration: Global, IP, IPX, Interfaces, Line Commands, SNMP, etc.

Software Image Manager (aka SWIM) allows you to pull fresh images easily off CCO. It'll give you a pick list of what's available, check the box, and it pulls the images for you. Multiple images. It'll make recommendations based on the hardware you have: what router models are in your inventory. It'll also allow you to schedule batch updates to groups of routers, using either TFTP or RCP. (The latter seems to be little known: highly recommended for slower links since waiting for 30-60 minutes then watching TFTP fail due to a line noise hiccup is not my idea of productive time). You can pull up a report of each job you submitted, send status report as email to folks upon task completion, etc. Neat!

Availability Manager is basically reporting on PING polling. You can pull up short or long-form lists of devices (including servers or other devices you've put into RME). They show up with downed devices at the top. Red down arrows, green up arrows, sort of like a Web based What's Up Gold. And you can get to graphs of history as to PING availability, graph of round-trip times, etc. There's also a report of Offline devices, and how long since they were last heard from.

Syslog Analyzer frequently scans new messages in /var/log/nmslog (on Solaris systems) into a database. You can then pull up reports, including one that breaks out the numbers of reports for each device by severity level (and total). As with most of the RME reports, you can sort on a column by clicking on the header. Click on the number of reports at say the Warning level for a device, and you get a tabular report showing all the messages. Click on a link and you get the documentation text as to what the message means. You can also use a User URL to fire off a CGI script of your own. You can also create custom reports on syslog messages matching various criteria, with some canned alternatives already available, e.g. linkDown, linkUp messages. Reload messages are already available as a built-in report.

For Cisco Management Connection, see below.

CiscoWorks for Switched Internetworks (CWSI)

The name CWSI Campus is also being used: it's not particularly intended (yet?) for WAN situations, and there are some current scaling issues with the Java Runtime Engines (jre's). The tool is partly written in Java and is apparently being converted to be totally in Java.

Right now CWSI Campus is a discovery and mapping tool that is being used to glue together several other evolving components as they become more tightly integrated. The list of components:

The mapping tool is somewhat similar in behavior to that used by Netsys. It has a multi-threaded discovery tool under the hood. When things work, they work well and quickly. When you change things rapidly (e.g. in a class), things sometimes don't sort themselves out very quickly. There's no ability to add or delete devices, no manual over-ride, which I find a little frustrating at times. (Also, you tell it to rediscover -- but there's no visible activity, no way to tell what it is doing or why it is doing it, etc.).

If you want to discover more than a switched domain -- the real use of the product -- then you need to go into Properties and select "discover through routers".

The mapping tool can also highlight devices matching various criteria shown at the right of the window. There is discrepancy checking, for things like switches with mismatches on speed, duplexness, trunking, etc.

CiscoView is well known. For switches, CiscoView gives you a lot of fill-in-the-form management capability, which sure beats set/clear/show. 'Nuf said?

VLAN Director shows you your VLAN's within a VTP domain. It allows you to add or delete VLAN's, and to move ports to VLAN's via drag-and-drop. ATM Director shows PNNI fabric, stats on ATM VC's, etc. I haven't had CWSI 2.2 alone with switches yet, so I won't comment further.

User Tracking is supposed to go out to switches and learn IP addresses of PC's, MAC addresses, and VLAN's. It can then be used with VMPS to do dynamic VLAN's. (I personally think dynamic VLAN's create another layer or two of complexity, layers that slow you down in troubleshooting when you have an outage. But dynamic VLAN's are technically pretty neat, and there are some situations where they seem to be necessary and appropriate. My feeling about the troubleshooting and its design implications may change as the tools evolve, and as we have tools that help us troubleshoot in such environments.) User Tracking in CWSI 2.1 was pretty sluggish from all reports and from my own observation. But CWSI 2.2 was focussed on bug fixes and performance enhancements, and supposedly a site is successfully using 2.2 with 10,000 nodes. This is all rumor, I'm not in a position to test it, so no further comment.

Traffic Director is the NetScout application for interacting with mini-RMON in routers and switches, and for interacting and reporting on RMON2 probes in your network. Good stuff!

(Sales note: Mentor Technologies does offer the 4 day NetScout training class, covering all the details of the reporting tools and probes in a lot more detail than the current Cisco courses. Suggestion: take the Cisco class, then the NetScout class for the details)

Internetwork Performance Monitor (IPM)

This used to be a tool bundled with CiscoWorks Blue. It is now apparently integrated to use RME for inventory and database. IPM allows you to easily access the Response Time Reporter (RTR) feature in IOS. Using this feature, IPM can determine and report the paths used between two devices, and it can display the response time for each of the router hops in each path. It can also measure performance for IP and SNA sessions. It can collect such data, provide long-term trending information, and send SNMP traps if thresholds are violated.

Future evolution of IPM may include the ability to probe with various TOS bits (see the previous series of articles on QoS), to determine characteristics of the paths and links used by various classes of traffic. This is a form of Service Level Agreement (SLA) management and reporting.

Cisco has also partnered with Concord to also provide easy use of RTR with reporting and thresholding, per an announcement about February of 1999.

Ganymede has data collection and reporting tools that apparently work somewhat similarly. It uses distributed NT's to collect the basic information. Contrast IPM's approach of distributing RTR polling from various routers to various key devices.

NetScout is rolling out probes and reporting software that allow Application Performance Monitoring. I believe this works by snooping on actual application traffic. This sounds like an interesting approach, although siting probes at client sites could get expensive. I note that probes at client sites sounds a bit more useful for network management than probe Ganymede NT's at remote sites, although one might perhaps find other uses for NT's. I suspect the choice partly depends on internal organization and politics at your company. See also http://209.122.128.128/appdemo/ .

This makes a lot more sense to me that what IBM and HP are doing. As I understand it, each of the latter has an approach where code is built into programs, instrumenting them and rendering them more manageable. While that in principle gives great control and solid information, in the real world third party vendors aren't going to buy into competing standards and competing vendor approaches. So it becomes another vendor lock-in and sales tool for applications from the vendor -- a situation most companies seem to be going to great lengths to avoid.

Cisco Management Connection (CMC)

This is a tool kit available to software vendors to link third-party Web based applications to RME, with context-based connections. There is "independent" third party testing and certification of links. And once the application is installed on a server in your network, there is a feature for RME installation of the links to that application from info on CCO. There's also a marketing logo for the packaging for the vendors. Users can use CMC to build their own connections out of RME.

As of 9/22/98 the following vendors had certified: APC, Apogee, Avesta, Computer Associates, Compuware, Concord, Desktalk, Fluke, Fujitsu, Ganymede HP, INS EnterprisePRO, Jyra, Knowledge Group, Micromuse, NetOps, Netscout, Network Associates, Nextpoint, Open Systems Solutions, Perform, Proactive Networks, Solsoft, Sterling Software, Sun Microsystems, Switchsoft, TAVVE Software Co., Tivoli, XACCT.

Cisco also uses CMC to tie the following (or their Web components) into RME: CW Blue maps, Cisco Cache Engine, CiscoSecure ACS/NT, Cisco PIX, and Cisco Voice Manager/Solaris.

Links to Netsys are built directly into RME's Configuration Management tools. Netsys Baseliner for NT is Java-based and looks like at some point in the future it might show up as tighter integration of Netsys and RME (and perhaps CWSI Maps?).

Summary

Mentor Technologies is constantly re-assessing our network management training offerings and considering possibly new courses. I'd appreciate any and all input as to what we should or should not offer, what you'd be interested in, how it would stack up versus hardware/configuration/pre-CCIE training in terms of your priorities, etc. I'd love to hear from you!

Here are some related links:

http://www.cisco.com/warp/customer/734/cwswit/literature.shtml
http://www.cisco.com/warp/customer/734/partner/cmc/cmcnw_ds.htm
http://www.cisco.com/warp/customer/734/crm/cwrme_ds.htm

(You may need a CCO login to get to some of these).

And here's a link summarizing the roles of the various IOS QoS tools we talked about in the last few articles:

http://www.cisco.com/warp/customer/732/net_enabled/qosio_wp.htm


Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net . 



3/3/99
Copyright 1999, Peter J. Welcher