CiscoWorks Service Level Manager

NETSYS General Product Questions

Document ID: 15174

Updated: Oct 01, 2009


Related Information
Related Cisco Support Community Discussions

Q: What Cisco IOS features does Netsys Service Manager (NSM) support?

A: Netsys support of Cisco IOS is feature specific, not Cisco IOS release dependent. For a list of Cisco IOS commands modeled by the Netsys software.

The following features are supported in Cisco NSM software:

Feature Release Level
  2.0 3.0 4.0
Network protocols:
Routing protocols:
Bridging protocols:
local and remote SRB, DLSw+
LAN topologies:
Ethernet, Fast Ethernet, Token Ring, FDDI, ATM interface
WAN connectivity:
Serial, HSSI, BRI, Frame Relay, IP unnumbered, X.25
Channelized T1, Async, SMDS, Dailer
Protocol-Specific Views:
IP, IPX, OSPF, RSRB, AppleTalk
BGP Automous Systems
Configuration Checking:
CiscoWorks 3.x interface
CiscoWorks 4.0 interface    

Q: On what platforms does the Netsys application run?

A: Here is a list of Netsys applications and the platforms on which they run:

Netsys Applications SunOS Solaris HP-UX AIX
Enterprise/Solver 1.x 4.1.3_U1/4.1.4 2.4/2.5 No 3.2.5
Enterprise/Solver Connectivity Tools 2.x
Enterprise/Solver Performance Tools 1.x
4.1.3_U1/4.1.4 2.4/2.5 9.x/10.x 3.2.5
Enterprise/Solver Connectivity Tools 3.x
Enterprise/Solver Performance Tools 2.x
Advisor 1.0
Multivendor Router Module
4.1.3_U1/4.1.4 2.4/2.5 9.x/10.x 4.1.5
Connectivity Service Manager 4.0
Performance Service Manager 4.0
LAN Service Manager 4.0
4.1.3_U1/4.1.4 2.4/2.5 10.x No
Connectivity Service Manager 4.1 No 2.5/2.6 10.x 4.1.5

Q: Does Netsys provide any trace or debug tools for examining problems in more detail?

A: Netsys uses the environment variable ECSP_DEBUG to enable its tracing mode. To set it, exit the tool and set environment variable ECSP_DEBUG to equal "1" or "2" (value "2" provides the most detail). Run ctk again; any status messages and debug output contains more detail about the components of each executed step. The debug messages can be viewed using Netscape under the <Baseline>/logs directory.

Q: How can NSM performance be improved?

A: As with any other application, run NSM on the recommended hardware and software configuration for the best results.

For large, redundant networks, it is recommended that when a baseline is created or re-opened whose configuration files have been modified, you initially start NSM in baseline mode (using ctk -mode baseline). Topology generation is CPU and RAM intensive, and running in Baseline mode (versus Connectivity full mode) is more efficient because it runs fewer processes. You can create and display the topology and examine the Integrity Checks report while in Baseline mode. Once you've done this, start NSM normally. Performance improves significantly because all the topology layout calculations have already been performed.

In addition, when fast analysis is required, the "Max Number of Routes" field can be set to "1" under File -> Open Baseline -> Advanced Options. This causes Netsys to drop equivalent, equal-cost routes once one has been found. Also, in the same window, you can disable IP or IPX analysis. The default is to perform analysis for both protocols, but you may want to select only one to save resources.

When working with large complex topologies, it is often helpful to increase the amount of available swap space. To temporarily increase the amount of swap space, enter the following commands while you are logged in as root:


    makefile 10m /<path>/swap2
        (where <path> is a location with enough space for the swap file. In this case, the file is 10 MB.)
    swapon /<path>/swap2


    makefile 10m /<path>/swap2 
    swap -a /<path>/swap2 
Edit /etc/vfstab to add a line similar to:
    #device            device        mount        FS         fsck       mount       mount
    #to mount          to fsck       point        type       pass       at boot     options
    /<path>/swap2        -            -          swap        -           no          -
It is also advisable to analyze NSM policies in several small policy file sets (sequentially), rather than in a single, large policy set. Policy Analysis allows the user to define and test network connectivity. Policies are very resource-intensive to analyze, so keeping policy sets small decreases wait time and memory requirements. Several sets can be loaded at once to test a large number of policies. This is particularly advantageous when working with large networks where the amount of information produced when analyzing a large set of policies can be difficult and voluminous.

Q: How large of a network can NSM model? Does performance change with network size?

A: NSM has been tested with networks ranging from 2 to 2000 routers, and up to 1500 subnets. At the upper end of this range, it was found that the Flat Topology view was very memory-intensive (it uses system resources at an exponential rate based on network size), and it may take NSM more than 30 minutes to produce a map. Increasing swap space beyond the recommended 2 GB improves this performance. The other functions (Campus Topology view, Report) were all handled in five to ten minutes, and presented no such strain on system resources.

Q: Why doesn't the "Configuration Text" show all the commands from my original configuration file?

A: The "Configuration Text" is the portion of the original configuration file that Netsys models. For example, if an access list is defined but not assigned (or duplicated) in the configuration, it is not modeled. Therefore, it does not appear in the "Configuration Text".

Q: Does the NSM software interact with the live network? What information is pulled from the live network?

A: The NSM software constructs a model of the internetwork from router configuration files. You can select a set of configuration files and put them into a directory; from there they can be imported into NSM. The network model generated from these files is the "baseline" network from which all further analysis can be done. The "baseline" model reflects the actual network only to the extent that the configuration files provided correspond to the current live network configuration files. Additional data such as Frame Relay PVC observed routing tables, observed BGP tables, and so on can be retrieved from the live network. If Performance Service Manager is also licensed, you can collect router-related data via SNMP and traffic data.

The NSM software includes an interface to CiscoWorks 3.x and 4.x through which the router configuration files can be imported, and proposed configuration changes (for implementation into the actual network) can be exported. Another related feature is the getconfig script, which automates the retrieval of configuration files from routers initially. Subsequently, the Scheduler allows you to schedule collections of configuration files as well as other data.

Q: How is traffic information modeled?

A: The Performance Service Manager adds traffic analysis and device utilization modeling to the network configuration and routing functions provided by the Connectivity Service Manager. With Performance Service Manager, users can analyze the interactions between traffic flows, topology, routing parameters, and Cisco IOS features. This allows users to perform various types of diagnosis and planning activities. For example, analysis can be performed to determine whether congestion is due to configuration or bandwidth problems, and "what if" scenarios can be used to evaluate the effects of additional routers and/or traffic workloads, configuration changes, or device/link failures. Traffic data input can be from RMON probes, router accounting, MIB information, and/or Netflow accounting.

Q: How does NSM handle bridging?

A: Source-Route Bridging (SRB), Remote Source-Route Bridging (RSRB), and DLSw+ are currently supported. NSM does not model the bridging capacity of bridging routers.

Q: Does NSM model routers besides Cisco routers?

A: Topology representation and integrity checks are supported for Cisco and Bay routers. Netsys supports the Bay MIB versions 9 and 10 only. Bay router support is bundled in the Netsys Service Level Manager 4.0 product, and is available as a separate option, "Multivendor Router Module," with Netsys 3.0.

Q: Does NSM support both PRI and BRI configurations for ISDN lines?

A: Yes, NSM parses and models both BRI and PRI serial interface configurations.

Q: Are floating static routes supported?

A: Yes.

Q: How are "Observed" routing tables used?

A: Collecting and importing live routing tables into Netsys does not cause in the "Observed Routing Tables" to replace the Netsys calculated tables in the model. Instead, the observed tables are used to augment the calculated tables as described below:

  • Observed IP Routing Table Coverage Exceptions Report: Provides information on differences between the routing table that Netsys calculates and the one that is collected from the router.

  • Observed Routing Table Changes Report: Indicates how observed routing tables have changed from one collection to the next.

  • Performance Analysis to exterior addresses: Calculates traffic distribution and device utilization by mapping the endpoints of traffic conversation onto the known network. Traffic with endpoint(s) that cannot be resolved in the known network are ignored unless observed routing tables are loaded into the model. In that case, Netsys is able to determine the egress point in the known network of these conversations, and they are included in Performance calculations.

Related Information


Updated: Oct 01, 2009
Document ID: 15174