CiscoWorks Service Level Manager

Collecting Configuration Files

Document ID: 15176

Updated: Oct 01, 2009


Related Information
Related Cisco Support Community Discussions

Q: What method does Netsys Service Manager (NSM) use to collect configuration files?

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.

Q: The getconfig script does not work with TACACS+. It gives me a "time out code 1" error message. What's wrong?

A: The getconfig script changes from release to release. Make sure you are running with the script that is part of the 4.0 release of Netsys. The options available with the getconfig script are explained below:

  • -h hostname
    Router's 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.

  • -n
    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.

Q: What does the interface between NSM and CiscoWorks consist of? What information is pulled/distributed to CiscoWorks?

A: An API integration between NSM and CiscoWorks facilitates certain functions for those users who have CiscoWorks 3.x or 4.x (however, CiscoWorks is not required to run NSM). The interface is bi-directional. It allows users to import router configuration files directly from the CiscoWorks database (such as Sybase) into NSM.

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).

Q: How do I extract configurations from CiscoWorks into NSM when they are not running on the same machine?

A: Sybase (used by CiscoWorks to store configuration files) does not allow remote access (via the network). You need to "nfs-mount" Netsys on the machine where CiscoWorks is installed and run the cwi program to extract the configuations (that is, cwi must run on the same machine where CiscoWorks is installed). The retrieved configs are placed in a directory which could be on a NFS file system shared between the two machines. If it is on a local file system, you need to use FTP (or rcp) to transfer to the machine where Netsys is installed. You could also copy the cwi script to the CiscoWorks machine, run the script, then copy the configurations to the NSM machine.

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.

Q: Which configuration is retrieved from the router?

A: If you schedule configuration retrieval from within NSM software, it issues a write terminal command (not a show config command) which retrieves the running configuration from the router, not the saved configuration.

Q: What should I do if I can't create a new baseline?

A: If you're not able to create a new baseline, check the following:

  1. Did you press <return> when completing the source and destination directory fields? This must be done in order for the input to take effect.

  2. Does the source directory contain Cisco router configuration files?

  3. Do you have "write" permissions to the target directory?

  4. Is there enough room on the partition?

Q: What happens if there are files other than routing configuration files in the New Baseline directory?

A: When creating a new baseline, NSM expects the specified directory to contain router configuration files only. The NSM software tries to discern if a file is a configuration file and ignores those that are not. However, it is possible that a file could be interpreted incorrectly. This can result in syntactical errors in the integrity checks report or errors in the topology, or both. Therefore, when creating a new baseline, remove all non-router configuration files from the baseline directory.

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.

Q: How do I use the editor of my choice to edit the configuration?

A: Set the EDITOR environment variable to your choice of editor; NSM will use that editor to view and edit configurations.

Q: When do modifications to a configuration file become part of a baseline?

A: Router configuration files can be changed in several places within NSM. (For example, the Report "Edit" button or the Open Baseline -> Router window.) Changes made to configuration files are not incorporated into the NSM baseline model until the changed configuration files are parsed (that is, when the baseline is re-opened or a new one is built). Changing configuration files has no effect on the currently opened baseline.

Q: What is the quickest way to integrate a modified configuration in a baseline?

A: Here is the standard way to do it:

  1. In Netsys, select Open Baseline -> Routers -> Add.

  2. 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.

Q: Can I modify the configuration files in config directory?

A: Configuration files in the config directory are under SCCS control. Do not modify the permissions on these files, as this might cause some SCCS operations to fail.

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:

  1. Open the baseline

  2. Select Open Baseline -> Routers -> Add to add a new configuration to the baseline.

Q: Can I modify the hostname parameter in the configuration?

A: The hostname parameter of the router configuration file should not be modified once the config is part of the baseline. Netsys assumes that the router's configuration file is stored in a file of the same name. Changing the hostname in the router configuration file causes the version control program to produce an error on that baseline.

Related Information

Updated: Oct 01, 2009
Document ID: 15176