NetConfig uses Telnet to push a partial configuration change into Cisco
IOS® Software (running configuration or startup configuration) or a Catalyst OS
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
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.
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
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
Before NetConfig functions can be used, there are a few things to
The devices to be configured must exist in the RME database as a
The devices to be configured must have correct attributes in the RME
You need a valid RME user account for the operation to work
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
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
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 >
This section helps you to troubleshoot various NetConfig
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
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
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:
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
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
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.
Test Blat, the freeware application that ships with CiscoWorks
This example sends the file hello (previously
created in $NMSROOT\CSCOpx\bin) by e-mail to firstname.lastname@example.org
from email@example.com. 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
Open a DOS window.
Issue the cd $NMSROOT\CSCOpx\bin
Issue the blat -install rooster
Issue the blat hello -t firstname.lastname@example.org
If the previous step succeeds, e-mail is functional. To troubleshoot
further, enable NetConfig debugs as shown here:
Edit the file
Change the line NetConfig=1 to
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
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
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
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
On Solaris platforms, log into your CiscoWorks 2000 server as root
and issue the snoop -s 1518 -o /tmp/snoop.cap
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