Professional Documents
Culture Documents
AdministrationFundamentals
NN10470-305
Document status: Standard
Document issue: 01.02
Document date: May 2007
Product release: 16.2
Job function: Administration and Security
Type: NTP
Language type: U.S. English
NORTEL, the Nortel logo and the Globemark are trademarks of Nortel Networks.
Contents
New in this release 9
Features 9
Other changes 9
Introduction 10
Multiservice Data Manager Run Time Environment 12
Multiservice Data Manager User Environment 12
Directory structure 13
/opt/MagellanNMS/loads/ 13
Default MDM user environment skeleton files 16
/opt/MagellanNMS/system/skel/.cshrc 17
Global environment variables 19
Mandatory variables 19
Optional variables 20
Environment setup scripts 20
/opt/MagellanNMS/bin/nmscsh 21
/opt/MagellanNMS/bin/nmssh 21
User session startup scripts 21
/opt/MagellanNMS/bin/nmssession 21
/opt/MagellanNMS/bin/nmstool 21
Shared memory 56
Determining the requirements for shared memory 56
Setting the amount of shared memory in the kernel 56
Workstation surveillance 75
Threshold configuration 75
Global clear 95
Global clear tool 96
How alarms from Multiservice Switch 7400/15000/20000 are collected and
stored 96
Features
There are no feature changes in this document release 16.2.
Other changes
See these sections for changes that are not feature-related:
All references to Nortel Multiservice Data Manager technical publications
were updated with new document numbers.
Use these topics when you require additional information about the
procedures used to customize Nortel Multiservice Data Manager (MDM)
software. Customization refers to any alterations you are required to make to
tailor Nortel Multiservice Data Manager software to the specific needs of your
network.
Use the information in the sections listed below in conjunction with the
procedures located in Nortel Multiservice Data Manager Administration
(NN10470-303).
Navigation
Multiservice Data Manager Run Time Environment (page 12)
Fundamentals for configuring Multiservice Data Manager servers for
Multiservice Switch (page 25)
Disruptive Command Safeguard (page 22)
Fundamentals for configuring Multiservice Data Manager servers for
Multiservice Provider Edge (page 36)
Multiservice Switch SDD file management (page 51)
Shared memory (page 56)
Network time synchronization (page 58)
Maximum heap size (page 69)
Navigation
Multiservice Data Manager User Environment (page 12)
Directory structure (page 13)
Default MDM user environment skeleton files (page 16)
Global environment variables (page 19)
Environment setup scripts (page 20)
User session startup scripts (page 21)
For a description of the directory structure, see Directory structure (page 13).
Multiservice Data Manager software includes a set of skeleton files which you
can copy into your home directory. When copied, these skeleton files
automatically set up Multiservice Data Manager environment variables, start
a session, and open the MDM window. For a description of these files, see
Default MDM user environment skeleton files (page 16).
For some existing accounts such as root, it is not always desirable to copy the
skeleton files into the accounts home directory. An example of this is when the
root account is used to manage workstations other than those used to run
Multiservice Data Manager. Multiservice Data Manager software includes
scripts that you can run from a command line or invoke in the set-up files of
the existing account to set up the variables and start a session. For
descriptions of these scripts, see Environment setup scripts (page 20) and
User session startup scripts (page 21).
Directory structure
The subdirectory /opt contains all Nortel Multiservice Data Manager software.
Sun recommends this subdirectory for all software other than that created by
Sun Microsystems Inc.
/opt/MagellanNMS/loads/
This directory contains the installed Nortel Multiservice Data Manager
software loads. This directory can be exported as a read-only file system that
other workstations can mount by using the Network File System (NFS) to gain
access to the software.
/opt/MagellanNMS/bin
/opt/MagellanNMS/lib
/opt/MagellanNMS/system
/opt/MagellanNMS/doc
These directories are symbolic links that point to the current Multiservice Data
Manager software load. They provide access to the following subdirectories:
bin: Multiservice Data Manager executables and scripts
lib: libraries and configuration file templates. The files found in lib are the
original versions and must not be modified. Copy these files to the
/opt/MagellanNMS/cfg directory and modify the copied files. Main
subdirectories of lib are as follows:
app-defaults: multi-lingual resource files
cfg: template configuration files
macros: macros and sample source files
messages: multi-lingual message files
model/types: Network Model Schema
nrs: schema and script files for the Network Reporting System (NRS)
tsets/$LANG/toolsets/<product line>: multi-lingual toolsets menu files.
See LANG (page 19) for information on resolving the value of $LANG.
tsets/$LANG/tools/<application area>: multi-lingual Start Tool menu
files. See LANG (page 19) for information on resolving the value of
$LANG.
system: system installation and configuration files. Main subdirectories of
system are as follows:
config: scripts for the Multiservice Data Manager Software
Configuration tool
init: NMS load initialization scripts
inst: NMS load installation scripts
skel: NMS default user environment system set-up files
doc: documentation files
To use a different software load, these symbolic links are redirected to
point to the bin, lib, system, and doc directories for a different Multiservice
Data Manager software load.
/opt/MagellanNMS/ext/bin
/opt/MagellanNMS/ext/lib
These directories are local directories for second-party customization
packages for Nortel Multiservice Data Manager. These customization
packages contain software and configurations that extend Multiservice Data
Manager and its device support. Their subdirectories are similar to those
delivered by Multiservice Data Manager. Multiservice Data Manager tools and
servers recognize these directories as part of their standard search paths. For
example, the Network Model utility looks for customized schema description
files in the following order:
1 /opt/MagellanNMS/data/model/types (end-user or third-party
customization)
/opt/
MagellanNMS/ (MDM Software)
loads/ (All MDM software loads)
/opt/MagellanNMS/data/
/opt/MagellanNMS/cfg/
These two directories contain the data files and configuration files that are
specific to the workstation. These two types of files are independent of the
Nortel Multiservice Data Manager software load.
Data files contain information manipulated by Multiservice Data Manager
software such as the network models for Fault, and the Service Data
Description (SDD) files. Main subdirectories of the data directory are as
follows:
model: Network Model related files
nrs: NRS data files
nvs: Network Viewer views and background maps
svm: Server Administration log and error files
Configuration files contain information used to configure the Multiservice
Data Manager workstation and optionally includes files that override some
of the other configurations (For example, Motif resource files and macro
files). Main subdirectories of the cfg directory are as follows:
PassportSchema: Nortel Multiservice Switch SDD and related files
app-defaults: customized resource files
macros: customized macros and Multiservice Data Manager-provided
macros
private: private Multiservice Data Manager configuration files
tsets: customized toolset and tools menu files
/opt/MagellanMDP
This directory contains the executables, utilities, schemas, spool, dump and
backup files for the Management Data Provider (MDP) software. This
directory is only present when the MDP software package is installed.
$HOME/MagellanNMS/
This is a subdirectory of a UNIX users home directory which contains the
user-specific Nortel Multiservice Data Manager configuration and preferences
files.
After you copy the files into the users home directory, the files automatically
start a Multiservice Data Manager session and open a the MDM main window
when the user logs in. By default, these files provide the user with access to
the English language set of Multiservice Data Manager tools defined in file
/opt/MagellanNMS/lib/tsets/C/Full.tsets. You can select a different toolset by
setting the NMSTSETS environment variable in the user accounts set-up
files. For more information on customizing the toolsets and Start Tool menus,
see Nortel Multiservice Data Manager AdministrationTools (NN10470-300).
Not every user account needs the skeleton files listed in this section. The files
required depend on factors that include the type of shell associated with the
user account and the window manager.
/opt/MagellanNMS/system/skel/.cshrc
This file contains the startup script that sets up the shell environment and
Nortel Multiservice Data Manager environment variables for UNIX accounts
that run C-shell.See Global environment variables (page 19).
/opt/MagellanNMS/system/skel/.login
This file contains the login script for accounts that run C-shell and provides a
prompt to start up one of the installed window environments (SDK Motif,
OpenWin, or CDE), or to fall back on a plain console session, if none is
installed.
/opt/MagellanNMS/system/skel/.profile
This file contains the equivalent of the .cshrc and .login scripts combined for
accounts that run Bourne shell or Korn shell. For a description of the
environment variables that are set up in this file, see Global environment
variables (page 19).
/opt/MagellanNMS/system/skel/.Xdefaults
This file contains customized Motif resources. The initial contents of this file
provide for SDK Motif, a look and feel that is similar to release 9 NMS software.
/opt/MagellanNMS/system/skel/.mwmrc
This file defines the SDK Motif Window Manager menu, keyboard, and mouse
actions to correspond with those used in release 9 NMS.
/opt/MagellanNMS/system/skel/.modmap
This file defines X11 keyboard mappings for the user account.
/opt/MagellanNMS/system/skel/.xsession
This file contains a script that automatically
starts a Multiservice Data Manager session (runs nmssession)
opens a Multiservice Data Manager window (runs nmstool)
opens a console window on the desktop for user accounts that run the
SDK Motif Window Manager
The script also ensures that the MDM session and the main window are
removed at exit.
/opt/MagellanNMS/system/skel/.xinitrc
This file contains a script that automatically
starts a Multiservice Data Manager session (runs nmssession)
opens a Multiservice Data Manager window (runs nmstool)
pens a console window on the desktop for user accounts that run
OpenWin
The script also ensures that the session and main window are removed at exit.
/opt/MagellanNMS/system/skel/.dtprofile
This file contains a script that automatically starts a Nortel Multiservice Data
Manager session (runs nmssession) and opens a Multiservice Data Manager
window (runs nmstool) when a CDE session is started by sessionetc and
sessionexit scripts.
/opt/MagellanNMS/system/skel/.sessionetc
This file is automatically copied to directory ${HOME}/.dt/sessionetc when you
log in for the first time using CDE. This file ensures that nmssession and
nmstool are started.
/opt/MagellanNMS/system/skel/.sessionexit
This file is automatically copied to directory ${HOME}/.dt/sessionexit for a
CDE session when you log in for the first time using CDE to ensure that
nmssession and nmstool are terminated upon exit.
There are two sets of variables: mandatory variables you must set up for
Multiservice Data Manager software to perform correctly, and optional symbol
variables. The following sections describe these two sets of variables.
Mandatory variables
The following variables must be set for Nortel Multiservice Data Manager
software to operate correctly. In the skeleton files that are provided with the
software, these variables are set by file .cshrc for user accounts that use C-
shell or set-up file .profile for user accounts that use Korn or Bourne shell.
DISPLAY
DISPLAY is the name of the X-Windows display and is usually set by the login
system (XDM, DTLOGIN). If the display is not set, Multiservice Data Manager
assumes a console login and sets the DISPLAY variable to :0.0.
LANG
LANG identifies the local language (the Locale). If not set, Multiservice Data
Manager sets the value of this variable to C. This value represents traditional
UNIX and English. Other values that can be used with Solaris and with the
software are ja for Japanese and zh for Chinese.
USMSERVER
USMSERVER is used internally by some Multiservice Data Manager tools
and is set to the same value as DISPLAY.
PATH/path
PATH/path lets you invoke Multiservice Data Manager tools without specifying
the full path name when you enter the startup command. Multiservice Data
Manager appends its macros and bin directories to it
(/opt/MagellanNMS/cfg/macros/user/opt/MagellanNMS/cfg/macros/nms and
/opt/MagellanNMS/bin).
XUSERFILESEARCHPATH
This is the Motif Resource lookup path. Nortel Multiservice Data Manager
appends its resource paths to it
(/opt/MagellanNMS/cfg/app-defaults/%L/%N and
/opt/MagellanNMS/lib/app-defaults/%L/%N). For an explanation of %L and
%N, see the man pages for the X command.
CAUTION
Inability of Multiservice Data Manager tools to run
correctly
This variable must be set with at least these two paths for
Multiservice Data Manager tools to run properly.
Optional variables
The following variables are optional and are not set in the skeleton files
supplied with the default Nortel Multiservice Data Manager environment. Set
them in file .cshrc for C-shell accounts and file .profile for Bourne or Korn shell
accounts.
NMSXTERM
NMSXTERM is the path for the preferred terminal console tool that the
Multiservice Data Manager software uses whenever it needs to start a
terminal window for UNIX Access or to execute a macro. If this variable is not
set, MDM software uses dtterm for the Common Desktop Environment (CDE)
window manager, and xterm for other window managers.
NMSTSETS
NMSTSETS is the toolsets definition file which is used to open a Multiservice
Data Manager window. If this variable is not set, Multiservice Data Manager
software uses the English language toolset definition file
/opt/MagellanNMS/lib/tsets/C/Full.tsets. For a list and description of the
toolset definition filenames you can use for this variable, see Nortel
Multiservice Data Manager AdministrationTools (NN10470-300).
LPDEST
LPDEST is the name of the default printer for the user account. The values of
the LPDEST and PRINTER environment variables must be identical to ensure
the same results with BSD and SVR4 style applications.
In the skeleton files that are provided with the MDM software, these scripts are
called in file .cshrc for user accounts that use C-shell or in set-up file .profile
for user accounts that use Korn or Bourne shell.
/opt/MagellanNMS/bin/nmscsh
This script sets up environmental variables for user accounts that run C-shell.
Invoke this script from a non-default .cshrc file
(source /opt/MagellanNMS/bin/nmscsh) to establish Nortel Multiservice Data
Manager environment.
/opt/MagellanNMS/bin/nmssh
This script sets up environmental variables for user accounts that run Korn
shell or Bourne shell. Run this script from a non-default .profile file
(. /opt/MagellanNMS/bin/nmssh) to establish the Multiservice Data Manager
environment.
In the skeleton files that are provided with Multiservice Data Manager
software, these scripts are invoked in file .xsession for accounts that run the
SDK Motif Window Manager, in file .xinitrc for accounts that run OpenWin, and
in files .dtprofile, .sessionetc, and .sessionexit for accounts that run the
Common Desktop Environment (CDE).
/opt/MagellanNMS/bin/nmssession
This script starts a Nortel Multiservice Data Manager session and maintains
it and its session servers. This script must be run once per DISPLAY session
and terminated when the session is terminated.
/opt/MagellanNMS/bin/nmstool
This script opens a Nortel Multiservice Data Manager window. By default this
script starts the English language toolset Full.tsets. For the instructions to use
a different toolset, see Nortel Multiservice Data Manager Administration
Tools (NN10470-300).
For initial installation, you can use the information in this section to configure
the Disruptive Command Safeguard, or you can use the Nortel Multiservice
Data Manager Software Configuration tool, as described in Nortel
Multiservice Data Manager Installation and CommissioningSoftware
(NN10470-100).
Navigation
About the Disruptive Command Safeguard feature (page 22)
The /opt/MagellanNMS/cfg/DCS.cfg configuration file (page 23)
Checking, enabling, and disabling the Disruptive Command Safeguard
(page 24)
File format
The opt/MagellanNMS/cfg/DCS/.cfg configuration file consists of a series of
lines, each having the following syntax:
<KEYWORD> <min_length> <NCS_CAPABILITY> [<MESSAGE>]
where:
Example
Assume the /opt/MagellanNMS/cfg/DCS.cfg file contains the following line:
FORMAT 6 SWITCHING DEVICE PRIVILEGED Disk formatting
will cause instability
and the Nortel Multiservice Data Manager operator issues the following
command:
R72 2 DISK 0 FORMAT 2 1 R70 2 SEC 512 DIR 1000
If the operator has capability SWITCHING DEVICE PRIVILEGED, the
Disruptive Command Safeguard facility instructs the NCS access tool to issue
the prompt Disk formatting will cause instability, followed by confirm or cancel
instructions.
#
# Disruptive Command configuration file.
# Syntax:
# Command minimum-length NCS capability (TYPE LEVEL IMPACT) message
#
ACTIVATE 3 SWITCHING LINE CONFIGURATION
COMMIT 3 SWITCHING DEVICE CONFIGURATION
CONFIRM 4 SWITCHING DEVICE CONFIGURATION
DEREGISTER 3 NONE NONE NONE
DISABLE 7 SWITCHING DEVICE SERVICE
ERASE 5 SWITCHING DEVICE PRIVILEGED
FILTER 1 NAMS NETWORK CONFIGURATION
FORMAT 6 SWITCHING DEVICE PRIVILEGED
LOAD 4 SWITCHING DEVICE PRIVILEGED
REFUSE 6 SWITCHING LINE SERVICE
REGISTER 3 NONE NONE NONE
RELOAD 6 SWITCHING DEVICE PRIVILEGED
RESET 5 SWITCHING DEVICE CONFIGURATION
RESTART 7 SWITCHING DEVICE PRIVILEGED
STOP 4 SWITCHING LINE SERVICE
For information about servers other than those that support these basic
functions, and for references to the instructions for configuring them, see
Nortel Multiservice Data Manager AdministrationServer Management
(NN10470-310).
For the procedures relating to the information listed below, see Nortel
Multiservice Data Manager Administration (NN10470-303). Descriptions of
the administrative tools used to perform the tasks listed here are found in
Nortel Multiservice Data Manager AdministrationTools (NN10470-300).
Navigation
Servers required to support Multiservice Switch network access,
surveillance, and provisioning access (page 26)
Groups of nodes for network access (page 27)
Reasons for Multiservice Switch groups and guidelines for set up
(page 26)
Groups of nodes for network access (page 27)
Because the user ID defines the administrative capability (scope and impact)
of a user, you can use groups to control access to the administrative functions
on a node. When a user logs on with a user ID, the user has access to all of
the nodes defined in the group and can perform any administrative functions
allowed by the administrative capability of the user ID.
GMDR
FMDR OAM
HGDS
Node
FDTM provisioning
stack
FDTR
Multiservice Switch
network
data flow
control flow
servers that you must configure manually
servers that are configured automatically
network access servers
group with a user ID defined on all nodes in the group, the user has access to
all of the nodes and can perform all of the functions that the scope and impact
of the user ID allows.
For an example of grouping nodes, see Do not create groups containing more
than 60 nodes for surveillance access. (page 32).
At startup time
To obtain surveillance information the following sequence occurs. See the
figure How the filtering of surveillance information is set up (page 30) for an
illustration of this sequence.
1 The FMDR server on a Nortel Multiservice Data Manager workstation logs
in to all of the nodes in a surveillance group with a common user ID and
password that it obtains from arguments in its startup command.
2 Each node authenticates the user ID and password, and returns a
customer network identifier (CNMID).
To perform its filtering function, an FMDR server needs to receive
surveillance information from all of the devices on all of the nodes in the
surveillance group. For an FMDR server to receive the information, the
common user ID and password must be defined on all the nodes such that
is has a scope impact sufficient to obtain the required surveillance
information, and that it causes all the nodes to return a CNMID of 0.
Once logged in, the FMDR server is ready to receive alarms and status
records automatically from all of the nodes in the surveillance group.
3 To obtain surveillance information from an FMDR server, a client
application, such as the GMDR server, registers with the FMDR server.
This registration request also includes a user ID and password, which can
set up by means of the GMDR Administration tool.
4 The FMDR server passes the user ID and password contained in the
registration request to one of the nodes in the surveillance group for
authentication.
5 The node authenticates the user ID and password, and returns a customer
network identifier (CNMID) to the FMDR server. The FMDR server stores
this CNMID for filtering purposes.
6 The FMDR initiates a state walk-through to obtain the states of all
components that it surveils. It also contains information about links that
terminate on TRK components and DPNGATE components and sets the
initial state of these links to in-service.
Attention: The Network Model Server determines and sets the actual states
of these links based on the states of components at both ends of each link.
At run time
When setup is complete and a node forwards surveillance information to the
Multiservice Data Manager workstation, the FMDR server filters the
surveillance information for the client application (GMDR) according to client
applications stored CNMID.
Client application
(GMDR server) FMDR server Multiservice
Setup begins Switch
FMDR server
is started 1
user ID and
password from
FMDR servers Authentication
startup command
2
GMDR server
is started 3 CNMID of 0
GMDR admin
tool is used to 4
associate Registration
request
FMDR server (userid and,
with GMDR user ID and
server password) password
5
Authentication
CNMID of 0 for
all devices or
other CNMID
for a VPN
6
Surveillance
information is
generated
Filtered
surveillance
information
password must authenticate in the same way on all nodes. That is, it must
have the same scope and impact, and must return the same CNMID.
For security reasons, a common user ID and password for surveillance
purposes must have the lowest possible scope and impact that still allows
the user to obtain surveillance information. The scope to do this is Device
and the impact is Service if the data model (SDD) is to be retrieved
automatically. A Passive impact will also work if the data model is already
available on the workstation.
To ensure that an FMDR server receives surveillance information from all
components in its group, the CNMID returned in response to the user ID
and password in the FMDR servers startup command must be CNMID 0,
also known as netman.
To ensure that a client application (GMDR) receives surveillance
information from all components in a surveillance group, the CNMID
returned in response to the user ID and password that the client
application provides must also return a CNMID of 0.
To ensure that a client application (GMDR) which monitors components in
a VPN only obtains surveillance information for the components that
belong to the VPN, the CNMID returned in response to the user ID and
password that the client application provides must be a CNMID other than
0, and it must be unique to that VPN.
For cases in which the FMDR server and the client application both need
to obtain surveillance information from all components on all nodes in a
surveillance group, they can use the same user ID and password. The
CNMID returned must be CNMID 0.
For cases in which the client application obtains surveillance information
for a VPN, and only needs to receive surveillance information from the
components in that VPN, the user ID and password provided by the client
application cannot be the same as the user ID password in the FMDR
servers startup command. The user ID and password provided by the
client application must also authenticate in the same way on all nodes on
which it is defined, and the CMNID returned must also be a CNMID other
than 0.
two groups called TOTO on the same workstation. You can, however,
duplicate the names of surveillance groups on different workstations.
Do not create groups containing more than 60 nodes for surveillance access.
CAUTION
Risk of difficulty in obtaining surveillance information
Defining groups with more than 60 members for surveillance
access may cause difficulty in connecting to all of the nodes in
the group to obtain surveillance information.
Group NY
NEWYORK1 NEWYORK2
Users: survey, Users: survey,
netman, prony netman, prony
Group NETWORK
Group PARIS
Group setup
Administering this network requires three groups:
a group that contains all of the nodes (NETWORK) that can be accessed
by users survey and netman
a group that contains only the New York-based nodes (NY) that can be
accessed by user prony
a group that contains all of the Paris-based nodes (PARIS) that can be
accessed by user propar
For a detailed description of how you can share servers among Nortel
Multiservice Data Manager workstations that are connected to an Ethernet
LAN, see the description of the Service Selection tool in Nortel Multiservice
Data Manager AdministrationTools (NN10470-300).
The GMDR server receives alarms from the FMDR servers on both
workstations but only displays the alarms once, because the GMDR server
discards duplicate alarm notifications. Therefore, should one of the FMDR
servers fail, the GMDR server continues to receive surveillance data from its
redundant FMDR server without producing an impact on the Fault tools that
rely on this information.
The figure FMDR server redundancy (page 34) shows a network containing
three nodes that are monitored by two standalone MDM workstations
connected by a LAN. Identical groups called G1 are defined on both
workstations. Separate FMDR servers are started to retrieve surveillance data
from the groups. The startup command for each FMDR server includes the
server name FMDR_G1.
The GMDR server on workstation A discards duplicate data from the FMDR
servers. Should server FMDR_G1 fail on workstation A, the GMDR server on
workstation A still gets the same surveillance information from the redundant
FMDR through its LAN connection to workstation B.
LAN
Workstation A Workstation B
GMDR GMDR
FMDR_G1 FMDR_G1
For medium and large networks, servers can be deployed among Nortel
Multiservice Data Manager workstations connected by the same Ethernet
LAN or by a WAN IP connection. This is can be done for a number of reasons
including the following:
to distribute the workload over a number of Multiservice Data Manager
workstations to improve performance
to permit effective use of older less powerful workstations along with new
more powerful workstations
to add redundancy and resiliency for fault management
The following guidelines apply to deploying the servers for Multiservice Switch
network access, surveillance, and provisioning access over multiple
workstations:
The following servers must run on a workstation that provides network
access (a workstation that has an X25 or Frame Relay link to the network):
HGDS, FDTM, and FDTR.
The FMDR server must run on the workstation that provides network
access by default. You can run it on another workstation, provided that you
specify the hostname of the workstation that runs the network access
server, as part of the FMDR servers startup command.
The GMDR server can run on any workstation on the LAN, provided the
workstation can handle traffic to the server. To ensure that the GMDR
server receives surveillance information, you must use the GMDR
Administration tool to specify the FMDR server (or servers) from which the
GMDR server is to obtain the surveillance information for nodes.
For the procedures relating to the information listed below, see Nortel
Multiservice Data Manager Administration (NN10470-303). Descriptions of
the administrative tools used to perform the tasks listed here are found in
Nortel Multiservice Data Manager AdministrationTools (NN10470-300).
Navigation
Servers required to support Multiservice Provider Edge network access,
surveillance, and provisioning access (page 36)
Groups of nodes for network access (page 38)
Reasons for groups and guidelines for set up (page 37)
Groups of nodes for network access (page 38)
Guidelines for grouping nodes for surveillance access (page 40)
NMDR server redundancy for surveillance access (page 42)
SNMP Proxy Agent (SPA) fundamentals (page 44)
Because the user ID defines the administrative capability (scope and impact)
of a user, you can use Multiservice Provider Edge groups to control access to
the administrative functions on a node. When a user logs on with a userid, the
user has access to all of the nodes defined in the group and can perform any
administrative functions allowed by the administrative capability of the userid.
Multiservice Provider Edge groups are therefore used to control access to the
network. Access is required for two main reasons:
network access: to allow an operator or administrator to log onto a node
with the command access or to perform provisioning operations
surveillance access: to allow the Management Data Router (NMDR)
server to log on to a group of nodes and obtain surveillance information
A Multiservice Provider Edge node can belong to several groups, so that it can
be accessed by different userids for different tasks. For example, a node can
be accessed by an operator for surveillance, and by a network administrator
for provisioning.
GMDR
NMDR OAM
HGDS
Node
NDTM provisioning
stack
NDTR
Multiservice
Provider Edge
network
data flow
control flow
servers that you must configure manually
servers that are configured automatically
network access servers
and password must authenticate in the same way on all nodes in the
group. That is, the userid and password must be defined with the same
login class permissions.
You are not limited to defining just one common userid and password. You
can define several common user IDs and passwords on the nodes in a
group and dedicate each to a different function. For example, one user ID
could have access privileges for provisioning, while another could have
access privileges for performing maintenance functions. However, any
common userid and password must authenticate in the same way on all
nodes in the group.
A node can belong to more than one group.
At startup time
To obtain surveillance information the following sequence occurs. See the
figure NMDR server redundancy (page 43) for an illustration of this sequence.
1 The NMDR server on a Nortel Multiservice Data Manager workstation
logs in to all of the nodes in a surveillance group with a common userid
and password that it obtains from arguments in its startup command.
2 Each node authenticates the user ID and password, and returns a
customer network identifier (CNMID).
To perform its filtering function, an NMDR server needs to receive
surveillance information from all of the devices on all of the nodes in the
surveillance group. For an NMDR server to receive the information, the
common userid and password must be defined on all nodes.
At run time
When setup is complete, the node forwards surveillance information to the
Nortel Multiservice Data Manager workstation.
Do not create groups containing more than 60 nodes for surveillance access.
CAUTION
Risk of difficulty in obtaining surveillance information
Defining groups with more than 60 members for surveillance
access may cause difficulty in connecting to all of the nodes in
the group to obtain surveillance information.
Group NY
NEWYORK1 NEWYORK2
Users: survey, Users: survey,
netman, prony netman, prony
Group NETWORK
Group PARIS
Group setup
Administering this network requires three groups:
a group that contains all of the nodes (NETWORK) that can be accessed
by users survey and netman
a group that contains only the New York-based nodes (NY) that can be
accessed by user prony
a group that contains all of the Paris-based nodes (PARIS) that can be
accessed by user propar
For a detailed description of how you can share servers among Nortel
Multiservice Data Manager workstations that are connected to an Ethernet
LAN, see the description of the Service Selection tool in Nortel Multiservice
Data Manager AdministrationTools (NN10470-300).
The GMDR server receives alarms from the NMDR servers on both
workstations but only displays the alarms once, because the GMDR server
discards duplicate alarm notifications. Therefore, should one of the NMDR
servers fail, the GMDR server continues to receive surveillance data from its
redundant NMDR server without producing an impact on the Fault tools that
rely on this information.
The figure NMDR server redundancy (page 43) shows a network containing
three nodes that are monitored by two standalone workstations connected by
a LAN. Identical groups called G1 are defined on both workstations. Separate
NMDR servers are started to retrieve surveillance data from the groups.
The GMDR server on workstation A discards duplicate data from the NMDR
servers. Should server NMDR_G1 fail on workstation A, the GMDR server on
workstation A still gets the same surveillance information from the redundant
NMDR through its LAN connection to workstation B.
LAN
Workstation A Workstation B
GMDR GMDR
NMDR_G1 NMDR_G1
SPA issues logs to notify operators of important server events and problems.
These logs are collected and displayed by the Multiservice Data Manager
OAM log collector. SPA can also record a trace of its execution by storing logs
in a server log file. The level of detail logged depends on which log levels are
selected as part of the SPA configuration. The log file is located in /opt/
MagellanNMS/data/log/spa/spa_<portnumber>.nlog and can be displayed by
the MDM Log Browser. For additional information see Nortel Multiservice Data
Manager Administration (NN10470-303) and Nortel Multiservice Data
Manager AdministrationServer Management (NN10470-310).
You can start up several SPA instances on one workstation to take care of
different groups of MPE devices separately or to share the load resulting from
a large number of SNMP managers.
Each SPA process has its own name and runtime parameters, uses a distinct
UDP port to receive requests and provides trap forwarding services to its own
SNMP managers list. The user must create a set of configuration files for each
SPA instance.
The SPA design assumes that the workstation is configured on each managed
MPE device as a SNMPv1 trap destination. SPA translates these traps into
SNMPv2c traps for SNMP managers requiring traps in this version.
SPA does not use this capability. SPA can therefore receive traps sent to
its workstation by non-MPE devices and reject those traps because the
sending device address does not match the IP address of any of the
managed MPE devices.
Address based filtering ensures that a client process only receives the
incoming traps sent from an IP address that is accepted by one of the IP
address filters specified by the client process upon connection with TSVR.
This capability is useful if more than one instance of the same server type
run on the same workstation and those instances are intended to manage
different regions of the network. By using this filtering option, the load put
on each instance is optimized by forwarding to each instance only the
traps originating from the network region that it is intended to manage.
SPA can optionally use this capability. However, SPA does its own address
filtering, using this option is never mandatory. If several SPA instances run
on the same workstation and are intended to manage different network
regions, using this option minimizes the number of traps forwarded to each
instance
By default, SPA does not use the 161 UDP port generally used by device
SNMP agents to receive SNMP managers requests. This is to avoid
conflicting with the MDM workstation SNMP Agent which binds to this UDP
port 161. If a SPA instance binding to the UDP port 161 is required, the MDM
workstation SNMP agent must first be disabled to free this port for SPA usage.
Since only one process can bind to each UDP port, each SPA instance on the
same workstation must use a different port. Trying to start a new SPA instance
using the same port as another SPA instance results in the attempt to create
2 SPA servers with the same name causing the new SPA to abort after issuing
the appropriate FATAL log. Trying to start a new SPA instance using a UDP
port already assigned to another process results in a failure to bind to this port
causing the new SPA to abort after issuing the appropriate FATAL log.
SNMP versions
The SNMP proxy agent supports both SNMP v1 and SNMP v2c. Managers
can send either SNMP v1 or v2c requests through SPA and get a
corresponding reply from the targeted MPE device. SPA does not perform any
request or reply translations.
Request types
This version of SNMP proxy agent supports GET, GET NEXT and GET BULK
request types.
From the SPA perspective, all requests received from SNMP managers and
all responses received from MPE devices have the same destination address
which is the SPA IP address. To forward these requests to the correct device
and help SNMP managers identify the device sending each response, all the
SNMP managers communicating with SPA are required to encode a special
community string in each request (the same community string format is used
by SPA in replies forwarded to managers). The required format is:
<NE id>[@<community>]
where:
<NE id> is either the IP address or the name of the MPE device
For example:
When SPA receives a request with this special community string, it extracts
<NE id> from the string and converts it to the device IP address. After
replacing the source IP address of the request with its IP address, the
destination IP address with the MPE IP address, and the encoded community
string with the selected community string, SPA forwards the SNMP request to
the destination MPE. Similarly, when SPA receives a response from MPE, it
replaces the source IP address with its own address, destination IP addresses
with the address of the manager that originated the request and adds the <NE
id> to the community string before forwarding the modified response to the
SNMP manager. The manager can therefore learn from this modified
community string where the source of the reply.
Traps handling
The SNMP Proxy Agent requires its workstation to be registered as a
SNMPv1 trap destination on each managed MPE device. Therefore, SNMPv2
traps received from TSVR are silently discarded without even trying to identify
the sender (they could have been sent by non-MPE devices).
For each SNMPv1 trap received, SPA first tries to find a managed MPE with
the same IP address. If no managed MPE is found, the trap is discarded.
If there are SNMP managers requiring SNMPv1 traps, the incoming trap is
cloned into another SNMPv1 trap with the following characteristics:
If there are SNMP managers requiring SNMPv2 traps, a new SNMPv2 trap
PDU is created with the following characteristics:
Logs
The SNMP proxy agent complies with the new MDM Server Logging
guidelines. It uses the new logging library to generate logs.
The logs with the following levels are sent to the OAMC server:
FATAL, ALERT, CRITICAL, CLEARED, NOTICE
SPA is also configured to send logs of selected levels to its server log file:
/opt/MagellanNMS/data/log/spa/
spa_<port_number>.nlog_<YYYYMMDD>
The following levels are selected by default to be sent to this server log file:
FATAL,ALERT,CRITICAL,ERROR,CLEARED,NOTICE,INFO
This selection can be modified using the logLevels option in the run-time
configuration file.
The USR1 signal can also be sent to SPA to dynamically toggle between the
selection of all log levels and the list of levels selected by the runtime
parameters configuration file. Since the selection of WARNING, DEBUG and
especially TRACE levels generates a very high quantity of logs, SPA should
only be left in this state for a short period of time.
Statistical logs
SPA issues statistical information to logs according to the statisticInt
configuration parameter to help a user monitor SPA performance and identify
communication problems. This statistical information includes the following
items:
average number of requests received per hour
average number of responses sent per hour
average number of traps forwarded per hour
number of requests discarded during the last statistical period because
the device did not respond in time
number of requests discarded during the last statistical period because
they could not be correctly decoded
number of requests discarded during the last statistical period because
the maximum number of concurrent requests had been reached
number of requests discarded during the last statistical period because
the targeted device cannot be identified
number of managed MPE devices
number of SNMP managers requesting SNMP v1 traps
number of SNMP managers requesting SNMP v2c traps
The first seven items each have a counter which accumulates during the
statistic collection interval. When this interval terminates, SPA calculates the
statistical values required, generates the corresponding logs at the INFO
level, resets those counters to 0, and starts a new statistical interval.
Because these logs are issued at the INFO level, they are not sent to OAMC
and are sent to the server log file under the default log levels selection.
The user can also require the statistical logs to be issued on demand by
sending the USR2 signal to SPA. This signal causes
the current statistical interval to be terminated immediately.
the statistical values to be computed for the terminating interval.
the corresponding logs to be issued.
a new statistical interval to be started.
Navigation
About SDD files (page 51)
Manually generating model files (page 53)
More than one SDD file is used to define the structure and format of the
service data for a node. Together these files constitute a model that is
identified by a version number, for example: AC0053C. Because SDD files
constitute a model, they are also referred to as model files.
Generating the model files manually requires the use of the fmsgetmod or
getsursdd utilities provided with the Nortel Multiservice Data Manager
software.
Fmsgetmod
This utility extracts source files from the tar file, generates output model files,
and installs them in the /opt/MagellanNMS/cfg/PassportSchema directory on
Nortel Multiservice Data Manager disk. The tar file can be on disk, in a
directory, or on a node. If the file is on a node, the fmsgetmod utility can be
used to upload the tar file first before doing the generate and install
operations.
The fmsgetmod utility also creates model files that are used to provision the
user interface. These model files are needed only for Nortel Multiservice
Switch provisioning applications. For all other applications, use the simpler
getsursdd utility to retrieve an SDD file from a node.
The fmsgetmod utility can also be used to delete old model files. You can
delete the files with the rm command, but you need to manually determine the
correct files to delete for a given version of the model. Because the fmsgetmod
utility automatically determines the correct files to delete for a given version
and deletes them, it is the recommended method.
Attention: If you used the getsursdd utility to retrieve an SDD file from a
node, you can use the rm command to delete the SDD file. No other files are
created by getsursdd.
[-d]
[-f]
where:
-u <host userid passwd> uploads a tar file from a node, generates model
files from it, and installs them where:
-t <tarfile> is the full pathname of the tar file on the Multiservice Data
Manager disk or on compact disk
-d removes all model files associated with the version except the files
/opt/MagellanNMS/cfg/PassportSchema/sursdd<version>.act, and
/opt/MagellanNMS/cfg/ANP/comp/<version>/anpmdl.co, where <version> is
the version of the model, for example, AC0323C. These files are master files
from which all other models files can be generated. To remove all files,
including the master files, use the -f option at the same time.
-f removes all model files associated with the version, including the file
named sursdd<version>.act, and then regenerates the model files
If you specify the -d option, the -u, -s, and -t options are ignored.
The -u, -t, and -s options are mutually exclusive. You can only use one of
them at a time.
Getsursdd
If the SDD file does not already exist on the Nortel Multiservice Data Manager
workstation the getsursdd utility retrieves the specified SDD file from a node.
This utility does not create any other files, such as the model files for the
provisioning user interfaces. The fmsgetmod utility performs that function.
-u <host userid passwd> specifies the node and valid user ID and
password from which to retrieve the SDD file
After you run the getsursdd utility, run the fdtm.newsdd.kick utility, which
signals FDTM to check the software version of each familys model files. If
FDTM finds any updated SDD files, fdtm.newsdd.kick parses the SDD files
and dynamically loads the new model files into shared memory.
Navigation
Determining the requirements for shared memory (page 56)
Setting the amount of shared memory in the kernel (page 56)
If you need to increase the amount of shared memory, you can use an editor,
such as vi, to change the value of the shared memory variable in kernel file
/etc/system, but Nortel Multiservice Data Manager software provides a
convenient script for this purpose. This scripts are contained in the files /opt/
MagellanNMS/system/config/config_sys_shmem <size> and
/opt/MagellanNMS/system/config/config_sys_semaphores. These scripts
have the following advantages:
reads the amount of shared memory allocated in the kernel file, and
increases the amount only if you specify an amount greater than the
amount that is already allocated
retains a copy of the existing kernel in file /etc/system.old
If you want to decrease the amount of shared memory, you cannot use script
config_sys_shmem. You need to edit the file with a UNIX editor.
Use the procedure for Using the config_sys_shem script to configure shared
memory in Nortel Multiservice Data Manager Administration (NN10470-303)
to reconfigure the amount of shared memory using the config_sys_shem
script.
Navigation
Overview of Network Time Synchronization (NTS) (page 58)
What is NTS
The Network Time Synchronization (NTS) system synchronizes the time of
day between Nortel Multiservice Data Manager workstations and network
elements, and ensures that
time clocks on workstations and network elements show a consistent time
of day
accounting records, alarms, statistics and logs bear a consistent
timestamp
Network elements in a timing hierarchy that provide the time to other devices
are known as time servers and those that receive the time are time clients. In
the figure A simple timing hierarchy (page 59), the Internet clock is the time
server for workstations A and B. Workstation A is a time server for the DPN
nodes and workstation B is a time server for Nortel Multiservice Switches. The
DPN nodes are time clients of workstation A and the Multiservice Switches
are time clients of workstation B. Devices containing clocks that have the
same precision are known as peers. In the figure A simple timing hierarchy
(page 59), workstations A and B are identical and have the same precision
clock; therefore, they are peers. Peers can obtain the time or provide the time
to one another.
Precision
Internet
clock Most
Workstation A Workstation B
DPN Multiservice
node Switch Least
The relationships shown in the figure A simple timing hierarchy (page 59) are
oversimplified. In a real timing hierarchy, devices are provisioned as backups.
An example of a timing hierarchy with backups is shown in the figure A timing
hierarchy with backups (page 60). In this figure, the workstations use an
Internet
clock
Workstation B Workstation C
Workstation A
(Primary backup) (Secondary backup)
DPN Multiservice
node Switch
In the most basic arrangement, the workstation uses its own internal clock as
a time server. The internal clock is the easiest time source to define because
it requires no IP connections to an external clock, and no expensive
equipment hardware such as a radio clock. The drawbacks to using the
internal clock are as follows:
the internal clock is relatively inaccurate compared with other types of time
sources
each time you wish to update the time you must manually enter the UNIX
date command
updating the time requires frequent and consistent monitoring and
intervention by a human operator
You can configure the Multiservice Data Manager workstation to access more
than one time source to provide backup. However, when you use a DPN OA
as a time source, do not configure any other time source for the workstation.
If you do, the cron job used to synchronize the workstation to the DPN OA, and
the XNTP software used to synchronize the workstation to the other time
sources will both attempt to reset the workstations time. This will lead to
timing conflicts and fluctuations.
Internet Precise
clock timing
device
MDM MDM
workstation workstation
InterNet
Internal
clock
OA
OA OA
DPN nodes
workstation workstation
Multiservice
Switches
OA
OA OA
DPN nodes
A Multiservice Data Manager workstation can only provide the time to DPN
nodes or obtain the time from them.
What is XNTP
XNTP is an Internet Standard Recommended Protocol that is built on two
protocols: the Internet Protocol (IP) and the User Datagram Protocol (UDP).
Although it was developed for synchronizing and distributing the time
throughout the Internet, XNTP can be used to synchronize and distribute the
time among most network elements that are connected by an IP link. Internet
clocks, Nortel Multiservice Data Manager workstations, and Multiservice
Switches support IP and can run XNTP. As a result, XNTP can be used to
synchronize and distribute the time among these devices.
With XNTP, the Internet time servers calculate clock offset and delay between
them using timestamps with a resolution of 200 picoseconds that are
exchanged at intervals of up to 1000 seconds.
time servers available. The stratum number ranges from 0 for very precise
clocks, such as atomic clocks, to 15 for the least precise clocks. For any given
device in a network XNTP dynamically calculates the stratum number of the
devices clock to be a lower value than that of its time server because the
server is higher up the timing hierarchy. When XNTP chooses a device to use
as a time source, it selects the device with the lowest stratum number first,
then the next lowest, and so on, until it runs out of configured devices.
The workstations can either obtain the time from the DPN nodes or provide
the time to them.
If you have more than one workstation in your network, choose one of them
as the primary time server for the DPN nodes, a second as backup time
server, and a third (if available) as a secondary backup time server. If you have
only one workstation, choose it as the primary time server.
On the MDM workstation you choose as the primary time server, schedule the
cron job to run the syncDPNtime program as shown in the figure Programs to
run to provide the time to DPN (page 67). On the workstations that are the
backup and secondary backup time servers, schedule the cron job to run the
syncDPNtime.backup program.
These two programs establish a connection to the DPN Top OA and send the
workstation time. The Top OA provides the time of all other DPN OAs and
synchronizes them to that time. The difference between the two programs is
that the syncDPNtime.backup also monitors other workstations that are acting
as time servers for DPN to determine if it should provide the time to the Top
OA.
Backup Secondary
Primary
time backup
time
server time
server
server
Top OA
OA OA
DPN nodes
Schedule the cron job to run the syncToDPNtime program on each of the
workstations obtaining the time from DPN, regardless of whether the
workstation is a primary, backup, or secondary backup time server for your
network. See the figure Program to run to obtain the time from DPN (page 68).
To set up a workstation to obtain the time from DPN, see the section on
Synchronizing the network time in Nortel Multiservice Data Manager
Administration (NN10470-303).
Secondary
Primary Backup
backup
time time
time
server server
server
OA
OA OA
DPN nodes
Navigation
About the maximum heap size (page 69)
The default /opt/MagellanNMS/lib/cfg/SharedJVM.cfg configuration file
(page 70)
Monitoring the maximum heap size (page 70)
The minimum heap size is 20M. The default for maximum heap size is 128M.
The default of 128M allows a user to run the following:
one instance of Nodal Provisioning
one instance of Shelf View with ENP
two instances of Data Viewer with default parameters, or one instance of
Data Viewer replaying a BDF file of about 10M in size.
File format
The /opt/MagellanNMS/lib/cfg/SharedJVM.cfg file consists of the following
syntax:
MAXHEAPSIZE <size in megabytes>
where:
Example
The following example demonstrates the file format:
MAXHEAPSIZE 128
Maximum heap size minus Currently used heap size < 20M
Navigation
Server alarm distribution and workstation status probing configuration
(page 73)
Workstation surveillance (page 75)
Multinodal Naming Service domains (page 78)
Multinodal Naming Service TCP/UDP port mappings (page 82)
Network access data mediation (page 84)
Multiservice Switch alarm clearing and storage (page 94)
For a first time installation, you can use the procedures in Nortel Multiservice
Data Manager Administration (NN10470-303) to set up server alarm
distribution and workstation status probing, or you can use the Nortel
Multiservice Data Manager Software Configuration tool, as described in
Nortel Multiservice Data Manager Installation and CommissioningSoftware
(NN10470-100).
Navigation
About server alarm distribution and workstation status probing (page 73)
You can configure the workstation to distribute them to a GMDR server that
runs on the workstation, or that runs on another workstation. By setting up a
hierarchy of GMDR servers on the workstations in your network, it is possible
to forward the workstations alarms and status changes to some, or to all of
the workstations in your network. For a detailed description of how server
alarms and status changes are propagated through GMDR, see Nortel
Multiservice Data Manager AdministrationServer Management
(NN10470-310).
You can also configure the workstation to distribute server alarms and status
changes to the NCS that runs on the DPN nodes in your network by
forwarding them to an OA in the NCS over an X.25 link. The X.25 link connects
to a Control Device Manager on the OA. The NCS propagates these alarms
and status changes throughout the OAs on all DPN modules in the network.
Any workstation that is configured to obtain surveillance information from the
NCS receives these alarms and status changes and can display them. For a
detailed description of how server alarms and status changes are propagated
through NCS, see Nortel Multiservice Data Manager AdministrationServer
Management (NN10470-310). This method of alarm distribution only applies
to networks that contain DPN nodes.
Navigation
Threshold configuration (page 75)
Threshold configuration
The configuration file lets you customize the thresholds at which workstation
surveillance generates alarms. You can also set the time interval at which the
workstation polls its managed components. The configuration file also
includes information on component-assigned fault codes. To change
configuration parameters, run the /opt/MagellanNMS/bin/sfm_config script to
create this file: /opt/MagellanNMS/cfg/SFM.cfg
You can edit the parameters in this file using any text editor. Prior to
undertaking each poll, workstation surveillance reads the configuration
parameters from this file. Only future alarms are affected; previous alarms are
not affected.
For information on the logs generated by the Server Administration tool, see
Nortel Multiservice Data Manager AdministrationTools (NN10470-300). For
information on alarms generated by this tool, see Nortel Multiservice Data
Manager Alarms Reference (NN10470-501).
When editing the SFM.cfg file, take the following points into consideration:
you can edit and save this file while the scripts are running
when defining numerical values, include only the number; do not add units
for any resource, the value for the minor alarm must be lower than the
value for the major alarm; the value for the major alarm must be lower than
the value for the critical alarm
always includes at least one space between the parameter name and the
configurable value
Skip this chapter if your Nortel Multiservice Data Manager workstations are
not located on a LAN, if your network only contains standalone workstations,
or if you are not planning to use the Service Selection tool.
Navigation
What MNS domains are used for (page 78)
Guidelines for setting up level 2 MNSD domains (page 80)
The client workstations can be configured to run just the servers that support
user sessions and provide access to Multiservice Data Manager tools.
Workstations configured to run these servers are referred to as Client Set
workstations.To perform their functions, the servers on the Client Set
workstations rely on the services provided by the servers on the Server Set
workstations.
A group of Server Set and Client Set workstations that run processes that
interact is referred to as a level 2 MNSD domain. You are not limited to just
one level 2 MNSD domain on a LAN. For networks that are being managed by
a number of workstations, you can define two or more level 2 MNSD domains,
each with its own set of workstations running processes that interact. For a
sample MNS configuration containing two level 2 MNSD domains see the
figure A sample MNS configuration of 2 MNS domains (page 80).
To provide redundancy, you can configure more than one workstation in a level
2 MNSD domain to run the level 2 MNSD process, as shown in the figure A
sample MNS configuration of 2 MNS domains (page 80). With more than one
workstation running a level 2 MNSD process, the servers on a workstation
have an alternate place to find the location of servers on other workstations in
the domain, in case of failure. In the sample configuration shown in the figure
A sample MNS configuration of 2 MNS domains (page 80), the servers
running on workstations in Domain 1 can select the MNSD level 2 process on
hosts A, B or C.
You can set up a workstation so it belongs to more than one level 2 MNSD
domain. In the figure A sample MNS configuration of 2 MNS domains
(page 80), workstation Host D belongs to two domains: Domain 1 and
Domain 2.
Domain 1
HostA HostB HostC
MNSD MNSD
level 2 level 2
process process
Domain 2
HostD HostE HostF
MNSD
level 2
process
Two main ways for organizing level 2 MNSD domains are possible. You can
choose to set up level 2 MNSD domains to manage the network on a
functional basis (specialization). For example, you can set up one domain that
contains workstations dedicated to provisioning, and another that contains
workstations dedicated to network access. Alternatively, you can choose to
set up level 2 MNSD domains on a regional basis. For example, you can
dedicate one domain that contains workstations for managing the eastern part
of your network, and another that contains workstations for managing the
western part.
Attention: You can configure more than one level 2 MNSD domain.
Navigation
Mapping service names to TCP/UDP port numbers (page 82)
Configuring TCP/UDP port numbers (page 82)
Navigation
Purpose of network data access mediation (page 84)
NDAM deployment and configuration strategies (page 89)
NDAM authentication configuration (page 91)
NDAM filterset file configuration (page 92)
The Fault clients (Alarm Display, Component Information Viewer) can access
the information collected by Nortel Multiservice Data Manager data collection
servers from the Global Management Data Router (GMDR) server and the
Network Model (NMSERVER) server. This information can be forwarded to
the clients such as HP OpenView NNM desktop.
Fault
tools/API
Fault Fault
tools/API tools/API
GMDR GMDR
Network Region B
Network Region A
Data
Component Criticality Filtered Data
Servers that you must configure manually
For HP OpenView NNM desktop clients, the NDAM server provides combined
access to the GMDR database and Network Model information. For
Multiservice Data Manager Fault clients, the NDAM server provides access to
the GMDR servers information only.
NDAM therefore supports all the capabilities of GMDR plus the filtering
described previously. NDAM is therefore always associated with a single
GMDR server and its clients. Unlike GMDR, NDAM does not store information
in a memory database. It passes through all queries to its assigned GMDR
and Network Model servers, and filters the replies according to the filtersets
associated with the client connections.
NDAM also uses a single notification stream from the GMDR and Network
Model servers, filters it and multiplexes it for NDAM clients. For example, the
NDAM server receives an alarm only once from GMDR but can forward the
alarm to many clients. An important fact is that NDAM supports Component
Criticality Filtering just like GMDR so it is possible to combine both forms of
filtering. This lets you do such things as divide the network into a number of
regions, one of which represents the network backbone. You can then access
data for each region with different Criticality Thresholds as follows:
connectivity information from the backbone
full regional information for the regional centers
hardware and connectivity information from the regions
full backbone information for the central operations center
NDAM also supports service name aliasing to allow a single NDAM server to
act as multiple subordinates to the same GMDR server, each connection with
a different filterset and criticality threshold mapping.
Fault Fault
tools/API tools/API
GMDR GMDR
GMDR
Network Core
Network Region B
Network Region A
Data
Component Criticality/Device/Type Filtered Data
Servers that you must configure manually
NDAM server acting as a proxy-GMDR
NDAM does not automatically prefix the provided alternate name as GMDR
does. This allows NDAM to act as a proxy for GMDR. If you want the service
name to include an NDAM_ prefix, you must include it in the value for the -n
option. In this deployment it is atypical to start NDAM with the forced
authentication (no -s) option.
Client
GMDR server
NDAM server
Subordinate
GMDR server
This allows the superior GMDR server to gather information that is filtered
according to region or according to component type from subordinate GMDRs
and provide it to its clients (Fault tools, SURNUP servers, API and EPI clients
and GMDR Administration tool).
In this configuration, you must start the NDAM server with the following
options:
GMDR option (-g)
-m option with a value of ~. The quotation marks are mandatory. The
-m~ value specifies that no network model information is involved.
-s option to set up forced authentication
In this mode, NDAM does not support the GMDR Administration Interface.
The GMDR Administration tool must be connected directly to the real GMDR
server used by NDAM. Similarly, NDAM used as a proxy-GMDR does not
support the Inbound API capabilities of the Alarm and Status API. To inject
alarms, you must connect directly to the underlying GMDR server. Finally, the
Alarm and Status API repFilter, repInfo, repScope, repOClass, and repOid
sieve attributes are not available because NDAM does not have an object
model of its own to which these filters can be applied.
With the -F (full types) option, the filterset files must be specified with all
intermediate types. For example:
All the default typeset files provided with Nortel Multiservice Data Manager
are specified with first-last types only. It is not possible to mix both types of
typeset files. If the -F option is used, all typeset files used must follow the full
type specification.
For more details about the structure of deviceset files and typeset files, see
Nortel Multiservice Data Manager AdministrationServer Management
(NN10470-310).
Navigation
Types of Multiservice Switch 7400/15000/20000 alarm clearing (page 94)
How alarms from Multiservice Switch 7400/15000/20000 are collected
and stored (page 96)
A Nortel Multiservice Data Manager (MDM) operator can delete alarms from
the active alarm lists (AALs) with the Component Information Viewer (CIV)
tool or the Alarm Display (AD) in active mode tool by selecting a specific alarm
or alarms with the mouse and selecting local or global clearing from a popup
menu. For information on clearing alarms, see the Alarm Display and
Component Information Viewer sections in the Nortel Multiservice Data
Manager Fault ManagementTools (NN10470-011).
Local clear
Local alarm clearing lets an operator clear alarms locally from the GMDR
database on a Nortel Multiservice Data Manager (MDM) workstation. When
an operator selects local clear with CIV or AD tool, the GUI applications sends
a clear request to the GMDR databases. The alarm is then cleared from the
GMDR databases on the workstation and the associated FMDR server(s).
Global clear
Global Clear lets an operator clear SET alarms from the Nortel Multiservice
Data Manager (MDM) servers and from the on-switch active alarm list (AAL).
The main reason for removing SET alarms from the AALs is to clean up the
lists so that only alarms of interest to the network operator remain. This makes
monitoring easier.
Clearing alarms using Global Clear from the Alarms menu allows many
alarms to be cleared at once. Anyone from Alarm Display or Component
Information Viewer can globally clear alarms that belongs to the node
members of the specified groups in the DMA configuration file.
Global Clear and the ManClear macro uses the DMA architecture for clearing
alarms. By default, Global Clear is available from the Alarms menu. Global
Clear can be removed from the menu by touching the following file:
opt/MagellanNMS/cfg/.DMAGlobalClearDisabled.
When the operator selects Global Clear from the CIV or AD tool, the DMA
server sends a clear request to the GMDR databases to clear the alarm local
on the workstation. The DMA server also logs on to the node using the
information contained in file /opt/MagellanNMS/cfg/DmaClrPP.cfg. For details
on how the DMA server performs this function, see the Data Manager Agent
(DMA) in Nortel Multiservice Data Manager AdministrationServer
Management (NN10470-310).
See setting up global alarm clearing for Nortel Multiservice Switch 7400/
15000/20000 in Nortel Multiservice Data Manager Administration
(NN10470-303).
Network operators using VT100 access or the Command Console tool can
delete alarms using the ManClear command with appropriate parameters.
See the Nortel Multiservice Data Manager AdministrationTools
(NN10470-300) for more information on ManClear.
Clearing alarms using Global Clear tool from the Start Tool ->Fault menu
allows only one alarm to be cleared at a time. Using the method, the user
needs an up-front authentication with a group before globally clearing an
alarm.
These alarms remain in the AAL until the corresponding alarm has been
cleared, or until the alarm is manually deleted. In both cases the alarm is
removed from the AAL.
Lists of active alarms are collected and maintained in the following places:
locally on the workstation in a database associated with the FMIP
Management Data Router (FMDR) server and in the GMDR database
in the AAL stored in the node.
Alarms stored in the FMDR and GMDR databases can be cleared with local
alarm clearing [local to the Nortel Multiservice Data Manager workstation] or
with global alarm clearing. However, alarms stored in the AALs of each node
can only be cleared by means of global alarm clearing.
Navigation
Multiservice Data Manager user customization fundamentals (page 98)
Resources for Multiservice Data Manager tools customization
fundamentals (page 109)
Menu customization fundamentals (page 121)
Component Information Viewer diagnostics (page 150)
snmpCmd macros (page 158)
Alarms in text format (page 169)
Helpsets for MPE devices (page 172)
Navigation
Access Control (page 98)
Service Selection (page 99)
Menu customization (page 99)
User Preferences (page 99)
Operator Client logging preferences (page 108)
Access Control
Access to applications running in the OC environment can be controlled by
displaying them based on the user ID. Access Control involves assigning
users to application categories such as Fault, Configuration, and
Performance. Launch and Tools menus are mapped to application categories
to restrict a users access to the assigned menus.
For example, a user assigned to the Fault category can only launch Alarm
Display, Component Information Viewer, and other fault applications. When
this Fault user opens a tools menu from any other tool, only those three items
are enabled.
tools can be used to set up Access Control for users. For information about
Multiservice Data Manager security, see Nortel Multiservice Data Manager
Network SecurityUser Access (NN10470-606).
Service Selection
The Service Selection tool can be used by Nortel Multiservice Data Manager
administrators and operators to modify Multiservice Data Manager default
service selection settings for workstations and specific users. Service
selection defines which workstation is to be used for connecting a specific
server from a Multiservice Data Manager tool.
Menu customization
Menu customization refers to controlling which Nortel Multiservice Data
Manager tools appear in the Launch and Tools menus. The Tools menus are
referred to as Start Tools menus and are displayed as popup menus in specific
contexts within each tool.
The ability to launch a tool in context means that within each tool the user can
select specific items and open a Start Tools category menu that provides a list
of tools that can be used with that item in the context of that tool.
Only Multiservice Data Manager administrator can customize the Launch and
Tools menus. For information about how to customize these menus, see the
description of customizing menus in Nortel Multiservice Data Manager
Administration (NN10470-303)
User Preferences
The user preference system allows Nortel Multiservice Data Manager
administrators to customize the default preferences for the Java applications
in the OC and MT environments.The user preference system for the MT and
OC environments is centralized at the User Administration server. See
Preferences system used by OC and MT environments (page 100).
Default preferences are defined for each application. They can be customized
at the system level or at the user level. System level preferences are changed
by an administrator outside a desktop session by editing a file. The change
takes effect only in subsequent desktop sessions. User level preferences are
changed within a desktop session. These preferences take effect immediately
and are visible with the relevant user action.
In the OC environment, the users preferences are stored against the user id
in the Sun One Identity server. In the MT environment, the user ID is the UNIX
user ID.
Sun workstation PC
Preferences System
Toolset Toolset
Sun workstation
The OC environment uses the following top-level directories for its Preference
System:
DEFAULT_SYSTEM_PREF_LOCATIONS = /opt/nortel/data/applications/
desktop/jws/MDM/prefs/default
SYSTEM_PREF_LOCATION = /opt/nortel/data/applications/desktop/jws/
mft/prefs/system
USER_PREF_LOCATION = /opt/nortel/data/applications/desktop/jws/
mft/prefs/users
The MT environment uses the following top-level directories for its Preference
System:
DEFAULT_SYSTEM_PREF_LOCATIONS = /opt/nortel/data/applications/
desktop/local/MDM/prefs/default
SYSTEM_PREF_LOCATION = /opt/nortel/data/applications/desktop/
local/mft/prefs/system
USER_PREF_LOCATION = /opt/nortel/data/applications/desktop/local/
mft/prefs/users
<DEFAULT_SYSTEM_PREF_LOCATIONS>/com/nortel/mdm/dvr
In this directory, there are three default Data Viewer user prefs.xml files:
one for basic Data Viewer operational preferences in /prefOptions/
one for Windows directory preferences in /filePathWinOptions/
one for Solaris directory preferences in /filePathSolOptions/
To change the preferences, the administrator copies the prefs.xml file to the
appropriate corresponding directory, either:
<SYSTEM_PREF_LOCATION>/com/nortel/mdm/dvr/prefOptions/
<SYSTEM_PREF_LOCATION>/com/nortel/mdm/dvr/filePathWinOptions/
<SYSTEM_PREF_LOCATION>/com/nortel/mdm/dvr/filePathSolOptions/
<DEFAULT_SYSTEM_PREF_LOCATIONS>/com/nortel/mdm/ocGUI
To change the preferences, the administrator copies the prefs.xml file to:
<SYSTEM_PREF_LOCATION>/com/nortel/mdm/ocGUI/prefOptions
State preferences
State preferences are the common system preferences shared by all the Fault
applications. The default system preferences are delivered in the prefs.xml file
in the system directory:
<DEFAULT_SYSTEM_PREF_LOCATIONS>/com/nortel/mdm/fault/state/
<state_node>/.
<SYSTEM_PREF_LOCATION>/com/nortel/mdm/fault/state/<state_node>/
and change the relevant default values.
Severity preferences
Severity preferences are the common system preferences shared by all the
Fault applications. The default system preferences are delivered in the
prefs.xml file in the system directory:
<DEFAULT_SYSTEM_PREF_LOCATIONS>/com/nortel/mdm/fault/
alarm_severity/<severity_node>/.
<SYSTEM_PREF_LOCATION>/com/nortel/mdm/fault/alarm_severity/
<severity_node>/ and change the relevant default values.
The default preference for logging is OFF. To activate logging, the logging
preference for the Operator Client application must be changed to ON. The
can be done by the administrator or by any user. There is a default logging
preference file called prefs.xml for every Nortel Multiservice Data Manager
tool.
To change the logging preference to ON, the user must copy the prefs.xml file
to a customization location and then change the logging preference to ON.
The customization location must be created for the user who is changing the
preference logging, as follows:
/opt/MagellanNMS/cfg/mft/OCpreferences/users/<userid>/
com/nortel/mdm/<application-subsystem>/logging/
prefs.xml
where:
Navigation
About resources used by Multiservice Data Manager tools (page 109)
Syntax of a resource definition statement (page 110)
Predominance (page 111)
Specificity (page 111)
Customizing resources for all users (page 113)
Customizing resources for specific users (page 117)
Setting resources for a single user in the .Xdefaults file (page 118)
Customizing resources in a command line (page 119)
Useful utilities (page 119)
associated with it that defines the appearance of the widget and how it acts.
For example, resources that define the background color and border width for
a push-button in the icon bar of a tool.
There may be widgets within widgets arranged into a hierarchy. For example,
the Network Viewer is equipped with many widgets such as an icon bar, and
the icon bar has a number of push-buttons that are subwidgets of the icon bar
widget.
The following sections explain the syntax used for writing resource definition
statements, provide predominance rules for resource definition statements,
explain the methods used to set resources for tools, and contain a few
examples that show how to set them.
Predominance
Two main factors affect the way in which one resource definition statement
overrules (predominates) another. These are:
the specificity of the resource definition statement
the location of the resource definition statement
Specificity
You can write resource definitions with varying degrees of specificity. As an
example, you can use the following five definitions to set the color of the label
in the main window of the Network Viewer tool. These sample definitions are
listed with the most specific statement first and the least specific statement
last:
ND*statusLabel.background: blue
ND*XmLabel.background: yellow
ND*background: brown
ND*Background: grey
*XmLabel.background: green
*background: red
*Background: pink
The general rule is that the more specific a resource definition statement is,
the more likely it is to overrule (predominate) a less specific statement, as
follows:
The more widgets and subwidgets there are in a resource definition
statement, the more specific the definition. In the samples, client names
are in fact widgets, so definitions that contain client names (ND)
predominate definitions that do not contain client names.
Widget names that begin with an uppercase letter represent classes of
widgets and widget names that begin with a lowercase letter are specific
instances of a class of widget. Resource definitions for specific instances
of a widget predominate resource definitions for classes. In the samples,
the definition *background: red predominates the definition *Background:
pink and the definition ND*statusLabel.background: blue
Location
On UNIX platforms you can to define resources for Nortel Multiservice Data
Manager tools in multiple locations. For user accounts that run the default
Multiservice Data Manager user environment, you can define resources in five
main locations. These locations and the order in which the system consults
them to determine settings for resources are as follows:
1 resources specified by means of -xrm arguments added to the command
lines used to start a tool.
These arguments can be added to the tool startup commands in the
toolsets menu definition files, start tool menu definition files, and icon bar
definition files.
2 the .Xdefaults file in a users home directory
Resource definitions in this file apply only to a single Multiservice Data
Manager user account. Resource definitions in this file are automatically
applied to the users session whenever the user logs in. However, if they
are to be applied without having the user log out then log back in again,
they must be applied manually by means of the xrdb utility.
3 a common resource definition file, whose definitions are added to a users
session by executing the xrdb -merge command
When this command is added to the .dt/sessions/sessionetc (CDE) file or
.xsession (Bourne Korn, or C-shell) file of every user account that is to use
the common resource definition file, it applies the definitions to the users
session whenever the user logs in.
Resource definitions applied this way can apply to a single user, specific
users, or all users of the tool. This method is best suited for applying
resource definitions to some users, but not all users of a tool.
4 MDM tools resource definition files located in directory /opt/MagellanNMS/
cfg/app-defaults
This directory also contains three subdirectories called C, ja, and zh.
Subdirectory C is used for storing customized English language resource
definition files. Subdirectories ja and zh contain the Japanese and
Chinese language equivalents. Resource definitions in these files apply to
all users of a tool.
resource definition file only apply to the appearance of the cascading menus
that are available from the MDM window. However, some of the resources
affect all tools that are started from the cascading menus. The following
example defines a resource that affects all Multiservice Data Manager tools.
The default Msm tool resource file contains font resources that allow an
operator to select one of five fonts for displaying information in the main
windows of all tools that are opened from the MDM window.
The default font selection menu available to an operator from the MDM
window is shown in the figure Default font selection menu (page 115).
The resource modification in this example defines a new sixth font selection
called nicefont.
Three resource definition statements are used to define a font select in the
Fonts menu. These are as follows:
defines the maximum number of font selections available from the Fonts
menu. In file /opt/MagellanNMS/lib/app-defaults/C/Msm, this resource is set
to 5. If you wish to provide more than five choices in the Fonts menu, you must
increase this number accordingly.
Msm*fontMnemonic<n>: <fontname>
defines the name that appears as a selection under the Fonts menu. In this
resource, <n> identifies the font selection involved. The value for <n> must lie
within the range of numbers defined for resource Msm*numFonts
Msm*fontname<n>:<font specification>
defines the size and type of the font to be displayed. In this resource <n>
identifies the font selection involved. The value for <n> must lie within the
range of numbers defined for resource Msm*numFonts.
10 Have users log out and log back in again to make the changes active.
The following example shows how resources for Network Viewer can be set
for multiple Multiservice Data Manager users by defining the resources in a
common resource file then applying them to each users account by running
the xrdb utility whenever the user logs in. To ensure that a user account
obtains resource definitions from the common file whenever the user logs in,
the following command must be added to the .dt/sessions/sessionetc (CDE)
or .xsession (Bourne, Korn, or C-shell) file of every user account that is to use
the common resource file:
xrdb -merge <pathname of common resource file>
Although this method is most useful when you wish to customize resources for
multiple users of a tool, you may also use it to customize resources for all
users. Do not customize resources for some tools with this method and
customize resources for other tools by creating new customized resource
definition files in directories /opt/MagellanNMS/cfg/app-defaults/C,
/opt/MagellanNMS/cfg/app-defaults/ja or
opt/MagellanNMS/cfg/app-defaults/zh
7 Do one of the following for each user account that will use the common
resource file:
If the account is running CDE, add the following command to set-up file
.dt/sessions/sessionetc:
xrdb -merge /opt/settings/myfile
If the account is running Bourne. Korn, or C-Shell add the following
command to set-up file .xsession:
xrdb -merge /opt/settings/myfile
8 Save the file and exit from it.
9 Have each of the users log out and log back again to obtain the new
settings, or alternatively have each user enter the following command to
activate the settings:
xrdb -merge /opt/settings/myfile
The resource set in the following example defines the color used to display the
in-service state in the Network Viewer tool.
You can set resources for an tool by adding resource definitions in -xrm
arguments to the tools startup command. However, the number of resources
that can be set in this way is limited because of the potential length of the
command line.
Startup commands for tools that appear in the MDM window cascading menus
are contained in toolset definition files. For descriptions of these files, see
Toolset definition files (page 137).
The following example shows a command that starts Network Viewer with the
labels visible and icons hidden:
/opt/MagellanNMS/bin/nd -xrm ND*showAllabels: True \
-xrm ND*showAllIcons: False"
Useful utilities
The following utility programs are provided with the Solaris operating system
and may be used for such things as setting resources, or determining the
values that can be used to set the attributes of a resource. The names of the
utilities and their purposes are as follows:
xrdb is used for two main purposes:
updating some Nortel Multiservice Data Manager tool users (but not
all users) with resources from a common resource definition file
updating a single user of a tool with resource set in the user accounts
.Xdefaults file
For information about this utility, see the man pages for the xrdb command and
for an example of its use to set resources for multiple Multiservice Data
Manager users, see Customizing resources for specific users (page 117).
xlsfonts displays the names of fonts available on the workstation. The
names displayed can be used as attribute values in resource definition
statements for font resources. For information about this utility, see the
man pages for the xlsfonts command.
xco displays the colors available on the workstation and their names. The
names displayed can be used as attribute values in resource definition
statements for color resources. For information about this utility, see the
man pages for the xco command.
Navigation
Attention: The shared JAVA tool and Start Tools menus used in the Toolset
and Operator Client environments are defined and customized using files
different from those used for the other tools in the Toolset environment. See
Customizing menus for Shared Java and Operator Client tools (page 142).
MDM window
When you log in to a UNIX account that is set up to run the default user
environment, as described in Nortel Multiservice Data Manager
Administration (NN10470-303), a Nortel Multiservice Data Manager session
starts and the MDM main window opens. The main window provides you with
access to Multiservice Data Manager tools through
a primary menu consisting of the menu items of fault, configuration,
accounting, performance and system
a set of cascading submenus from which you can start Multiservice Data
Manager tools
The figure MDM main window and menus (page 122) shows the Fault menu
and its submenus.
Main
window
Toolsets menu
Tools submenu
For information on customizing Start Tool menus, see Nortel Multiservice Data
Manager Administration (NN10470-303).
An example of a Start Tool menu is shown in the figure Sample Start Tool
menu for the Component Status Display (page 123).
Start Tool
category menu Start Tool menu
The figure Sample icon bar from Network Viewer main window (page 124)
shows the icon bar.
File syntax
In a menu definition file, a record for a menu entry consists of one or more
specification lines. General rules for creating such records are as follows:
each record must be followed by at least one blank line
each comment line must begin with an exclamation mark (!)
the information for a record should fit on one line
file path and script path specifications do not need to start with a directory.
If there is no directory, the search paths described in Automatic search
path (page 135) are invoked.
The records in a menu definition file are partial Motif widget resource
descriptions with a few extra resources added. Partial descriptions mean that
you only need to specify the resource name and value; the tools menu system
manages the widget name itself. See Resources for Multiservice Data
Manager tools customization fundamentals (page 109) for more information
about widgets and X resource specifications.
See the following sections for information on the categories into which menu
definition records are grouped:
Include records (page 125)
Menu entry descriptions (including icon bar push-buttons) (page 127)
Titles (page 131)
Separators (page 132)
Submenus (page 132)
Include records
These records are used to call up the contents of other files. Include records
take one the following forms:
#include <file path|GLOB pattern>
#ifinclude <file path|GLOB pattern> <presence test>
where:
ifinclude includes the file specified by <file path|GLOB pattern> only if the
presence test succeeds
<file path> is the pathname of the file to be included. The <file path> can
start with a tilde (~) character, which resolves to your current home directory.
The absolute file path can also contain the string $LANG. See Resolving the
value of $LANG (page 136).
<GLOB pattern> indicates you can use a series of wildcards to expand the
file path. The file path resolves to the first match found for every matching
filename found in a specified absolute path or all paths described in Automatic
search path (page 135) for a specified relative path.
The <file path> and <script path> options can include the tilde (~) character,
which resolves to your current home directory. Also, you can include the string
$LANG in either of these options. See Resolving the value of $LANG
(page 136) for more information.
The table $APPCLASS and $APPMENU values (page 127) lists the allowed
values of $APPCLASS for toolset menus and Start Tool menus and the
allowed values of $APPMENU for Start Tool menus. For main window menus,
the value of $APPMENU is the name of the toolset definition file, for example,
Full.tsets.
You can set the value of $APPMENU in a toolset definition file such as
Full.tsets using the tMMenuAppName parameter.
You can also use $@ to test the numerical user-ID value. For example, to allow
certain tools to be invoked only by the root user (user-ID 0), use the following
test:
-E $@ 0.
By convention, the toolset definition file and tools definition file are the only
files that contain include and ifinclude records. See Toolset definition files
(page 137) and Tools definition file (page 140) for more information.
As a minimum, you must specify the labelString record, plus one of the
tMCommandLine or tMAction lines. Explanations for each of these lines are
as follows:
labelType: pixmap
is used in icon bars to specify the full path name of the bitmap image to display
as an icon on a push-button. If this line is specified, the labelType line must
also be specified. The icon must be in X-11 Bitmap format.
is the command line to execute when the menu entry or the push-button is
selected. This string is in Bourne shell syntax and executed through the Motif
Session Manager (MSM). The MSM label in the main window displays a
response to indicate when a tool is started.
For some Fault tools, this line can contain a substitution variable that passes
the name of a component or other information along to the tool being started.
See Substitution variables in a Start Tool menu definition file (page 134) for
information about the use of substitution variables in these lines.
This line can also be used to invoke a macro. For an example, see Example
2, Creating a submenu item that invokes a macro (page 142).
identifies an internal action to perform and its parameter. The internal action
depends on the tool. See Nortel Multiservice Data Manager Fault
ManagementTools (NN10470-011) for more information.
For some Fault tools, this line can contain a substitution variable that passes
the name of a component or other information along to the tool being started.
See Substitution variables in a Start Tool menu definition file (page 134) for
information about the use of substitution variables in these lines.
are pattern alternatives similar to those provided with the UNIX egrep
command that are used to enable or disable the menu item for certain
components. For example, the pattern ^PM.*|^OA.*enables the menu item for
DPN-100 modules (PMs) and operations agents (OAs). If this line is omitted,
the menu items is enabled for all components.
The <file path> and <script path> options can include the tilde (~) character,
which resolves to your current home directory. Also, you can include the string
$LANG in either of these options. See Resolving the value of $LANG
(page 136) for more information.
The table $APPCLASS and $APPMENU values (page 127) lists the allowed
values of $APPCLASS for main window menus and Start Tool menus and the
allowed values of $APPMENU for Start Tool menus. For main window menus,
the value of $APPMENU is the name of the toolset definition file, for example,
Full.tsets.
You can set the value of $APPMENU in a toolset definition file such as
Full.tsets using the tMMenuAppName parameter.
You can also use $@ to test the numerical user-ID value. For example, to allow
certain tools to be invoked only by the root user (user-ID 0), use the following
test:
-E $@ 0.
Multiple tests can be strung together with && (AND) and || (OR) operators. For
example, the following test includes a tool in the menu if the executable is
found and the current DISPLAY is not the main console:
tMPresenceTest: -x /opt/MagellanNMS/bin/svmadm \
&& ^ -E DISPLAY :0.0
tMPresencePatterns: <pattern alternatives>
are pattern alternatives that are used to make an menu entry visible or hidden.
Unlike a presence test, a presence pattern does not hide a menu entry
permanently. If a presence pattern is specified, the menu item is visible only if
the target component ID matches one of the pattern alternatives. Presence
patterns are only supported in Start Tool menus, where a component ID
context exists.
resources for Motif PushButtons that specify the appearance of the menu item
or push-button. See Useful OSF/Motif resources (page 135).
Titles
Titles are actually Motif Label widgets and therefore support all of the
corresponding resources. The general syntax for a title record is as follows:
labelString: <title name>
tMMenuAppName: <$appmenu env. variable>
tMPresenceTest: <presence test>
<Motif resource line for Labels>
Only the labelString line needs to be specified in a title. Explanations for each
of these lines are as follows:
is the title that appears in the menu. Some Fault tools allow you to use a
substitution variable in this string. See Nortel Multiservice Data Manager Fault
ManagementTools (NN10470-011) for information about the use of
substitution variables in these lines.
is used to set the value of the environment variable $APPMENU. For more
information, see the explanation given on page 126 with
-E <environment variable> [<value>].
are resources for Motif Labels that specify the appearance of the title. See
Useful OSF/Motif resources (page 135).
Separators
Separators are actually Motif Separator widgets and therefore support all of
the corresponding resources. The general syntax for a separator record is as
follows:
tMSeparator:
tMPresenceTest: <presence test>
<Motif resource line for separators>
Only the tMSeparator line needs to be specified. Explanations for each of
these lines are as follows:
tMSeparator:
indicates only that the record is for a separator. By default, this is a single
horizontal line.
resources for Motif Separators that specify the appearance of the separator.
See Useful OSF/Motif resources (page 135).
Submenus
Submenus begin with a submenu header record and end with a submenu
footer record. Submenus can be nested one within another, each of which
must be started with its own submenu header record and terminated by its
own submenu footer record.
is the name of the submenu as it is displayed in the menu button of the menu
that opens the submenu. Some tools allow you to specify a substitution
variable name in this string that is replaced by the appropriate value when the
menu is displayed.
is used to set the value of the environment variable $APPMENU. For more
information, see the explanation given on page 126 with
-E <environment variable> [<value>].
tMSelectionPatterns:<enabling patterns>
are pattern alternatives similar to those provided with the UNIX egrep
command that are used to enable or disable the entire submenu in certain
contexts. For example, the pattern ^PM.*|^OA.*enables a command for DPN-
100 modules (PMs) and operations agents (OAs). If this line is omitted, all
components are enabled.
are pattern alternatives that are used to make an menu entry visible or hidden.
Unlike a presence test, a presence pattern does not hide a menu entry
permanently. If a presence pattern is specified, the menu entry is visible only
if the target component ID matches one of the pattern alternatives. Presence
patterns are only supported in Start Tool menus, where a component ID
context exists.
resources for Motif CascadeButtons that specify the appearance of the menu
item that causes the submenu to appear. See Useful OSF/Motif resources
(page 135).
By convention, only the records in the extract are used in Start Tool menu
definition files.
alignment: <alignment_beginning|alignment_center
|alignment_end>
controls the way in which the tools menu entry or push-button is displayed: left
justified, centered, or right-justified
The tools menu system applies search paths, $LANG substitutions, and
GLOB pattern matching and picks the first found match for each resolved
filename. This search pattern means that user customizations take
precedence over workstation customizations, which take precedence over
Multiservice Data Manager defaults.
See Resolving GLOB patterns (page 136) and Resolving the value of $LANG
(page 136) for more information on how pathnames are resolved.
<search path>/toolsets/fcaps/<area>/<filename>
where:
area is one of the subdirectories that contain menu definition files for entries
on the main window primary menu. See Toolset definition files (page 137) for
information on how these subdirectories are ordered for display purposes.
The following subdirectories come with the software:
fault contains menu definition files for fault menu items. For example
Network Status Bar.
utilities contains menu definition files for utilities menu items. For
example System -> Utilities -> Customer Data.
filename is one of the menu definition files. A menu definition file contains
the records that define one entry on the main window primary menu and the
submenus that cascade from the entry. The names of the menu definition files
begin with a number, which determines the order in which the menu entries
are displayed in the primary menu. Menu definition files for the main window
menus have the extension .tools.
/opt/MagellanNMS/lib/tsets/C/toolsets/fcaps/configuration/60service.tools.
The entry Fault -> Circuit Viewer precedes the HP-OV NNM entry, but follows
all other Fault tool entries on the Fault menu because of the values of the
numbers that begin with filenames.
Toolset definition files are written using the same syntax as menu definition
files. In a toolset definition file, the area subdirectories are listed in the order
in which their menu definition files appear in the primary menu.
For example, in the figure MDM main window and menus (page 122), the
toolset definition file would list the area subdirectories in this order: fault,
configuration, configuration/nrs_common, accounting, performance, security,
administration, utilities, and help.
<search path>/<filename>
where:
filename is one of the toolset definition files. The default toolset definition
used by Multiservice Data Manager is
/opt/MagellanNMS/lib/tsets/C/Full.tsets. The default value of Full.tsets is set
by the environment variable NMSTSETS. Multiservice Data Manager
software provides a number of toolset definition files that you can use and they
are:
where:
top contains menu definition files for menu entries you add to the top of the
Start Tool menu. Until you add menu definition files to it, this subdirectory is
empty.
surv contains menu definition files for the Fault menu entry on the Start Tool
category menu. For example, Component Information Viewer and Alarm Help.
prov contains menu definition files for the Configuration menu entry on the
Start Tool category menu.
misc contains menu definition files for the Utilities menu entry on the Start
Tool category menu. For example, Customer Data and Command Console.
custom contains menu definition files for the Custom menu entry on the Start
Tool category menu. Until you add menu definition files to it, this subdirectory
is empty and the Custom menu entry is not displayed.
bottom contains menu definition files for menu entries you add to the bottom
of the Start Tool menu. Until you add menu definition files to it, this
subdirectory is empty.
filename is one of the menu definition files. A menu definition file contains
the records that define one entry on the Start Tool menu and any submenus
that cascade from the entry. The names of the menu definition files begin with
a number, which determines the order in which the menu entries are displayed
on the Start Tool menu. Menu definition files for the Start Tool menus have the
extension .menu.
Example
/opt/MagellanNMS/lib/tsets/C/tools/surv/10adv_diagnostic.menu contains the
menu definition records for the entry Component Information Viewer and
/opt/MagellanNMS/lib/tsets/C/tools/surv/20adv_performance.menu contains
the menu definition records for the entry DPN Performance Viewer on the
Start Tool menu. See the figure Sample Start Tool menu for the Component
Status Display (page 123).
The tools definition file is written using the same syntax as menu definition
files. In a tools definition file, the application area subdirectories as described
in Finding menu definition files for Start Tool menus (page 138) are listed in
the order in which their menu definition files appear in the Start Tool menu. For
example, in the figure Sample Start Tool menu for the Component Status
Display (page 123), the tools definition file would list the application area
subdirectories in this order: top (empty), survs, prov, misc, custom (empty),
and bottom (empty). This order causes the entries for the surveillance tools to
be listed first, followed by the provisioning tools, and the miscellaneous tools.
<search path>/NMSToolsMenu.menu
where:
Where to find icon bar definition files for the Network Viewer icon bars
Icon bars are defined in icon bar definition files, which use the same syntax as
menu definition files. Network Viewer has two icon bars but only one is
displayed at a time.
Use the following path to find the icon bar definition files:
<search path>/<filename>
where:
The default icon bar definition files that come with the software are:
/opt/MagellanNMS/lib/tsets/C/NDIconBar.menu
This icon bar file defines the icon bar displayed while Network Viewer is
being used in surveillance mode.
/opt/MagellanNMS/lib/tsets/C/NDIconBarEdit.menu
This icon bar file defines the icon bar displayed while Network Viewer is
being used in Network Model Edit mode.
Customization examples
See the following sections for examples of customizing menus and setting
resources in startup options:
Example 1, Setting the startup options in a menu definition file (page 141)
Example 2, Creating a submenu item that invokes a macro (page 142)
You can also set resources in other places, including the user
accounts.Xdefaults set-up file and the Network Viewer default resource
definition file /opt/MagellanNMS/cfg/app-defaults/C/ND. See Resources for
Multiservice Data Manager tools customization fundamentals (page 109) for
information about setting resources by other means.
The presence of the items in the menus is defined in the Application Launch
(AL) configuration files for the MT and OC environments. The MT AL
configuration file contains all applications, including those for the JAVA tool
plug-ins, while the OC AL configuration file contains only the Java tool plug-
ins.
Do not modify the existing default AL configuration files. You must copy the file,
place it in the customization location, and edit the copied file.
For the OC environment, the default AL configuration files are stored on the
web server and are located in:
/opt/nortel/config/applications/desktop/jws/MDM/
launchscripts/default
For the MT environment, the default AL configuration files are stored in the
UNIX local file system and are located in:
/opt/nortel/config/applications/desktop/local/MDM/
launchscripts/default
The Launch menu AL files are named with the following syntax:
<Tool name>LM.cfg
The Tools menu AL files are named with the following syntax:
<Tool name>OM.cfg
Each AL configuration file contains a Command Block for each tool with the
parameters that describe the tool presence in the specified menu.See
Example of Command Block in an AL configuration file (page 143).
Field Entry
Menutype = MenuBar
Menu/Submenu = Configuration
CommandLabel = Nodal Provisioning
CommandType = Plugin
Command = Class=com.nortel.cpt.gui.CoreProvisioningTool,Client=yes,Single=no
SandboxName = NodalProvisioningSandbox_<sandbox_id>
SandboxJars = /opt/MagellanNMS/lib/jar/ANPClient.jar
/opt/MagellanNMS/lib/jar/ ANPShared.jar
/opt/MagellanNMS/lib/jar/ANPTemplateIcons.jar
/opt/MagellanNMS/lib/jar/MdmLib-MftApp.jar
/opt/MagellanNMS/lib/jar/nmsweb.jar
/opt/MagellanNMS/lib/jar/parser.jar
/opt/MagellanNMS/lib/jar/jaxp.jar
/opt/MagellanNMS/lib/mft/pluginJars/applications/sharedJVMApp.jar
The custom location for new launchscript files and copies of existing
launchscript files is:
/opt/nortel/config/applications/desktop/jws/MDM/
launchscripts/custom
To remove a tool from the launch menu, the Command Block must be deleted
from the copy of the *LM.cfg file that has been stored in the custom location.
To add a third party tool a new launchscript file must be created in the custom
location, with a Command Block to describe the parameters for the tools
appearance in the menu.
Attention: A third party tool can be added to the launch only if the
application is present on the client workstation. There must be a local
executable and its full path must be used.
For an example of a Command Bloc created for a third party tool, see Example
of Command Block to launch Outlook (page 144)
Field Entry
Menutype = MenuBar
Menu/Submenu = System/Customer
CommandLabel = My Outlook
CommandType = Local Application
ApplicationType = Fault
ACLevel = ISACLevel
Command = C:\Program Files\Microsoft Office\Office10\OUTLOOK.EXE
The PersistWindow value will cause the Desktop to remember size and
position data of the Operational Commands main window and associate such
data with the authenticated user.
Field Entry
Menutype = MenuBar
Menu/Submenu = System/Utilities
CommandLabel = Operational Commands
ApplicationType = Nodal Access
ACLevel = ISACLevel
CommandType= Plugin
Command= Class="com.nortel.mdm.operationalCommands.gui.OperationalCommands",
Client="yes", Single="no"
SandboxName= OperationalCommandSandbox_<sandbox_id>
SandboxJars= MDM/pluginJars/TableLayout.jar MDM/pluginJars/operationalCommands.jar
MDM/pluginJars/MdmLib-General-MftApp.jar MDM/pluginJars/MdmLib-
LoggingNSecurity-MftApp.jar MDM/pluginJars/MdmLib-ServersNCom-
MftApp.jar MDM/pluginJars/MdmLib-GenericGUI-MftApp.jar MDM/
pluginJars/MdmLib-SharedJVM-MftApp.jar
MenuMnemonic= S/U
CommandMnemonic= 0
PersistWindow= True
Window size and position preferences are user preferences. The key used to
save these preferences is an ID constructed from the plug-in class name and
window title. If there are multiple windows with the same title and plug-in, the
size and position preferences for the last window in focus is saved.
A delete preference script can be used to remove any Desktop saved position
and size parameters. To restore default size and position, the user must either
manually reset them using the preference script or by manually placing each
plug-in main window. The following command removes the Operator Client
preferences for all plug-in windows size and position:
/opt/nortel/applications/desktop/current_desktop/bin/
deletepreferences.sh [ -h ] [ -f ] {-user <user_id> |
[-windows]} | {-local | -jws}
Add the -f switch if no confirmation is required before preference files are
removed.
Care should be taken to avoid reuse of mnemonics in the same menu. When
customizing, you need to examine existing mnemonics and accelerators to
avoid using duplicates. A duplicate mnemonic or accelerator could be
encountered when:
Two (or more) cfg files specify the same mnemonics for the same Menu /
Submenu
Two (or more) cfg files specify the same accelerator for their
CommandLabel
When duplicates are created, the Desktop will use Java default behavior to
handle them. Based on the current Java behavior, the menu item positioned
higher in the menu is selected first. The other items are selected upon
subsequent typing of the duplicated mnemonics.
The following table contains launchscript tokens and values for MDM plug-ins:
In the OC environment, the custom location for new launchscript files is:
/opt/nortel/config/applications/desktop/jws/MDM/
launchscripts/custom
In the MT environment, the custom location for new launchscript files is:
/opt/nortel/config/applications/desktop/local/MDM/
launchscripts/custom
To remove a tool from a Tools menu, the Command Block must be deleted
from the copy of the *OM.cfg file that has been stored in the custom location.
To modify a tool name, the Command Block must be modified in the copy of
the *OM.cfg file that has been stored in the custom location.
PresencePattern field, then the Data Viewer launch menu will be visible in
the tools menus and can be launched with the component name as the
context.
The entries for the modifiable fields are shown in bold in Data ViewerOM.cfg
file (page 149).
Field Entry
Menutype = objectmenu
Menu/Submenu = ExternalLaunches/Start Tools/Performance
CommandLabel = Data Viewer
ApplicationType = Performance
ACLevel = ISACLevel
CommandType = Plugin
Command = Class=com.nortel.mdm.dvr.apps.DataViewer,Clien=yes,Single=no,Args=
-component <component name>
PresencePattern = ^<device type>.*|^<device type>.*
SandboxName = DataViewerSandbox_<sandbox_id>
SandboxJars = /opt/MagellanNMS/lib/jar/dataViewer.jar
/opt/MagellanNMS/lib/jar/ MdmLib.jar
/opt/MagellanNMS/lib/jar/nmsweb.jar
/opt/MagellanContrib/Advent/current/ builder/classes/AdventNetCharts.jar
/opt/MagellanContrib/Advent/current/builder/classes/AdventNetSnmp.jar
/opt/MagellanContrib/Advent/current/builder/classes/jcchartK.jar
For example, to create a new command entry for the PP4400 device type:
PresencePattern=^MPA.*
Customizing tools menus for Nodal Provisioning
The information on menu customization for Nodal Provisioning is covered in
NN10470-610 Nortel Multiservice Data Manager Nodal Provisioning User
Guide, chapters Nodal Provisioning Procedures and Nodal Provisioning
Template Editor.
Navigation
Diagnostic menu management (page 150)
Component Information Viewer diagnostic utilities (page 152)
When customizing, you can use wild cards and presence test patterns.
Example
Command
queryParameter: $VAL Nb seconds between polls:
queryParameter: Lock the component?
If you specify a substitution variable name using the $ prefix, an input dialog
opens and prompts for a value. The input value is then substituted in the
command line where the identified variable name is used. If you do not specify
a substitution variable, a confirmation dialog opens and prompts to continue
or abort the command execution.
<search path>/dial/*.menu>
where:
<search path> is the usual search path sequence. (see Automatic search
path (page 135)).
To add new diagnostic commands, you need only add a file in the directory
$HOME/MagellanNMS/diag to customize a single user
/opt/MagellanNMS/cfg/tsets/$LANG/diag/ to customize a workstation,
(where $LANG is C for standard-ANSI/English language)
execWithDest
The execWithDest utility performs the following activities:
identifies the default destination as specified in the diagnostic command
Select Command Route
opens the Connection Console to establish the connection when needed
executes a specified command in the context of that connection
Variable Definition
-inline is used when execWithDest is invoked from a DtKsh script. The
utility is sourced rather than invoked as a subprocess
(. /opt/MagellanNMS/bin/execWithDest -inline). This option
directs the utility not to drop the EPI Command Interface
connection so that the connection can be used again by the
sourcing script.
-ask|-noask controls whether the Connection Console is invoked. If you
specify -ask, the Connection Console always opens. If you
specify -noask, the Connection Console never opens and the
command does not execute if there is no current default
applicable.
-oa|group specifies the destination type
-def <default destination> specifies the default destination name.
-mod <module name> specifies the name of the module and is used in selecting an
appropriate connected destination, if possible
-name <command name> specifies a meaningful name for the command to be executed.
This option is used only for prompts and messages.
<command and args> specifies the command line to execute, in context of the selected
destination. When you source the utility into a DtKsh script,
usually with the -inline option, do not specify the command and
arguments.
execDPNCommand
The execDPNCommand utility executes a single DPN command as a macro
in the context of an OA route similar to execWithDest -OA. The command
line is as follows:
/opt/MagellanNMS/bin/execDPNCommand
[-msg <message>]
[-pe|-pi|-po]
<command> <arguments> <component>
Variable definitions
The following variable definitions apply to the execDPNCommand utility.
Variable Definition
-msg <message> outputs the value of a message on the standard output stream before
the command output.
-pe|-po|-pi identifies the level to which the component ID is interpreted.
Superfluous component ID elements are dropeed and the utility
converts the remainder to the appropriate component ID format.
Variable Definition
<command> specifies the command to execute, in context of the selected
destination
<arguments> specifies the command line arguments for <command>
<component> specifies the component ID in canonical format ($COMP, space
separator) that will be used by <command>
execPPCommand
The execPPCommand utility executes a single Nortel Multiservice Switch
CAS command as a macro in the context of a group route similar to
execWithDest -group. The command line is as follows:
/opt/MagellanNMS/bin/execPPCommand
[-msg <message>]
[-level <category>]
[-selector <patterns>]
<command and options> <arguments> <component>
Variable definitions
The following variable definitions apply to the execPPCommand utility.
Variable Definition
-msg <message> outputs the value of a message on the standard output stream before
the command output
-level <category> identifies the category to which the component ID is interpreted.
Superfluous component ID items are ignored
-selector <patterns> appends the specified patterns (separated by a | character) to the
interpreted subcomponent to produce a set of component patterns.
These patterns are used by the ppCompSelector utility to open a
dialog listing all the matching components existing on a target node.
The component selected from the dialog is used for the command
execution. This option allows you to create diagnostic commands for
components that are not managed by fault tools and do not appear in
the CIV Related Components List. For a description of
ppCompSelector, see ppCompSelector (page 156).
ppCompSelector
The ppCompSelector utility provides a selection dialog with a list of Nortel
Multiservice Switch components matching the specified patterns. The
command line is as follows:
/opt/MagellanNMS/bin/ppCompSelector
[-title <dialog title>]
<group name> <component patterns>
Variable definitions
The following variable definitions apply to the ppCompSelector utility.
Variable Definition
-title <dialog title> is the title in the dialog bar
<group name> specifies a group to be used for command access
<component patterns> specifies full component IDs in Nortel Multiservice Data Manager
display format. Specify components using Multiservice Switch CAS
wild cards. Separate multiple patterns with the | character. If you use
wild card in the module name, all matching nodes within the specified
group are used. The group is also used to query the target modules
for the matching subcomponents.
For example, the following command opens a dialog with all LPs of all nodes
in the UNIVERSE group:
ppCompSelector UNIVERSE EM/* LP/*
In the following example, all circuits of a specific ATM interface are used:
ppCompSelector UNIVERSE EM/NODEA05 ATMIF/122 VPC/*|EM/
NODEA05 ATMIF/122 VPT/*|EM/NODEA05 ATMIFf/122 VCC/*|EM/
NODEA05 ATMIF/122 VPT/* VCC/*
execWithIPAddr
The execWithIpAdd utility extracts an IP address, community string or generic
property name for a specified component ID. The IP address, community
string or generic property name is then substituted in the command line and
the command is executed. The command line is as follows:
/opt/MagellanNMS/bin/execWithIPAddr
[-warn|-best-effort] <component ID> <command line>
Variable definitions
The following variable definitions apply to the execWithIPAddr utility.
Variable Definition
-warn displays a warning dialog when the IP address or community string
cannot be identified and the command line does not execute. By
default, the execWithIPAddr utility does not display warnings when the
properties cannot be identified.
-best-effort executes the command line when the IP address and community
string cannot be identified, substituting an empty string for the
matching parameter in the command line.
<component ID> specifies the component or subcomponent for which the IP address
and/or community string is required. If the component ID identifies a
sub-component and the property cannot be extracted at that level,
execWithIPAddr automatically tries to fetch them at the module level.
<command line> specifies the command line to be executed. The utility substitutes any
occurrence of %IPADDR% and %COMMUNITY%, or any generic
property name embedded within % characters, in the command line to
the extracted IP address, community string, or generic property name
respectively. If a generic property name is specified and the property
cannot be identified, nothing is substituted in the command line.
You can use this utility to perform IP address substitution using the component
variable IPADDR and the generic property name
NortelMomsProxyIpAddress, for example
/opt/MagellanNMS/bin/execWithIpAddress "EM/<node_name>"
/bin/echo "IP address is %IPADDR% or
%NortelMomsProxyIpAddress%."
You can use this utility to start a Telnet session in context of a selected
component ID, for example
/opt/MagellanNMS/bin/execWithIPAddr -best-effort \
"$COMP" "/bin/telnet %IPADDR%"
To enable context launching, specify the preceding command line in the
Multiservice Data Manager device-type specific tools-menu configuration
files. For details on customizing the toolsets and Start Tool menus, see Nortel
Multiservice Data Manager Administration (NN10470-303).
Navigation
What you need to know (page 158)
Runtime environment (page 158)
About snmpCmd macros (page 162)
For the location of directories in which these MIBs are stored, see also
Runtime environment (page 158).
Runtime environment
Tool Command Language (TCL) and Scotty are used to create the snmpCmd
macros that are provided with the Nortel Multiservice Data Manager software
package.
TCL and Scotty executables are part of the Magellan Contrib MagTcl software
package, which must be installed on the workstation along with the
Multiservice Data Manager software package to be able to run snmpCmd
macros.
Paths to the TCL and Scotty executables are set up automatically when the
Magellan Contrib MagTcl package is installed. Paths to these executables are
as follows:
TCL: /opt/MagellanContrib/bin/tclsh
Scotty: /opt/MagellanContrib/bin/scotty
When the account is set up to run the default Nortel Multiservice Data
Manager environment, the values of these variables are set automatically and
no intervention is required. The method used in the default environment for
setting up the values of the environmental variables is as follows:
For user accounts that run C-shell, the values are set by script
/opt/MagellanNMS/bin/nmscsh which is called by the .cshrc file in the
users home directory.
For user accounts that run Korn or Bourne shell, the values are set by
script /opt/MagellanNMS/bin/nmssh which is called by the .profile file in
the users home directory.
If the account is not using the default user environment, you must take steps
to ensure that these environment variables are set either when the user logs
in or once login is complete.
TCL_LIBRARY
The value of variable TCL_LIBRARY is set to path /opt/MagellanContrib/lib/
tcl17.5. This path provides access to the high level init script for TCL and to
high-level utilities and error checking routines.
TCLLIBPATH
The value of variable TCLLIBPATH is set to the following paths:
/opt/MagellanContrib/lib/tnm2.1.7
/opt/MagellanContrib/lib/tkined1.4.7
/opt/MagellanNMS/cfg/snm
snmpCmd macros
A number of snmpCmd macros are provided with the Nortel Multiservice Data
Manager software. These are located in the following subdirectories of
software library directory
opt/MagellanNMS/lib/cfg/snm/Commands:
GEN contains general command macros.
MPA contains device-specific command macros for Passport 4400 series
devices.
Any snmpCmd macros you write are stored in subdirectories GEN or MPA in
customer configuration directory /opt/MagellanNMS/cfg/snm/Commands.
MIBs
A Management Information Base (MIB), is a set of files that list of all the
variables you can use to retrieve management information about SNMP
devices and their interfaces. Locations of the MIBs for SNMP devices used by
snmpCmd macros are as follows:
standard high-level MIBs provided with the Magellan Contrib software
package: /opt/MagellanContrib/lib/tnm2.1.7/mibs
MIBs for Passport 4400 series devices: /opt/MagellanMPA/mibs
Utilities
A number of TCL and Scotty utilities have been created for Nortel Multiservice
Data Manager supplied macros. These are located in file
/opt/MagellanNMS/lib/cfg/snm/Commands/libraryRoutines.tcl. A summary of
these utilities is as follows:
getIpAddr <device type> <device name>
This utility attempts to get the IP address of an SNMP device from a
number of locations, according to the <device type>. For example,
Passport 4400 uses GMDR as the primary source of the IP address. If the
attempt to get the address is unsuccessful, the utility returns a dash (-).
getDevNames <device type> <device name>
This utility obtains a list of devices for the specified <device type>. This
utility can also be used to get subcomponent names of a particular device
by specifying the additional <device name> parameter. For sample usage
of this utility, look at files showdev and showcomp in directory
/opt/MagellanNMS/dev/lib/cfg/snm/Commands/GEN.
getIndexStringFromGMDR <comp id>
This utility accepts a <comp id> parameter, which is used to fetch the
SNMP index from DCD (through GMDR) for a specified component. An
example of a <comp_id> is MPA MPADEV1 CARD 1 PO 1.
The indexes are in the form <index_name>/<index_val>.
The index name is actually the name of a MIB table which indicates that
the index value can be applied to any element in the table. For example, if
the index string returned is ifTable/1.1., it would be possible for the
command macro to get the state of the component by doing an SNMP
GET on ifOperStatus.1.1.
This utility returns the index string returned from GMDR, or - if the index
name was not found, in which case the invoking script can choose another
course of action.
[optional parameters] define what the command verb is to act on. These
depend on the specific implementation of the macro whose name is
<command verb>.
any macro that wishes to establish read access to the SNMP device (or
devices).
If the command is entered without a read community string, the
corresponding environment variable is removed and the default value of
public is assumed.
setwritecom creates an environment variable for a specified write
community string for all SNMP devices of a specified type, or for a single
specified SNMP device. This environment variable can then be used by
any macro that wishes to establish write access to the SNMP device (or
devices).
If the command is entered without a write community string, the
corresponding environment variable is removed and the default value of
private is assumed.
setsnmpport creates an environment variable for the port number used for
establishing sessions to all SNMP devices of a specified type, or to a
single specified SNMP device. This environment variable can then be
used by any macro that wishes to establish a session with the SNMP
device (or devices).
If the command is entered without a read community string, the
corresponding environment variable is removed and the default value of
port 161 is assumed.
setenvironment contains a template that allows you to run multiple
setreadcom, setwritecom, and setsnmpport commands at a time to set
environment variables at the beginning of a command console session. To
use the macro, edit the macro and add the commands to the macro then
enter setenvironment to run it.
native allows you to direct commands in native SNMP protocol format to a
specified SNMP device.
[optional parameters] define what the command verb is to act on. These
depend on the specific implementation of the macro whose name is
<command verb>.
Commands must be directed to the @ route to ensure that they are directed
to snmpCmd processor which then locates the macro and invokes it with the
required variables.
Application
Network OVMDR
SNMPcmd element
file
macro
Passport 4400
Running an snmpCmd macro involves the following steps (see the figure
Dataflow diagram for snmpCmd command macros (page 166)):
1 The user sets the command route to @ to indicate that the command is to
run an snmpCmd macro, in one of the following ways:
If you use the Command Console, select @ with the Route menu button.
If you use the API of the CMCFun server (cmcmd), prefix the command
with @.
If it finds two macros with the same name, the macro in the customer
configuration directory takes precedence.
7 If the macro is device-specific, the snmpCmd processor obtains the IP
address of the device as follows:
For Passport 4400, the snmpCmd processor sends a request to the
GMDR server. GMDR sends a property request to OVMDR running on a
remote workstation through the PSERVER. OVMDR automatically obtains
and updates information about SNMP components, including the IP
addresses of PP4400s. This notification requests injection of device and
component information, including the IP address. The IP address is
injected back to IMDR through the PSERVER and is supplied to GMDR
and to the snmpCMD processor.
8 The snmpCmd processor calls the macro and passes it the required
options and parameters as follows:
For a general macro the command structure is <command verb> <optional
parameters>. The snmpCmd processor passes the optional parameters to
the macro.
For a device-specific macro the command structure is <device type>
<device name> <command verb> <optional parameters>. The snmpCmd
processor passes arguments to the macro in the following order:
1 The macro runs. If a device-specific macro is involved, the macro gets the
SNMP device index from GMDR for Passport 4400 devices, translates the
parameters into an SNMP command, and routes the command to the
managed device.
2 Replies and error messages are returned to the originating application.
Navigation
About the rncsalarm utility (page 169)
Command syntax (page 170)
Consider the following alternatives to the rncsalarm utility for extracting alarms
from Multiservice Data Manager:
using the Alarm and Status API described in Nortel Multiservice Data
Manager Fault ManagementAlarm and Status API Reference
(NN10470-203)
Because of its field selection and filtering capabilities, and its regular
(parsable) output format, the Alarm and Status API is a better source of
information, especially for alarms that need to be processed by other
applications, such as an umbrella management system.
using alarm on-switch alarm spooling facilities
For devices that support it, spooling of alarms is a more reliable way of
collecting alarms for later analysis.
When it is run without the -d and -h options (the default situation), the
rncsalarm utility continuously receives matching alarms from a specified
GMDR server and displays them in a specified format and mode. When it is
run with the -d and -h options, the rncsalarm utility dumps the matching
contents of the Active Alarm list (-d option) or the Alarm History list (-h option).
Command syntax
The command syntax for the rnscalarm utility is as follows:
/opt/MagellanNMS/bin/rncsalarm \
[-d] \
[-h] \
[-f TERSE|NORMAL|FULL] \
[-m DPN|COMMON] \
[-i <component name>]... \
[-n <NTP index>]* \
[-s <severity>]* \
[-l <server name>] \
[-H <server host>]
where:
[-h] dumps the matching alarms from the Alarm History list
[-i <component name>]... displays only the alarms for components that
match the specified component name. Adding an asterisk (*) after the
component name displays all alarms matching the specified component
name. You can specify up to 5 -i options. When you specify more than one
component name, alarms matching any of the component names are
displayed. The component name must be specified in API format, with blank
separators and no slashes. For example, EM TOTO LP 2, not EM/TOTO/LP/2.
[-n <NTP index>]* displays only the alarms whose NTP index matches the
specified NTP index. You can specify up to 5 -n options.
[-s <severity>]* displays only the alarms whose severity matches a specified
alarm severity. Valid severities in DPN mode display are: NONE, DEGRADE,
OVERLOAD, MAJOR, and MINOR. For COMMON mode display, valid
severities are: UNKNOWN, WARNING, MAJOR, MINOR and CRITICAL. You
can specify up to 5 -s options.
[-l <server name>] lets you name an alternate GMDR server to connect to.
By default, the server name used is GMDR.
[-H <server host>] lets you override the host on which the connected GMDR
server is running. By default, the host that has been selected for Surveillance
Access with the Service Selection tool is used as the host on which the GMDR
server is running.
If -i, -n, and/or the -s options are specified, only alarms matching all specified
sets of filters are displayed.
Navigation
About customizing the MPE helpset (page 172)
Command syntax (page 173)
The master Alarm Help index is also updated to reflect the change using the
mpegetmode script. In addition, the script is used to retrieve the configuration
data model from a Multiservice Provider Edge device. This script is also used
to retrieve the configuration data model from an MPE device. The update
process is illustrated in Alarm help update process (page 173).
Command syntax
The command syntax for the mpegetmod command is:
mpegetmod
[-h]
[-version <version>]
[-u <device> <user-id> <password>]
[(-a | -xa)]
[-fa
[-da]
Variable Definition
-h provides the usage information to the user.
-version version specifies the version of MPE software being run.
-u <device> <user-id> specifies the MPE device name/ip address, user ID and
<password> password.
-a retrieves the alarm help file in addition to the configuration
model file
-xa retrieves only the alarm help file
-fa forces the retrieval of the alarm help file if it already exists
-da removes the specified version of the alarm help file
Publication: NN10470-305
Document status: Standard
Document issue: 01.02
Document date: May 2007
Product release: 16.2
Job function: Administration and Security
Type: NTP
Language type: U.S. English
Nortel, the Nortel logo, and the Globemark are trademarks of Nortel Networks.