A: For Netsys purposes, the term "serial" refers only to serial,
HSSI, and BRI interfaces.
If only two serial router interfaces are connected to the same subnet,
a serial link is created between them. If more than two serial router interfaces
are connected to the same subnet, Cisco uses a special heuristic to assign
consecutive pairs of IP addresses to both ends of a serial link. Other serial
links may not follow this convention; they can be manually connected by
modifying the appropriate configuration files used to create the baseline
(so they appear unconnected in the topology).
If each interface in a pair of endpoint candidates are of the same type
(serial and serial, BRI and BRI, HSSI and HSSI), a link is created between
End Point 1
End Point 2
* In these cases, no link is created if either endpoint
has Frame Relay encapsulation
A: If an interface has more than one ip access-group command
applied to it, only the first ip access-group command appears in the
baseline model. You can add more access groups to that interface in a new
Q: How are IP unnumbered interfaces resolved?
A: If the interface has also been configured to run with either AppleTalk
or IPX, then those protools are used to resolve the links. If there are no
other protocols configured, you can add the link with the Add Serial Link
menu option in the Topology.
Q: How are the routing algorithms modeled?
A: NSM imports Cisco router configuration files, then builds the
baseline network from these files. So all network examination, modeling, and
analysis are based on actual router configurations.
NSM also models routing algorithms; for example, how each router constructs
its routing and connectivity parameters (from the router configuration files),
as well as a detailed representation of how a particular routing protocol
A: A default value of two is used as the maximum number of routes
per destination for each supported routed protocol. The default can be explicitly
overwritten for a specific router's routing protocol by changing the "Max
Routes" field in a scenario's "RIP/IGRP/EIGRP Algorithm" window, and then
Another way to increase the number of routes calculated per destination
to four is to set the max number of routes field in the "Open Baseline"
window. This is not recommended for large networks, as it becomes resource-intensive.
Q: What support does NSM have for DLSw+?
A: Netsys has supported DLSw+ since release 2.0. No new functionality
has been added since then.
Below is a brief description of the DLSw connectivity features.
Treatment of DLSw+ features supporting promiscuous peers, groups and
border peers, on-demand peer relations, backup peers, peers costs, ring
lists, and port lists.
DLSW implicit policies that show the peering relations. There are
currently three implicit policies that show up when one or more router
has DLSw+ configured:
dlsw group 0
The first policy (dlsw group 0) is analogous to the srb_ring_xxx policy. If
this policy is selected, the paths between all explicitly-configured DLSw
remote peers are examined
The second policy (DLSw Peer On Demand) is used to determine the
peering relations between all routers configured with DLSw (this includes
the relation between peers that are not explicitly configured to each
other). If this policy is selected, the state of each pair is returned
and, if the pair can communicate, the path taken is identified. The
states for pairs are explained below:
OK - Both peers are explicitly configured to each other and the
pairs can communicate, using the selected encapsulation method (such as
TCP, fst, direct).
Promiscuous - One peer is explicitly configured to the
other, which is a promiscuous peer (a promiscuous relation), and
the pairs can communicate.
On Demand - The peers are not explicitly configured to
each other, but can form an on-demand peering relation, and the
pairs can communicate.
Backup Peer - The target (destination) peer cannot be reached,
but it has a configured backup peer that can be reached. In this
case, a path is returned not to the destination peer, but to the
backup peer instead.
Peer Disconn - Because of configuration reasons, the pair
cannot peer together in an explicit, on-demand, or promiscuous relation.
Explorer Blocked - If the peers could connect it would
be through an on-demand relation, but they cannot connect because
the explorer path (which goes through border peers) is blocked.
NOTOK - There is no path between the peers.
The third policy (DLSw Explorers) is used to examine the paths that explorers
going from DLSw peer-to-peer take, which can differ from a direct path when
there are DLSw groups (and border peers). If this analysis is selected,
the paths taken by the explorers for all pairs that can communicate are
Q: Why won't NSM allow a scenario to be
edited when a newer scenario is open?
A: This functionality is inherent to the intended design of the scenario
generator; namely, scenarios are intended to allow regression analysis. Once
a given scenario has been changed (and represents a satisfactory configuration),
subsequent scenarios will use that model as a static base upon which to build.
Thus, changes are only allowed for the most recent scenario opened, and all
prior scenarios are "fixed" layers of modification to the original baseline.
The only exception is that (beginning with NSM 4.x) you can run/update some
reports on the previous scenarios, and the reports will be color coded to
match the scenario.