CiscoWorks Resource Manager Essentials

Understanding and Troubleshooting NetConfig

Document ID: 13469

Updated: Jul 23, 2008



NetConfig uses Telnet to push a partial configuration change into Cisco IOS® Software (running configuration or startup configuration) or a Catalyst OS device.

NetConfig can be scheduled as a job for single or multiple device configuration changes. It uses configuration templates to create the configuration commands run on devices when a NetConfig job runs.

There are three types of configuration templates:

  • System-defined: Provided with NetConfig, these templates simplify the creation of common configuration commands. It contains some predefined configuration templates, such as device Telnet/enable password and TACACS+/RADIUS changes.

  • User-defined: Created by system administrators, these templates can contain any configuration commands.

  • Ad hoc: Allows you to add any configuration commands to a NetConfig job while you define it.



There are no specific requirements for this document.

Components Used

To use the NetConfig functions described in this document, your device must be supported in the Resource Manager Essentials (RME) configuration management, and must run a supported version of code. Refer to Supported Device Table for Resource Manager Essentials for a matrix of supported devices for RME.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.


For more information on document conventions, refer to the Cisco Technical Tips Conventions.

NetConfig Requirements

Before NetConfig functions can be used, there are a few things to remember:

  • The devices to be configured must exist in the RME database as a Managed Device.

  • The devices to be configured must have correct attributes in the RME device Inventory.

  • You need a valid RME user account for the operation to work properly.

  • By default, only users with Network Administrator privilege have access to configuration templates. Network administrators can assign template access privileges to other RME users.

  • When a NetConfig job is scheduled, the affected devices are locked. Therefore, you can execute no other operations or jobs.

  • NetConfig jobs for multiple devices can be executed either in a series or in parallel.

  • When you change Telnet and enable passwords or TACACS+/RADIUS information with the system-defined templates, NetConfig automatically updates device attributes in RME Inventory for affected devices.

  • If a device is configured to send syslog messages back to an RME server, then a successful NetConfig job results in a new configuration archive for this device triggered by its configuration change syslog messages.

  • Make sure you test NetConfig on a single device before you make modifications to multiple devices on the network.

  • NetConfig is designed for partial configuration changes. If you need to push an entire configuration file to a device, use Config Editor instead.

  • The online help feature for NetConfig is very extensive. To get more details on how to use NetConfig functions, choose Resource Manager Essentials > Configuration Management > NetConfig > Help.

Troubleshoot NetConfig

This section helps you to troubleshoot various NetConfig problems.

Cannot Schedule NetConfig Jobs Because the Job and Resource Manager (JRM) Server Is Down

NetConfig and Config Editor schedule jobs with the jrm process. If you get error messages such as this one, you may have a problem with JRM:

cannot access JRM server, it is down or unavailable

Issue the pdshow command or use the GUI to check the jrm process status at Sever Configuration > Administration > Process Management > Process Status.

NetConfig Job Failed Because Device Is Locked

If a device is locked by another scheduled job or another user, and you need to unlock the device in order to push the new NetConfig job, go to RME > Configuration Management > Config Editor > Tools > List Checked Out Files > Unlock.

You can also go to Server Configuration > Administration > Job Management to find all the locks the JRM knows about. This location provides a list of jobs and resource locks, and you can free a locked resource.

NetConfig Job Failed Because of Telnet Timeout

NetConfig jobs can sometimes time out and the configuration changes fail, especially if the devices are over WAN links, or if you schedule configuration changes for multiple devices.

You can modify TelnetTimeout values (the default is 60 seconds) and increase them accordingly in TransportIos.ini or TransportCat.ini. The default location is:

  • From UNIX:

    • /opt/CSCOpx/objects/cmf/data/TransportIos.ini

    • /opt/CSCOpx/objects/cmf/data/TransportCat.ini

  • From Windows NT or Windows 2000:

    • NMSROOT\objects\cmf\data\TransportIos.ini

    • NMSROOT\objects\cmf\data\TransportCat.ini

NetConfig Job Failed Because of TACACS+ Authentication Failures

Some older versions of Cisco IOS Software (such as version 11.x) may have a problem with the Telnet buffer when TACACS+ is enabled. You may see Username: t instead of Username: as the TACACS+ username prompt from the device in the sniffer trace. This confuses NetConfig and causes TACACS+ authentication failures for NetConfig jobs.

You may notice this problem on the TACACS+ server log as well. The best workaround is to upgrade the device to Cisco IOS Software version 12.0 or later.

NetConfig Job Does Not Send E-mail Properly (NT/2000)

In Windows NT or Windows 2000, you may experience a problem when you try to send e-mail after a NetConfig job. Try these steps to address the problem:

  1. Log in as admin and verify that the Simple Mail Transfer Protocol (SMTP) server name is entered in Resource Manager Essentials > Administration > System Configuration > SMTP.

    Note: The default SMTP server name is localhost.

  2. Test Blat, the freeware application that ships with CiscoWorks 2000.

    This example sends the file hello (previously created in $NMSROOT\CSCOpx\bin) by e-mail to from The SMTP server is rooster. Verify that the name of the SMTP server is resolvable in both forward and reverse directions (from IP address to name and name back to the same IP address). Also verify that you can ping the SMTP server from the CiscoWorks 2000 server. $NMSROOT is the default install location for CiscoWorks 2000 (C:\Program Files\CSCOpx).

    1. Open a DOS window.

    2. Issue the cd $NMSROOT\CSCOpx\bin command.

    3. Issue the blat -install rooster command.

    4. Issue the blat hello -t command.

  3. If the previous step succeeds, e-mail is functional. To troubleshoot further, enable NetConfig debugs as shown here:

    1. Edit the file $NMSROOT\CSCOpx\www\classpath\com\cisco\nm\cmf\

    2. Change the line NetConfig=1 to NetConfig=4.

    3. Submit the NetConfig job again, which generates the debugs in the log files for that job. These files reside in a folder named after the job number (such as 1004) in the $NMSROOT\CSCOpx\files\jobs\config folder.

Other NetConfig Known Issues

  • Because NetConfig uses Telnet to paste configuration changes, try not to issue show commands on the device while a NetConfig session is underway.

  • Sometimes, when NetConfig runs a job against a Cisco IOS Software-based device that is configured to send syslog messages back to an RME server, a race condition can occur. After NetConfig modifies the device configuration, it exits the configure terminal mode. This triggers the configuration change syslog message, which then triggers ConfigArchive to grab the configuration of the device. NetConfig then does a write terminal to get the running configuration of the device. This can produce the Non-volatile memory is in use error from the device, which causes the NetConfig job to fail.

    There are multiple workarounds, such as not configuring RME to listen to syslog messages, or not configuring the device to send syslog messages to this RME server. Cisco Technical Support may also provide a patch for RME.

  • If multiple devices are selected for a NetConfig job with a parallel execution option, and TACACS+/RADIUS authentication is required for each device, some TACACS+/RADIUS servers may not be able to handle many authentications at the same time and a denial of service may occur. In this case, change the NetConfig job execution option to Series.

  • Most NetConfig problems can be resolved by a sniffer trace on the CiscoWorks 2000 server. Use the server IP and the device IP as the filter to do a trace.

    On Solaris platforms, log into your CiscoWorks 2000 server as root and issue the snoop -s 1518 -o /tmp/snoop.cap your_device_ip command during a NetConfig job to get a snoop trace.

    A free sniffer tool for both Windows and UNIX platforms can also be downloaded from the Ethereal web site

Related Information

Updated: Jul 23, 2008
Document ID: 13469