- How does Netsys Service Manager (NSM) determine when to create serial links?
- What is the default bandwidth value used for a serial link interface when there is no bandwidth statement configured?
- How does NSM handle multiple access groups on a single interface?
- How are IP unnumbered interfaces resolved?
- How are the routing algorithms modeled?
- Why are the EIGRP metric(s) larger in Netsys than they are in the actual network?
- Why is the maximum number of routes set to two for IGRP and EIGRP?
- What support does NSM have for DLSw+?
- Why won't NSM allow a scenario to be edited when a newer scenario is open?
- Q: How does Netsys Service Manager (NSM) determine
when to create serial links?
- 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 them.
End Point 1 End Point 2 Link Created Serial BRI yes * Serial HSSI yes BRI Serial yes * BRI HSSI no HSSI Serial yes HSSI BRI no
- Q: What is the default bandwidth value used for
a serial link interface when there is no bandwidth statement configured?
- A: The following default values are used:
Link Type Default Value
Serial 1544 HSSI 45045 Async 115 BRI 16
- Q: How does NSM handle multiple access
groups on a single interface?
- 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 scenario.
- 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 functions.
The following are included:
- For IP routing:
- RIP/IGRP/EIGRP/OSPF/BGP protocols
- distribution lists
- passive interfaces
- distance commands
- static routes
- default networks
- algorithm metrics
- For IPX RIP and SAP:
- SAP filter lists
- network filter lists
- SAP filter lists
- Q: Why are the EIGRP metric(s) larger in
Netsys than they are in the actual network?
- A: The EIGRP metric is scaled by a factor of 10. However, if there is redistribution into or out of EIGRP, this scaling is correctly taken into account.
- Q: Why is the maximum number of routes set to two
for IGRP and EIGRP?
- 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
- DLSW Peer-On-Demand
- DLSw Explorers
- dlsw group 0
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 given.
- Treatment of DLSw+ features supporting promiscuous peers, groups and border peers, on-demand peer relations, backup peers, peers costs, ring lists, and port lists.
- 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.
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.