In last week's article we discussed what to expect from the various packages. Once you've decided what package you need, and installed it on your server (use one with lots of memory, and always read the latest release notes for platform specifications, patches etc), setting CW up is actually pretty easy. It uses CDP to get a lot of its information, so you don't have to tell it too much - if you don't run CDP, though, you're going to lose a lot of information. If you have non-Cisco devices separating Cisco networks, that's not a problem. CW starts its discovery process from a seed device address, so you can enter several of these if you have discrete Cisco pockets.

Basic Configuration
You need to tell CW the telnet and enable passwords of your devices, and the SNMP strings, and that's basically it. Give it the IP address of one device (typically a core switch) and it will start to discover everything out on the network.

You can tune performance so that discovery takes less resources and more time, and other activities speed up, but unless you're experiencing problems it's probably worth leaving it alone.

On install, the administrator id and password are admin/admin. Change them. You can create multiple users with differing privilege levels, from help desk read-only to full developer rights. And you can choose whether to authenticate locally, or use a central TACACs server.

You should also set up a backup schedule - you'll need to back up CiscoWorks data to a disk that is then backed up with your servers.

Note that CiscoWorks uses DNS heavily, so make sure your server is set up correctly for this. The server also doesn't particularly like having its IP address changed after CiscoWorks has been installed, so set it up completely before you start installing.

Network Configuration
On the network device side, you need to configure the routers/switches to send syslog messages and logged config changes for audit purposes to the CW server. If CW is notified of a change in software or hardware, it will request the new config from the device, and you can archive configs back over time.

You have to run CDP, as mentioned, and NTP is also essential if you want your logs, alarms and audits to tie up.

It's recommended that you install CW on a server hidden away in a comms room and browse into it - it supports concurrent user access. However, you have to be careful if you cross a firewall between client and server, as the CORBA implementation used for Campus Manager, ACLM and IPM can't cope with NAT traffic, though you're okay for accessing all the RME inventory/change reports. And of course, you have to allow CW traffic from the server to all your network devices: some of the common ports required are listed below, but best to check with the install guides for a full list.

RME Inventory, Campus Manager & CiscoView (SNMP) UDP 161
RME Config Manager (telnet, TFTP, SNMP) TCP 23, UDP 69, UDP 161
RME Change Audit (syslog) UDP 514

Once you've got CiscoWorks to discover your network, you might want to customise some of the reports and views. For instance, RME has a series of 'views' pre-defined where devices are distinguished by model type, for inventory and config details. You can add your own views, so that you can easily group all remote site routers, say, or all head office 4500s.

Similarly there are pre-defined reports ready to run (changes, syslog messages, etc), but you can create your own, to build up a group of daily checks to be run each morning.

If you want to use the ACL Manager or IPM, you need to define groups of network resources by IP address for ACLM to use, and you have to create IPM collectors (a combination of source, target and operation to be carried out between the two) to start gathering statistics.

For DFM, you may want to change error thresholds or polling intervals, although it's best to let it run unchanged for a few weeks to see what sort of alarms you get. One thing you may want to change though is that by default DFM does not monitor the status of any 10/100 switch ports, as it figures you don't really want an alarm generated every time someone switches their PC off. You'll probably want to go in and change the status to 'managed' for server ports, where it is important for you to know if they go offline.

Scaling CiscoWorks
For most enterprises, you don't have to worry about the size of your network. CiscoWorks can handle in the region of 5000 devices in RME (depending on the server hardware), though only if you turn off availability monitoring. You can't run reports on all of them at once though, which is where the customised views come into play. Having said that, Campus Manager is really only good for 2000 devices, though that's still plenty for most environments.

If you do need greater numbers, you can split out parts of CiscoWorks to give extra headroom, or deploy multiple copies and geographically distribute which look after which part of the network (there are some deployment guides for this on There's no clustering or failover within CiscoWorks though, and if you want a second copy running on a standby machine, you need to buy two copies and configure your devices to send data to both.

As with any network management platform, you have to spend the time getting it set up correctly to begin with, and understanding the information it can give you. At least with CiscoWorks, the effort in getting your first initial reports back is pretty minimal.