Q: On what platforms does the Netsys application run?
A: Here is a list of Netsys applications and the platforms on which they run:
Enterprise/Solver Connectivity Tools 2.x
Enterprise/Solver Performance Tools 1.x
Enterprise/Solver Connectivity Tools 3.x
Enterprise/Solver Performance Tools 2.x
Multivendor Router Module
Connectivity Service Manager 4.0
Performance Service Manager 4.0
LAN Service Manager 4.0
Connectivity Service Manager 4.1
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
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
<path> is a location with
enough space for the swap file. In this case, the file is 10 MB.)
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.
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
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?
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.