DCD Design Note 1.12 <P> <b> NSA- A Network Statistics Analyzer </b>

DCD Design Note 1.12

NSA- A Network Statistics Analyzer

JACK C. SCHMIDT

.5cm

NSA is a software package that allows the user to monitor server, bridge, and node status at Fermilab.

Overview

NSA will replace the currently used NETSTAT network status monitoring program. In an effort to be more flexible, NSA will be written in VAX C using the screen management routines provided by Digital. This will allow the user to run the software on any Digital workstation or VT200 terminal and up. Another improvement over the NETSTAT design is that the user will be able to run NSA from any VAX onsite.

Client End

The client end of NSA provides the user with a menu-driven interface to displaying bridge, node, and terminal server information. The screen contains a title bar, menu bar, and work area. The title bar consists of the program title and is the very first line of the screen. The menubar provides the user with global choices to be made in the program and is the second line of the screen. The remaining 22 rows are considered the work area and it is here that network status information will be displayed (see Dia. 1).

The work area displays information in grids on pages. Each page contains node, bridge, or server names, a page title, and the page number in the upper right corner of the work area. The video attribute of the name reflects the current status. Normal for reachable, and bold for unreachable or error. Though no one page contains the complete list of devices available, the pages can be linked together. The `PREV SCREEN' and `NEXT SCREEN' keys will allow the user to move between pages manually. A menu item allows automatic cycling of pages with an adjustable cycle rate.

The menubar provides the user with these choices: list

[Status] On selection produces a pulldown menu with the choices: Nodes, Bridges, TServers, and Menu Exit. When one of the first three choices are selected, the corresponding status screen appears below the menubar. If Menu Exit is selected then the menu is removed with no choice being applied.

[Cycle Rate] This item controls the cycle rate of the data. On selection produces a pulldown menu with numeric times, another option to allow the user to enter their own cycle rate, and toggle/notoggle choices. The toggle options enable/disable the auto-scrolling of pages. An Menu Exit choice is provided to allow the user to leave the menu with no choice being applied.

[Print] Prompts the user for the queuename of the output device. A copy of the current screen is then routed to that output device.

[Exit] Gracefully exits the NSA program.

The Node Screen

Each node page consists of a grid of 80 nodes (Dia. 2), with a maximum of 13 pages available. The user can specify the location of node names in the grid with an initialization file- NODE_INIT.DAT. The program uses SYS$LOGIN:NODE_INIT.DAT as the default. The user may override the default by defining the logical NSA_NODE_INIT. The file allows the grouping of nodes by floor, department or any other criteria. The node records in the initialization file are of the format:

{ page_number box_number node_name

where: list [page_number] Page number of the page where status of this node should be displayed.

[box_identifier] Box identifier on the page to display node name and status. The box identifier consists of a character to signify the column and a number to signify the row. For example the first box would be A1 and the last box on a node page would be H10. [node_name] DECnet node name, up to six characters.

Each page can have a unique title associated with it. Titles are defined by adding a line to the NODE_INIT.DAT file. The line must consist of a title logical with the page number and the title of the page. Some examples are:

NODE_TITLE_1 "FNAL Cluster"

NODE_TITLE_2 "FNALD Cluster"

NODE_TITLE_3 "NUT Cluster"

More information about the node is available to the user by interrupting over the node name- either by mouse or by carriage return. A subwindow appears with more information about the node (Dia. 3). The subwindow contains the following fields:

list [Name] Name of the node selected.

[Address] Address of the node selected.

[Status] The state of node: list [Unknown] The node is having unidentified problems.

[Reachable] The node can be communicated with.

The Bridge Screen

Each bridge page consists of a grid of 20 bridges (Dia. 4), with a maximum of 13 pages available. The user can specify the location of bridge names in the grid with an initialization file- BRIDGE_INIT.DAT. This file is located in the account of the user executing the program. This file allows the grouping of bridges by floor, department or any other criteria. The bridge records in the initialization file are of the format:

page_number box_number bridge_name

where: list [page_number] Page number of the page where status of this bridge should be displayed.

[box_number] Box number on the page to display bridge name and status.

[node_name] Bridge name, up to thirty-one characters, as it appears in the DECelms database.

Each page can have a unique title associated with it. Titles are defined by adding a line to the BRIDGE_INIT.DAT file. The line must consist of a title logical with the page number and the title of the page. Some examples are:

BRIDGE_TITLE_1 "Hub Bridges"

BRIDGE_TITLE_2 "D0 Bridges"

BRIDGE_TITLE_3 "London Bridges"

More information about the bridge is available to the user by interrupting over the bridge name- either by mouse or by carriage return. A subwindow appears with more information about the bridge (Dia. 5). The subwindow contains the following fields:

list [Name] Name of the bridge selected.

[Status] The state of the bridge: list [INIT] The bridge is performing the initialization and self-test sequence.

[BROKEN] The bridge has detected an internal hardware error.

[OPERATE] The bridge is in a normal operating state.

[Broken Reason] The reason that the bridge state is BROKEN.

The Terminal Server Screen

Each terminal server page consists of a grid of 40 terminal servers (Dia. 6), with a maximum of 13 pages available. The user can specify the location of tserver names in the grid with an initialization file- TSERVER_INIT.DAT. This file is located in the account of the user executing the program. This file allows the grouping of terminal servers. The terminal server records in the initialization file are of the format:

page_number box_number tserver_name

where: list [page_number] Page number of the page where status of this tserver should be displayed.

[box_number] Box number on the page to display tserver name and status.

[node_name] Tserver name, up to 16 characters, as it appears in the TSM database.

Each page can have a unique title associated with it. Titles are defined by adding a line to the TSERVER_INIT.DAT file. The line must consist of a title logical with the page number and the title of the page. Some examples are:

TSERVER_TITLE_1 "CDF Tservers"

TSERVER_TITLE_2 "D0 Tservers"

TSERVER_TITLE_3 "RD Tservers"

More information about the tserver is available to the user by interrupting over the tserver name- either by mouse or by carriage return. A subwindow appears with more information about the tserver (Dia. 7). The subwindow contains the following fields:

list [Name] Name of the terminal server selected.

[Address] Address of the terminal server selected.

[Status] The state of the terminal server: list [Unavailable] The terminal server can not be communicated with.

[Available] The terminal server is operating properly.

Communications

Hidden deep inside the recesses of the client are routines that communicate with the server. These routines are responsible for connecting to the server, handling requests and replies to the server, and manipulating returned information into display format.

Server Side

The server must reside on a machine where DECelms and TSM are running. The server uses SNS routines to communicate with the client. The server will run independently, and can be connected to by any number of clients. The server is divided into three sections for data gathering. These section run independently and are not affected by problems with another. In other words, if the terminal server routines are experiencing problems, the server would continue to gather data about bridges and nodes. All three sections continuously gather data.

Node Information

The node information is gathered by way of direct DECnet calls. The information is stored in memory and passed to the client upon request.

Bridge Information

The bridge information is gathered by spawning a process that executes a DECelms command with the output being routed to a file. The file is then parsed by the server and is stored in memory until the client requests the information.

Terminal Server Information

The terminal server information is gathered by spawning a process that executes a TSM command with the output being routed to a file. The file is then parsed by the server and is stored in memory until the client requests the information.

Security, Privacy, Legal

rwest@fsus04.fnal.gov