CiscoWorks Service Level Manager

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

*   In these cases, no link is created if either endpoint has Frame Relay encapsulation

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 (in KBps)
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

• redistribution

• distribution lists

• passive interfaces

• distance commands

• static routes

• default networks

• algorithm metrics

• For IPX RIP and SAP:
  • SAP filter lists

  • network 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 running Analysis.

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

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

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.

Related Information

• Netsys End of Life Plan
• Technical Support & Documentation - Cisco Systems