- What method does Netsys Service Manager (NSM) use to collect configuration files?
- The getconfig script does not work with TACACS+. It gives me a "time out code 1" error message. What's wrong?
- What does the interface between NSM and CiscoWorks consist of? What information is pulled/distributed to CiscoWorks?
- How do I extract configurations from CiscoWorks into NSM when they are not running on the same machine?
- Which configuration is retrieved from the router?
- What should I do if I can't create a new baseline?
- What happens if there are files other than routing configuration files in the New Baseline directory?
- How do I use the editor of my choice to edit the configuration?
- When do modifications to a configuration file become part of a baseline?
- What is the quickest way to integrate a modified configuration in a baseline?
- Can I modify the configuration files in the configuration directory?
- Can I modify the hostname parameter in the configuration?
- Q: What method does Netsys Service Manager (NSM) use to collect configuration
- A: There are two ways to collect router configuration files:
- The getconfig script
- The "Wizard Manager"
Both methods use Telnet sessions and a write term.
There is also an option via the "Wizard Manager" collection to collect files from a directory. So, if you prefer your own method of collection, you can continue to use it and use the "Wizard Manager" collection to import the configuration files into Netsys. Configurations can also be collected from CiscoWorks using the cwi script or the "Collect Cisco Configurations from Ciscoworks Host" wizard which allows you to schedule the collection of router configuration files from hosts running CiscoWorks.
- The getconfig script
- -h hostname
Note: This is the name used to telnet to the router (IP address in dotted notation is acceptable). It may or may not be the same as the name set by the "hostname" command in the router's configuration file.
- -p login_password
Password to log in to the router.
- -u login_user_name
User name to login to the router (for those routers that require both a username and a password to login (the line configuration command "login [local|tacacs] was used))
- -U enable_user_name
username to enter privileged exec mode (for those routers that require both a username and a password to get into privileged mode). if not specified, the login_user_name will be used.
- -e enablepassword
Password to enter privileged exec mode. If only password or enablepassword is specified, it will be used as both login and enable password.
- -c config filename
Name of output file in which config information for the router should be saved. Allows a user to override our default behavior of saving config output in a file name same as the router hostname.
- -s suffix
Suffix to be used with every output config file. Allows user to name output config files as,
-confg OR anything they desire.
- -a ip_addr
If telnet using hostname given by -h option failed, ip_addr will be used next to try telnet again. This is useful in cases where DNS or /etc/hosts is not properly set up. However, hostname is still used as output file name. If DNS fails the time_out parameter will need to be increased.
- -t time_out
How long to wait for output from telnet to arrive. If omitted, a default value of 10 seconds is used.
Use this option if neither username nor password is required to log in to the router. enable password may still be needed to enter privileged exec mode (no longer needed, maintained for compatability only)
- -f filename
Name of a file containing hostnames, passwords, etc. of the routers whose configuration files to be retrieved.
- -a ip_addr
The interface also allows users to export proposed configuration changes (via a delta configuration command file) after reaching a desired network configuration through "what-if" analysis within the NSM software. "Delta" files should be checked and confirmed by the user. They can then either be exported to the CiscoWorks database (Sybase) or through the database to the routers (with a copy of the new configuration file stored in Sybase).
In NSM 4.02 and later, the "Collect Cisco Configurations from Ciscoworks Host" wizard allows you to schedule the collection of router configuration files from hosts running CiscoWorks.
- Did you press <return> when completing the source and destination
directory fields? This must be done in order for the input to take effect.
- Does the source directory contain Cisco router configuration files?
- Do you have "write" permissions to the target directory?
- Is there enough room on the partition?
NSM assumes that a router configuration file contains a "hostname" entry or an "interface" entry within the first 32,767 bytes. If not, the file is omitted during the creation of the new baseline.
- In Netsys, select Open Baseline -> Routers -> Add.
- In the dialog box that displays, specify the source directory and select the new configurations. If any of the configs match an existing configuration by filename (not hostname), you will be asked if you want to replace the old with the new.
The faster way to do this is to use the run_ngs executable and invoke the feature to update the baseline with configuration files from a specified directory. For example:
run_ngs -baseline <baselineDir> -u <newConfigsDir>
Here is the help output from run_ngs -h:
The u <dir> | -update_baseline <dir> [-no_case] command updates the baseline with configuration files from the given <dir>. If the -no_case option is specified, the file names specified are not case sensitive.
It is also important not to modify the actual files in the config directory. The only safe way to modify files in the config directory is through an editor started from within Cisco NSM.
Also, do not copy a new configuration file into the <baseline>/config directory, then attempt to import the configuration into the baseline because these configs are under SCCS control. If you want to add another configuration to the baseline:
- Open the baseline
- Select Open Baseline -> Routers -> Add to add a new configuration to the baseline.
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.