Cisco NSM 4.2/4.3 - READ THIS FIRST

Year 2000 Support

With this 4.2 release, the Cisco NSM software has been made Year 2000 (Y2K) compliant. All previous versions of the Cisco NSM software do not meet Y2K requirements, therefore, Cisco strongly recommends you upgrade to this new version.

The Cisco NSM 4.2 release is "Year 2000" compliant only in conjunction with the following operating systems:

• Sun Solaris 2.6 with the Year 2000 patches. Information about the Year 2000 patches and how to obtain them is available from Sun at the following URL:

http://www.sun.com/y2000/solaris26.html

• IBM AIX 4.3.1 with Year 2000 patches. The Year 2000 patch bundles are available from IBM at the following URL:

http://www.software.ibm.com/year2000/papers/aixy2k.html

• HP-UX 10.20 with the Core OS Year 2000 patch bundles. A list of all required patches to achieve HP-UX Year 2000 compliance are listed at the following URL:

http://www.software.hp.com/products/Y2K/corelist.html

The Year 2000 patch bundles are available from HP at the following URL:

http://us-support.external.hp.com

Note, you must first register for an account before you can obtain the patch bundles as follows:

Step 1 Select the Enter the ECS option. You will be required to specify a userid and password.

Step 2 Select the Standard Patch Bundles option.

Step 3 Select the Obtain Y2K Bundles from Patch Database option.

Step 4 Select the appropriate Core OS Year 2000 patch bundle.

NetFlow Collector 2.0 Support

The Cisco NSM 4.2 release now supports the NetFlow Collector 1.x and 2.x header formats.

Point-to-Point ATM WAN Link Support

The Cisco NSM 4.2 release now supports point-to-point ATM WAN links from an Layer 3 connectivity perspective. The point-to-point ATM WAN links are treated like serial links. The WAN Types visualization scheme is now able to show ATM WAN links and Frame Relay-to-ATM interworking. Note, this does not infer that the internals of the Layer 2 fabric is modeled.

What's New in the 4.1 Cisco NSM Release

This section provides information about the new features and functionality provided in the Cisco NSM 4.1 release only. It does not include information about the features provided in the 4.0 release.

VPDN Support

This subsection provides information about the new features and functionality provided to support the VPDN tunnels.

Wizard Manager

This subsection describes the "Run VPDN Collection And Web Reports" wizard. This wizard allows you to:

• collect router configuration information and IP routing tables

• collect VPDN tunnel information (requires the UCP to be configured)

• generate connectivity reports (including those for VPDN tunnels)

• send notification through email and directly to the NCC (when it is configured)

See "Chapter 7 - Wizard Manager" in the 4.0 Netsys Connectivity Service Manager General Reference Guide for detailed information about the Wizard Manager.

Topology

This subsection describes the VPDN-related topology enhancements. See "Chapter 4 - Creating the Topology" in the 4.0 Netsys Connectivity Service Manager General Reference Guide for detailed information about topology features.

1. Network Access Servers (NAS) are displayed in Level-3 topology views. Cisco NSM determines that a router is a NAS by checking for the presence of the following commands in a router configuration file: aaa authentication ppp, vpdn enable, and vpdn outgoing. The routers having NAS functionality are indicated by a NAS icon (multidirectional, curved arrows drawn within a rectangle), rather than the standard Cisco router icon.

2. Provisioned VPDN tunnels are displayed in a new logical VPDN Topology View window. You can view the following in the VPDN topology view:

(a) The location of the VPDN tunnels that are provisioned (not the active tunnels). This entails displaying the links between the NASs and the home-gateways at the other end of the VPDN tunnels.

(b) The grouping of home-gateways that belong to the same organization.

Report Manager

This subsection describes the new VPDN-related reports added to the Report Manager. See "Chapter 5 - Report Manager" in the 4.0 Netsys Connectivity Service Manager General Reference Guide for detailed information about the Report Manager.

1. VPDN Inventory Report. This report is generated when you double-click on the "VPDN Inventory Report" entry. This report provides you a list of the VPDN tunnels defined in the baseline router configuration files and/or that are added to a AAA server (when Cisco NSM is communicating with the Cisco UCP product). The information provided in this report includes the source router name, domain name, home gateway address, tunnel ID, and tunnel source (local, RADIUS, or TACACS+).

2. AAA Inventory Report. This report is generated when you double-click on the "AAA Inventory Report" entry. This report provides you a list of the AAA servers defined in the baseline router configuration files. The information provided in this report includes the baseline router names providing AAA services and their associated AAA server/proxy names or addresses, and the protocol used for authentication (local, RADIUS, or TACACS+).

Integrity Checks

This subsection describes the VPDN-related integrity checks added in this release. See "Appendix A - Baseline Integrity Checks" in the 4.0 Netsys Connectivity Service Manager General Reference Guide for detailed information about the integrity checks performed by the Cisco NSM software.

1. AAA: RADIUS Server Host Not Specified

When radius is in either the AAA Authentication or AAA Authorization method list, at least one RADIUS host server must be specified. (Warning Level)

2. AAA: TACACS+ Server Host Not Specified

When tacacs+ is in either a AAA Authentication or AAA Authorization method list, at least one TACACS+ host server must be specified. (Warning Level)

3. PPP: Defined Authentication List Name Not Used

A global "aaa authentication ppp" command specifies a list name, but no "interface ppp" command exists that mentions this list name. (Warning Level)

4. PPP: PPP Not Configured on Virtual Template

A "vpdn incoming" command mentions a virtual template, but this interface does not have PPP configured. (Warning Level)

5. PPP: Undefined Authentication List Name

When an "interface ppp" command mentions an "authentication <list-name>" command, a global "aaa authentication ppp" command must define this list. (Warning Level)

6. VPDN: Local VPDN Definitions Cannot be Used

There are "vpdn outgoing" commands defining local VPDN tunnels, however, these local tunnels cannot be used as no global "aaa authentication ppp" command specifies the keyword local in its method list. (Warning Level)

7. VPDN: Undefined Virtual Template

The virtual template mentioned in a "vpdn incoming" command must be defined. (Warning Level)

Policies

This subsection describes the VPDN-related implicit policies added in this release. See Section 2.2 "Policy Sets Window," in the 4.0 Netsys Connectivity Service Manager Analysis Reference Guide for detailed information about policy sets.

1. NAS to AAA Server

This implicit policy identifies the IP routes between the Network Access Servers (NAS) and the AAA (Authentication, Authorization, and Accounting) servers they are required to communicate with. The results of the connectivity analysis are displayed in the Policies Analysis window. When IP connectivity does not exist, diagnostic reports are provided to help you identify the cause of the problem(s).

2. VPDN Tunnels

This implicit policy identifies the IP routes between the NASs and the home gateways at the other ends of VPDN tunnels. When a home gateway is not being managed by the service provider, connectivity is evaluated between the NASs and the possible ingress/egress points in the service provider's network. The results of the connectivity analysis are displayed in the Policies Analysis window. When IP connectivity does not exist, diagnostic reports are provided to help you identify the cause of the problem(s).

Cisco IOS Commands Modeled

This subsection describes the VPDN-related Cisco IOS commands currently modeled in this release. See "Appendix A - Cisco IOS Commands Modeled" in the 4.0 Netsys Connectivity Service Manager Analysis Reference Guide for detailed information about the Cisco IOS commands modeled by the Cisco NSM software.

1. "aaa authentication local-override"

This global configuration command is used to have the router check the local user database before attempting another form of authentication.

2. "aaa authentication ppp {default | <list-name>} <method1> [...[<method4>]]"

This global configuration command is used to enable one or more Authentication Authorization and Accounting (AAA) authentication methods for use on serial interfaces running PPP (Point-to-Point Protocol) when using TACACS+ (Terminal Access Controller Access Control System Plus).

3. "aaa authorization {network | exec | command <level>} <method>"

This global configuration command is used to set parameters that restrict a user's network access.

4. "aaa new-model"

This global configuration command is used to enable the Authentication Authorization and Accounting (AAA) access control model.

5. "group-range <low-end-of-range> <high-end-of-range>"

This interface configuration command is used to create a list of member asynchronous interfaces (associated with a group interface).

6. "interface group-async <number>"

This global configuration command is used to create a group interface that will serve as master, to which asynchronous interfaces can be associated as members.

7. "interface virtual-template <number>"

This global configuration command is used to associate a virtual template with a virtual template interface.

8. "ip host <name> [<tcp-port-number>] <address1> [<address2> .. <address8>]"

This global configuration command is used to define a static host name-to-address mapping in the host cache.

9. "ppp authentication {chap | chap pap | pap chap | pap} [if-needed [<list-name> | default] [call-in]"

This interface configuration command is used to enable Challenge Handshake Authentication Protocol (CHAP) or Password Authentication Protocol (PAP) and to enable an Authentication Authorization and Accounting (AAA) authentication method on an interface. Note, when you use a <list-name> value that was not configured with the aaa authentication ppp command, you will disable PPP on this interface.

10. "ppp multilink"

This interface configuration command is used to enable Multilink PPP on an ISDN interface.

11. "radius-server host {<hostname> | <ip-address>}"

This global configuration command is used to specify a server host. You can use multiple radius-server host commands to specify multiple hosts. The Cisco IOS software searches for the hosts in the order you specify.

12. "tacacs-server directed-request"

This global configuration command is used to send only a username to a specified server when a direct request is issued.

13. "tacacs-server host <hostname> [single-connection] [port <integer>] [timeout <integer>] [key <string>]"

This global configuration command is used to specify the name of a TACACS host. You can use multiple tacacs-server host commands to specify multiple hosts. The Cisco IOS software searches for the hosts in the order you specify.

14. "vpdn enable"

This global configuration command is used to enable virtual private dial-up networking (VPDN) on the router and inform the router to look for tunnel definitions in a database and on a remote authorization server (home gateway), when one is present.

15. "vpdn force-local-chap"

This global configuration command is used to force the home gateway to issue its own CHAP challenge even when one has already been issued from the network's access server.

16. "vpdn incoming {<remote-name>} {<local-name>} virtual-template <number>"

This global configuration command is used to specify the local name for authenticating and the virtual template to use for building incoming connections when a Level 2 Forwarding (tunnel) connection is requested from a certain remote host.

17. "vpdn outgoing {<domain-name>} {<local-name>} ip <address>"

This global configuration command is used to specify the name and IP address of a remote host and the name to use when authenticating a tunnel for forwarding traffic to the remote host on a virtual private dial-up network.

18. "vpdn source-ip <address>"

This configuration option is used to allow the NAS to specify the source IP address of the NAS. When this is specified, L2F (Layer 2 Forwarding Protocol) packets to the home gateway always have this as the source IP address. By default, the source IP address is chosen by IP (this is usually, not always, the interface to send out the IP packet.)

Cisco Router Attributes Supported

This subsection describes the VPDN-related Cisco router attributes available through the router configuration windows. You can modify these router attributes with the GUI editor and then invoke "what-if" analysis.

Router Window

The following modifications were made to the Router window:

1. A "Network Access Security" button was added. You click on this button to display the Network Access Security Info window. You can do the following through this window:

(a) enable AAA on the router

(b) create/view/delete TACACS Server Hosts

(c) enable/disable Direct Requests

(d) create/view/delete RADIUS Server Hosts

(e) create/view/delete AAA Authentication PPP methods

(f) enable/disable Local Override

(g) specify/view/delete AAA Authorization types, levels, and/or methods.

2. A "VPDN Configuration" button has been added. You click on this button to display the VPDN Configuration Info window. You can do the following through this window:

(a) enable/disable VPDN

(b) add/view/delete incoming and outgoing connections

(c) force local CHAP

(d) assign a new or clear an existing source IP address.

3. An "IP Hosts" button has been added. You click on this button to display the IP Hosts window. You can add/view/delete static IP host name-to-address mapping(s) in the host cache through this window.

Router Interface Window

A "Configured PPP" button has been added. This button is only displayed when a virtual-template interface exists on the router. You click on this button to display the Configure PPP window. You can add/modify/delete Point-to-Point Protocol interface attributes through this window.

New Elements Window

GRE (generic routing encapsulation) has been added to the list of viable transport layer protocol type options for extended IP access lists. GRE is a tunneling protocol developed by Cisco that can encapsulate a wide variety of protocol packet types inside IP tunnels, creating a virtual point-to-point link to Cisco routers at remote points over an IP internetwork. By connecting multiprotocol subnetworks in a single protocol backbone environment, IP tunneling using GRE allows network expansion across a single-protocol backbone environment.

Cisco MC3810 Support

This subsection provides a brief overview of the new features and functionality provided to support the Cisco MC3810. Cisco MC3810s are access products that provide multiservice switching access concentrator functionality to your site's network while introducing the ability to transport data, video, and voice traffic. The units can be used in an office or laboratory setting. Managing a variety of data and voice traffic types, Cisco MC3810 systems optimize your network's bandwidth with protocol synchronization and negotiation. Cisco MC3810 models offer T1 and E1 data and voice integration. The MC3810 also supports standard Cisco IOS IP, IPX, bridging, and SNA functionality.

The MC3810 configuration files are supported in the same manner as other Cisco router configuration files. That is, the Cisco NSM product must have access to the MC3810 configuration files in order to create a baseline model of your network. Initially, you provide access to the configuration files in one of the following manners:

• by furnishing their location during the creation of the baseline

• by using Telnet to retrieve them with the $ECSP_HOME/bin/getconfig script

Topology

This subsection describes the MC3810-related topology enhancements. See "Chapter 4 - Creating the Topology" in the 4.0 Netsys Connectivity Service Manager General Reference Guide for detailed information about the topology features.

1. The standard Cisco router icon is used to depict the MC3810. The router icon is colored white when you select the "Cisco Router Types" Data Visualization scheme.

2. Logical connectivity between MC3810s and other network devices is shown in Level-3 topology views.

3. A Voice view is available through the Views pane in the Topology Manager window. You double-click on the Voice entry to display the MC3810s and their interfaces supporting POTS (Plain Old Telephone Service) and only the routers and PVCs involved in vofr (voice over Frame Relay), vtoa (Voice and Telephony over ATM), and vohdlc (voice over HDLC). The POTS interfaces are represented by a triangular shaped icon which is connected to an MC3810 device icon.

4. A new button with a triangle icon as its label ("Show Voice Plain Old Telephone Service Labels") has been added to the Labels pane in the Topology View windows. This button allows you to display the Voice POTS labels.

5. You can test whether a path exists between an MC3810 device and a voice POTS interface on another MC3810, by using the QuickPath feature in the Voice Topology View window. First you click the left mouse button on an MC3810 icon to select that device as the source device, then you click the left mouse button within the Source field. Next you click the left mouse button on a voice POTS icon, then you click the left mouse button within the Destination field. With the source and destination fields populated, you next click on the Show Voice Path button. At this point, the Cisco NSM product determines whether a voice path exists between the two locations, with the results displayed in the Policies Analysis window. When the path status in the Policies Analysis window is set to OK (a path exists), a pink line (default color) is drawn from the source device icon to the destination voice POTS icon in the Voice Topology View window.

Wizard Manager

The "Collect/Import Cisco Configurations" wizard was modified to allow the collection of MC3810 router configuration. See "Chapter 7 - Wizard Manager" in the 4.0 Netsys Connectivity Service Manager General Reference Guide for detailed information about the Wizard Manager.

Report Manager

This subsection describes the new MC3810-related "Voice Routing Loops and Dangling Routes" report added to the Report Manager. This report provides you a list of the routing loops and dangling routes detected by the Cisco NSM product.

A voice routing loop is created when the voice path defined by the dial-peer destination-pattern statements in the MC3810 configuration files originate and terminate at the same MC3810.

A voice dangling route occurs when the voice path defined by the dial-peer destination-pattern statement in an MC3810 configuration file does not match a dial-peer destination-pattern statement in one of the MC3810s along the path to the destination, effectively terminating the path at that point.

Integrity Checks

This subsection describes the new MC3810-related integrity checks. See "Appendix A - Baseline Integrity Checks" in the 4.0 Netsys Connectivity Service Manager General Reference Guide for detailed information about the integrity checks performed by the Cisco NSM software.

1. CES: Circuit Emulation Mapped to Non-Existent or Shutdown Interface

The "ces map pvc <vcd> <atm-interface>" command maps a circuit emulation service to a PVC on an interface. When the interface does not exist or is shutdown, this high-severity warning is issued.

2. CES: Circuit Emulation Mapped to Non-Existent ATM PVC

The "ces map pvc <vcd> <atm-interface>" command maps a circuit emulation service to a PVC on an ATM interface. The PVC must be defined on the ATM interface. Otherwise, this high-severity warning is issued.

3. CES: Clock Configuration Problem

The "ces connect <atm-interface> <vcd>" command connects circuit emulation service to an ATM PVC. In order for it to work, the global command "network-clock base-rate [56k|64k]" must be used to configure the network clock base-rate to 64k and the interface configuration command "clock rate network [<rate>]" must be used to configure the serial interface clock speed. Even though allowable ranges for <rate> are from 56000 to 3968000, <rate> must be a multiple of 64k as the "network-clock base-rate" must be set to 64k. The upper limit of the CES clock speed is the trunk line speed: 1544000 for T1 and 2048000 for E1. When either command is missing or <rate> is set to an invalid value, this high severity warning is issued.

4. CES: Low Peak and Average Rates Set On ATM PVC

The "ces map pvc <vcd> <atm-interface>" command maps circuit emulation service to an ATM PVC. To accommodate overhead, the values of the peak and average rates of the ATM PVC should be 10-13% greater than the PLL (phase-locked-loop) clock rate from the command
"clock rate network [<rate>]". Otherwise, this high severity warning is issued.

5. CES: Wrong AAL Encapsulation On ATM PVC

The "ces map pvc <vcd> <atm-interface>" command maps circuit emulation service to an ATM PVC. The AAL (ATM Adaptation Layer) encapsulation type of this ATM PVC must be "aal1". Otherwise, this high severity warning is issued.

6. Dial-Peer: Next Hop Router Contains No Route

For each destination-pattern to be routed over the network, voatm, vofr, and vohdlc, this check looks at the next-hop router. When the next-hop router does not handle this pattern (there is no "dial-peer" statement with a matching pattern), this high severity warning is issued.

7. Dial-Peer: Non-Existent Or Shutdown Interface

When the interface referenced by the "session target" command within a "dial-peer" statement is either non-existent or shutdown, this high severity warning is issued.

8. Dial-Peer: Non-Existent Or Shutdown Voice Port

The voice port "port <slot>/<port>" referenced by the "dial-peer" statement is either non-existent or shutdown on this router. This is a high severity warning.

9. Dial-Peer: Non-utilized "dial-peer" Statement

The "dial-peer voice <tag> <protocol>" statements specify a collection of rules used for voice routing. The statements are evaluated sequentially, comparing the destination phone number with the destination pattern of the "dial-peer" statement ("destination-pattern <pattern>").

The evaluation also takes into account the preference value ("preference <value>") of a statement. For all statements of the same preference value, the first match, in the appearance order in the configuration file, is selected. However, preference is not used for selecting between network "dial-peer" (voatm, vofr, vohdlc, voip) and local "dial-peer" (pots) statements.

The use of the dot "." in the pattern to match any digit 0-9 enables the creation of very general patterns. This check locates all preceding "dial-peer" statements with a destination pattern which shadows (or are more general than) subsequent statements with the same preference.

10. FR-ATM: Frame-Relay DLCIs Mapped To Multiple ATM VCDs

The "fr-atm -iwf map pvc <dlci> <atm-interface> <vcd> command maps a Frame Relay PVC to an ATM PVC. On a FR-ATM interface, all Frame Relay PVCs must be mapped to the same ATM PVC. Otherwise, this high severity warning is issued.

11. FR-ATM: Frame-Relay PVC Mapped to Non-Existent ATM PVC

The "fr-atm-iwf map pvc <dlci> <atm-interface> <vcd>" command maps a Frame Relay PVC to an ATM PVC. The ATM interface must exist and the PVC (identified by <vcd>) must be defined on the interface. When the ATM interface does not exist or the PVC is not defined, this high-severity warning is issued.

12. FR-ATM: Wrong AAL Encapsulation On ATM PVC

The "fr-atm-iwf map pvc <dlci> <atm-interface> <vcd>" command maps a Frame Relay PVC to an ATM PVC. The AAL encapsulation type of this ATM PVC must be "aal5fratm". Otherwise, this high severity warning is issued.

13. VOATM: Target ATM PVC Does Not Exist

The "session target [interface] [vcd]" command specifies an ATM PVC over which voice data will be carried. When either the interface does not exist or the PVC is not defined, this high severity warning is issued.

14. VOATM: Wrong AAL Encapsulation On ATM PVC

The "session target [interface] [vcd]" command specifies an ATM PVC over which voice data will be carried. The AAL encapsulation type of this ATM PVC must be "aal5voice". Otherwise, this high severity warning is issued.

15. VOFR: Frame Relay Map-Class Configuration Problem

The "session target [interface] [dlci]" command specifies a Frame Relay PVC over which voice data will be carried. The interface the PVC belongs to must be associated with a map-class (using the command "frame-relay class"). Traffic-shaping characteristics must also be defined (using the command "frame-relay traffic-rate") in the map-class. Otherwise, this high-severity warning is issued.

16. VOFR: Frame Relay PVC Must Have Voice Encapsulation

The "session target [interface] [dlci]" command specifies a Frame Relay PVC over which voice data will be carried. Data fragmentation (FRF-12) must be enabled on this PVC (through the "voice-encap" option in the "frame-relay interface-dlci" command) to support voice. Otherwise, this high-severity warning is issued.

17. VOFR: Target Frame Relay PVC Does Not Exist

The "session target [interface] [dlci]" command specifies a Frame Relay PVC over which voice data will be carried. When either the interface does not exist or the PVC is not defined, this high severity warning is issued.

18. VOHDLC: Configuration Problem

The "session target [interface]" command specifies a serial interface over which voice data (encapsulated with Cisco serial encapsulation method HDLC) will be carried. The encapsulation method of the interface must be set to HDLC (using the "encapsulation hdlc" command) and data fragmentation (FRF-12 fashion for HDLC to support voice) must also be enabled (using the "voice-encap [<size>]" command. Otherwise, this high-severity warning is issued.

Cisco IOS Commands Modeled

This subsection describes the MC3810-related Cisco IOS commands currently modeled. See "Appendix A - Cisco IOS Commands Modeled" in the 4.0 Netsys Connectivity Service Manager Analysis Reference Guide for detailed information about the Cisco IOS commands modeled by the Cisco NSM software.

1. "atm pvc <vcd> <vpi> <vci> <aal-encap> [<peak> <average> <burst>] \
[oam <seconds>] [inarp <minutes>] [compress]"

This global configuration command is used to create a permanent virtual circuit (PVC) on the MC3810 and, optionally, generate Operation, Administration, and Maintenance (OAM) F5 loopback cells or enable Inverse ATM ARP.

2. "<protocol> <protocol-address> atm vc {<vcd>} [broadcast]"

This map list configuration command is used to define an ATM map statement for a PVC. Protocols supported are ip and ipx.

3. "ces connect <atm-interface> <vcd>"

This interface configuration command is used to map the CES (Circuit Emulation Service) to an ATM PVC. The interface must be encapsulated as ces-atm. The <atm-interface> must be configured to be encapsulation atm and the <vcd> must be defined on the interface. For the MC3810, the <atm-interface> must be Serial 2.

4. "clock rate network [<rate>]"

This interface configuration command is used to configure a serial interface's phase-lock-loop (PLL) clock rate.

5. "dial-peer voice <tag> {pots | atm | frame-relay | hdlc}"

This global configuration command is used to enter dial-peer configuration mode. The "port <slot/port>", "session target [interface] [<string>], destination-pattern <string>", "preference <value>", and "shutdown" subcommands are supported when in dial-peer configuration mode. Note, voip (voice over IP) is not supported by the Cisco NSM software in this release.

Cisco Router Attributes Supported

This subsection describes the MC3810-related Cisco router attributes currently supported. You can modify the supported router attributes and then invoke "what-if" analysis. See the 4.0 Netsys Connectivity Service Manager Analysis Reference Guide for detailed information obtaining access to the router attributes.

Router Window

The following modifications were made to the Router window:

1. A Voice Port List pane has been added. A list of the voice module's slot (0 for trunk channels, 1 for analog and digital) and port (analog voice: 1 through 6, digital T1: 1 through 24, digital E1: 1 through 15, 17 through 31) numbers are provided.

2. A Network Clock Base Rate text field has been added. You can specify either 56k (default) or 64k.

3. A Configured Voice Info button has been added. You click on this button to display the Voice Info window. You can do the following using this button:

(a) add a new dial peer voice list entry or view/delete an existing dial peer voice list entry

(b) add a new dial and/or destination pattern or view/delete an existing dial and/or destination pattern.

4. A Map Classes button has been added. You click on this button to display the Map Classes window. You can add a new Frame Relay map class or view/delete an existing Frame Relay map class using this button.

5. A Map List button has been added. You click on this button to display the Map List window. You can add a Frame Relay new map list or view/delete an existing Frame Relay map class through this window.

Router Interface Window

The following modifications were made to the Router Interface window:

1. A Clock Rate Network text field has been added. You specify the serial interface's PLL (Phase-Lock-Loop) clock rate in this field. You can specify a value ranging from 56000 through 3968000, however the value must be a multiple of either 56k or 64k, depending on the network clock value set by the "network-clock base-rate" command.

2. A Frame Relay Info button has been added. This button is only displayed for interfaces with Frame Relay encapsulation. You click on this button to display the Frame Relay Info window. You can assign a Frame Relay class name and add/modify/delete DLCI interface attributes through this window.

3. An ATM Info button has been added. This button is only displayed for serial interfaces with ATM encapsulation. You click on this button to display the ATM Interface Info window. You can add/modify/delete ATM PVCs through this window.

4. A Frame Relay/ATM Interworking Info button has been added. This button is only displayed for Frame Relay/ATM interfaces. You click on this button to display the Frame Relay/ATM Interworking Info window. You can add/modify/delete Frame Relay/ATM Map PVC List entries through this window.

5. An ATM-CES Interface Info button has been added. This button is only displayed when a serial interface supporting ATM-CES (Circuit Emulation Service) encapsulation exists on the router. You click on this button to display the ATM-CES Interface Info window. You can add/modify/delete ATM interfaces supporting CES through this window.

Policies

This subsection describes the "Voice over IP" implicit policy added in this release. This policy applies to Cisco 3600 and AS5300 devices. See Section 2.2 "Policy Sets Window," in the 4.0 Netsys Connectivity Service Manager Analysis Reference Guide for detailed information about policy sets.

Voice over IP is configured using a dial-plan composed of the following forwarding rules:

1. dial-peer voice <rule#> voip

2. destination-pattern <phone-number>

3. session target ipv4:<next-hop-ip-address>

This implicit policy verifies IP connectivity, using UDP port 16000, to the above mentioned <next-hop-ip-address>.

General Enhancements

This subsection provides information about the remainder of the Cisco NSM 4.1 features and functionality added in this release.

Web Server Support

In Cisco NSM releases prior to 4.1, Cisco NSM provided viewing access to HTML reports, Java-based topologies, and on-line Help through a Web browser using a file system-based URL (for example, file://localhost/usr/netsys_data/perf.tutorial). The Cisco NSM 4.1 release now provides a Web server, making the HTML reports, Java-based topologies, and on-line Help available to Web browsers not having access to the file system.

By default, the Web server is not used by Cisco NSM when accessing Help functionality and the Web reports. You click on the Administer Web Options button in the Schedule window, then click on the Client Access tab in the Administer Web Options window to specify whether the logs, Web reports, and on-line Help are accessed directly from the file system or through a Web server.

You click on the View Home Page button in the Schedule window to obtain access to the Netsys Web server's home page.

By default, the Web server is not running. To start the Web server:

Step 1 Click on the Schedule button in the Cisco Netsys window.

The Schedule window is displayed.

Step 2 Click on the Administer Web Options button in the Schedule window.

The Administer Web Options window is displayed.

Step 3 Click on the Web Server tab in the Administer Web Options window.

The Status pane informs you whether the Web Server is currently running.

Step 4 Click on the Reset Server button to invoke the Web Server.

By default, the Web server is invoked on port 8015. The Web server is configured with the locations of the on-line Help directory and the baseline directories (specified by the $ECSP_DATA environment variable). The baselines and on-line Help are made accessible through links on the home page at http://<hostname>:<port>, as well as being directly accessible from launch points throughout the Cisco NSM software.

You can add additional data directory mappings using the Mappings button (other than $ECSP_DATA), to the Web server's home page and modify the Web server's port number and home page configuration settings (using the Advanced button) through the Administer Web Options window.

When you click on the Mappings button, the $ECSP_HOME/resources/httpd/conf/mapping.conf file is opened. When you click on the Advanced button, the $ECSP_HOME/resources/httpd/conf/server.conf file is opened. Both files are opened using the text editor specified by the EDITOR environment variable. Upon editing the mapping.conf and/or server.conf files, you must click on the Reset Server button, thereby incorporating the configuration changes you made into the Web server.

Web Server Security

By default, the Cisco Netsys Web server ships without any security restrictions enabled. When the port number on which the Web server operates is known, access to the data contained in your baselines (such as configuration files) is available.

Turning Off the Web Server

Turning off the Web server is the easiest and most secure way to ensure no one can access your baselines through a Web browser. By default, Cisco NSM 4.1 ships with the Web server turned off. To turn off the Web server, you must:

Step 1 Remove the Web server entry from the Scheduler. When you start the Web server, an entry is added to the Cisco NSM Scheduler and a check is found running, the Scheduler restarts it. You must remove this entry to ensure the Cisco NSM Scheduler does not restart the Web server after you kill it.

(a) Open the $ECSP_HOME/resources/scheduler/scheduler_file file with the text editor of your choice.

(b) Delete the line having web_0 as one of the first words.

(c) Save the modified scheduler_file.

Step 2 Kill the running Web server. After removing the entry from the scheduler_file, you must kill the Netsys Web server. Three processes are associated with the Netsys Web server; one parent and two child. Search for the tclsh string, then kill the associated process (the child processes are also killed.) For example, from a C Shell command line prompt:

(a) Invoke ps -ef|grep tclsh

(b) One process, with $ECSP_HOME/bin as part of the executable path, is displayed. In the following example, ECSP_HOME is set to /usr/myuser/netsys:

host% ps -ef | grep tclsh
myuser 23237 23236 0 Feb 27 ? 0:33
/usr/myuser/netsys/bin/solaris/tclsh
/usr/myuser/netsys/resources/tclhttpd2.0.1/b
 

(c) Ensure the grep tclsh output is associated with the Cisco NSM installation by verifying the process is prepended with $ECSP_HOME/bin, then kill the associated process as follows:

host% kill -9 23237


(d) Ensure the Web server is no longer running by trying to access the Web server through a Web browser (make sure your Web browser is not retrieving a cached version).

Configuring Web Server Security

The Cisco NSM Web server implements host filtering and basic HTTP authentication in a manner similar to that of NCSA's Web server, httpd. With host filtering, you can allow or deny access based on a client's domain or IP address. With basic authentication, you can require the user to enter an ID and a password. Basic HTTP authentication is a widely used standard that many Web servers implement. A description of Basic HTTP authentication and how to set it up can be found on many Internet Web sites, for example, http://hoohoo.ncsa.uiuc.edu/docs/tutorials/user.html. Much of the description below was based on this document.

In terms of its security, basic HTTP authentication does not send the user ID and passwords over the network in clear text. Instead, they are uuencoded.

Note, every time you change Web server security, you should kill and restart the Web server as described above.

Host Filtering

The Cisco NSM Web server reads a .htaccess file from each directory that needs to be protected (note, this also protects all subdirectories on the file system). To experiment with these, you can try placing a .htaccess file within the $ECSP_HOME/resources/httpd/htdocs directory. Note, an access.conf file does not exist as with other Web servers based on NCSA httpd. Following is a sample .htaccess file using host filtering (based on IP address) allowing access from 129.129.129.28:

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName WebAdministration
AuthType Basic
 
<Limit GET>
order deny,allow
deny from all
allow from 129.129.129.28
</Limit>
 

Ensure the .htaccess file has an IP address different from the IP address of the machine where your Web browser is running. The AuthUserFile, AuthGroupFile, AuthName, and AuthType fields are used below in basic authentication and can be left to the default values.

Place the .htaccess file within the $ECSP_HOME/resources/httpd/htdocs directory, and try accessing the Web server and port (by default, http://<hostname>:8015) from your Web browser. You should be presented with the following message:

Got the error Permission denied
while trying to obtain /index.html.

Following is a sample .htaccess file using host filtering that allows an entire subnet:

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName WebAdministration
AuthType Basic
 
<Limit GET>
order deny,allow
deny from all
allow from 129.129.129.28
</Limit>
 

Following is a sample .htaccess file using host filtering based on a name instead of an IP address:

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName WebAdministration
AuthType Basic
 
<Limit GET POST>
order deny,allow
deny from all
allow from .cisco.com
</Limit>
 

Both the client hostname and IP address are checked against the allow and deny specifications. By default, IP address specifications have a wildcard character appended during the matching, while hostname specifications have a wildcard prepended. In the two examples above, 129.129.129. is treated as 129.129.129.*, thus, it allows any IP address with the high-order octets 129.129.129. The .cisco.com is treated as *.cisco.com, thus, it allows any hostname ending in .cisco.com. To override this behavior, use "*" as a wildcard character in the allow and deny specifications. For example, "allow from *129*" allows access to any client with 129 in its hostname or IP address.

Basic HTTP Authentication

Basic HTTP authentication uses user ID/password combinations. Note, the Web server uses users/passwords that are not related to the UNIX users/passwords (as in the /etc/passwd file). The set of users allowed access to a given directory and subdirectories is specified in the .htaccess file. The user ID/password mapping is specified in other files specified in the AuthUserFile and AuthGroupFile fields. For example, to create basic HTTP authentication for the sampleuser user using the samplepw password you must:

Step 1 Create a .htaccess file in the $ECSP_HOME/resources/httpd/htdocs directory as follows:

AuthUserFile /<mydirectory>/.htpasswd
AuthGroupFile /dev/null
AuthName WebAdministration
AuthType Basic
 
<Limit GET>
require user sampleuser
</Limit>

The AuthUserFile and AuthGroupFile fields specify where the password files are located. In the above example, AuthGroupFile is set to /dev/null as groups are not used.

The AuthName field is the name of the set of documents of the Web server you are attempting to secure. The AuthName field is presented to the user when asking for a password during basic authentication and is saved by the Web browser so when you attempt to reaccess the same page, or another page in the same AuthName set of documents, the Web browser automatically enters the user ID/password values.

Step 2 Create the password file. Within the file you reference in the AuthUserFile line above, you must add a line for the user. This line can be generated using a Perl program that is shipped with Cisco NSM 4.1. Assuming $ECSP_HOME/bin is defined in your path, invoke:

host% execperl.sh $ECSP_HOME/resources/perl/htpasswd.pl sampleuser \ samplepw
Executing perl script: /usr/myuser/netsys/resources/perl/htpasswd.pl
sampleuser:jQcji9e7OUCJs
 

Step 3 Add the line with the user name and encrypted password (sampleuser:jQcji9e7OUCJs in the above example) and add it to the /<mydirectory>/.htpasswd file.

Step 4 Restart the Web server, then try accessing it with your Web browser. You should be prompted to enter user and password values. When you do not specify sampleuser and samplepw, you should not be able to access the Web server.

Basic HTTP Authentication with Multiple Usernames/Passwords

Support for multiple users is provided through the use of groups. The steps are very similar to the single user case.

Step 1 Add the multiple user entries to the /<mydirectory>/.htpasswd file. You can use the output from htpasswd.pl command to accomplish this.

Step 2 Create the group file. Create a file called /<mydirectory>/.htgroup where the list of users from the password file is assigned to a group name. The format is as follows (usernames are listed on the right with spaces as delimiters):

samplegroup: sampleuser sample1 sample2 sample3
 

Step 3 Modify the $ECSP_HOME/resources/httpd/htdocs/.htaccess file. You should replace the /dev/null that was being used for the AuthGroupFile within the /<mydirectory>/.htgroup file. In the required statement, you should now say
"require group samplegroup" instead of "require user sampleuser".

Restricting Access to Specific Directories

The examples above assumed the .htaccess file was being placed into the $ECSP_HOME/resources/httpd/htdocs directory. This protects the "home page" of the Web server, for example, when a user tries to access http://: (for example, http://myhost:8015). The home page that is generated by the Cisco NSM Web server has links to baseline logs and reports. In order to restrict access to specific baselines and directories under the baselines, more security needs to be configured. This involves the use of more .htaccess files distributed throughout your baseline directories.

Protecting All Baselines

In order to protect all baseline directories and their subdirectories, you must place a .htaccess file within every directory specified in the $ECSP_HOME/resources/httpd/conf/mapping.conf file. For example, suppose a mapping statement maps your /baselines/netsys_data directory to your $ECSP_DATA directory (mapping /baselines/netsys_data to /usr/myuser/netsys_data). You must place a .htaccess file within the /usr/myuser/netsys_data directory. This places security on every baseline within the /usr/myuser/netsys_data directory.

Protecting Specific Baselines

When you want some baselines accessible and others not, you must place a .htaccess file within each baseline directory you want protected.

Protecting Specific Baseline Subdirectories

When you want to provide access only to specific baseline subdirectories, (for example, the reports and logs subdirectories, but do not want to allow access to the config subdirectory, you must place a .htaccess file within the config subdirectory.

Access and Error Logs

The Cisco NSM Web server's logs are located in the $ECSP_HOME/resources/httpd/logs directory. A daily access log file with the name log<port and date> (for example, log801598.03.02). A file named log<port> ending in error (for example, log8015error) containing errors and debug information also exists. Following is a sample entry resulting when someone from an unauthorized IP address tries to access the Web server:

[02/Mar/1998:10:27:46] sock14
[02/Mar/1998:11:07:17] sock14 AuthVerifyNet {access denied to dummyhost.dummydomain.com (129.129.129.1) in htdocs}
[02/Mar/1998:11:07:17] sock14 Error 403 /index.html {}

You can periodically check the error log to see when unauthorized access has been attempted.

Topology

This subsection describes the topology related enhancements. See "Chapter 4 - Creating the Topology" in the 4.0 Netsys Connectivity Service Manager General Reference Guide for detailed information about the topology features.

1. You can now add serial links between IP Unnumbered ATM interfaces. You accomplish this by invoking the Add Serial Link option from a Topology View window.

2. An ATM subview is now available. You click on the ATM button in the Subview pane in a Topology View window to display the baseline routers with ATM interfaces.

Wizard Manager/Scheduler

This subsection describes the Wizard Manager and Scheduler related enhancements. See "Chapter 7 - Wizard Manager" in the 4.0 Netsys Connectivity Service Manager General Reference Guide for detailed information about the Wizard Manager. See "Chapter 1 - Netsys Scheduler" in the 4.0 Netsys Scheduling and Web Reports Guide for detailed information about the Scheduler.

1. The collection of traffic data from Bay Networks hubs is no longer supported.

2. The "Collect Cisco Configurations from CiscoWorks Hosts" wizard allows you to schedule the collection of Cisco router configuration files from hosts running the 4.0 version of CiscoWorks. A CiscoWorks Host option has been added to the device list in the "Administer Password Database" wizard. Following are the requirements and steps you must follow for this wizard to function properly:

(a) CiscoWorks related environment variables must be set in the user's profile for the Login User ID on the CiscoWorks host machine.

(b) You must do the following:

* download the CW_Connectivity.tar.Z file from    "ftp://www.cisco.com/pub/netmgmt/ciscoworks"

* uncompress the CW_Connectivity.tar.Z file

* copy the CW_Connectivity.tar file to the $NMSROOT/etc directory on the    CiscoWorks host machine

* untar the $NMSROOT/etc/CW_Connectivity.tar file

* set the file's permissions to 755 (chmod $NMSROOT/etc/CW_Connectivity.tar 755).

(c) You must add the following CiscoWorks host information to the Device Password Database (through the "Administer Password Database" wizard):

* Login User ID: the UNIX login user name (note, this login name must be a part of the    CiscoWorks group on the CiscoWorks host machine)

* Login Password: the UNIX login user password

* CiscoWorks User ID: the login user name required to login to CiscoWorks

* CiscoWorks Password: the login password required to login in CiscoWorks.

(d) You must invoke the "Collect Configurations from CiscoWorks Hosts" wizard from either the Wizard Manager or Scheduler. When the wizard starts, you must:

* choose the desired CiscoWorks host

* specify the qualified path to the directory where tftp is running on the CiscoWorks host

* choose the domain containing the configuration files you want to collect

* choose the routers whose configuration files you want to collect

* specify whether the collected configuration files are to be saved to the baseline Data    Repository and baseline directories or to an alternative directory

* schedule this event.

3. The "Collect Serial IP Unnumbered Information" wizard allows you to collect IP unnumbered connectivity information, using the "show cdp neighbors" command, from the routers you specify.

4. The "Run Web Reports", "Run Service Management Collection and Web Reports", and "Run VPDN Collection and Web Reports" wizards were modified to allow you to generate Cisco NSM Web based reports in Java format, as well as in HTML format.

5. The "Collect Frame Relay PVC Information" wizard was modified to allow you to also collect ATM PVC information. ATM PVC information is collected from the end points of the dynamically mapped ATM PVCs when the inarp option is specified with the atm pvc command. The following show commands are used to gather this information: "show ip arp", "show cdp neighbors detail", and "show ip interface brief". This wizard is now entitled: "Collect Frame Relay/ATM PVC Information".

6. The "Run Service Management Collection and Web Reports" wizard was modified to allow you to collect MIB performance data, Cisco router types, Frame Relay, ATM, and/or IP unnumbered information, in addition to Cisco router configuration files from the routers you specify, prior to generating (using the latest configuration information collected) the Web based reports you specify.

7. The "Collect/Import Cisco Configurations" wizard was modified to allow you to collect Cisco router types, Frame Relay, ATM, and/or IP unnumbered information, in addition to Cisco router configuration files from the routers you specify.

8. The "Administer Password Database" wizard was modified allowing you to specify the enable mode level. Valid level values range from 0 through 15.

9. The "Create a Tar File From Baselines" wizard allows you to copy the contents of one or more baselines, to a new tar file in the directory you specify. You can then retrieve the information contained in this tar file by invoking the "Administer/Untar Baseline Data" wizard (described below). As baseline logs and reports directories can be very large, you have the choice of not including them (this is the default) on the tar file.

10. The "Administer/Untar Baseline Data" wizard provides the following options:

(a) retrieve the baseline data that was created by the "Create a Tar File From Baselines" wizard.

(b) copy a baseline's Device Password Database, or copy Repository data from one baseline to an existing baseline, or delete Repository data from a baseline.

You can copy all or a subset of the following types of information:

(a) configuration files

(b) observed BGP tables

(c) Frame Relay/ATM PVCs

(d) Cisco router types

(e) traffic data files

(f) MIB data files

(g) observed IP/IPX routing tables

11. A Reschedule button was added to the Scheduler window allowing you to reschedule an expired or yet-to-be run wizard. You select an entry in the Current Schedule pane pertaining to the task you want to reschedule, then you click on the Reschedule button.

12. An Active/Inactive button was added to the Scheduler window allowing you to change the state of an active wizard (currently scheduled) to inactive, or the state of an inactive wizard (currently not scheduled) to active. You must select an entry in the Current Schedule pane pertaining to the task you want to activate/deactivate prior to clicking on the Active/Inactive button.

13. The "Collect Performance MIB Data" wizard was modified allowing you to specify a description to be used for the collected Performance MIB data.

14. Upon completion of the "Collect Performance MIB Data" wizard, detailed information about the MIB data collection process is made available to you through the Details button in the
Data - Performance MIB Data window. This window is displayed when you click on the Data button in the Cisco Netsys window and you then select the "Performance MIB Data" tab in the Data - Summary window.

The following new columns are displayed in the Data - Performance MIB Data window:

(a) # Routers - the total number of routers whose Performance MIB data sets you collected through the "Collect Performance MIB Data" wizard, is displayed in this column.

(b) # Failed - the total number of routers where collection errors occurred while collecting Performance MIB data through the "Collect Performance MIB Data" wizard, is displayed in this column.

(c) Packets - the average number of packets sent and received by all router interfaces during the Performance MIB data collection is displayed in this column.

(d) Kbytes - the average number of kilobytes of data sent and received by all router interfaces during the Performance MIB data collection is displayed in this column.

Java Reports

This subsection describes the new feature allowing you to create Java formatted reports.

1. You can now choose to generate the Web reports in Java or HTML format through the Wizard Manager's "Run Web Reports" wizards. In many cases, Java formatted reports can represent a sixty percent or greater savings in disk space over HTML formatted reports.

2. You can filter, suppress, and sort the information displayed in the Java formatted reports.

3. The Save/Print button in the Java Report window converts the report to the selected format (ASCII text, HTML, and CSV (Comma Separated Values) and places the results in a new Web browser window. You can then print from the Web browser window or use the Web browser's Save As feature to save the report.

4. You have the option of saving Java reports in CSV format, making it possible for you to import the reports into various spreadsheet programs.

5. When saving text or CSV formatted reports from a 3.0 or 4.0 Netscape Navigator browser, you must change the "Format for Saved Document:" in the Netscape Save As window from Source to Text. You should leave it set to Source for saving HTML formatted reports.

Integrity Checks

This subsection describes the ATMUndefined Map-List integrity check added in this release. See "Appendix A - Baseline Integrity Checks" in the 4.0 Netsys Connectivity Service Manager General Reference Guide for detailed information about the integrity checks performed by the Cisco NSM software.

The interface configuration command "map-group <name>" associates a map-list with the interface (or sub-interface). The map-list, where a protocol and address is associated with an ATM PVC, should be defined using the global configuration command "map-list <name>". When the map-list is not defined, this high-severity warning is issued.

Cisco IOS Commands Modeled

This subsection describes the new "ip split-horizon eigrp <as#>" Cisco IOS command currently modeled. See "Appendix A - Cisco IOS Commands Modeled" in the 4.0 Netsys Connectivity Service Manager Analysis Reference Guide for detailed information about the Cisco IOS commands modeled by the Cisco NSM software.

The "ip split-horizon eigrp <as#>" interface configuration command is used to enable/disable EIGRP split horizon functionality. By default, split-horizon is enabled for all interface types for EIGRP.

Cisco Router Attributes Supported

This subsection describes the new Cisco router attributes currently supported. You can modify the supported router attributes and then invoke "what-if" analysis. See the 4.0 Netsys Connectivity Service Manager Analysis Reference Guide for detailed information obtaining access to the router attributes.

Router Interface Window

A Disable EIGRP Split Horizon button has been added to the Router Interface window. You click on this button to specify the EIGRP Autonomous System ID, where the EIGRP split horizon feature is to be disabled. By default, split-horizon is enabled for all interface types for EIGRP.

IP Access List Window

1. This window has been reformatted. The source and destination operator and port information is now displayed in a column entitled Elements - Src Op/Port and Elements - Dest Op/Port, respectively.

2. A new column entitled Elements - Connection has also been added to this window. established is displayed in this column to indicate an established TCP connection. Otherwise, this column is blank.

Policies

This subsection describes the Static IP Hosts implicit policy added in this release. See Section 2.2 "Policy Sets Window," in the 4.0 Netsys Connectivity Service Manager Analysis Reference Guide for detailed information about policy sets.

The Static IP Hosts implicit policy identifies whether the router can connect to each of the host addresses specified with the "ip host <host-name> <ip_address>" commands specified in the router's configuration file. The results of the connectivity analysis are displayed in the Policies Analysis window. When IP connectivity does not exist, diagnostic reports are provided to help you identify the cause of the problem(s).

Additional getconfig Options

This subsection describes the $ECSP_HOME/bin/getconfig related enhancements. See "Appendix C" in the 4.0 Netsys Connectivity Service Manager General Reference Guide for detailed information about the getconfig command.

1. Support for the "-l <enable_level>" option was added. This option allows you to specify the level of the enable mode to be used. Valid values range from 0 through 15.

2. Support for the "-outdir <dir_name>" option was added. This option allows you to specify the name of the directory where the contents of the retrieved configuration file are stored. When this option is not specified, the contents of the retrieved configuration file are saved in the directory where you invoked this script.

Baseline Data Repository

This subsection describes the baseline Data Repository (hereafter referred to as the Repository) added in the Cisco NSM 4.0 release and the new options added to the File menu's Save Copy As option in the Cisco NSM 4.1 release.

Overview

The baseline Repository is a data storage area for information associated with a Cisco NSM baseline. It is located in the $ECSP_DATA directory. The Repository consists of a set of baseline folders. Each baseline is associated with a single Repository folder. A Repository folder may be associated with more than one baseline.

Repository Contents

The Repository contains the following types of information:

• device password database

• device type data

• observed routing tables

• network Performance data

• observed BGP table

• Frame Relay/ATM PVCs

• traffic data

• MIB data

• serial interfaces

• router configuration files

Repository and New Baselines

When you select the File menu's New Baseline option in the Cisco Netsys window, a new Repository folder is created. This folder is assigned the name of the new baseline.

Repository and Saving Baselines

When you select the File menu's Save Copy As option in the Cisco Netsys window, the Save Baseline window is displayed. You are provided three options for creating a copy of the baseline. They are:

1. "Share data with current baseline" - Create a new copy of the baseline, with the resulting baseline sharing a common Repository folder with the originating baseline. In this case, changes made to the Repository folder through either of the baselines, affects both baselines (for example, changing/deleting password entries, collecting new observed routing tables, and collecting new performance data.)

2. "Copy data from current baseline" - Create a new copy of the baseline with a new Repository folder, and include a copy of all existing Repository information into the new Repository folder. Note, this includes all performance data, and may result in disk space concerns.

3. "Do not copy data from current baseline" - Create a new copy of the baseline with a new Repository folder (that is, leave the new Repository folder empty.)

Repository and Copying Performance Data

You select the Wizard Manager's "Administer/Untar Baseline Data" wizard to copy performance data between Repository folders.

Repository and Changing the Folder Assignment

You click on the Change Network Folder button in the Data - Summary window to specify an alternative Repository folder an existing baseline points to. The alternative Repository folder must already exist.

Repository and Deleting Baselines

When you select the File menu's Delete Baseline option in the Cisco Netsys window to delete a baseline, it is not known whether the associated Repository folder is shared with another baseline. Therefore, the Repository folder is not deleted. Manually deleting a Repository folder is not recommended.

Note, the Repository folder may consume significant disk space in one of two cases:

1. The baseline has been used to collect significant volumes of network performance data.

2. A significant volume of observed BGP routing tables have been collected.

When either of these conditions apply, and you need to delete the associated baseline, we recommend you delete the collected performance data and/or observed routing tables (using the "Administer/Untar Baseline Data" wizard) prior to selecting the File menu's Delete Baseline option.

Note, the remaining Repository folder prevents you from creating a new baseline with the name of a baseline you previously deleted.

Repository and Moving a Baseline Directory Within a Single File System

Each baseline contains an absolute directory reference to allow it to find the associated Repository folder. No other baseline administration steps are required.

Repository and Moving an Entire $ECSP_DATA Directory

When you move the directory pointed to by the $ECSP_DATA environment variable, the pointer to the Repository folder may be rendered invalid. Therefore, the baseline cannot be opened. In this situation, you may need to manually update the pointer to the appropriate Repository folder.

The $ECSP_DATA/<baseline>/default.ddf text file includes a full directory reference to the Repository, and the baseline's Repository folder. You should only modify the directory reference on the first line of this file. Following is a sample default.ddf file showing the baseline Repository folder twolabs and the Repository directory /users/netsys/netsys_data/.dataroot:

(repository-info /users/netsys/netsys_data/.dataroot Repository twolabs
Domain)
    (data-definition-file 1 "default data definition file created from panel
by user" loadOnOpen=false)
    (mib-datasets latest)
    (traffic-sets none useFilterInfo=false useLoadOptions=false)
    (load-options applyOptions=true skipUnmapped=false removeEncap=true
collapseToNetwork=true collapseToNetworkLayer=false collapseIntraLAN=false
skipIntraLAN=false fixPacketSize=true skipInfo=(useBothDirs bytes 1)
harmonizeInfo=(level1 0 0 false) timeAdjustInfo=(false 0))

General Functionality

This subsection describes the remainder of the Cisco NSM 4.1 enhancements.

1. The Query and Suppression mechanisms in the Integrity Checks report now allow you to match on a text string found in the Integrity Check Report window's Detail pane. For example, when you want to suppress all integrity check problem entries that contain a 193.31.7.16 IP address in the Detail pane, you first click on the Suppress button in the Integrity Check Report window. You then click on the D6 button in the Integrity Check Report Suppressions window's Add Suppression pane, specify "*193.31.7.16*" in the Detail text field, and then click on the Add button. All integrity check problem entries containing 193.31.7.16 in the Detail pane, are no longer displayed in the Integrity Check Report window. See "Chapter 8" in the 4.0 Netsys Connectivity Service Manager General Reference Guide for detailed information about the Query and Suppression mechanisms.

2. A Use Observed Routing Tables for Pathing button has been added to the Advanced Options window (displayed when you click on the Advanced Options button in the Open Baseline window). Selecting this option informs the Cisco NSM software to use the IP/IPX/BGP routing tables, collected through the Wizard Manager's "Collect IP/IPX/BGP Routing Tables" wizards, when simulating the routing of packets through the network. Otherwise, the simulation is only based on the information contained in the baseline router configuration files. By default, this option is turned off.

3. Cisco NSM determines traffic pathing based on the IPX network addresses in the calculated IPX routing tables. In order to map Novell server traffic, it is necessary to translate the internal IPX server addresses (found in traffic data sets) into a LAN address recognized by the Cisco NSM model. To accomplish this, you must create and populate an $ECSP_HOME/ipx_mapping file with the server address of each Novell server (its internal address) and its Novell network address (its external address). A template ipx_mapping file, describing the required format of this IPX mapping file, is provided for you in the $ECSP_HOME/resources/datamgmt directory. The format of the ipx_mapping file is as follows:

/ IPX Server Addresses
/ internal external
  a5c34b01 a5c34b00
  a5c30401 a5c30400

Documentation

This section provides information on viewing the Cisco NSM on-line documentation, using the Help feature, and the problems known to exist with the Cisco NSM 4.x documentation.

Viewing On-line Documentation

The Cisco NSM documentation included on the 4.2/4.3 CD-ROM is provided in PostScript, PDF (Portable Document Format), and HTML formats. You can view the PostScript version of the Cisco NSM 4.x documentation with the pageview or imagetool commands. You can view the PDF version of the Cisco NSM 4.x documentation with the Adobe® Acrobat® Reader 3.0 program. You can view the modified Cisco NSM 4.x HTML documentation with a 3.<x> or 4.<x> Netscape Navigator or 4.<x> Microsoft Internet Explorer browser.

You can obtain the Adobe Acrobat Reader from Adobe's Web site: http://www.adobe.com.

You can obtain the Netscape browser as follows:

• by anonymous ftp from ftp.netscape.com

• from Netscape's Web site: http://www.netscape.com

HTML formatted documentation pertaining to the MC3810- and VPDN-related configuration windows is provided in the $ECSP_HOME/help/analysis_Conn/3810.html and $ECSP_HOME/help/analysis_Conn/vpdn.html files, respectively.

PDF formatted documentation pertaining to the MC3810- and VPDN-related configuration windows is provided in the $ECSP_HOME/doc/analysis_Conn/3810.pdf and $ECSP_HOME/doc/analysis_Conn/vpdn.pdf files, respectively.

PostScript formatted documentation pertaining to the MC3810- and VPDN-related configuration windows is provided in the $ECSP_HOME/doc/analysis_Conn/3810.ps and $ECSP_HOME/doc/analysis_Conn/vpdn.ps files, respectively.

HTML, PDF, and PostScript Documentation

The modified HTML versions of the 4.x documentation are installed in subdirectories under the $ECSP_HOME/help directory. The 4.x PostScript and PDF versions are installed in subdirectories under the $ECSP_HOME/doc directory.

To view the on-line documentation with an HTML browser, we recommend you first open the $ECSP_HOME/help/books_list.html file. You click on a specific entry in this file to obtain access to that book's Table of Contents (TOC.html) file.

• 4.0 Netsys Connectivity Service Manager General Reference Guide - installed in the reference_Conn subdirectory

• 4.0 Netsys Connectivity Service Manager Analysis Reference Guide - installed in the analysis_Conn subdirectory

• 4.1 Netsys Connectivity Service Manager User's Guide - installed in the user_Conn subdirectory

• 4.0 Netsys Scheduling and Web Reports Guide - installed in the reports_reference subdirectory.

• 4.0 Netsys Performance Service Manager Reference Guide - installed in the reference_Perf subdirectory.

• 4.0 Netsys Performance Service Manager User's Guide - installed in the user_Perf subdirectory.

Using the Help Feature

The HELP buttons located in the product's windows are linked to the 4.0 Cisco NSM Reference Guides. The Cisco NSM on-line Help system requires one of the previously mentioned HTML browsers for viewing.

You can specify/change the path to the HTML browser you wish to use for Help by setting the ECSP_HELPVIEWER environment variable. For example, in a C shell environment, when you wish to use the Netscape Navigator HTML browser, set the ECSP_HELPVIEWER environment variable at the command line prompt as follows:

host% setenv ECSP_HELPVIEWER /usr/local/bin/netscape

Documentation and Help Issues

1. The collection of traffic data from Bay Networks hubs was supported in the Cisco NSM 4.0 release. The Cisco NSM 4.1/4.2/4.3 releases no longer provides this functionality.

2. All references to "Frontier" have changed to "NetScout" within the Cisco NSM 4.1/4.2/4.3 releases. However, the Cisco NSM 4.0 documentation does not reflect this name change.

3. The concept of a baseline Data Repository was added to the Cisco NSM 4.0 release, however, it was not adequately documented. See the "Baseline Data Repository" section for a detailed description of this feature.

4. Information on how you manage router types using Cisco NSM is lacking in the Cisco NSM 4.0 documentation. Cisco NSM collects router type information from your network through the Wizard Manager's "Collect Device-Related Data from MIBs" collection wizard and saves it to a router types dataset file in the baseline Data Repository (hereafter referred to as Repository). A separate master router types file named data.router_types exists in the baseline directory. This file can be edited by clicking on the Routers with Observed Types button in the Data-Summary window.

When you open a baseline, Cisco NSM checks to see whether router type information exists in the Repository and whether it is more recent than the master data.router_types file. When this is the case, Cisco NSM merges the contents of the Repository's router type information with the master data.router_types file in the following manner:

(a) When a particular router has an entry in both the Repository and the master file, the Repository entry overwrites the master file entry.

(b) When a router has an entry in the Repository but not in the master file, the Repository entry is added to the master file.

(c) When a router has an entry in the master file but not in the Repository, the master file entry is retained.

The resulting data.router_types file becomes the new master data.router_types file. A backup copy of the previous master is saved in the baseline directory as data.router_types.bak.

Router type information collected from the router and stored into the Repository ends up in the master file as a "data-router-type" record with the following format (see the actual file for more details):

data-router-type,netsys1,cisco7000,7000

Each time a collection occurs and the baseline is reopened, this record is merged with the new observed value from the Repository (according to the merge procedure described above.)

With Cisco NSM 4.1/4.2/4.3, you can now specify "user-asserted" values that will always override the observed values. This is done by creating a "data-router-type-user" record in the master file in the following format:

data-router-type-user,netsys1,ciscoRSP7000,7000

In this example, the netsys1 router is treated as a Cisco 7200 and any future collection will not override this setting. The order of these two types of entries in the master file is not important, the user-asserted value always take precedence.

5. Information on how you import Catalyst Database information into the Cisco NSM is lacking in the Cisco NSM 4.0 documentation. Catalyst switch information is imported from the VLANDirector (only versions 1.3 and 1.3.1 are supported) database and must be saved to a file you place in the $ECSP_DATA/<baseline-name> directory. Following are the steps you must follow to accomplish this task:

(a) Invoke the Wizard Manager's "Administer Password Database" wizard and add the VLANDirector host and user information to the Device Password Database.

(b) Invoke the Wizard Manager's "Collect Catalyst Database" wizard, making certain the full path to the Catalyst Database is used when it is anything other than the default (that is, /opt/CSCOvlan).

(c) Load the Catalyst switch information into a baseline. To do this, you must:

* Select the File menu's Open Baseline option in the Cisco Netsys window.

* Select a baseline and then click on the Routers button in the Open Baseline window.

* Click on the Add button in the Routers window.

* Specify the directory pointed to by the $ECSP_TMPDIR environment variable in the
   "Go to:" text field in the New Router window, select the file with the database name,    then click on the OK button. View the "Collect Catalyst Database" wizard's standard out    log file for the exact directory and file names.

6. Information on how you create and import unsupported Layer 2/SNMP MIB2 data sets into the Netsys Performance Service Manager is lacking in the Cisco NSM 4.0 documentation. For the Netsys Performance Service Manager to use this data for performance report generation and performance analysis, you must create an ASCII file with a .mdf suffix appended to the file's name and convert the unsupported Layer 2/SNMP MIB2 data into the format supported by the Netsys Performance Service Manager. Following are the components of a sample .mdf file showing the required format of the Layer 2/SNMP MIB2 data. All records shown in the sample .mdf file require all fields to be specified as indicated below. You must not omit any field.

General Information:

# Typically the data in the file is in sets. You will typically have one
# "type-xxx" line followed by one or more "data-xxx" lines. The "type-xxx"
# lines help understand the fields in the "data-xxx" lines.
type-snmp-stats,type,interval_info,contained_types, version
data-snmp-stats,interval,["25 Nov 97 17:34:00" "25 Nov 97 17:35:00"], [
buffers mib2-ifstats cisco-ifstats cpu],1.0
 
# The above two lines are global to an mdf file. The type line indicates that
# the fields in the data line are,
#   type             Internal usage. Use the value "interval".
#   interval_info    Data capture time interval. Consists of start and end
#                    time. Use the format in the example above.
#   contained_types  Types of data contained in the mib stats.
#                    In prior releases, the user had to choose the various
#                    types of mib stats collected. Nowadays, all four
#                    types are collected. So the value of the field should
#                    always be as shown in the example above.
#   version          version #. Keep it 1.0

Buffer Stats:

# The next two lines provide Buffer stats. The field names match the names
# defined in the MIB and should be pretty self explanatory. All values are
# comma separated.
type-router-buffers,router_name,bufferFail,bufferNoMem,bufferSmallHits,buffe
rSmallMisses,bufferMediumHits,bufferMediumMisses,bufferBigHits,bufferBigMiss
es,bufferLargeHits,bufferLargeMisses,bufferHugeHits,bufferHugeMisses,bufferS
mallTrims,bufferSmallCreates,bufferMediumTrims,bufferMediumCreates,bufferBig
Trims,bufferBigCreates,bufferLargeTrims,bufferLargeCreates,bufferHugeTrims,b
ufferHugeCreates,
data-router-buffers,andale,0,0,590,0,280,0,51,0,0,0,194,0,0,0,0,0,0,0,0,0,0,0,

MIB2 Stats:

# The next set of lines contain MIB2 stats. They are organized as one line per
# interface, for each interface of the router. You can group data lines for
# all interfaces of all routers for which you have the mib stats. These fields
# are what is defined in the standard portion of MIB2. Each interface is
# identified by its IP address.
type-mib2-ifstats,router_name,interface_id,ifIndex,ifInOctets,ifInUcastPkts,
ifInNUcastPkts,ifInErrors,ifOutOctets,ifOutUcastPkts,ifOutNUcastPkts,ifOutEr
rors,
data-mib2-ifstats,andale,192.168.114.239,1,65294,199,176,0,1831,22,0,0,
data-mib2-ifstats,andale,40.128.16.52,2,6254,5,24,0,111822,247,3,0,
data-mib2-ifstats,andale,192.168.132.5,3,1546,5,4,0,1561,19,0,0,

Interface Stats:

# The following set of lines contain detailed interface stats from the Cisco
# enterprise portion of mib2. Data is again organized as the standard MIB2
# stats, that is, one data line per interface of a router. Each interface is
# identified by its IP address.
 
type-cisco-ifstats,router_name,interface_id,locIfInBitsSec,locIfInPktsSec,lo
cIfOutBitsSec,locIfOutPktsSec,locIfInputQueueDrops,locIfOutputQueueDrops,loc
IfIgnored,locIfSlowInPkts,locIfSlowOutPkts,locIfSlowInOctets,locIfSlowOutOct
ets,locIfFastInPkts,locIfFastOutPkts,locIfFastInOctets,locIfFastOutOctets,lo
cIfotherInPkts,locIfotherOutPkts,locIfotherInOctets,locIfotherOutOctets,locI
fipInPkts,locIfipOutPkts,locIfipInOctets,locIfipOutOctets,locIfdecnetInPkts,
locIfdecnetOutPkts,locIfdecnetInOctets,locIfdecnetOutOctets,locIfxnsInPkts,l
ocIfxnsOutPkts,locIfxnsInOctets,locIfxnsOutOctets,locIfclnsInPkts,locIfclnsO
utPkts,locIfclnsInOctets,locIfclnsOutOctets,locIfappletalkInPkts,locIfapplet
alkOutPkts,locIfappletalkInOctets,locIfappletalkOutOctets,locIfnovellInPkts,
locIfnovellOutPkts,locIfnovellInOctets,locIfnovellOutOctets,locIfapolloInPkt
s,locIfapolloOutPkts,locIfapolloInOctets,locIfapolloOutOctets,locIfvinesInPk
ts,locIfvinesOutPkts,locIfvinesInOctets,locIfvinesOutOctets,locIfbridgedInPk
ts,locIfbridgedOutPkts,locIfbridgedInOctets,locIfbridgedOutOctets,locIfsrbIn
Pkts,locIfsrbOutPkts,locIfsrbInOctets,locIfsrbOutOctets,locIfchaosInPkts,loc
IfchaosOutPkts,locIfchaosInOctets,locIfchaosOutOctets,locIfpupInPkts,locIfpu
pOutPkts,locIfpupInOctets,locIfpupOutOctets,locIfmopInPkts,locIfmopOutPkts,l
ocIfmopInOctets,locIfmopOutOctets,locIflanmanInPkts,locIflanmanOutPkts,locIf
lanmanInOctets,locIflanmanOutOctets,locIfstunInPkts,locIfstunOutPkts,locIfst
unInOctets,locIfstunOutOctets,locIfspanInPkts,locIfspanOutPkts,locIfspanInOc
tets,locIfspanOutOctets,locIfarpInPkts,locIfarpOutPkts,locIfarpInOctets,locI
farpOutOctets,locIfprobeInPkts,locIfprobeOutPkts,locIfprobeInOctets,
data-cisco-ifstats,andale,192.168.114.239,0,0,0,0,0,0,0,375,19,65294,1561,0,
3,0,270,12,5,720,300,347,16,61205,1232,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
,0,0,0,0,0,0,0,0,0,0,
data-cisco-ifstats,andale,40.128.16.52,4294966296,0,1000,0,0,0,0,29,249,6254
,110307,0,0,0,0,0,5,0,300,18,203,4124,49134,0,0,0,0,0,0,0,0,0,40,0,60560,0,0
,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
data-cisco-ifstats,andale,192.168.132.5,0,0,0,0,0,0,0,9,18,1546,1487,0,0,0,0
,0,5,0,300,0,12,0,888,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
data-cisco-ifstats,andale,192.168.133.65,0,0,0,0,0,0,0,0,5,0,300,0,0,0,0,0,5
,0,300,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,

CPU Stats:

# The next two lines provide the CPU stats for the router.
# It provides the CPU utilization for current, average over last 1 minute and
# average over last 5 minutes.
 
type-cpu,router_name,busyPer,avgBusy1,avgBusy5,
data-cpu,andale,0,0,0,
 

Once you create the Layer 2/SNMP MIB2 data file(s), you must make them available to the Netsys Performance Service Manager. Following are the steps you must follow to accomplish this:

(a) When it does not already exist, create the $ECSP_DATA/<baseline-name>/datasets directory.

(b) Copy the Layer 2/SNMP MIB2 data files (*.mdf) to the $ECSP_DATA/<baseline-name>/datasets directory.

(c) Re-open the baseline (<baseline-name>). The Layer 2/SNMP MIB2 data is imported into the Netsys Performance Service Manager.

7. Information on how you import user created traffic data sets into the Netsys Performance Service Manager is lacking in the Cisco NSM 4.0 documentation. Following are the steps you must follow to accomplish this:

(a) Convert the traffic data to the format supported by Cisco NSM. See "Chapter 3 - Section 3.1.7" in the Netsys Performance Service Manager Reference Guide for a description of the supported format. The traffic data must reside in an ASCII file with a .tdf suffix in the file's name.

(b) When it does not already exist, create the $ECSP_DATA/<baseline-name>/datasets directory.

(c) Copy the traffic data files (*.tdf) to the $ECSP_DATA/<baseline-name>/datasets directory.

(d) Re-open the baseline (<baseline-name>). The traffic data is imported into the Netsys Performance Service Manager.

8. The "Collect Traffic From NetFlow" wizard instructions in the Netsys Performance Service Manager Reference Guide are rather sparse. Following are the modified instructions.

You select this wizard to collect NetFlow traffic data (representing end-to-end conversations similar to RMON2 at the Application Layer) from a NetFlow collector station (the machine on which the NetFlow collector (nfcollector) software is installed). You must have login and password capabilities for the NetFlow collector station, and the NFC_DIR environment variable must be set to the root directory of the NetFlow collector installation on that host. NetFlow data collection must be activated on a router with the data collection flow directed towards the machine where the NetFlow collector is installed and running. The NetFlow collector then saves the traffic sets at its local site. In order to collect the NetFlow data sets, you must do the following:

(a) ensure telnet access to the NetFlow collector station

(b) ensure the nfcollector program is running on the NetFlow collector station

(c) ensure the DetailHostMatrix aggregation scheme is activated on the NetFlow collector station

(d) create a login user ID on the NetFlow collector station

(e) ensure the NFC_DIR environment variable is set on the NetFlow collector station

(f) create a NetFlow host entry, using the login user ID described above, in the Device Password Database by invoking the "Administer Password Database" wizard

(g) schedule a NetFlow traffic data collection by invoking the "Collect Traffic From NetFlow" wizard.

The NetFlow collector software is not provided on the Cisco NSM CD-ROM. The nfcollector and Cisco NSM software can be installed on the same or different machines. When they are installed on different machines, the Cisco NSM software requires telnet access to the NetFlow collector station.

This wizard does not interact with the nfcollector program. It does not trigger nfcollector to start collecting traffic data sets, nor does it interface with the router. It passively observes the NetFlow traffic data sets already saved by the NetFlow collector station. When any NetFlow data sets are within the specified time interval, it transfers them to the Cisco NSM machine's NetFlow Data Repository directory.

General Information

This section provides general information and suggestions about how to use the Cisco NSM 4.2/4.3 software.

Netsys Connectivity Service Manager

1. You should not invoke the Cisco NSM software as root.

2. When you previously scheduled reports and/or collections using the 3.x version of the Scheduler process, you must kill the 3.x netsys_scheduler process prior to scheduling reports and/or collections using the Cisco NSM 4.x Scheduler. Note also, the 3.x Scheduler files are not compatible with the Cisco NSM 4.x Scheduler.

3. The ECSP_TMPDIR environment variable defaults to the $ECSP_DATA/tmp directory. We strongly recommend you do not set the ECSP_TMPDIR environment variable to point to the /tmp directory so as to avoid losing all of the files saved to this directory when your machine is rebooted.

4. When you use the Scheduler, your baseline directories and the directory defined by the ECSP_TMPDIR environment variable must be accessible by the same path on every machine you run the Cisco NSM software.

5. The ExplainAll analysis (invoked from the Policies Analysis window), only pertains to No Route, Routing Loop, and Access List problems. All other violations are not currently analyzed.

6. When you plan on running the Netscape browser while using the Cisco NSM 4.x software, we recommend you create an alias to start the netscape process with the -install option to avoid running into potential color map problems. You can also start the Cisco NSM 4.x software using the -install option with the ctk command. A drawback to these options is that on some machines, color map flashing occurs when moving the cursor over other windows.

7. To ensure the various reports created by the Netsys Connectivity Service Manager are up-to-date and contain the latest information, we strongly recommend you click on the Connectivity button in the Cisco Netsys window's Analysis pane once you modify network element attributes.

8. When opening a baseline you created using a previous version of the Netsys Connectivity Service Manager, existing layouts are not discarded. There is a chance the topology is more complete than it was in previous versions, therefore, all new devices, WAN clouds, and campuses are laid out along the bottom of the Topology View windows, where they can be repositioned, when desired. Note that new devices and campuses can also result from a modification to a configuration file.

When you want the Netsys Connectivity Service Manager to discard the current layout and recreate the topology from the configuration files, you must use the Topology View window's Options menu's Recalculate Layout option.

9. The Wizard Manager's "Create WAN/LAN Subnet" wizard is not the same as the "Add Serial Link" option accessible from the router icon in the Topology View window. Whereas the "Add Serial Link" option is used to fill in missing information with regards to a known, existing subnet and can be persistently saved, the "Create WAN/LAN Subnet" wizard is used as a "what-if" scheme resulting in the creation of hypothetical IP interfaces on different routers, with new IP addresses for a new subnet and can not be persistently saved or managed.

10. When you modify a router configuration file using the Netsys Connectivity Service Manager's configuration editor (for example, vi or emacs), the modifications are not saved when the delta feature is invoked, as changes made through the Configuration editor are not included in the object model and therefore, are not available for export until the next time you load the baseline.

11. Configuration files in the $ECSP_DATA/<baseline_dir>/config directory are under SCCS control. Do not modify the permissions on these files, as this might cause some SCCS operations to fail. It is also important not to manually copy files into or directly modify the files in the config directory. The only safe way to modify files in the config directory is through the Configuration editor started from within the Netsys Connectivity Service Manager.

12. With the exception of SRB, RSRB, and DLSw+ bridging, bridging routers are not modeled. This may result in unnecessary integrity checks as well as a cluttered or wrong topology.

13. End-to-end Source Route Bridging connectivity policies are supported, requiring the Netsys Connectivity Service Manager to decide whether to bridge or route end-to-end connectivity policies. The following heuristic is used:

(a) For an IP or IPX connectivity policy originating at an end system, the Netsys Connectivity Service Manager looks at the directly connected routers to the source. When the routers have IP/IPX routing enabled, routing is attempted. Otherwise, bridging is attempted.

(b) IP connectivity policies originating at a router are routed, not bridged.

(c) SNA connectivity policies are bridged.

14. For bridged connectivity policies, it is assumed that spanning, as opposed to all-rings, Explorer packets are used.

15. IP redirect is not modeled.

16. Tunneling simulation is supported in a limited fashion.

17. As the Netsys Connectivity Service Manager can not recognize a host's default router setting, it attempts to determine the host's next hop by evaluating routers linked to the segment where the host is located. In the case where none of the linked routers have a valid routing table entry for the destination, a BLOCKED or NO ROUTE status results.

Netsys Performance Service Manager

1. We strongly recommend you provide accurate router type information, either manually or through collection from the routers, in order to ensure accurate router modeling.

2. To ensure the various reports created by the Netsys Performance Service Manager are up-to-date and contain the latest information, we strongly recommend you click on the Performance button in the Cisco Netsys window's Analysis pane once you have modified network element attributes.

3. When collecting MIB data on a Frame Relay interface with multiple subinterfaces, the "MIB Interface Detail" report lists the packets for the entire Frame Relay interface under the name of the subinterface with the lowest numeric address.

4. An assumption is made that route-cache is enabled for Source-Route Bridging (SRB).

5. The effects of custom and priority queueing on end-to-end delay are not taken into consideration when simulating router performance and capacity.

6. The capacity values for LANs and links are based on actual bandwidth. By default, the configured bandwidth is used. When the router's actual bandwidth is different from the configured bandwidth, you can modify the actual bandwidth using the load interface capacity under data collection. When a change is made, you are prompted whether the change should be persistently stored when you exit the Netsys Performance Service Manager.

7. In the "Broadcast and Routing Update Overhead Report", a LAN's speed is expressed in Mbps (megabits per second), whereas for Serial links, speed is expressed in Kbps (kilobits per second).

8. The only IP header compression commands considered when analyzing efficiency and calculating utilization are ip tcp header-compression and
frame-relay ip tcp header-compression.

9. Network resource utilization calculations assume load balancing between all possible paths (this represents an average utilization) bounded by the "Max Number of Routes" setting.

10. Units in the AvgDelay column in the End-to-End Delay Report are in milliseconds.

11. IP Accounting records the number of bytes (IP header and data) and packets switched through the system on a source and destination IP address basis. Only outbound, transit IP traffic is measured; traffic generated by the router or terminating in the router is not included in the Accounting statistics.

Statistics are accurate even when IP fast switching or IP access lists are being used on the interface.

12. The "End-to-End Delay Report" does not show conversations between end points not having connectivity.

13. The 4.x Netsys Performance Service Manager interfaces with NetScout 3.2, 3.3, and 4.1.2 console software. The 3.x version of the Performance Tools only interface with NetScout 3.2 and 3.3 console software.

Netsys LAN Service Manager

1. You must have access to a CWSI (CiscoWorks for Switched Internetworking) VLanDirector program, operating on a machine running the UNIX operating system, in order to export configuration and spanning-tree information into the Netsys LAN Service Manager for topology creation.

2. It is not necessary to have VLANs to run VLANDirector.

3. The VLanDirector program can run on the same or a separate machine as the Netsys LAN Service Manager.

Known Software Problems

This section provides a list of problems known to exist with the 4.2/4.3 version of the Cisco NSM software at the time this document was written.

Netsys Connectivity Service Manager

1. At sites that have not installed Hewlett Packard's set of periodic recommended patches, a possibility exists that some of the shared libraries used by the Cisco NSM 4.2/4.3 product may be out of date. This is indicated by the observance of a number of unknown symbol errors from the Dynamic Library Loader (dld), prior to a core dump occurring. The solution is to update the C++ and C runtime libraries. You can obtain corresponding patches through HP's Electronic Support Center at http://us-support.external.hp.com. The current set of patches that fix the dld problems are PHSS_16585 and PHCO_16723. Note, however, that at any time, these patches may be superseded by subsequent patches from HP.

2. Router hostnames containing more than fifty characters cause Cisco NSM to dump core. To avoid this problem, please create router hostnames that contain fifty or less characters.

3. If the system clock, of the UNIX host that Cisco NSM is running, is set back to an earlier time, the execution of certain scheduled tasks may be skipped. To workaround this problem, you must reschedule those tasks.

4. A simulation problem exists with in-bound access lists applied to an interface. When a packet's destination is to another interface on the same router with an in-bound access list, the access list is ignored. Note, in-bound access lists for packets passing through the router work properly.

5. The "Administer/Untar Baseline Data" wizard's "Copy Baseline Repository Data From One Baseline to Another" option, does not function properly when you specify to select the data to be copied based on the time value being equal to a specific time. Instead, you must select a time using the "less than or equal to" or "greater than or equal to" logical operators.

6. Host names containing the characters listed below have those characters changed to an underscore ("_") character by the Netsys Connectivity Service Manager. This can result in duplicate hostnames and router configuration files. This then results in one of the duplicate router configuration files being dropped when the baseline is created. The characters are: "$", "'", ";", "#", "\Q", "{", "}", "[", "]", as well as the space, quote, and all control characters.

7. The Add IP/IPX/SAP/SNA Policies windows display a maximum of 4999 source and destination end systems. This limitation makes it possible for policies between some of the source and destination end systems in the topology to not be analyzed. The following workarounds are available:

(a) you can use the Topology View window's QuickPath feature to analyze connectivity when your network contains more than 4999 source and destination end systems.

(b) you can use the "Define Connection Policy" wizard to define connection policies between the unlisted LANs. This wizard allows you to select unlisted LANs but not router logical interfaces or WAN interfaces.

8. The Diagnosis buttons in the reports available through the Service Level Exceptions window are not activated until you display the "Exceptions by Policy Set" report. The Service Level Exceptions window is displayed when you double-click on the Service Level Exceptions entry in the Report Manager window.

9. When you change the location of a baseline Data Repository, all scheduled wizards for that baseline must be rescheduled.

10. When you modify baseline router configuration files through the Netsys Connectivity Service Manager's Configuration editor (for example, vi or emacs), the modifications you make are overwritten when you also have automatic router configuration file collection scheduled. The workaround is to maintain separate baselines: one working copy and one copy containing automatically updated configuration files.

11. When many open baseline operations are invoked from within the same ctk session, it is possible for the Netsys Connectivity Service Manager to run out of file descriptors. The symptoms include errors opening files, inability to write to directories, permissions problems, etc. The workaround is to exit the Netsys Connectivity Service Manager and then restart it with the ctk command.

12. When the Netsys Connectivity Service Manager routes traffic using a static route to an unknown next hop IP address, the route fails. A connectivity analysis displays a "No Route" condition. This is especially prevalent when using dial backup.

13. Both generated and ungenerated reports appear as Ready in the Report Manager window. When you modify underlying data that affects reports, the reports that have been generated have their status changed to "Out-of-date", whereas the status of the reports that were never generated continue to be shown as "Ready".

14. The Inventory report is not saved when you click on the Save button in the Report Manager window, and therefore, can not be re-loaded as a historical report. You can however, save this report with the Inventory window's Save/Print button.

15. When using the QuickSolver feature, the status "incorrect direct route" can be erroneously displayed in the Explanation Propagation window when a WAN connection is missing between the two interfaces shown in this window.

16. When using the QuickSolver feature, IPX host addresses corresponding to router ports, have "0.0000.0000.0000" displayed as their addresses.

17. When a QuickSolver analysis is performed on a path that failed because it matched a static route pointing to an unknown address, the recommended fix produced by the QuickSolver may suggest cancelling out the static address with the unknown address; however, rather than providing the address in the command, it erroneously uses the term "unknown" in the address field of the IOS command.

18. Propagation of EIGRP routes may be incorrect when a one-to-one correspondence between the primary and secondary addresses on adjacent routers running EIGRP does not exist.

19. When you edit a router configuration file from within the Netsys Connectivity Service Manager, you must specify complete interface and command names as the use of unambiguous, partial interface or command names is not supported by the Netsys Connectivity Service Manager. For example, when you want to restart a previously shut down interface, you must add the
no shutdown (as opposed to no shut) command after the shutdown command in the router configuration file.

20. The Netsys Connectivity Service Manager applies case sensitivity to AppleTalk zones. While this is not a problem for Cisco routers, it can be a problem for other routers supporting AppleTalk.

21. OSPF virtual links are not supported in this release.

22. When the Window Manager appears to lock up, press Esc (Escape).

23. When the red interface labels or round trip paths are displayed in the Topology View window, object selection can be difficult. The workarounds are to turn off the displaying of the interface labels by clicking in the Topology View window's background, and to turn off the displaying of round trip paths by deselecting the Round Trip Path button in the Topology Manager window, prior to selecting an object.

24. The simulator does not handle indirect source route bridging (that is, bridging from one virtual ring group to another by having two token ring ports on the same router go to the same token ring).

25. When the "DLSw Peer On Demand" policy file set is analyzed, a promiscuous relation between DLSw pairs is erroneously reported as having an OK status, rather than a PROMISCUOUS status.

26. When a static route exists to a dangling serial link and a link is added to this interface, you must click on the Connectivity button in the Cisco Netsys window's Analysis pane for the static route to appear in the routing table.

27. When the destination address in the Policies Analysis window is empty, it represents the pseudo-network (0.0.0.0), generated for example, by the RIP protocol.

28. Analysis uses tick count as the IPX RIP metric on all routers unless the router's configuration file contains a version command with an IOS version number less than 9.21, in which case hop count is used as the metric. This is correct behavior for IOS 9.21+; however for IOS versions less than 9.21, when a version command is not present, tick count is erroneously used as the IPX RIP metric. The workaround is to make sure you include the version command for any router running an IOS version less than 9.21.

In actual routers, the "ipx delay interface" command, when present, is used to calculate tick count. When this command is not present, the delay metric associated with that interface is used instead. In all cases, the Netsys Connectivity Service Manager uses the delay metric associated with that interface to calculate tick count.

29. Entries in an IPX routing table generated by the Netsys Connectivity Service Manager differ from those in an actual router running IOS 9.21+. Consider the entry: R 8a [1/7] Ethernet4 netsys3. In the table generated by the Netsys Connectivity Service Manager, [1/7] represents [RIP or directly connected route/hop count or tick count], where RIP=1, directly connected=0. In an actual router, [1/7] represents [tick count/hop count]. See the previous issue for additional information.

30. In analysis for RIP, IGRP, and EIGRP, a redistributed static route that is summarized can get back to its source. This differs from actual router behavior.

Netsys Performance Service Manager

1. The "Network Performance Summary" and "Traffic Summary" reports are not saved when you click on the Save button in the Report Manager window, and therefore, can not be re-loaded as historical reports. You can save these reports with the Save/Print button in the Report windows. As a workaround, you can generate the "Network Performance Summary Report" from the Scheduler. The report is named: "Network Summary Report for Default Data Definition" and you can view it through the Historical Report entry in the Report Manager window or with a Netscape browser.

2. Do not request connectivity analysis on SNA traffic from the "End-to-End Delay" or "End-to-End Conversation" reports. The workaround is to create the connectivity policies directly within the Netsys Connectivity Service Manager.

3. Values greater than 2^32 cannot be entered into text fields in the Wizard Manager's "Create Traffic" and "Edit Traffic" wizards.

4. When the path defined by the NSHOME environment variable is longer than 64 characters, the Netsys Performance Service Manager can not access the NetScout probes. The workaround is to create a symbolic link, which must be less than 64 characters in length, to the NSHOME directory and then set the NSHOME environment variable to that symbolic link. For example, in the default case where the NetScout executables are installed in the ECSP_HOME tree, NSHOME is set to:

$ECSP_HOME/resources/datamgmt/netscout

When the ECSP_HOME environment variable is set to:

/export/home/apps/this_is_a_very_long_name/netsys

the path the NSHOME environment variable defines is longer than 64 characters. You must create a symbolic link to this directory and then set the NSHOME environment variable to that directory. For example, in C Shell:

host% ln -s $ECSP_HOME/resources/datamgmt/netscout /tmp/netscout
host% setenv NSHOME /tmp/netscout

Obtaining Help

If you experience problems installing or using the 4.2/4.3 Cisco NSM software or obtaining or installing the required license, please call Cisco Systems at 1-800-553-2447 or send email to tac@cisco.com.

Cisco Connection Online

Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.

Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.

CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.

You can access CCO in the following ways:

• WWW:  http://www.cisco.com

• WWW:  http://www-europe.cisco.com

• WWW:  http://www-china.cisco.com

• Telnet:  cco.cisco.com

• Modem:  From North America, 408 526-8070; from Europe, 33 1 64 46 40 82. Use the following terminal settings: VT100 emulation; databits: 8; parity: none; stop bits: 1; and connection rates up to 28.8 kbps.

For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.

Documentation CD-ROM

Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.

If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.

Posted: Fri Sep 24 11:16:38 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.