830-00742-47 ZMS Admin Guide

ZMS Administrator’s Guide
For software version ZMS 2.1

July 2010
Document Part Number: 830-00742-47
Zhone Technologies
@Zhone Way
7001 Oakport Street
Oakland, CA 94621
USA
510.777.7000
www.zhone.com
info@zhone.com
COPYRIGHT ©2000-2010 Zhone Technologies, Inc. All rights reserved.

This publication is protected by copyright law. No part of this publication may be copied,
distributed, displayed, modified, transmitted, stored in a retrieval system, or translated without
express written permission from Zhone Technologies, Inc.
Bitstorm, EtherXtend, IMACS, MALC, MXK, Raptor, SLMS, Z-Edge, Zhone, ZMS, zNID and
the Zhone logo are trademarks of Zhone Technologies, Inc.
Zhone Technologies makes no representation or warranties with respect to the contents hereof
and specifically disclaims any implied warranties of merchantability, noninfringement, or
fitness for a particular purpose. Further, Zhone Technologies reserves the right to revise this
publication and to make changes from time to time in the contents hereof without obligation of
Zhone Technologies to notify any person of such revision or changes.
2 ZMS Administrator’s Guide

CONTENTS
About This Guide .............................................................................................................................13

Audience .....................................................................................................................13
Document organization...........................................................................................13
Style and notation conventions............................................................................14
Typographical conventions.....................................................................................14
Related documentation...........................................................................................15
Contacting Global Service and Support.............................................................17
Technical support....................................................................................................17
Hardware repair .....................................................................................................18
Chapter 1 Overview ....................................................................................................................19

ZMS system components.......................................................................................19
Redundancy overview.............................................................................................22
ZMS application servers .........................................................................................24
ZMS database servers .............................................................................................25
Switchover ..............................................................................................................25
Backups...................................................................................................................25
Hot backup .......................................................................................................25
Cold backup......................................................................................................26
Active Cold backup ..........................................................................................26
About the ZMS database ........................................................................................26
ZMS system terminology........................................................................................26
Sequence of system setup tasks .........................................................................27
Chapter 2 System Administration........................................................................................29

Starting and stopping the ZMS server ................................................................29
Configuring ZMS managers (properties files) ..................................................30
Network service ......................................................................................................30
Fault manager..........................................................................................................32
Performance manager .............................................................................................37
Monitoring service ..................................................................................................38
Diagnostics service .................................................................................................38
Configuration synchronization service ...................................................................38
ZMS Administrator’s Guide 3

Contents
Configuration service..............................................................................................39
Asynchronous service .............................................................................................40
Debug service..........................................................................................................41
MTAC external relay alarm templates....................................................................44
Changing the normal relay state to close..........................................................45
Changing the alarm severity of external relay alarm .......................................45
Changing the alarm description of external relay alarm ..................................46
ONU/ONT serial number format (Hexa-decimal, Decimal) ..................................46
Chapter 3 ZMS database server administration ............................................................49

ZMS database utilities .............................................................................................49
ZMS database redundancy maintenance procedures ....................................51
Database monitoring ...............................................................................................55
Database backup and restore ...............................................................................55
Restoring the database ............................................................................................57
Backup files ............................................................................................................58
Cleanup utilities ........................................................................................................59
Common database administration procedures................................................60
Database utilities FAQs ..........................................................................................61
What is the name of the configuration file the dbmonitor reads?...........................61
Where can I find the dbmonitor log files? ..............................................................61
How to disable the dbmonitor for a particular database? .......................................61
How do I disable the dbmonitor?............................................................................61
How do I add/remove an email address from DBA Pager or Operators?...............61
How do I exclude some common benign Oracle errors in the alert log files?........62
What do I do when you find errors in the alert log? ...............................................62
Backing up database archive logs.......................................................................62
Adding swap space to a Solaris server ..............................................................62
Chapter 4 Administering Operator Accounts ................................................................65

Overview .....................................................................................................................65
How objects are grouped ........................................................................................65
How permissions function ......................................................................................66
Recommended sequence for setup tasks.................................................................67
Administering groups and operators as the admin user...............................68
Changing the admin password ................................................................................68
Creating a group......................................................................................................69
Creating an operator account ..................................................................................69
Viewing an operator account ..................................................................................70
Modifying an operator account...............................................................................70
When modifications take effect .......................................................................71
Deleting an operator account ..................................................................................71
Configuring security policy as the admin user ................................................71

Administering operators as a user administrator ...........................................74
Creating an operator account ..................................................................................74
Viewing an operator account ..................................................................................75
Modifying an operator account...............................................................................76
When modifications take effect .......................................................................76
Deleting an operator account ..................................................................................76
Account information for operators ......................................................................77
About activating operator accounts....................................................................77
Chapter 5 Monitoring ZMS Logs ..........................................................................................79

Overview .....................................................................................................................79
Alarm log.....................................................................................................................80
Audit logs....................................................................................................................80
Modifying the information written to the audit log ................................................81
Task logs.....................................................................................................................82
Debug log....................................................................................................................83
Forwarded alarm log................................................................................................83
Forwarded trap log...................................................................................................84
Server log....................................................................................................................84
Trap log .......................................................................................................................84
ZMS error log .............................................................................................................87
Appendix A How ZMS Manages Network Elements.........................................................89

Administration manager .........................................................................................89
Configuration synchronization service ..............................................................90
Configuration manager ...........................................................................................93
Fault manager............................................................................................................94
Fault processing ......................................................................................................95
Trap receiver.....................................................................................................96
Alarm processor ...............................................................................................99
Performance manager...........................................................................................102
Monitoring service..................................................................................................104
Diagnostics service ...............................................................................................105
Appendix B Traps and Alarms.................................................................................................107

ADSL alarms ............................................................................................................108
ADSL ATUC initialization failure alarms............................................................108
ADSL ATUC threshold alarms.............................................................................109
ADSL ATUR threshold alarms.............................................................................110
ADSL rate change alarms .....................................................................................110

Contents
ATM TC sublayer alarms ......................................................................................110

ATM VCL alarms .....................................................................................................111
Bitstorm HP alarm ( Bitstorm devices only)....................................................111
Bonded G.SHDSL and T1E1 alarms ..................................................................113
Bulk statistics alarms ............................................................................................114
Card alarms ..............................................................................................................115
Card memory alarms.............................................................................................115
Card services alarms .............................................................................................115
Card status change alarms.....................................................................................116
Card version alarm................................................................................................117
External relay (environmental) alarms..................................................................117
Card redundancy unsafe alarms ............................................................................118
CLI alarms.................................................................................................................118
CLI blocking alarms .............................................................................................118
CPE alarms...............................................................................................................119
CPE alarms............................................................................................................119
DHCP alarms............................................................................................................119
DHCP alarms ........................................................................................................119
DS1 and DS3 alarms .............................................................................................119
DS1 alarms............................................................................................................119
DS3 alarms............................................................................................................121
DS3 PLCP alarms .................................................................................................122
DSL alarms ...............................................................................................................123
DSL status change alarms.....................................................................................123
ELCP alarms ............................................................................................................123
ELCP alarms .........................................................................................................123
Flash card alarms ...................................................................................................124
GigaMux TL1 alarms (GigaMux 6400 devices only) ......................................125
GR303 alarms ..........................................................................................................126
GR303 IG alarms ..................................................................................................126
GR303 CRV remote state alarms..........................................................................127
GR303 TMC state change alarms .........................................................................127
GR303 EOC primary state change alarms ............................................................128
GR303 EOC secondary state change alarms ........................................................128
GR303 IG operational state change alarms ..........................................................129
GR303 TMC primary state change alarms ...........................................................129
GR303 TMC secondary state change alarms........................................................130
IMA alarms................................................................................................................131
IMA.......................................................................................................................131
IPD 4200 alarms (Paradyne devices only) .......................................................134
IPD 8800/8620 alarms (Paradyne devices only) .............................................137
IPSLA alarms ...........................................................................................................140
MTAC alarm..............................................................................................................140

.....................................................................................................................................140
ONU OMCI alarms...................................................................................................141
ONU dying gasp alarm ..........................................................................................142
ZNID 4200 alarms ...................................................................................................142
Physical alarms.......................................................................................................143
Physical link alarms ..............................................................................................143
Link up/ link down .........................................................................................143
Shelf alarms .............................................................................................................144
Shelf temperature alarms ......................................................................................144
Shelf power alarms ...............................................................................................144
Shelf fan alarms ....................................................................................................145
Shelf controller alarms..........................................................................................146
SNR monitor threshold crossing alarms .........................................................146
SONET alarms .........................................................................................................147
SONET line alarms ...............................................................................................147
SONET path alarms ..............................................................................................148
SONET section alarms..........................................................................................148
Subscriber alarms ..................................................................................................149
Subscriber alarm ...................................................................................................149
V5.2 alarms...............................................................................................................149
V5.2 IG alarms......................................................................................................149
V5.2 C channel status change alarms ...................................................................149
V5.2 C path operational state change alarms........................................................150
V5.2 IG operational state change alarms ..............................................................150
V5.2 protection C path operational state change alarms.......................................151
ZMS alarms...............................................................................................................151
ZMS alarms...........................................................................................................151
ZMS cannot reach device ...............................................................................151
ZMS login failure alarm support...........................................................................151
ZMS config sync alarms .......................................................................................152
A full config sync update has failed...............................................................152
ZRG alarms...............................................................................................................152
Appendix C Modifying ZMS alarm descriptions ..............................................................153
Index ....................................................................................................................................................155

Contents

LIST OF FIGURES
Figure 1: ZMS environment ........................................................................ 21

Figure 2: ZMS server and databases on a single machine........................... 23
Figure 3: ZMS server and databases on a single machine........................... 24
Figure 4: ZMS servers and database servers on 3 machines ...................... 24
Figure 5: Administering a management request .......................................... 90
Figure 6: Synchronization following a device-level change ....................... 92
Figure 7: Configuring resources .................................................................. 94
Figure 8: Fault manager processors ............................................................. 96
Figure 9: Handling reliable traps by sequence number ............................... 97
Figure 10: Handling reliable traps by timeout ............................................. 97
Figure 11: Processing traps.......................................................................... 99
Figure 12: Sample alarm mapping............................................................. 100
Figure 13: Processing alarms..................................................................... 102
Figure 14: Gathering real-time statistics.................................................... 103
Figure 15: Monitoring device network connection status ......................... 105
Figure 16: Running diagnostics ................................................................. 106

List of Figures

LIST OF TABLES
Table 1: ZMS system terminology .............................................................. 26

Table 2: Sequence for setup operations ....................................................... 27
Table 3: Network service (NWS.properties) variables................................ 31
Table 4: Fault manager (FaultService.properties) variables........................ 32
Table 5: Performance manager (PS.properties) variables ........................... 37
Table 6: Monitoring service variables ......................................................... 38
Table 7: Diagnostics service (DGS.properties) variables............................ 38
Table 8: Configuration synchronization service (CSS.properties) variables39
Table 9: Configuration service (CS.properties) variables ........................... 40
Table 10: Async service (Async.properties) variables ................................ 41
Table 11: Debug service (Debug.properties) variables ............................... 41
Table 12: Database utilities.......................................................................... 49
Table 13: Audit log fields ............................................................................ 80
Table 14: ADS.properties options ............................................................... 81
Table 15: Task log fields ............................................................................. 83
Table 16: Trap information.......................................................................... 85

List of Tables

ABOUT THIS GUIDE
Zhone Management System (ZMS™) is the network management system that

provides service-to-subscriber management for Zhone™ local loop network
elements, including Broadband Access Node (BAN™), Multi-Access Line
Concentrator (MALC™), Raptor, Z-Edge™, MXK™.
ZMS includes a comprehensive suite of applications that deliver fault,
configuration, performance, and security management functions as well as
operator account management. NetHorizhon™ is the application that
operators use to navigate, monitor, and manage objects in their networks.
Audience
This guide is written for the system administrator who installs and administers
the ZMS system and who sets up and manages operator accounts. As a reader
of this guide, you should be familiar with basic networking components such
as network devices, cards, physical ports, logical interfaces, and permanent
virtual circuits (PVCs). You should also be familiar with network
administrative tasks such as managing network components and operator
accounts.
Document organization
This guide contains the following information:
Read To learn about
Chapter 1, Overview, on page 19. System components and description.
Chapter 2, System Administration, on page 29. Administering ZMS components.
Chapter 3, ZMS database server administration, Administering the ZMS database.

on page 49
Chapter 4, Administering Operator Accounts, on Administering operator accounts.

page 65.

About This Guide
Read To learn about
Chapter 5, Monitoring ZMS Logs, on page 79. Monitoring logs.
Appendix A, How ZMS Manages Network Details of how ZMS manages resources on the network.
Elements, on page 89.
Appendix B, Traps and Alarms, on page 107. How SNMP traps from devices are mapped to ZMS alarms.
Appendix C, Modifying ZMS alarm descriptions, Modifying ZMS alarm descriptions.

on page 153.
Style and notation conventions

The following conventions are used in this document to alert users to
information that is instructional, warns of potential damage to system
equipment or data, and warns of potential injury or death. Carefully read and
follow the instructions included in this document.
Caution: A caution alerts users to conditions or actions that could

damage equipment or data.
Note: A note provides important supplemental or amplified

information.
Tip: A tip provides additional information that enables users to more

readily complete their tasks.
WARNING! A warning alerts users to conditions or actions that

could lead to injury or death.
WARNING! A warning with this icon alerts users to conditions or

actions that could lead to injury caused by a laser.
Typographical conventions
The following typographical styles are used in this guide to represent specific
types of information.
Bold Used for names of buttons, dialog boxes, icons, menus,

profiles when placed in body text, and property pages (or
sheets). Also used for commands, options, parameters in
body text, and user input in body text.
Fixed Used in code examples for computer output, file names, path
names, and the contents of online files or directories.
Fixed Bold Used in code examples for text typed by users.

Related documentation
Fixed Bold Used in code examples for variable text typed by users.
Italic
Italic Used for book titles, chapter titles, file path names, notes in
body text requiring special attention, section titles,
emphasized terms, and variables.
PLAIN UPPER Used for environment variables.

CASE
Command Syntax Brackets [ ] indicate optional syntax.

Vertical bar | indicates the OR symbol.
Related documentation
Refer to the following publications for additional information:
ZMS Installation Guide describes how to install the various components of
the ZMS system.
NetHorizhon User’s Guide describes how to provision your device using
NetHorizhon.
ZMS Release Notes contains the most current ZMS product information and
requirements.
OSS Gateway User’s Guide describes how to install, configure, and use the
OSS gateway application.
OSS Gateway Reference Guide describes the OSS Gateway configuration,
performance, and notification attributes.
OSS Gateway Release Notes contains the most current product information
and requirements.
MALC Hardware Installation Guide describes how to install the Multi-Access
Line Concentrator.
MALC Configuration Guide describes how to provision the Multi-Access
Line Concentrator.
MALC Release Notes contain the most current product information and
requirements.
MXK Hardware Installation Guide describes how to install the MXK.
MXK Configuration Guide describes how to provision the MXK.
MXK Release Notes contain the most current product information and
requirements.
Raptor XP Hardware Installation and Configuration Guide describes how to
install and configure the Raptor XP.
Raptor XP Release Notes contains the most current product information and
requirements.

About This Guide
Raptor Hardware Installation and Configuration Guide describes how to

install and configure the Raptor.
Raptor Release Notes contains the most current product information and
requirements.
Gigamus 3200/1600 Series documentation describes how to install and
configure the Gigamux 3200/1600.
Gigamus 6400 documentation describes how to install and configure the
Gigamux 6400.

Contacting Global Service and Support
Contacting Global Service and Support

If your product is under warranty (typically one year from date of purchase)
or you have a valid service contract, you can contact Global Service and
Support (GSS) for questions about this or other Zhone products, or for
Technical Support or Hardware Repairs.
Before contacting GSS, make sure you have the following information:
• Zhone product you are using
• System configuration
• Software version running on the system
• Description of the issue
• Your contact information
If your product is not under warranty or you do not have a valid service
contract, please contact GSS or your local sales representative to get a quote
on a service plan. You can view the options on our web site at
http://www.zhone.com/support/services/warranty.
Technical support
The Technical Assistance Center (TAC) is available with experienced support

engineers who can handle questions, assist with service requests, and help
troubleshoot systems.
Hours of operation Monday - Friday, 8 a.m. to 5 p.m, Pacific

(excluding U.S. holidays)
Telephone (North America) 877-ZHONE20 (877-946-6320)
Telephone (International) 510-777-7133
E-mail support@zhone.com
The Web is also available 24 x 7 www.zhone.com/support
to submit and track Service
Requests (SR's)
If you purchased the product from an authorized dealer, distributor, Value

Added Reseller (VAR), or third party, contact that supplier for technical
assistance and warranty support.

About This Guide
Hardware repair
If the product malfunctions, all repairs must be authorized by Zhone with a

Return Merchandise Authorization (RMA) and performed by the
manufacturer or a Zhone-authorized agent. It is the responsibility of users
requiring service to report the need for repair to GSS as follows:
• Complete the RMA Request form (http://www.zhone.com/account/sr/
submit.cgi) or contact Zhone Support via phone or email:
Hours of operation: Monday Friday, 6:30am-5:00pm (Pacific Time)
E-mail: support@zhone.com (preferred)
Phone: 877-946-6320 or 510-777-7133, prompt #3, #2
• Provide the part numbers and serial numbers of the products to be
repaired.
• All product lines ship with a minimum one year standard warranty (may
vary by contract).
• Zhone will verify the warranty and provide the customer with a repair
quote for anything that is not under warranty. Zhone requires a purchase
order or credit card for out of warranty fees.

OVERVIEW
This chapter introduces ZMS. It includes the following sections:

• ZMS system components, page 19
• Redundancy overview, page 22
• About the ZMS database, page 26
• ZMS system terminology, page 26
• Sequence of system setup tasks, page 27
ZMS system components

Zhone Management System (ZMS) is the network management system that
provides service-to-subscriber management for Zhone local loop network
elements, including Broadband Access Node (BAN), Multi-Access Line
Concentrator (MALC), Raptor, Sechtor 100A, and Z-Edge.
ZMS includes a comprehensive suite of applications that deliver fault,
configuration, performance, and security management functions as well as
operator account management. The ZMS system allows carriers and service
providers to operate networks efficiently and to rapidly deploy new services.
ZMS supports a connection with Operations System Support (OSS) gateway
to provide a published CORBA interface for bidirectional transfer of all
management information to the Zhone network, thus integrating ZMS
applications into service provider back-office systems and third-party
applications. Both OSS gateway modules (Corba or XML) have separate
licenses from ZMS.
ZMS is based on a distributed client/server network management architecture.
The components in the ZMS environment are:
• The ZMS application server is a UNIX process that provides a suite of
management applications to support all functional areas of network
management. The server responds to client requests to manage Zhone
network elements and updates the ZMS database.
• ZMS managers/services are entities that deliver network management
services:

Overview
Configuration services manager (CS) makes configuration changes to

network elements and provisions subscribers and end-to-end services
within the Zhone environment. Supports the use of templates, which
allow the operator to streamline configuration tasks. Handles element
software downloads.
Fault services manager (FS) handles traps and alarms from network
elements. Forwards traps to destination addresses as needed. Applies
rules to determine what action to take on alarms. Trap and alarm
information identifies network issues that need to be addressed.
Performance services manager (PS) tracks network performance data
in real time, collects interval statistics, and monitors the status of
network elements. This data allows service providers and subscribers
to track trends and service levels.
Administration services manager (ADS) enforces security through
operator authentication and authorization. Controls system access by
NetHorizhon operators based on operator login and assigned
permissions. Tracks and stores operator actions in an audit log.
Database service (DS) manages and stores network management data
in the ZMS database.
Configuration Synchronization service (CSS) ensures that network
elements, the ZMS database, and NetHorizhon clients remain
synchronized.
• ZMS database is an Oracle™ database that stores fault, configuration, and
performance data, as well as subscriber and operator information.
• NetHorizhon client is the Java application that operators use to navigate,
monitor, and manage objects in their Zhone Management System (ZMS)
networks. Objects are networking components such as network devices,
cards, physical ports, logical interfaces, and permanent virtual circuits
(PVCs).
The ZMS administrator determines the specific operations that are offered
to operators. If the ZMS administrator provides full ZMS permissions,
operators can perform the following types of operations from the
NetHorizhon application:
– View and monitor the status of network elements.
– Make configuration changes to network elements and provision
subscribers and end-to-end services within the Zhone SLMS
environment.
– View traps and alarms from network elements and configure alarm
forwarding to destination addresses, as needed.
– Track real-time and interval network performance statistics.
– Run diagnostics on network elements.
• Zhone network objects are Zhone network devices and their various
components.

ZMS system components
The actual functionality provided to the operator depends on the operator

permissions assigned by the ZMS administrator. If an operator does not have
permissions to a particular function, menu options that support that function
are hidden in NetHorizhon. For example, if the ZMS administrator does not
grant permission for the operator to run diagnostics, NetHorizhon hides that
function.
Figure 1 illustrates the ZMS system environment.
Figure 1: ZMS environment
Zhone Integrated Access Devices
ZMS Server
Network Service
Configuration Manager
Zhone Network Devices
Fault Manager
Performance Manager
Monitoring Service
Diagnostics Service
Accounting Manager
Database Service
ZMS
Administration Manager Database
Configuration Synchronization Service
OSS Gateway
OSS Gateway Client

NetHorizhon Client
NetHorizhon Client

Overview
Redundancy overview
ZMS provides a redundancy scheme with primary and standby ZMS
application servers as well as primary and standby ZMS database servers.
The ZMS application consists of four major components:
• Primary ZMS database
• Primary ZMS application
• Standby ZMS database
• Standby ZMS application
ZMS application servers and database servers can be installed on different
machines, with the restriction that primary and standby ZMS application
servers cannot be on the same machine.
ZMS supports the following configurations:
• A single machine configuration with the primary ZMS application and the
primary and standby databases installed on a single machine. This
configuration does not provide redundancy.
• A two machine configuration with the primary ZMS application and the
primary database installed on one machine, and the standby ZMS
application and standby ZMS database installed on a second machine.
• A three machine configuration with the primary ZMS application
installed on one machine, the primary ZMS database on a second
machine, and the standby ZMS application and standby ZMS database
installed on a third machine.
In the three machine configuration, if either the primary ZMS database server
or the primary ZMS application server fails, both the primary ZMS database
and primary ZMS application servers will be switched to standby ZMS
database and standby ZMS application on the third machine.

Redundancy overview
Figure 2: ZMS server and databases on a single machine

Zhone Integrated Access Devices
ZMS Server
Network Service
Configuration Manager
Zhone Network Devices
Fault Manager
Performance Manager
Monitoring Service
Diagnostics Service
Accounting Manager
Database Service
ZMS
Administration Manager Database
Configuration Synchronization Service
OSS Gateway
OSS Gateway Client

NetHorizhon Client
NetHorizhon Client
In the three machine configuration, if either the primary ZMS database server
or the primary ZMS application server fails, both the primary ZMS database
and primary ZMS application servers will be switched to standby ZMS
database and standby ZMS application on the third machine.

Overview
Figure 3: ZMS server and databases on a single machine
ZMS application
Primary ZMS
database
Machine 1
Figure 4: ZMS servers and database servers on 3 machines
Primary ZMS
database
Primary ZMS
application
Machine 1 Machine 2
Database
synchronization
Standby ZMS
database
(optional)
Standby ZMS
application
(optional)
Machine 3
ZMS application servers
The primary ZMS application server communicates with the managed devices
and the primary database server. An optional standby ZMS application server
can be installed on another machine on the network. If the primary ZMS
application server goes down, administrators can manually switch over to the
standby ZMS application server using scripts provided as part of the ZMS
installation.
Depending on the configuration, after a switchover of the ZMS application
server, the standby (now primary) ZMS application server can continue to

Redundancy overview
communicate with the primary ZMS database server, or the database servers
can also be switched over.
Note that only one ZMS application server can be active at a time.
ZMS database servers
The primary ZMS database is an Oracle 9i database that stores fault,

configuration, and performance data, as well as subscriber and operator
information for the devices being managed by the ZMS application server.
The standby ZMS database is a copy of the primary ZMS database and
provides redundancy in case the primary database server goes down.
ZMS provides scripts and processes for synchronizing the primary and
standby databases. The frequency of updates to the standby database can be
configured to meet site-specific needs.
Switchover
If either the primary ZMS application server or the primary database server
fails, you can switch over to a standby ZMS application server and/or standby
database server. The switchover is a manual process, but ZMS provides a
series of scripts and processes that facilitate the switchover. You can switch
over just the ZMS application servers, or the ZMS database servers, or both.
Note that switchover is non-revertive. If the original ZMS application or ZMS
database server becomes operational again, the administrator must manually
switch back.
Backups
ZMS supports the following types of database backups:

• Hot backup
• Cold backup
• Active Cold backup
ZMS writes database backups to disk. You should ensure that database
backups are archived to tape for disaster recovery purposes.
Hot backup
A Hot backup is used for the primary database only. It creates a copy of the
database while it is running and updates the copy at a user-defined frequency.
When the database is restored from a Hot backup, the database archive log
files are used to recreate the database as it existed at a user-defined point in
time.

Overview
Note: After a hot backup is performed, the error message “there are
no logs that need archiving” may appear in the log file. This message
indicates that all files were archived.
Cold backup
Cold backup is used for the standby database. It creates a copy of the database
and updates the copy at a user-defined frequency. When the database is
restored from a Cold backup, the database is recreated as it existed at the time
of the last update.
Active Cold backup

Active Cold backup is the same as a Cold backup but it’s done on the primary
database. Active Cold backups are typically done when ZMS is upgraded or
for site-specific administration or maintenance needs.
About the ZMS database

Oracle 9i is the relational database software used to store ZMS database
information. The software provides access to the full set of database tools,
including SQL queries, backup, and recovery of database files.
ZMS maintains a primary database and synchronizes it with a standby
database. For information on administrative tasks you may need to perform on
the ZMS database, see Chapter 3, ZMS database server administration
ZMS system terminology

Table 1 describes the terminology used in the ZMS system.
Table 1: ZMS system terminology
Term Definition
Admin The admin user can manage groups and users and grant permissions to the users. The
admin user cannot view or manage ZMS objects.
Default group The default group contains users and objects that were added before any groups were
explicitly created.
Group A group is a collection of users and objects for the purpose of access control.
Manager A manager is the entity that delivers a network management service by way of the
client. For example, the configuration manager delivers the provisioning service so that
operators can configure network elements and subscribers. The administration manager
enforces security through operator authentication and authorization.
Object An object is a ZMS network component, such as a network device, card, physical port,
logical interface, PVC, and so on.

Sequence of system setup tasks
Table 1: ZMS system terminology
Term Definition
Operator An operator or user can view and/or manage ZMS objects in his or her group. The
or permissions associated with an operator’s account determines the operations he or she
user can perform. An operator cannot add groups or users.
Permissions Permissions are the set of allowed actions that an operator can perform, ranging from
add, modify, and delete privileges to view-only privileges for ZMS objects.
Subscriber A subscriber is the remote user to which the Zhone system provides services.
User A user administrator can manage users in his or her group and grants permissions to the
Administrator users. The user administrator can also manage ZMS objects in his or her group, but
cannot add groups.
Sequence of system setup tasks

Table 2 shows the proper sequence for system setup tasks.
Table 2: Sequence for setup operations
Setup operation See
Install ZMS system components ZMS Installation Guide
Administer ZMS system components ZMS system components, page 19.
Create groups and operator accounts Administering Operator Accounts,

and assign permissions page 49.

Overview

SYSTEM ADMINISTRATION
This chapter describes how to administer the various components of the ZMS
system. It describes the following administrative tasks:
• Starting and stopping the ZMS server, page 29
• Configuring ZMS managers (properties files), page 30
Note: For instructions on installing the various components of the

ZMS system, see the ZMS Release Notes that shipped with this
release.
Starting and stopping the ZMS server

Note: Only one ZMS application server can be active at a time.
Starting the ZMS application server

1 Log into the primary ZMS application server (as root)
2 Issue the following commands to manually start the ZMS application
server:
cd /zms/bin
./zms start
The ZMS software displays and writes startup progress to the file
install_directory/opt/weblogic/zms.log. For details on the log file, see
Monitoring ZMS Logs, page 59.
To verify that the ZMS server has started, view the zms.log file. The
following message indicates the ZMS application server has successfully
started:
ZMS Started...
Stopping the ZMS application server

1 Log in to the primary ZMS application server (as root).
2 Issue the following command to shut down the ZMS application server:

System Administration
cd /zms/bin
./zms stop
Configuring ZMS managers (properties files)

To set environment variables and configure the various ZMS managers and
ZMS services, use a text editor to modify the appropriate .properties file
located in /install directory/lib/com/zhone/zms/properties.
Once you make any changes to a .properties file, you need to manually restart
the ZMS server for the changes to take effect. For instructions, see Starting
and stopping the ZMS server on page 29. Changes to the properties file are
network-wide and apply to all MALCs being managed by the ZMS server.
Ensure the settings apply to all MALCs in the network.
Note: Changes to the ZMS properties files are maintained during a

ZMS upgrade. For additional safe guards, it is recommended that you
backup the changed properties files before upgrading your device.
Changes to the ZMS properties files on the active ZMS server are not
automatically added to the properties files on the standby ZMS server.
To ensure compatibility between the active and standby servers, it is
recommended that you copy the changed properties files to the
standby server.
The following services with properties files are supported:

• Network service
• Fault manager
• Performance manager
• Monitoring service
• Diagnostics service
• Configuration synchronization service
• Configuration service
• Asynchronous service
• Debug service
• MTAC external relay alarm templates
• ONU/ONT serial number format (Hexa-decimal, Decimal)
Network service
To configure the network service, set the variables in the file NWS.properties.
Network service variables are listed in Table 3.

Table 3: Network service (NWS.properties) variables
Variable Default value Description
DefaultCpeCommunityString ZhonePrivate The CPE default community string.
MaxVarBindsToPoll 16 Devices at times fail to respond if too many OIDs are

requested at a time in the same snmpget command.
Hence defaulted to 16. If there are 40 OIDs to be polled,
ZMS server will divide them into 3 requests with
16+16+8 OIDs in each, and consolidate the response
before it sends to client.
mibsToLoad commonMibs Determins which mib groups to load. Removing unused

SLMSMibs mib groups will decrease startup time.
GigaMuxMibs Possible mib groups which are defined in

mibs.properties are:
IPDMibs
commonMibs - RFC and standardized mibs
GM6400Mibs
This is always needed and has to be first in list.
VPSMibs
SLMSMibs - mibs specifying SLMS mibs (MxK, Malc,
BSMibs Raptor, ...)
GigamuxMibs- mibs specifying GigaMux mibs
IPDMibs - mibs for IPD 4000/12000/8400 ...
GM6400Mibs - GigaMux 6400 device mibs
VPSMibs - Valence Power System mib
BSMibs - HP BitStorm device mibs
Verso8300Mibs - Verso 8300 device MIBs
SkyZhoneMibs - SkyZhone device MIBs
example value for when only SLMS products exist in
network:
mibsToLoad=commonMibs SLMSMibs
SNMPTimeOut 12000 Request timeout: base amount of time, in millisecond

increments, between SNMP retries from the server to
the Zhone device. With each retry, the server increases
the timeout value by a factor of three.
SNMPRetries 1 Request retries: number of SNMP retries the server

attempts before it declares a timeout. Note: With each
retry, the server increases the request timeout value by a
factor of three.
SNMPCommString ZhonePrivate SNMP Read–Only community name.
SNMPWriteCommString ZhonePrivate SNMP Read–Write community name.
SNMPRemotePort 161 Remote port on which messages are sent.
SNMPStartLocalPort 161 Local server port on which messages are received.
PollWakeUp 1000 Wake up timer: time, in millisecond increments, when

the manager checks for data to poll from each device.

Fault manager
The following properties files provide the flexibility to customize ZMS alarm
handling and processing.
• FSAlarmSeverity.properties file
• FSAlarmDescription.properties file
• FaultService.properties file
To configure the fault manager, set the variables in the following files:
• FaultService.properties. Fault manager variables are listed in Table 4.
You can customize the settings for email notifications, trap/alarm
forwarding, trap storm, alarm history log and other fault service settings.
• FSAlarmServerity.properties. Alarm severity levels can be changed by
modifying the FSAlarmSeverity.properties file. Alarm severities that are
commented out in the FSAlarmSeverity.properties (with a “#” sign)
derive their severity level from a trap. Alarm severities that are not
commented in the FSAlarmSeverity.properties file have the severity level
defined in the file. This severity assignment overrides the trap severity
setting on the MALC to one of the severity settings (Critical, Major,
Minor, Warning or Informational). Refer to Traps and Alarms on
page 107 for the SNMP traps that generate alarms.
• FSAlarmDescription.properties. You can customize individual alarm
descriptions to include one or more attribute values. To add an attribute to
an alarm description, use the format $$attribute_name$$, where
attribute_name is an existing attribute on the object generating the alarm.
This description is appended to the contact name assigned to the alarm
relay contact through the CLI or ZMS. For example, to identify what
particular object generated an alarm, you can add the object name to the
alarm description:
The status of AAL type 2 PVC ($$name$$) has gone down
For more information about modifying alarm descriptions, see Appendix
C, Modifying ZMS alarm descriptions, on page 153.
Table 4: Fault manager (FaultService.properties) variables
alarmForwardLogFile AlarmForward.log Name of the log file to capture

forwarded alarms.
alarmForwardPort 162 Server port on which alarms are

received.
alarmForwardStopList UpdateFailed Alarm(s) to be excluded from

UpdateCompleted forwarding to specified host(s) and
excluded from notification mail
PartialUpdateCompleted messages.

Table 4: Fault manager (FaultService.properties) variables (Continued)
alarmLogFile alarm.log Name of the log file to capture

alarms.
alarmMailRetryRetryCount 10 Number of times mail will be retried,

if there is a problem.
alarmMailRetryInterval 30000 Interval (in milli-seconds) at which

mail will be retried.
alarmMailSender — Name or e-mail address of the sender

of the alarm notification mail
messages (for example “ZMS Fault
Manager” or jsmith.xyz.com.). If the
name contains a blank character,
enclose the name in quotation marks.
alarmMailServer — Name of the mail server that manages

mail for the individuals to receive
mail message notification of alarms
(for example email.ny.xyz.com.)
authPassword — Authentication password.
authProtocol MD5 Authentication protocol.
criticalAlarmForwardHosts — Alarm forward host(s) to receive

critical alarm information. Use the
format:
<IP_address>|<community_name>
If you omit the community name,
ZMS uses the default community
name ZmsTrapPrivate. Separate the
entries by commas.
criticalAlarmMailRecepients — E-mail address of the recipients of the

critical alarm notification mail
messages (for example
jsmith.xyz.com.) Separate the
addresses by commas.
enableClearAlarmCheck true Enables or disables the ability to clear

alarms if the condition still exists on
the device. If set to true, ZMS will
check whether the alarm exists before
clearing it. If set to false, ZMS will
not check whether the alarm exists
before clearing it.
enableTrapSequencer false Set to true to enable trap sequencer.

Set to false to disable trap sequencer.
engineID — SNMP v3 engine ID.

external_relay_#_normal_state.deviceIP — Determines which relay state is

considered normal. # represents the
relay ID number. Valid values are
open (default value) and close.
A relay contact with a default state of
open causes ZMS to generate an
alarm when the state changes to
close. The ZMS alarm is cleared
when the state changes back to open.
For some elements, such as a device
fan, the default relay may need to be
set to close so that an alarm is
generated when a fan failure (open
circuit) occurs and the relay state
changes to open. Optionally, a device
IP address can be appended to the
EXTERNAL_RELAY_#_NORMAL
_STATE variable to apply the setting
only to the device with the specified
IP address.
informationalAlarmForwardHosts — Alarm forward host(s) to receive

alarm information.
Use the format:
entries by commas.
informationalAlarmMailRecepients — E-mail address of the recipients of the

informational alarm notification mail
keepAliveTrapInterval 600 Interval for posting a trap that ZMS

server is Up (in seconds).
mailClearedAlarms false Enables or disables the ability to mail

cleared alarms to all members listed
in zmsAlarmMailRecepients.
If sets to true, and if the properties
alarmMailServer, alarmMailSender,
and zmsAlarmMailRecepients are set
to non-empty values, and the alarm
that is cleared is not part of
alarmForwardStopList, the cleared
alarm will mailed to the all members
listed in zmsAlarmMailRecepients.

majorAlarmForwardHosts — Alarm forward host(s) to receive

major alarm information. Use the
format:
entries by commas.
majorAlarmMailRecepients — E-mail address of the recipients of the

major alarm notification mail
maxAlarmLogRecords 5000 Specifies the maximum number of

alarm log records stored in the alarm
history log. When the maximum is
reached, additional log records are
not recorded.
mibfile SNMPv2-MIB SNMP MIB to generate traps.
minorAlarmForwardHosts — Alarm forward host(s) to receive

minor alarm information. Use the
format:
entries by commas.
minorAlarmMailRecepients — E-mail address of the recipients of the

minor alarm notification mail
privPassword — Private password.
trapAuthKey ZmsTrapPrivate Trap authorization name.
trapCacheSize 1000 Specifies the number of traps cached

by ZMS. If cache is full and ZMS
receives more traps, those traps will
be dropped by ZMS. Because
increasing the cache size will have
memory and performance
implications, use caution when
modifying this value.

trapForwardLogFile TrapForward.log Name of the log file to capture

forwarded traps.
trapForwardPort 162 Port of the destination host to which

traps are forwarded.
trapForwardStopList zhoneTrapConfigSyncCha Trap(s) to be excluded from

nge forwarding to specified host(s).
trapLogFile trap.log Name of the log file to capture traps.
trapReceiverPort 162 Server port on which traps are

received.
trapSeqTimeout 30000 Timeout (in milliseconds) before the

fault manager requests the Zhone
device resend a missing trap.
trapSeqTrapWindowSize 5 Number of higher-numbered traps

received after a missing trap before
the fault manager requests the Zhone
device resend the trap.
trapStormThreshold 200 Used to identify a trap storm.

When ZMS receives traps from
device, ZMS caches the traps.
If ZMS has more traps in its cache
than specified by
trapStormThreshold, it declares that it
is receiving a trap storm from that
device. ZMS then stops receiving
traps from that device by turning off
trap destination and raising a
TRAP_STORM_ALARM on that
device.
ZMS then waits for a period of time
specified by trapStormTimeout. After
this period, ZMS clears the alarm,
retrieves active alarms from the
device and enables trap destination to
start receiving traps again from that
device.
Note that ZMS trap storm actions are
specific to a device. ZMS will
continue to receive and process traps
from other devices.

trapStormTimeout 60 The period of time (in minutes) ZMS

waits before declaring an end to a trap
storm. See the description for
trapStormThreshold.
While in trap storm mode and waiting
for timeout, you can manually end the
timeout period by right-clicking a
device and selecting Update Display
from Database.
username — SNMP v3 username.
warningAlarmForwardHosts — Alarm forward host(s) to receive

warning alarm information. Use the
format:
entries by commas.
warningAlarmMailRecepients — E-mail address of the recipients of the

warning alarm notification mail
zmsAlarmMailRecepients — If ZMS login failure alarm raising is

enabled. Every time user fails on the
login, a ZMS login failure alarm will
be raised, and an alarm notification
email with username and host IP
information will be sent out if
alarmMailServer, alarmMailSender,
and zmsAlarmMailRecepients are
specified in the property file.
Performance manager
To configure the performance manager, set the variables in the file

PS.properties. The performance manager variable is listed in Table 5.
Table 5: Performance manager (PS.properties) variables
LeaseTimeOut 1200000 Duration, in milliseconds, during which the manager polls

for performance data. NetHorizhon must renew the lease
within this period for the performance manager to continue
polling for data.

Monitoring service
To configure the monitoring service, set the variables in the file

MS.properties. Monitoring service variables are listed in Table 6.
Table 6: Monitoring service variables
PollRetries 0 The number of times ZMS will attempt to reach the

device before declaring the device unreachable.
PollTimeout 5 The number of seconds before an SNMP poll

request to a device timeouts.
PollInterval 120 Frequency of poll requests, in seconds, made to the

network to determine if the device is reachable.
ServicePollInterval 60000 The amount of time, in millisecond increments,

that the monitoring service startup class waits
between retries to locate a ZMS service that is not
available.
ServicePollRetry 100 The number of times the monitoring service startup

class tries to obtain a reference to a ZMS service
before failing.
Diagnostics service
To configure the diagnostics service, set the variables in the file

DGS.properties. The diagnostics service variable is listed in Table 7.
Table 7: Diagnostics service (DGS.properties) variables
LeaseTimeOut 360000 Duration, in milliseconds, during which the manager polls

for diagnostics test results. NetHorizhon must renew the
lease within this period for the diagnostics service to
continue polling for test results.
Configuration synchronization service
To configure the configuration synchronization service, set the variables in

the file CSS.properties. Configuration synchronization service variables are
listed in Table 8.

Table 8: Configuration synchronization service (CSS.properties) variables
useDevicePortDescriptions true Set to false to set the port description field as a

ZMS only field. It will only be stored in ZMS not
on device.
deleteProcessedUpdateFiles true Set to true to have configuration synchronization

service deletes update files once they have been
processed. Update files that are not successfully
processed are not deleted.
ftpUserName — FTP user on the ZMS server host, which allows the
configuration synchronization service to receive
update records from devices.
initialPollWait 15000 The amount of time, in milliseconds, that the

configuration synchronization service waits before
first polling for the update file transfer status.
locateFullUpdateRetry 5000 The amount of time, in millisecond increments,

that the configuration synchronization service
waits between retries to locate the file containing
full update records. The full update (synchronize
with device) request timeout value is the product of
this variable and the numFullUpdateStatusPolls
variable.
locateUpdateRetry 2000 The amount of time, in millisecond increments,

that the configuration synchronization service
waits between retries to locate the file containing
partial update records. The partial update request
timeout value is the product of this variable and the
numUpdateStatusPolls variable.
numFullUpdateStatusPolls 72 The number of times the device polls for the full
update file transfer status before CSS times out.
The full update (synchronize with device) request
timeout value is the product of this variable and the
locateFullUpdateRetry variable.
numUpdateStatusPolls 24 The number of times the device polls for the partial
update file transfer status before CSS times out.
The partial update request timeout value is the
product of this variable and the locateUpdateRetry
variable.
updateFileLocation — The path on the server where to store the file

containing update records.
Configuration service
To configure the configuration service, set the variables in the file

CS.properties. Configuration service variables are listed in Table 9.

Table 9: Configuration service (CS.properties) variables
auto-delete-cc-pvcs true When an ATM Cross Connect is deleted, this

determines whether the pvcs # that it cross
connects should be deleted automatically.
auto-delete-related-voice true This flag determines whether items related to voice

connections are deleted when the voice connection
is deleted, i.e.: Cids, Crvs, Vcls.
setCCnameOnDevice false Starting in 1.12.2, the device can store the

cross-connect name as handleId. The handleId field
is only 16 chars, and ZMS has always allowed 32
char CC name.
The handleId field was added just for Etisalat and
they agreed to a 16 char handleId. However, we
don't want to force other customers to shorten all of
their cross-connect names.
use-alternate-bridge-name false Bridges on top of bond groups create the bridge

name by appending "-n2nbond-vlan" to the
physical (bond group) name. Since the bridge
name has to be <= 35 chars, the max bond group
name is 22 chars. In order to allow longer bond
group names, an alternate bridge name format can
be used.
The alternate bridge name is physicalName-xx.
Where xx is 01-99. ZMS will ensure that the
bridge name is unique.
csPollInterval 5000 Poll interval for finding out whether the poll
(example : software download or restore) operation
has been completed in msecs.
5000 msecs is 5 secs.
csPollNumOfTimes 200 Max number of times to poll. The total time for
polling is equal to
csPollInterval*csPollNumOfTimes.
maxBridgesAllowed 12288 Maximum number of bridges that can be created

per device.
Asynchronous service
To configure the asynchronous service, set the variables in the file

Async.properties. Async variables are listed in Table 10.

Table 10: Async service (Async.properties) variables
maxConcurrentHeavyWeightTasks 3 Maximum number of heavy weight tasks to run at

the same time.
Heavy weight tasks are tasks that use significant
ZMS (DB or Java) resources.
Current heavy weight tasks are config sync.
maxConcurrentLightWeightTasks 10 Maximum number of light weight tasks to run at

the same time.
Light weight tasks are tasks that do not use
significant ZMS (DB or Java) resources.
Current light weight tasks are image download and
device backup.
Debug service
To configure the debug service, set the variables in the file Debug.properties.
Debug service variables are listed in Table 11.
Table 11: Debug service (Debug.properties) variables
AdminService 1 Debug setting on admin service:

0 - Debug Off
1 - Exception, minimum output
2 - Method, in which method
3 - Info, detailed info.
AsyncService=2 2 Debug setting on async service:

0 - Debug Off
CommonService 1 Debug setting on common service:

0 - Debug Off

Table 11: Debug service (Debug.properties) variables (Continued)
ConfigService 1 Debug setting on config service:

0 - Debug Off
3 - Info, detailed info
ConfigSyncService 2 Debug setting on config sync service:

0 - Debug Off
DataService 1 Debug setting on data service:

0 - Debug Off
PerformanceService 1 Debug setting on performance service:

0 - Debug Off
NetworkService 2 Debug setting on network service:

0 - Debug Off
DiagService 1 Debug setting on network service:

0 - Debug Off
MonitoringService 2 Debug setting on network service:

0 - Debug Off

FaultService 2 Debug setting on network service:

0 - Debug Off
EventManager 1 Debug setting on network service:

0 - Debug Off
LeaseManager 1 Debug setting on network service:

0 - Debug Off
OSS 1 Debug setting on network service:

0 - Debug Off
OSSXML 1 Debug setting on network service:

0 - Debug Off
DumpRestoreService 1 Debug setting on network service:

0 - Debug Off
addTime 1 Additional Debug flags

0 - Turn Flag off
1 - Turn Flag on
addThreadName 1 Additional Debug flags

0 - Turn Flag off
1 - Turn Flag on

showExceptions 1 Additional Debug flags

0 - Turn Flag off
1 - Turn Flag on
errsToSysErr 0 Additional Debug flags

0 - Turn Flag off
1 - Turn Flag on
flushTime 1000 Time in milliseconds between debug buffer file

writes.
errorFile ZMSErrors.log Filenames for errors and debugging.
debugFile debug.log Filenames for errors and debugging.
logDir /weblogic This directory name must contain the full path, and
must use standard
# URL style forward slashes to represent
directories.
e.g.: (NT) c:/zhone or (Unix) /weblogic
The dos style (c:\zhone) is not standard URL
syntax, so it will not work
MTAC external relay alarm templates
The following properties files provide the templates to customize MTAC

external alarm handling and processing.
• UDAlarmSeverity_template.properties
Refer to Changing the normal relay state to close on page 45 for the
detail.
• UDAlarmDescription_template.properties
Refer to Changing the alarm severity of external relay alarm on page 45
for the detail.
• UserDefined_template.properties
Refer to Changing the alarm description of external relay alarm on
page 46 for the detail.
Follow the instructions and examples in these property files to modify the
entries and variables. And also note that:
• MTAC external relay alarm properties files are not used until “_template”
is removed from their names.
• The “#” symbol in the properties files means comment. Any lines that
start with “#” are ignored.

Changing the normal relay state to close

In order to create an alarm for an external input, MALC must know the
normal state (open or closed) of the relay. ZMS allows the normal relay states
to be defined in the UserDefined_template.properties. By default, the normal
state is open.
• If the normal state is defined as “open”, an alarm will be generated when
the relay transitions to a close state. The alarm will be cleared when the
relay transitions back to open.
• If the normal state is defined as “close”, an alarm will be generated when
the relay transitions to an open state. The alarm will be cleared when the
relay transitions back to closed.
It is possible to define the normal state on a device or on the entire network.
For example:
• To change the normal state of relay with Relay ID 2 on the MALC with IP
address 100.100.100.100, enters this entry into the properties file:
EXTERNAL_RELAY_2_NORMAL_STATE.100.100.100.100=closed
• To change all relays with Relay ID 2 on the entire network, enters:
EXTERNAL_RELAY_2_NORMAL_STATE=closed
All entries that specify an IP address take precedence over entries without an
IP address. For example, if both the following entries exist:
EXTERNAL_RELAY_3_NORMAL_STATE=closed
EXTERNAL_RELAY_3_NORMAL_STATE.100.100.100.100=open
Relay 3 on the 100.100.100.100 device will have the open normal state. And
relay 3 on all other devices will have the close normal states.
Note: Existing alarms are not automatically re-evaluated. Perform an

update display from database from the device node to update the
current alarms.
Changing the alarm severity of external relay alarm

MTAC external relay alarm severity levels (Critical=1, Major=2, Minor=3,
Warning=4 or Informational=5) can be changed by modifying the
UDAlarmSeverity.properties file. By default, the MTAC relay alarm severity
level is 4. Refer to Traps and Alarms on page 107 for the traps that generate
MTAC relay alarms.
You can change the MTAC relay alarm severity level on a device or on the
entire network. For example:
• To change the alarm severity of all relay with Relay ID 2 on the MALC
with IP address 100.100.100.100, enters this entry into the properties file:
EXTERNAL_RELAY_2_ALARM.100.100.100.100=3
• To change all relays with Relay ID 2 on the entire network, enters:

EXTERNAL_RELAY_2_ALARM=1
EXTERNAL_RELAY_3_ALARM=3
EXTERNAL_RELAY_3_NORMAL.100.100.100.100=1
A relay 3 alarm on the 100.100.100.100 device will be critical. And a relay 3
alarm on all other devices will be minor.
Note: Existing alarms are not automatically re-evaluated. To change

the severity on existing conditions, the alarm will need to be cleared
and re-added.
Changing the alarm description of external relay

alarm
The default alarm description for an external relay alarm is Alarm on
External Relay relayID ($$zhoneExternalRelayName$$).
You can customize individual MTAC external relay alarm descriptions in the
UDAlarmDescription.properties file.
• To change the alarm description for the external relay alarm on the
MALC with IP address 100.100.100.100, enters:
EXTERNAL_RELAY_2_ALARM.100.100.100.100=MTAC extenal
alarm
• To change the alarm description for all external relay alarms with Relay
ID 2, enters:
EXTERNAL_RELAY_2_ALARM=MTAC external alarm
EXTERNAL_RELAY_3_ALARM=MTAC
EXTERNAL_RELAY_3_ALARM.100.100.100.100=ALARM
A relay 3 alarm on the 100.100.100.100 device will show as ALARM. And a
relay 3 alarm on all other devices will show as MTAC.
ONU/ONT serial number format (Hexa-decimal, Decimal)
ZMS supports one type of ONU/ONT serial number format displayed or set at
a time. It could be either decimal or hexa-decimal.
To switch the ONU/ONT serial number format between decimal and
hexa-decimal, use the UseOnuFsanSN flag in NetHorizhon.properties and
CS.properties files. If this flag is false (this is the default value), all ONT
serial numbers will be displayed and set in decimal format. If this flag is true,
all ONT serial numbers will be displayed and set in hexa-decimal format.

Changing serial number format from decimal to hex

To change from decimal to hex format:
1 Set value = true for UseOnuFsanSN flag in
/zms/client/lib/com/zhone/zms/properties/NetHorizhon.properties
2 Set value = true for UseOnuFsanSN flag in
/zms/lib/com/zhone/zms/CS.properties
3 Restart ZMS server.
4 Run /zms/bin/publish_zms
5 Restart clients.


ZMS DATABASE SERVER ADMINISTRATION
This chapter describes basic ZMS database server administration. It includes:

• ZMS database utilities, page 49
• ZMS database redundancy maintenance procedures, page 51
• Database backup and restore, page 55
• Cleanup utilities, page 59
• Common database administration procedures, page 60
• Database utilities FAQs, page 61
• Backing up database archive logs, page 62
• Adding swap space to a Solaris server, page 62
ZMS database utilities

A typical ZMS installation will include the following scripts and cron jobs to
monitor and maintain the database. Optionally, change the default oracle user
account. The default user is oracle.
set ZMS_ORACLE_USER = oracle2
At installation time, you can configure many of the parameters for these
scripts. After the installation is complete, modify these scripts using the
crontab command.
Table 12: Database utilities
Script Location Run as Description
active_cold_backup.sh zms/bin $ZMS_ORACLE_USER Performs a manual Cold backup of the

primary database. This script must be
executed prior to performing maintenance
on the ZMS application or databases.
active_cold_restore.sh zms/bin $ZMS_ORACLE_USER Restores the primary database from a

manual Cold backup taken using
active_cold_backup.sh script.

ZMS database server administration
Table 12: Database utilities
Script Location Run as Description
cold_backup.sh zms/bin $ZMS_ORACLE_USER A cron job that creates a Cold backup of a

standby database.
This is only scheduled on the standby ZMS
database server if you have a standby
database and decided to perform Cold
backup.
dbmonitor zms/bin $ZMS_ORACLE_USER A cron job that monitors the health of

Oracle database and sends an alert if it
detects one of the following errors:
The primary or the standby database goes
down.
The database listener is in a fault state.
It detects and error in a log file. The log
files are located in /opt/oracle/product/
9.2.1/admin/ZhoneCS/bdump.
hot_backup.sh zms/bin $ZMS_ORACLE_USER A cron job that creates a Hot backup of a

primary database.
This is only scheduled on the primary ZMS
database server if you decide to perform
Hot backup.
ora_cleanup.sh zms/bin $ZMS_ORACLE_USER A cron script that deletes the old log files
and trace files. Directories to be deleted are
listed in /opt/oracle/cfg/cleanup.cfg.
ora_compress.sh zms/bin $ZMS_ORACLE_USER A cron job that compresses the old log files
and trace files. Directories to be
compressed are listed in /opt/oracle/cfg/
compress.cfg.
standby_admin.sh zms/bin root Provides a menu of standby database

maintenance scripts.
sync_standby.sh zms/bin $ZMS_ORACLE_USER A cron job that synchronizes the standby

database with the primary database,
whether the standby database is on a
remote server or local server.
This is only scheduled only the primary
ZMS database server if your installation
includes a ZMS standby database.
You can modify the re-sync frequency of
the standby ZMS database by modifying
the Oracle user cron.
If the sync_standby.sh job fails an alert will
be sent to the DBA pager address
configured as part of the installation.

ZMS database redundancy maintenance procedures

This section describes the following procedures related to database
redundancy:
• Refreshing the standby database on page 51
• Swapping ZMS application servers on page 52
• Activating a standby database on page 52
• Switching back to a primary database on page 54
Refreshing the standby database

Refreshing the standby database recreates a standby database on a local or
remote host. When executed, this script copies the database files only, not the
Oracle software and other configuration files.
Note: This process will shut the primary database down until the
standby database is refreshed.
You should refresh the standby database in the following situations:

• After upgrading the ZMS database server
• After adding data files to the primary database
• After restoring the primary database from a backup
• After any major database changes
• At regular intervals, such as once a month or once a quarter, to keep the
primary and standby database in sync.
Note: The standby database will be refreshed automatically as part of

activation of standby database if the primary database machine is
reachable and as port of switchover from standby to production
database.
To refresh the standby database:

1 Log in to ZMS primary database server (as root).
2 Issue the following command to run the standby database administration
script:
/opt/oracle/zms/bin/standby_admin.sh
The database admin menu appears, listing the options:
Standby Database Admin Menu
1) Refresh Standby Database (Deletes and recreates standby DB,
doesn't install Oracle binaries)
2) Activate Standby Database (Opening Standby DB for users due
to problem with active DB)
3) Switch back from Standby to Production

4) Restore Active or Standby DB from COLD backup

5) Shutdown Standby Database
6) Start Standby Database
q) Quit
Please select Standby Admin Option:
3 Select option 1: Refresh Standby Database
Activating a standby database

Activating a standby database is a manual process that may be done if the
primary database goes down. If you are swapping ZMS application servers,
make sure you have switched over to the standby database before swapping
the ZMS application servers.
To activate a standby database:
1 Log in to the standby ZMS database server (as root).
script:
q) Quit
3 Select option 2: Activate Standby Database

4 If you need to switch to a standby ZMS application server, proceed with
Swapping ZMS application servers, next.
5 Log in to the active ZMS application server (as root).
6 Update the /weblogic/config/ZMS/config.xml file to refer to the new
active database server.
Swapping ZMS application servers

This procedure can be used to switch between ZMS application servers (either
from primary to standby or from standby to primary).
If you are switching from a primary ZMS application server to a standby ZMS
application server, perform the switchover in the following order:

Note: Changes to the ZMS properties files on the active ZMS server
are not automatically added to the properties files on the standby
ZMS server. To ensure compatibility between the active and standby
servers, it is recommended that you copy the changed properties files
to the standby server before switching ZMS application servers.
1. Switch to the standby database.

2. Switch the standby ZMS application server
If you are switching back from an active ZMS application server to the
original primary ZMS application server, perform the switchover in the
following order:
1. Create an active Cold backup of the active database (the original standby
database).
2. Switch to the original ZMS application server.
3. Switch to the original primary database.
4. Refresh the standby database.
Caution: Before switching to a different ZMS application server,

make sure that:
The /etc/hosts file on both machines must contain both server names
and IP addresses.
The /.rhosts file on both machines must contain an entry for the other
machine.
Switching over to a different ZMS application server requires the IP address

of the ZMS application servers be switched. After changing the IP address of
the ZMS application server to match the IP address of the inactive server, the
server is rebooted.
To switch to a different ZMS application server:
1 Log in to the standby ZMS application server (as root).
2 Execute the following command to make the standby ZMS application
server the primary ZMS application server:
/zms/bin/swap_zms_servers.ksh ipAddress hostname
where ipAddress is the IP address of the inactive primary ZMS
application server and hostname is the hostname of the inactive primary
ZMS application server.
Caution: Make sure you enter the correct IP address. Failure to

do so may require a reinstallation of the ZMS server machines.

Switching back to a primary database

Database redundancy is non-revertive. If a standby database has been made
primary, you must manually switch back to the original primary database, if
desired.
Note: During the switchover process, neither the primary nor the
standby database server will be available for between 25 minutes and
1 hour, depending on the size of the database.
To switch back to the original primary database:

1 Log in to the primary ZMS database server.
2 Create an active Cold backup of the active database (the original standby
database).
See the Active cold backup of the primary database on page 56 for
information.
3 Swap the ZMS application server, if necessary.
See the Swapping ZMS application servers on page 52 for information.
4 Log in to the standby ZMS database server (as root).
script:
q) Quit
6 Select option 3: Switch back from Standby to Production

The script copies the required database files from the active standby
database server to the original primary database server and starts the
database on the primary database server.
7 Stop and start the ZMS server:
/zms/bin/zms stop
/zms/bin/zms start
8 After the database has switched back, verify that the ZMS application
server and the database are operational by launching ZMS.

Database monitoring
9 Log in to the primary ZMS database server (as root).

script:
q) Quit
11 Log in to the primary ZMS application server (as root).

12 Update the /weblogic/config/ZMS/config.xml file to refer to the new
active database server.
Database monitoring
As part of the ZMS database installation, dbmonitor, a database monitoring
script, gets scheduled. his script monitors the following:
• Database status (up and down)
• TNS listener status (up and down)
• Error messages in the alert log file
If the database is down, the TNS Listener is down or if there is an error
message in the alert log file (/opt/oracle/product/9.2.1/admin/ZhoneCS/
bdump/alert_ZhoneCS.log) an alert will be mailed to the DBA pager email
address specified during the installation.
Database backup and restore

This section describes the following types of backup.
• Active cold backup of the primary database on page 56
• Cold backup of the standby ZMS database on page 56
• Hot backup of the primary ZMS database on page 57

Active cold backup of the primary database

Before upgrading ZMS or performing any major maintenance on the UNIX
server, Zhone recommends that you perform a Cold backup of the primary
ZMS database. Make sure primary ZMS application is not running before you
start the Cold backup and no one is connected to the database.
The script shuts down the database and performs a full backup of the database
files.
Note that you can find the backups at /opt/oracle/zms/backup, even if you
enter a different directory name. There is a soft link from /opt/oracle/zms/
backup to actual backup location.
Note: Zhone does not recommend or support scheduled Cold

backups of the primary ZMS database server.
1 Log in to the primary ZMS database server (as ZMS_ORACLE_USER).

2 As the user ZMS_ORACLE_USER, issue the following commands to set
the UNIX environment to the ZMS database server:
cd /opt/oracle/zms/env
source cs.env
3 Issue the following commands to execute the backup script:
cd /opt/oracle/zms/bin
./active_cold_backup.sh
Note: It is recommended that you copy the ZhoneCS_<date>.tar

file to another location in case you need to remove the ZMS
installation.
When the backup completes, the script restarts the ZMS database server.
It then displays the following message and returns to the UNIX prompt:
Backup Complete
Cold backup of the standby ZMS database

You can schedule a Cold backup for your standby database only. During the
installation if you decided to perform a Cold backup, you will find a
cold_backup.sh job in Oracle cron.You can change the frequency and time of
this job by using the crontab command.
When you run the cold_backup.sh script on the standby database server,
it:
– Disables the sync_standby.sh job on primary ZMS database server.
– Shuts down the standby ZMS database.
– Backs up the database files to the directory specified during the
installation.
– Enables the sync_standby.sh job.

Database backup and restore
For the status of the Cold backup, check the Cold backup log file:
/opt/oracle/log/cold_back_up_log_<date>
Hot backup of the primary ZMS database

You can schedule a Hot backup for your primary ZMS database only. During
the installation if you decided to perform Hot backup, you will find a
hot_backup.sh job in the Oracle cron. You can change the frequency and time
of this job by using the crontab command to modify Oracle cron.
An email message is sent to the DBA operator. address specified during
installation whenever a successful backup occurs.
When you run the hot_backup.sh script on primary database server, it will
copy the data files to the backup location specified during the installation.
During a Hot database backup is up and running, there is no down time.
For the status of the Hot backup, check the Hot backup log file:
/opt/oracle/log/hot_back_up_log_<date>
Restoring the database
There are two methods of restoring the database from a backup:

• Restoring the database from a Cold backup on page 57
• Restoring from a Hot backup on page 58
Restoring the database from a Cold backup
Caution: Only qualified DBAs should perform an active cold

restore. For more information, contact GSS.
You can restore the active or the standby database from a Cold backup that
was made of the standby database. You might need to restore from an active
cold backup if an upgrade fails and you need to revert it back to the active
Cold backup taken prior to the upgrade. Restoring from a Cold backup will
restore the database the state it was in at the time of the last backup.
1 Log in to standby ZMS database server (as root).
script:


q) Quit
3 Select option 4: Restore Active or Standby DB from COLD backup

The script copies the required database files from the Cold backup of the
standby database to either the primary or standby database.
4 You will be given list of available backups to restore from, enter the
directory name from which you would like to restore the database from.
5 When prompted enter the database you would like to restore (primary
ZMS database or standby ZMS database)
6 After the restore is complete, select option 1: Refresh Standby
Database.
Restoring from a Hot backup

Each recovery scenario is different. Zhone recommends that each
installation site have a qualified DBA in their staff to perform a recovery
using the Hot backups. Contact GSS for additional support.
Backup files
All the backup files are compressed. You should copy these backup files to
offline storage. The ora_cleanup.sh script deletes the old backup files. Make
sure there is sufficient space on this disk for successful backups and also back
them to offline storage before they get deleted.
If the backup fails an email alert will be sent to the DBA pager address. If the
backup is successful, an email message will be sent to the Operator email
address.
You can modify the backup directory by modifying the
BACKUP_LOCATION variable in the following files:
• /opt/oracle/cfg/primary.cfg file for the primary database
• /opt/oracle/cfg/standby.cfg file for the standby database
If you change the BACKUP_LOCATION you must do the following.
• For a standby database, modify standby configuration file, /opt/oracle/
cfg/standby.cfg on the primary ZMS database server to include the same
information.
• Modify /opt/oracle/cfg/cleanup.cfg to include the new backup directory
name. Otherwise old backup files will not be deleted and your backups
will fail.

Cleanup utilities
• Rename /opt/oracle/zms/backup directory and create a soft link to that

directory. For example:
BACKUP_LOCATION=/data
#mv /opt/oracle/zms/backup /opt/oracle/zms/backup.save
# ln –s /data /opt/oracle/zms/backup
Cleanup utilities
As part of the ZMS installation, the following Oracle cron jobs are scheduled
to perform maintenance on the Oracle database files:
Script Modified by
ora_cleanup.sh /opt/oracle/cfg/cleanup.cfg
ora_compress.sh /opt/oracle/cfg/compress.cfg
You can modify the frequency of these jobs by using the crontab command to
modify the Oracle user cron.
The configuration files control which files get deleted or compressed, and
how often.
For example, the following is an example of the cleanup.cfg file.
#
Format=Directory_Name:sub_directories:Owner_of_files:days_old_files_will_be_de
leted
#
#
/opt/oracle/log:*:ALL:30
/opt/oracle/product/9.2.1/rdbms/audit:*:oracle:30
/opt/oracle/product/9.2.1/admin/ZhoneCS/udump,cdump,bdump:*:oracle:30
/opt/oracle/product/9.2.1/admin/CSStndby/udump,cdump,bdump:*:oracle:30
/opt/oracle/oradata/ZhoneCS/archive:*:oracle:5
/opt/oracle/zms/backup:*:oracle:5
/ora-backup/oraback:*:oracle:3
To modify the script so that it deletes the files in /opt/oracle/log after 60 days,
change:
to
The following is an example of the compress.cfg file:
# Enter the directory names which needs to be compressed
#
Format=Directory_Name:sub_directories:Owner_of_files:days_old_files_will_be_de
leted

#
#
/opt/oracle/product/9.2.1/rdbms/audit:*:oracle:3
/opt/oracle/product/9.2.1/admin/ZhoneCS/udump,cdump,bdump:*:oracle:3
/opt/oracle/product/9.2.1/admin/CSStndby/udump,cdump,bdump:*:oracle:3
/opt/oracle/oradata/ZhoneCS/archive:*:oracle:1
To modify the script so that it compresses the files in /opt/oracle/log after 1

day, change:
to
Common database administration procedures

This section describes the following ZMS database procedures you might
need to perform to configure and maintain your ZMS database:
• Configuring ZMS managers on page 60
• Changing the administrator password on page 60
Configuring ZMS managers

To set environment variables to configure the various ZMS managers and
ZMS services, use a text editor to modify the appropriate .properties file
located in /<install directory>/lib/classes/com/zhone/zms/properties. For
details on environment variables, see Configuring ZMS managers
(properties files) on page 30.
Once you make any changes to a .properties file, you need to manually
restart the ZMS application server for the changes to take effect. For
instructions, see Starting and stopping the ZMS server on page 29.
Changes to the properties file are network-wide and apply to all Zhone
devices being managed by the ZMS server. Ensure the settings apply to
all MALCs in the network.
Changing the administrator password

To log in as a ZMS database administrator, use the user name zdba and the
password zdba. As the database administrator, you have full privileges to the
ZMS database server.
It is highly recommended that you change the administrator password to a
private password. Use the following procedure to do so:
1 Log in to the primary ZMS database server, using the user account
ZMS_ORACLE_USER.
2 Issue the following command to change the password:

Database utilities FAQs
sqlplus /nolog
SQL>connect /as sysdba
SQL>alter user zdba identified by new_password;
exit
where new_password is the new private password for the user.

Be sure to record the new password, so you can provide it to any
administrator who needs to upgrade or maintain the ZMS database server.
Database utilities FAQs

This section provides answers to frequently asked questions about the ZMS
database utilities.
What is the name of the configuration file the dbmonitor reads?
/opt/oracle/cfg/standby.cfg
Where can I find the dbmonitor log files?
/opt/oracle/log/dbmonitor_yymmdd
where yymmdd is the year, month, and day.
How to disable the dbmonitor for a particular database?
Edit /opt/oracle/cfg/primary.cfg and set

MON_DB_FLAG=N
How do I disable the dbmonitor?
Use the Oracle crontab command to comment out the dbmonitor line.
How do I add/remove an email address from DBA Pager or Operators?
Edit /opt/oracle/cfg/primary.cfg and modify DBA_PAGER variable to add/

remove email addresses. All the email address must be included in double
quotes and separated by spaces.
For example:
DBA_PAGER="dba@zhone.com backupdba@zhone.com"
OPERATORS="jdoe@zhone.com scott@zhone.com"

How do I exclude some common benign Oracle errors in the alert log
files?
Edit /opt/oracle/cfg/primary.cfg and modify the EXCL_ORA_ERRORS

variable to include the benign error message:
For example, if you want to exclude error message ORA-2433, edit the /opt/
oracle/cfg/primary.cfg as follows:
EXCL_ORA_ERRROR= "ORA-1234 ORA-2345 ORA-2433"
What do I do when you find errors in the alert log?
Fix the problem listed in the alert log file and comment out the particular error
line which starts with ORA. For example:
#ORA
Backing up database archive logs

The ZMS system generates database archive logs, listing database activity.
ZMS uses these logs to ensure that a standby database remains synchronized
with the ZMS database. ZMS generates the archive logs to the path:
opt/oracle/oradata/ZhoneCS/archive. The logs are named dynamically and
have the suffix .ARC.
Be aware that these archive logs can quickly become large, especially during
periods of high activity. If the files reach directory capacity, the ZMS database
halts until more space becomes available. Twice daily (at 800 hours and 2000
hours), ZMS runs an automated process that purges archive files older than 24
hours.
Keep in mind that the archive logs are required in the recovery process,
especially if the standby database is not used as part of your install. The ZMS
database administrator should make backup copies of the archive logs before
the logs are purged by the automated process. Do not delete the logs without
saving them to permanent medium.The automated purging process does not
back up archive logs. If the typical activity of your system causes the archive
directory to fill, increase the available disk space over the 1 GB recommended
size.
Adding swap space to a Solaris server

The ZMS application server requires swap space equal to twice the amount of
RAM. The following procedure can be used to all additional swap space to a
Solaris system while it is running and without repartioning the hard drive.
Note: Do not create the swap file in /tmp or in /var/run.

Adding swap space to a Solaris server
Adding swap space

1 Make a swap file of the desired size using the following command.
mkfile size [ k | b | m ] filename
For example, to make a 1 GB file in the /opt partition:
mkfile 1024 m /opt/swapfile
2 Add the swap file to the existing swap with the following command.
swap -a filename
For example:
swap -a /opt/swapfile
3 Edit the /etc/vfstab file and add the following line so that the swap file
will be added if the system is rebooted.
swap will be added if the system is rebooted.
/path/filename - - swap - no -
For example:
/opt/swapfile - - swap - no -


ADMINISTERING OPERATOR ACCOUNTS
This chapter describes how to use NetHorizhon to set up operator accounts

and how to and assign operator permissions. It includes the following
sections:
• Overview, page 65
• Administering groups and operators as the admin user, page 68
• Configuring security policy as the admin user, page 71
• Administering operators as a user administrator, page 74
• Account information for operators, page 77
• About activating operator accounts, page 77
Overview
Before you set up operators and assign permissions, you should understand
how they are defined and how they function.
How objects are grouped
Operators and objects are associated with particular groups for the purpose of
access control.
When operators are added, they are added to a particular group:
• The admin user can add an operator to any group.
• A user administrator can add an operator only to the user administrator’s
group.
Each operator can be assigned to only one group. An operator can manage
objects only in his or her own group.
When objects are added to the network, they inherit the group ID of the
operator performing the add operation:
• Once a region is added, all child objects added to the region (devices,
cards, ports, and so on) inherit the same group ID.
• Once a customer is added, all child objects added to the customer
(subscriber, voice gateways, and so on) inherit the same group ID.

Administering Operator Accounts
• Once a subscriber is added, all child objects added to the subscriber

(voice gateways, and so on) inherit the same group ID.
All operators and objects that were added before any groups were explicitly
added inherit the default group ID.
How permissions function
Operators are assigned operator permissions. The ZMS administration

manager uses these permissions to control each operator account. When the
operator logs into NetHorizhon, ZMS grants the operator access to specific
types of objects and controls the actions the operator can perform on those
objects:
• Only those objects accessible to an operator are visible in NetHorizhon.
• Only those management functions granted to the operator are visible in
menu selections in NetHorizhon.
The permissions you can assign operators are:
User Administration—Specifies whether the operator is a user
administrator who can add other users or is a basic operator. Only the
admin user can grant this permission.
View Objects in All Groups—Specifies whether the operator can view
objects that belong to any group or is restricted from viewing objects that
are not in the user’s group.
View Alarm Summary in Main Window—Specifies whether the
operator can view a summary of the alarm status in the ZMS main
window. This permission is required for users to enable the beep on alarm
user preference setting.
OSS Gateway User—Specifies whether this is an operator that operates
through OSS gateway.
Region Configuration—Specifies whether the operator can add, modify,
and delete regions in the user’s group or can only view configuration
settings for regions in the user’s group.
Equipment Provisioning—Specifies whether the operator can add,
modify, and delete equipment (devices, cards, physical ports, and so on)
in the user’s group or can only view configuration settings and
performance data for equipment in the user’s group.
Note: ZMS users with Equipment Provisioning permission set to

Read, can run MTAC, SELT and DELT tests as long as Diagnostics
Administration permission is also enabled.
ZMS users with Equipment Provisioning permission set to Write,
continue to be able to run the MTAC, SELT and DELT tests by
default..

Overview
Subscriber Provisioning—Specifies whether the operator can add,

modify, and delete customers, subscribers, and voice and data connections
in the user’s group or can only view configuration settings for customers,
subscribers, and voice and data connections in the user’s group.
Trap/Alarms Administration—Specifies whether the operator can view
traps and alarms and acknowledge, assign to troubleshooter, and close
alarms of objects in the user’s group or can only view traps and alarms of
objects in the user’s group.
Diagnostics Administration—Specifies whether the operator can run
diagnostics tests on cards in the user’s group or is restricted from running
tests.
User Idle Session Auto Logout—Specify whether the idle session auto
logout feature is applied to the operator. If this parameter is disabled, the
client session will never auto logout. For instance, an operator may be
allowed to leave his/her session idled for indefinitely length of time while
viewing alarm viewer or performance monitor chart.
Note: The admin user is a special account whose permissions cannot

be changed. The admin user can only manage groups and users and
grant permissions. And the admin user is the only user that can
configure zms security policy.
Recommended sequence for setup tasks
In order to administer operator accounts and permissions, you need to be

logged in as a user with the appropriate permissions. In addition, you need to
perform tasks in the correct order. The following procedures describe the
recommended sequences for administering accounts in the following network
scenarios:
• A new ZMS network with no objects
• A ZMS network with existing objects
Scenario 1: Administering accounts in a new ZMS network

Use this procedure to administer accounts in a ZMS network that does not yet
contain objects.
1 To add group and users, log into NetHorizhon as the admin user. (The
default username is admin, the default password is zhone).
2 For security purposes, change the password of the admin user to a private
password. For instructions, see Changing the admin password on page 68.
3 Create groups to contains operators and the objects they can manage. For
instructions, see Creating a group on page 69.
4 Create a user administrator for each group. For instructions, see Creating
an operator account on page 69.

5 Add operators and assign permissions. For instructions, see Creating an

operator account on page 69.
6 To add network objects, login into NetHorizhon as an operator with the
appropriate Write permissions.
7 Add network objects. The objects inherit that operator’s group ID.
8 To add additional operators, login into NetHorizhon as a user
administrator.
9 Add operators and assign permissions. For instructions, see Creating an
operator account on page 74.
The operators inherit that user administrator’s group ID. The operators
can manage objects only in that group. If the operators have View
Objects in All Groups permission, they can view objects in other groups.
Scenario 2: Administering accounts in an existing ZMS

network
In the case of ZMS networks created before any groups were explicitly added,
all existing operators and objects reside in the default group. In order to allow
new operator accounts to view and manage these existing objects, you need to
add the accounts to the default group. Use this procedure to add accounts to
the default group.
1 To add operators, log into NetHorizhon as a user administrator.
2 Add operators to the default group and assign permissions. For
instructions, see Creating an operator account on page 74.
The operators inherit the default group ID. The operators can manage
objects only in the default group. If the operators have View Objects in
All Groups permission, they can view objects that are in other groups.
Administering groups and operators as the admin user

When you log in as the admin user, the tree display lists only groups and
operators. As the admin user, your permissions limit you to only managing
groups and users and assigning permissions.
Changing the admin password
When you log in as the admin user, for security reasons, you should change
the password to a private password.
To change the admin password:

1 Click Tools > Change My Password from the menu bar.
NetHorizhon displays the Change Password dialog box.
2 Enter the current password in the Current Password box.

Administering groups and operators as the admin user
3 Follow the password rules displayed on the screen to enter a new

password in the New Password and the Confirm Password boxes.
Note: The password rules are set in the Modify Security Policy
dialog box. For the detail refer to Setting the password rules on
page 71.
4 Click OK.
Be sure to record the new password, so you can provide it to any
individual who needs to log in as the admin user to add groups and add
operators to various groups.
Creating a group
To use NetHorizhon to create groups:

1 In the tree display, navigate to the list of groups.
2 Right-click the groups container and click Add.
NetHorizhon displays the Add Groups dialog box.
3 In the Name parameter, enter a name for the group.
4 Click Add.
You can now add operator accounts to the group.
Creating an operator account
When you create an operator account, you specify the user name and
password, and assign user permissions. Specifically, you associate the
operator with a particular group and a set of permissions for the purpose of
access control.
Once you activate the account, the operator can download, install, and run the
NetHorizhon client application. The operator permissions define what actions
the operator can perform in NetHorizhon.
To use NetHorizhon to create operators:

1 In the tree display, navigate to the list of operators.
2 Right-click the operators container and click Add.
NetHorizhon displays the Add Operator Configuration dialog box.
3 Complete the parameters in the Add Operator Configuration dialog
box:
Name—Enter the user name. Use only alphanumeric characters and the
underscore (_) character. (Do not use blank characters.)
Password—Enter a unique password for the user.

Confirm Password—Re-enter the password for the user.

Account Status—To activate the operator, choose Active from the
drop-down list. To deactivate the operator, choose Inactive from the
drop-down list.
(Be sure to record the user name and password, so you can provide it to
the operator.)
Permissions—Assign permissions for the user. For information about
permissions see How permissions function on page 66.
4 Click Add.
The operator inherits the user administrator’s group ID. The operator can
manage objects only in that group. If the operator has View Objects in
All Groups permission, the operator can view objects in other groups.
Viewing an operator account
To use NetHorizhon to view an operator account:

2 Select the operator you want to view and click Edit > View.
NetHorizhon displays the View Operator Configuration dialog box with
the following parameters:
Name—Operator’s user name.
Account Status—Account status for the operator (Active or Inactive).
Permissions—View permissions for the user. For information about
3 When you have finished viewing the operator settings, click Close.
Modifying an operator account
To use NetHorizhon to modify an operator account:

2 Right-click the operator and click Modify.
NetHorizhon displays the Modify Operator Configuration dialog box.
3 Make the necessary changes to the values in the Modify Operator
Configuration dialog box:

Configuring security policy as the admin user

drop-down list.
4 When you have finished modifying the operator settings, click Modify.
When modifications take effect

If you change a user name or password, the operator must supply the new
login information the next time the operator logs in to NetHorizhon.
If you deactivate the operator, the operator can no longer log in to
NetHorizhon.
Other changes you make to an operator account take effect the next time the
operator logs in. If operators are running NetHorizhon when you modify their
accounts, let them know that they must exit and log in to NetHorizhon again
for the change to take effect.
Deleting an operator account
If you want to permanently remove an operator from the system, you can
delete the account. If you want to temporarily remove the operator from the
system, you can deactivate the account (For instructions, see Modifying an
operator account on page 70).
To permanently delete an operator account:

2 Right-click the operator and click Delete.
3 At the confirmation prompt, click OK.
Once you delete an operator, the user can no longer log in to NetHorizhon.

An admin user define security policies that will be applied when user login.
The security policies include password rules, password blacklist, user login
failure handling, user idle session auto logout, and user IP address filter.
Setting the password rules

Set the password rules. Those password rules will be displayed when user
change password.
1 Click Tools > Configure Security Policy from the menu bar.

NetHorizhon displays the Modify Security Policy Configuration dialog

box.
2 The Password Rules window displays the current password rule settings.
Make the necessary changes to the values in the Password Rules
window:
Minimum Password Length — Set the minimum password length,
within the range of 4 to 30 characters.
Maximum Password Length — Set the maximum password length,
within the range of 4 to 30 characters, and could not be less than the value
in the Minimum Password Length.
Must Have Special Characters — To include special characters in the
password, click Enabled.
Must Have Mixed Upper and Lower Cases — To include mixed upper
and lower cases characters in the password, click Enabled.
Must Have Mixed Alphabetic and Numberic — To include mixed
alphabetic and numberic in the password, click Enabled.
Default Characters — By default, the valid characters for password are
A-Z, a-z, and 0-9.
Default Special Characters — The default special characters are ! # $ &
‘()+,-./:;<=>?@[\]^_`{}~.
Select Special Character Set — If the Must Have Special Characters
is enabled, then user can configure the special character set in this field.
– To include default special characters into the password, select the
Default Special Characters.
– To include specific special characters into the password, select
Specific Special Characters.
Input Special Characters — To create a set of specific special
characters, input desired special characters in this field.
Do Not Allow Password Re-use — To prevent using old passwords,
check Enabled.
Number of Old Password Stored — Set the maximum number of old
passwords to be stored, in the range of 5 to 10. The stored old passwords
are the most recent passwords the user has used. Those stored old
passwords could not be used now.
Password Expiration — Enable or Disable the password valid days
setting.
Password Valid Days — If password expiration is enabled, set the length
of days a password is valid in this field. In the range of 30 to 90.
Days to Warn Before Expiration — Set number of days before
expiration that warning is given. In the range of 5 to 15 days.
3 Click Modify.

The new password rules will appear in the Change Password dialog box.
Setting the advanced security policies

Set the advanced security policies.
1 Click Tools > Modify Security Policy from the menu bar.
NetHorizhon displays the Modify Security Policy Configuration dialog
box.
2 Click the Advanced tab. Make the necessary changes to the values in the
Advanced window:
Password Blacklist — To block passwords listed in the password
blacklist, check Enabled.
Password Blacklist — If Password Blacklist is Enabled, admin user can
edit the password blacklist. Click Edit to open the Password Blacklist
Dialog. A list of existing blocked passwords appears.
– To add more passwords into the password blacklist, click Add to
open the Blocked Password Dialog. In the Blocked Password
Dialog, input desired blocked password and click OK.
– To remove a password from the blacklist, select the password and
click Delete.
Do Not Allow Username As Password — To allow password is same as
username, uncheck Enabled. Not allow password is same as username,
check Enabled.
User Login Failure Handle — To apply the setting on the allowed
number of login attempts, check Enabled. To have no limitation on the
login attempts, uncheck Enabled.
Allowed Number of Login Attempts — If User Login Failure Handle
is Enabled, admin user can input number of login attempts allowed
before locking user out in this field.
Generate ZMS Alarm on Login Failure — To generate an alarm on
ZMS alarm viewer when login failed, check Enabled.
User Idle Session Auto Logout — To apply the idle session timeout
settings, check Enabled.
Maximum Session Idle Time (minutes)— If User Idle Session Auto
Logout is enabled, admin user can specify the length of idle time that
triggers an auto logout. The unit is in minutes.
Time Before Logout Warning (minutes)— If User Idle Session Auto
Logout is enabled, admin user can specify the length of time that a
warning message appears before auto logout.
User IP Address Filter— To apply the IP address filter, check Enabled.

IP Address Whitelist— To define a list of IP address ranges which are

valid for a user to login from, click Edit to open the User IP Whitelist
Dialog. A list of existing valid IP address ranges appears.
– To add an IP address range into the IP address whitelist, click Add to
open the Add Client IP Address dialog box. In the Add Client IP
Address dialog box, input desired IP address range to both Start IP
address and End IP address fields and click OK. (If it is a single IP
address, input it to Start IP Address field.)
– To remove an IP address range or a single IP address from the IP
address whitelist, select it and click Delete.
IP Address Blacklist— To define a list of IP address ranges which no
user may login from, click Edit to open the User IP Blacklist Dialog.
– To add an IP address range into the IP address blacklist, click Add to
open the Add Client IP Address dialog box. In the Add Client IP
Address dialog box, input desired IP address range to both Start IP
address and End IP address fields and click OK. (If it is a single IP
address, input it to Start IP Address field.)
– To remove an IP address range or a single IP address from the IP
address blacklist, select it and click Delete.
3 Click Modify.
Administering operators as a user administrator

Creating an operator account
When you create an operator account, you specify the user name and
password and assign user permissions.
Once you activate the account, the operator can download, install, and run the
NetHorizhon client application. The operator permissions define what actions
the operator can perform in NetHorizhon.
To use NetHorizhon to create operators:

1 If you are logged in to NetHorizhon as an operator with User
Administration privileges, click Tools > Configure Users.
NetHorizhon displays the User Administration dialog box, listing
existing users in your group.
(If you are logged in as the admin user, the tree view is already
displayed.)
2 Right click the operators container and click Add.
NetHorizhon display the Add Operator Configuration dialog box.

Administering operators as a user administrator
3 Complete the parameters in the Add Operator Configuration dialog

box:
drop-down list.
(Be sure to record the user name and password, so you can provide it to
the operator.)
4 Click Add.
The operator inherits the user administrator’s group ID. The operator can
manage objects only in that group. If the operator has View Objects in
All Groups permission, the operator can view objects in other groups.
Viewing an operator account
To use NetHorizhon to view an operator account:

1 If you are logged in to the NetHorizhon as an operator with User
2 Right-click the operator you want to view and click View.
NetHorizhon displays the Operator Configuration dialog box with the
following parameters:
Name—Operator’s user name.
Password—Asterisks in place of the operator’s password.
Account Status—Account status for the operator (Active or Inactive).
Account Active Date and Time— View day(s) of week that account is
activated, and time range per day when account is activated.
3 When you have finished viewing the operator settings, click Close.

Modifying an operator account
To use NetHorizhon to modify an operator account:

2 Select the operator and click Edit > Modify.
NetHorizhon displays the Operator Configuration dialog box.
3 Make the necessary changes to the values in the Operator Configuration
dialog box:
Password—Enter a new password for the user.
Confirm Password—Re-enter the new password for the user. (Be sure to
record the new password, so you can provide it to the operator.)
drop-down list.
Account Active Date and Time— Modify day(s) of week that account is
activated, and set time range per day when account is activated.
4 When you have finished modifying the operator settings, click Modify.
When modifications take effect

If you change a user name or password, the operator must supply the new
login information the next time the operator logs in to NetHorizhon.
If you deactivate the operator, the operator can no longer log in to
NetHorizhon.
Other changes you make to an operator account take effect the next time the
operator logs in. If operators are running NetHorizhon when you modify their
accounts, let them know that they must exit and log in to NetHorizhon again
for the change to take effect.
Deleting an operator account
If you want to permanently remove an operator from the system, you can
delete the account. If you want to temporarily remove the operator from the
system, you can deactivate the account (For instructions, see Modifying an
operator account on page 76).

Account information for operators
To permanently delete an operator account:

2 Right-click the operator and click Delete.
3 At the confirmation prompt, click OK.
Once you delete an operator, the user can no longer log in to NetHorizhon.
Account information for operators

As you define operator accounts, be sure to record the user name and
password information.
Supply operators with the following information so they can download,
install, and run NetHorizhon.
• URL for the ZMS secure web server. The URL has the following format:
http://server_hostname:server_port_number
For example:
http://grove:7001
• NetHorizhon user name and password.
About activating operator accounts

Before operators can log in to NetHorizhon, their accounts must be activated.
To activate an operator account, modify the user account and set the Account
Status parameter to Active.
After the User Login Failure Handle is enabled, and the Allowed Number
of Login Attempts is specified in the Modify Security Policy
Configuration dialog box. If an operator attempts to log in to NetHorizhon
certain consecutive times, but fails (because the operator supplies the wrong
user name or password), the administration manager automatically
deactivates the operator account. The operator cannot log in to NetHorizhon
until you reactivate the account.


MONITORING ZMS LOGS
This chapter describes how to use ZMS logs. It includes the following
information:
• Alarm log, page 80
• Audit logs, page 80
• Task logs, page 82
• Debug log, page 83
• Forwarded alarm log, page 83
• Forwarded trap log, page 84
• Trap log, page 84
• Server log, page 84
• ZMS error log, page 87
Overview
The ZMS application server creates the following logs:
• Alarm log (yyyy_mmm_dd_alarm.log)
• Audit log (yyyy_mmm_dd_ZmsAudit.log)
• Task log (yyyy_mmm_dd_Task.log)
• Debug log (yyyy_mmm_dd_debug.log)
• Forwarded alarm log (yyyy_mmm_dd_AlarmForward.log)
• Forwarded trap log (yyyy_mmm_dd_TrapForward.log)
• Trap log (yyyy_mmm_dd_trap.log)
• ZMS error log (yyyy_mmm_dd_ZMSErrors.log)
• Server log (zms.log)
Each of these logs (with the exception of the ZMS server log) is created daily
and stored in the following location:
install_directory/opt/weblogic/yyyy_mmm_dd_LogName.log

Monitoring ZMS Logs
where yyyy_mmm_dd is the timestamp for when the log was created. These
log files are purged periodically based on the configuration of the
ADS.properties file. The default is 31 days. For details, see Modifying the
information written to the audit log on page 81.
. If you want to save the log file information, you should periodically backup
the log files to another location.
Alarm log
The ZMS system generates an alarm log (alarm.log), listing all alarms
generated on the network. The alarm log lists entries sequentially by date and
time, with the most recent trap appearing at the end of the file.
The following sample illustrates an alarm log entry:
Tue Feb 05 18:08:58 EST 2002: Received LINK_DOWN_ALARM
Severity: Critical
ALARM: Communication link is about to enter the down
state
Device: NEDevice
Shelf: 1
Slot: 1
Port: 7
Tue Feb 05 18:10:41 EST 2002: Cleared LINK_DOWN_ALARM

Device: NEDevice
Shelf: 1
Slot: 1
Port: 7
---
Audit logs
ZMS generates an audit log, listing all operator activity. The log lists entries
sequentially by date and time, with the most recent event appearing at the end
of the file.
The ZMS system stores the audit log files in the following path:
install_directory/opt/weblogic/yyyy_mmm_dd_ZmsAudit.log.
Entries in the log file can be viewed from ZMS by selecting Tools > View
Audit Log.
Audit log entries include the fields listed in Table 13.
Table 13: Audit log fields
Audit log field Description
Time Date and time of the activity.
User User performing an operation.

Audit logs
Table 13: Audit log fields
Operation Type Operation performed by ZMS. Possible values

are:
Add: An object has been added.
Modify: An object has been modified.
Delete: An object has been deleted.
DR_List: An objects attributes have been
listed.
DR_Restore: A device configuration has been
restored.
Login: A user has logged in.
Logout: A user has logged out.
Authorization Whether the request was granted or denied.
Device Name Name of affected device.
Object Type The type of object affected.
Message An explanatory message describing the event.
Operation Request Operation requested by the user.
Modifying the information written to the audit log
The information that ZMS sends to the audit log can be configured in the
ADS.properties file. Note that since each level of auditing requires more
resources (such as disk space, time, and CPU resources), some tuning may be
required in order to achieve the desired outcome.
The following table describes the options in the ADS.properties file. Note that
changes to the log files take effect after the ZMS application server is
restarted.
Table 14: ADS.properties options
bulkStatsLogPurge Indicates the number of days ZMS should store

the bulk statistics logs before purging them.
The default is 31.
gctimer How often the memory optimizer runs to clean

up any available memory within ZMS. This
option should not be changed from its default
of 60 minutes.

Monitoring ZMS Logs
Table 14: ADS.properties options (Continued)
logLogin Whether attempts to log in should be logged in

the audit file.
The default is 1 (added to log).
logLogout Whether attempts to log out should be logged

in the audit file.
logPurge Indicates the number of days ZMS should store

the logs before purging them.
The default is 31. Must be greater than 1.
logRequest Whether every operational request made to

ZMS is logged. This option enables logging of
the user, request type made, object type, and
unique object ID for every request.
This is the lowest form of request logging
available that accurately depicts the interaction
of clients with the ZMS server.
logModDetails Whether additional details of modification

requests should be logged. The additional
information includes every attribute that was
modified and its prior and new value.
Note that this option can substantially add to
the size of the log files.
The default is 0 (not added to log).
logAddDetails This option logs every attribute of a object

whenever it is added to ZMS. These attributes
are unique to each object, and include
information such as name, index, admin status,
and so on.
Note that this option can substantially add to
the size of the log files.
The default is 0 (not added to log).
Task logs
ZMS generates a task log, listing all activity for these four tasks: Auto
Discovery, Device Backup, ConfigSync, and Download Image. The log lists
entries sequentially by date and time, with the most recent event appearing at
the end of the file.
The ZMS system stores the task log files in the following path:
install_directory/opt/weblogic/yyyy_mmm_dd_Task.log.

Debug log
Entries in the log file can be viewed from ZMS by selecting Tools > View
Task Log.
Task log entries include the fields listed in Table 13.
Table 15: Task log fields
Task log field Description
Time Date and time of the activity.
Task Type The type of task: ALL, Auto Discovery, Device

Backup, ConfigSync, Download Image.
Message Type Whether the task was started or finished.
Status Whether the task was successed or failed.
Description A brief description describing the events.
Object Type The type of object affected.
Message An explanatory message describing the event.
Operation Request Operation requested by the user.
Debug log
The ZMS system generates a debug log (debug.log), that stores a variety of
debugging information related to the ZMS server operations. This log file is
typically only useful for Zhone development engineers.
The ZMS system generates the debug log to the path: install_directory/opt/
weblogic/yyyy_mmm_dd_debug.log.
Forwarded alarm log

The ZMS system generates a forwarded alarm log (AlarmForward.log),
listing information about alarms that are forwarded to IP addresses on the
network. The forwarded alarm log lists entries sequentially by date and time,
with the most recent alarm appearing at the end of the file.
The following sample illustrates an alarm log entry:
Wed Jan 30 16:46:18 EDT 2002: Forwarded
CARD_PROVISIONING_FAILED (alarmReceived) Host =
172.16.28.50, Community = ZmsTrapPrivate, Port = 162 Wed
Jan 30 16:47:18 EDT 2002: Forwarded
CARD_PROVISIONING_FAILED (alarmCleared) Host =
172.16.28.50, Community = ZmsTrapPrivate, Port = 162
The ZMS system generates the forwarded alarm log to the path:
install_directory/opt/weblogic/yyyy_mmm_dd_AlarmForward.log.

Monitoring ZMS Logs
Forwarded trap log

The ZMS system generates a forwarded trap log (TrapForward.log), listing
information about traps that are forwarded to IP addresses on the network.
The forwarded trap log lists entries sequentially by date and time, with the
most recent trap appearing at the end of the file.
The following sample illustrates a trap log entry:
Fri Feb 01 09:13:10 EST 2002: sending trap to
172.16.90.150
The ZMS system generates the forwarded trap log to the path:
install_directory/opt/weblogic/yyyy_mmm_dd_TrapForward.log.
Server log
The ZMS system generates an server log (zms.log), listing server processes.
For example, when the ZMS server is started, startup progress messages are
written to the log. The log lists entries sequentially by date and time, with the
most recent event appearing at the end of the file.
The ZMS system generates the server log to the path: install_directory/opt/
weblogic/zms.log.
Trap log
The ZMS system generates a trap log (trap.log), listing all traps generated on
the network. The trap log lists entries sequentially by date and time, with the
most recent trap appearing at the end of the file.
These traps are defined in zmsAlarm.mib. Table 16 lists the varbinds included
in these traps.
The first five varbinds are standard to all Zhone traps.
The last nine varbinds are defined for alarmReceived and alarmCleared traps
defined in zmsAlarm.mib (faultServiceTraps).

Trap log
Table 16: Trap information
Parameter Description
SysUpTime Elapsed time the device has been running

when it generated the trap. This a
standard SNMP varbind. Some SNMP
tools may display this information in the
trap header, rather than in the trap itself.
Trap OID The trap OID. This a standard SNMP

varbind. Some SNMP tools may display
this information in the trap header, rather
than in the trap itself.
Trap Version Version number of the format of the trap.
Trap Sequence Number Sequence number of the trap.
Trap Severity Severity of the trap (critical, severe,

moderate, or low).
Alarm Name Name of the alarm.
Alarm Description Description of the alarm.
Alarm Type Type of the alarm.
Alarm Severity Severity level of the alarm.
Alarm Timestamp Time that the alarm was created.
Alarm Device Name or IP address of the device that

generated the alarm.
Alarm Shelf Shelf that generated the alarm. A zero

value indicates that the alarm was
generated on a device.
Alarm Slot Card slot that generated the alarm. A zero

value indicates that the alarm was
generated on a shelf.
Alarm Port Physical port that generated the alarm. A

zero value indicates that the alarm was
generated on a card.
The following sample illustrates a trap log entry:

Tue Jan 08 15:07:12 EDT 2002: SNMP V2 Trap PDU
SNMP Version: Version 2C
Remote Host: 172.16.90.211
Remote Port: 41860
Community: ZmsTrapPrivate
Request ID: 1909962606
Timeout: 0
Retries: 0
Error Status: no error

Monitoring ZMS Logs
SNMP PDU Variable Bindings:

Object ID: .iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0
TimeTicks: 0 hours, 0 minutes, 0 seconds.
Object ID:
.iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTrap.snmpT
rapOID.0
OBJID:
.iso.org.dod.internet.private.enterprises.zhone.zhoneGeneric.zhoneShelf.zhoneT
rapShelfMonitorV2Traps.zhoneTrapCardStatusChange
Object ID:
.iso.org.dod.internet.private.enterprises.zhone.zhoneGeneric.zhoneSystem.zhone
Traps.zhoneTrapVersion
INTEGER: version1 (1)
Object ID:
Traps.zhoneTrapFlags
INTEGER: trapAcknowledge (0)
Object ID:
Traps.zhoneTrapsTable.zhoneTrapsEntry.zhoneTrapsSequenceNumber
INTEGER: 1
Object ID:
Traps.zhoneTrapsTable.zhoneTrapsEntry.zhoneTrapsSeverity
INTEGER: severe (2)
Object ID:
Traps.zhoneTrapsTable.zhoneTrapsEntry.zhoneTrapsAllowedCategories
INTEGER: catAdmin (0)
Object ID:
Traps.zhoneTrapShelf
INTEGER: 1
Object ID:
Traps.zhoneTrapSlot
INTEGER: 3
Object ID:
Traps.zhoneTrapPort
INTEGER: 0
Object ID:
.iso.org.dod.internet.private.enterprises.zhone.zhoneGeneric.zhoneShelf.zhoneC
ardStatus
INTEGER: cardRemoved (1)
The ZMS system generates the trap log to the path:

install_directory/opt/weblogic/yyyy_mmm_dd_trap.log.

ZMS error log
ZMS error log

The ZMS system generates a debug log (ZMSErrors.log), that stores any
errors that were received due to improper provisioning (incorrect values) or
device-related errors (such as SNMP time outs).
This log file is typically only useful for Zhone development engineers.
The ZMS system generates the error log to the path: install_directory/opt/
weblogic/yyyy_mmm_dd_ZMSErrors.log.

Monitoring ZMS Logs

HOW ZMS MANAGES NETWORK ELEMENTS
This appendix explains how the ZMS managers and services function
together to manage network elements. It describes the following managers
and services:
• Administration manager, page 89
• Configuration synchronization service, page 90
• Configuration manager, page 93
• Fault manager, page 94
• Performance manager, page 102
• Monitoring service, page 104
• Diagnostics service, page 105
Administration manager
The function of the administration manager (ADS) is to enforce security
through operator authentication and authorization.
General process to managing operator requests:

1 When the operator logs in to NetHorizhon, ADS authenticates the
operator.
2 ADS stores operator authentication requests in an audit log.
3 When a management request comes into ZMS from the operator, the
appropriate manager (such as the configuration manager or the
performance manager.) requests ADS to authorize the request. The
manager also stores the operator request in an audit log
4 ADS authorizes the request based on the operator’s permissions.
5 The appropriate manager performs the request and forwards the response
back to the client.
ADS is also responsible for managing operator accounts, including adding,
modifying, activating, deactivating, and deleting accounts.
Figure 5 illustrates how ADS authorizes and manages client requests.

How ZMS Manages Network Elements
Figure 5: Administering a management request
NetHorizhon Clients
5
Responds to request
ZMS Server
Network
Configuration
Fault
Performance
Monitoring
Diagnostics 1
Authenticates operator login
3 Accounting
Requests authorization
Administration 2
and stores request
in audit log
Stores operator authentication
Database in audit log
4
Configuration Sync Audit Log
Authorizes request

As resources are added to the network, the ZMS system uses the ZMS
configuration synchronization service (CSS) to automatically synchronize
elements in the system. The function of CSS is to ensure that the
configuration information on a network device and in the ZMS database are
synchronized.
When a ZMS object is first activated on the network:

1 The device notifies CSS (by way of the fault service) that it is on-line.

2 CSS requests (by way of the network service) the device’s configuration
information.
3 In response, the device transfers the configuration information.
4 Once CSS receives the configuration information, it requests the
configuration manager to validate the data.
5 Once the data is validated, CSS stores the data (by way of the database
service) in the database.
6 CSS notifies each NetHorizhon client that information has changed.
7 In response, the client retrieves the new information from the database
service.
In the same way, anytime an object is modified at the device level (by way of
the command line interface), the device notifies CSS in real time that a change
has occurred. CSS requests the device’s configuration information, and, once
it receives it, notifies the database service and notifies NetHorizhon of the
change.
Figure 6 illustrates the synchronization process following a device-level
change.

Figure 6: Synchronization following a device-level change
Zhone Device Local

Database
Configuration
NetHorizhon Clients
7 6
3
Retrieves changes Notifies clients
Sends update
2
Requests update
ZMS Server
Network
Configuration 4
1 Validates data
Notifies ZMS Fault
Performance
Monitoring
Diagnostics
Accounting
Administration
Database 5
Updates database
Configuration Sync
ZMS
Database
If the ZMS system is not active when an object is added or modified (such as
during a network outage), the device stores the configuration changes in its
local database. When the ZMS system comes back on-line, CSS notifies
network devices that it is available. The devices send their configuration
updates to CSS, which forwards it to the database service and to clients. The
database service updates the ZMS database, and the clients update their
displays with the information.

Configuration manager
Configuration manager
The function of the configuration manager (CS) is to make configuration
changes to network elements and provision subscribers and end-to-end
services within the ZMS network.
General process to provision resources:

1 NetHorizhon makes a request to add, modify, or delete a network
resource.
2 CS authorizes the configuration request (by way of the ADS).
3 CS performs the request and stores the data (by way of the database
service) in the database.
4 CS sends the configuration update (by way of the network service) to the
device.
5 CS notifies other NetHorizhon clients of the change. Each operator’s
NetHorizhon display updates to reflect the changes.
CS also handles element software downloads.
Figure 7 illustrates how the CS provisions resources.

Figure 7: Configuring resources
Zhone Device Local

Database
Configuration
NetHorizhon Clients
5 1
Updates clients Makes changes
4
Sends update ZMS Server
Network
Configuration
Fault
Performance
Monitoring
Diagnostics
Accounting
2 Administration
Authorizes request
Database
Configuration Sync
3 ZMS
Database
Updates database
Fault manager
The fault manager (FS) provides monitoring, logging, and notification of fault
information (traps and alarms) on the ZMS network. FS also forwards traps to
destination addresses, as needed.
A trap is an SNMP PDU containing real-time information about a predefined
event occurring on a network device. A trap can indicate a problem such as a
power supply failure or a performance problem. Or, a trap can indicate other
dynamic information about network activity, such as a network object being
brought down by a system administrator or a threshold level being exceeded.
Traps exist for all objects, including devices, cards, physical ports, logical
interfaces, permanent virtual circuits (PVCs), and so on.

Fault manager
The traps generated by ZMS objects are reliable traps. Each Zhone device
maintains a buffer of outgoing traps, so that it can resend any trap that is lost
during transit.
An event is an SNMP PDU containing real-time information about a
predefined event occurring in the management software. An event can
indicate information about software processing, such as completion of card
provisioning or completion of a partial update from the device.
A trap or an event can trigger an alarm, which is a human-readable message
that notifies an operator or administrator of a network problem. A variety of
alarm indications and statistics loggings are available for objects. For a list of
traps that trigger alarms, see Traps and Alarms on page 107.
Fault processing
FS processes faults through a series of processors:

• Trap receiver, which collects and forwards traps.
• Alarm processor, which maps traps and events to alarms and applies
faults to a set of rules to determine what action to take on each alarm.
ZMS allows the operator the flexibility of customizing the alarm processing
and handling settings in the properties files (FSAlarmSeverity.properties,
FSAlarmDescription.properties, and the FaultService.properties) on the ZMS
server. See Modifying ZMS alarm descriptions, page 119.
Figure 8 shows how FS components process faults.

Figure 8: Fault manager processors
Redirect traps Publish traps Publish alarms
Fault Manager Components
Incoming
traps Trap Alarm
Receiver Processor
Resend
trap requests
Store traps Store alarms
ZMS
Database
Trap receiver
The trap receiver performs the following tasks:
• Processes traps
• Forwards traps
Trap processing
The trap receiver processes incoming traps in the order in which they arrive.
The receiver uses the sequence number of each trap to verify that it has
received all incoming traps. If the trap receiver detects that a trap is received
out of sequence, the receiver reorders the traps into the correct sequence. If
the trap receiver detects that a trap is missing, the receiver requests that the
Zhone device resend the trap.
The trap receiver uses the following criteria to determine if a trap is missing:
After five traps—If a trap with a particular sequence number is not
received after receiving some number of higher-numbered traps (default:
five).

Fault manager
For example, if the trap receiver receives traps in the order shown in
Figure 9, the receiver considers the trap with sequence number 4 missing
when it receives the trap with sequence number 9 (4 + 5 = 9). The trap
receiver requests the Zhone device to resend trap 4.
Figure 9: Handling reliable traps by sequence number
1 2 3 5 6 7 8 9
Trap with sequence Five higher-numbered traps received.

number 4 not received. Trap receiver requests trap 4 be resent.
After timeout — If a trap with a particular sequence number is not

received after receiving one higher-number trap and after a timeout
(default: 30 seconds) elapses.
For example, if the trap receiver receives traps in the order shown in
Figure 10, the receiver considers the trap with sequence number 4 missing
when it receives the trap with sequence number 5, and then the timeout
expires (30 seconds). The trap receiver requests the Zhone device to
resend trap 4.
Figure 10: Handling reliable traps by timeout
1 2 3 5
Trap with sequence One higher-numbered trap received.

number 4 not received. After timeout expires, trap receiver
requests trap 4 be resent.
The trap receiver stores information about each trap in a trap log and in the
ZMS database, including the trap source (the object that generated the trap),
the time at which the trap occurred, and the SNMP trap itself.
The trap receiver publishes each trap to NetHorizhon clients.
The trap receiver forwards specific information about each trap to the alarm
processor.
Trap forwarding
The trap receiver also forwards traps to other locations if any forwarding
maps have been configured. As part of the process, the trap receiver adds the

zhoneTrapsDestination variable binding to the trap to be forwarded. The

variable binding specifies the IP address of the agent that generated the trap.
Environment variables in the FaultService.properties file specify trap
forwarding. Specific destination hosts are specified. Specific traps to be
excluded from forwarding are also specified.
Figure 11 illustrates the general process that FS uses to process traps. The
basic steps are:
General steps to process traps:

1 The device sends a trap that is received by the ZMS system (by way of
FS).
2 The trap receiver publishes the trap to NetHorizhon clients.
3 The trap receiver stores trap details in the trap log.
4 The trap receiver stores the trap (by way of the database service) to the
database.
5 The trap receiver forwards the trap (including the zhoneTrapsDestination
variable binding) to other registered workstations.

Fault manager
Figure 11: Processing traps
Zhone Device
Trap
NetHorizhon Clients
2
1 Publishes trap
Generates trap
ZMS Server
Network
3
Configuration
Stores trap information
in trap log
Fault
Trap Log
Performance
Monitoring
5
Forwards trap Diagnostics
Accounting
Administration
4
Database Updates database
Configuration Sync
ZMS
Database
Alarm processor
The alarm processor performs the following tasks:
• Applies traps to a set of mappings that determine whether the trap
becomes an alarm.
• Applies newly-created alarm to a set of rules that determine what action
to take.
• Forwards alarms to the forward host manager, which sends a mail
message to registered individuals, indicating that the alarm has occurred
on the network (if configured to do so).
• Forward alarms to specific IP addresses (if configured to do so).

Alarm mapping
The alarm processor applies traps to a set of mappings that determine whether
the trap becomes an alarm. Only a trap that meets the criteria specified by a
particular map becomes an alarm.
An alarm mapping specifies:
• Name of the originating trap.
• Any restrictions for the values of the trap variables.
• Name of the generated alarm.
An alarm mapping may generate one or more alarms. For example, the trap
zhoneTrapShelfStatusChange with trap variable zhoneShelfStatus = 5 maps to
the alarm POWER_SUPPLYA_FAILURE _ALARM (Power supply A
failure).
Figure 12: Sample alarm mapping

Alarm Mapping
Incoming
Trap Alarm
from device zhoneTrapShelf
POWER_SUPPLY
StatusChange
A_FAILURE_
zhoneShelfStatus ALARM
=5
For DS1 and Ds3 line status traps (zhoneLineStatusChange and

dsx3LineStatus traps), if the value of the trap variable zhoneLineStatus is a
power of 2 (such as, 1, 2, 4, 8, 16, and so on), the alarm processor generates a
single alarm. If the trap variable value is a value other than a power of 2 (for
example, 100), the alarm processor generates multiple alarms, one for each
trap with zhoneLineStatus value within the variable value (in this case, 100).
For example, the trap zhoneLineStatusChange with trap variable
zhoneLineStatus = 2 maps to the single alarm
LINE_RCV_FAR_END_LOF_ALARM. The trap zhoneLineStatusChange
with trap variable zhoneLineStatus = 100 maps to three alarms (those
generated for the variable values 4, 32, and 64). The sum of the values of
zhoneLineStatus for these alarm-generating traps is 100.
Alarm severities
Alarm severities are defined in the FSAlarmSeverity.properties file or by the
trap that generates the alarm. Alarm severity levels can be changed by
modifying the FSAlarmSeverity.properties file. Alarm severities that are
commented out in the FSAlarmSeverity.properties(with a “#” sign) derive
their severity level from a trap. Alarm severities that are not commented in the
FSAlarmSeverity.propertie file have the severity level defined in the file.

Fault manager
Applying rules
The alarm processor applies faults to a set of rules that determine what action
to take. Applied rules may cause a trap to be cancelled or an alarm to be
cleared.
For example, the alarm POWER_SUPPLYA_FAILURE_ALARM followed
by the trap zhoneTrapShelfStatusChange with trap binding of
zhoneShelfStatus = 6 results in the action to clear the initial alarm.
An alarm can affect other alarms only while it is still active. Once an alarm is
cleared, it can no longer clear other alarms.
Once the alarm has been applied to the rules, the alarm processor stores the
alarm in an alarm log and in the ZMS database.
The alarm processor publishes each alarm to NetHorizhon clients.
Alarm forwarding
The alarm processor also forwards alarms to specific IP addresses if any
forwarding maps have been configured. The fault manager forwards alarm
information wrapped in special traps to particular fault system(s) for
processing.
The special traps defined for alarm forwarding are:
• alarmReceived, which is sent when a new alarm is generated in response
to a trap from device.
• alarmCleared, which is sent when an existing alarm is cleared (either by a
clearing trap or explicitly by an operator).
Environment variables in the FaultService.properties file specify alarm
forwarding, including destination hosts by alarm severity level and specific
alarms to be excluded from forwarding. See Traps and Alarms on page 107.
Figure 13 illustrates the general process that FS uses to process alarms. The
basic steps are:
General process to processing alarms:

1 Based on a trap received from a device, the alarm processor creates an
alarm.
2 The alarm processor stores the alarm (by way of the database service) to
the database.
3 The alarm processor publishes the alarm to NetHorizhon clients.
4 If FS is configured to send alarm notification mail messages, the forward
host processor forwards the alarm to the forward host manager, which
sends a mail message to registered individuals, indicating that the alarm
has occurred on the network.
5 If FS is configured to forward alarms, the alarm processor forwards the
alarm wrapped in special traps to particular fault system(s) for processing.

6 The alarm processor stores alarm details in the alarm log.
Figure 13: Processing alarms
Zhone Device
Trap
NetHorizhon Clients
3
Publishes alarm
ZMS Server
Network
6
Configuration
1 Stores alarm information
Fault in alarm log
Generates alarm
from trap Alarm Log
Performance
Monitoring
4
Sends alarm notification Diagnostics
mail message
Accounting
Administration
2
Database
Updates database
5
Forwards alarm Configuration Sync
ZMS
Database
Performance manager
The performance manager (PS) tracks network performance data in real time,
collects interval statistics, and monitors the status of network elements. This
data allows service providers and subscribers to track trends and service
levels.
General process to collect real-time statistics:

1 NetHorizhon requests real-time statistics at a specified polling interval.

Performance manager
2 PS authorizes the performance request (by way of the ADS).

3 Each polling interval, PS requests (by way of the network service) the
statistics from the device.
4 The device sends the real-time statistics (by way of the network service)
to PS.
5 PS forwards the response back to the client.
Figure 14 illustrates how PS collects real-time statistics.
Figure 14: Gathering real-time statistics
Zhone Device
Statistics
NetHorizhon Clients
3 4 5 1
Requests statistics Reports statistics Updates client Requests real-time
statistics
ZMS Server
Network
Configuration
Fault
Performance
Monitoring
Diagnostics
Accounting
2 Administration
Authorizes request
Database
Configuration Sync Multiple requests/

updates

Monitoring service
The monitoring services (MS) monitors devices for changes in network
connection status.
General process to monitor device status:

1 MS requests an inventory of devices from the database service.
2 Each polling interval, MS requests (by way of the network service) the
network connection status from each device.
3 The device sends the connection status (by way of the network service) to
MS.
4 MS sends an alarm (by way of the fault service) notifying NetHorizhon
clients of the change. Each operator’s NetHorizhon display updates to
reflect the trap.
Figure 15 illustrates how MS monitors for device network connection status.

Diagnostics service
Figure 15: Monitoring device network connection status
Zhone Device
Connection
Status
NetHorizhon Clients
2 3 4
Requests status Reports status Sends alarm
ZMS Server
Network
Configuration
Fault
Performance
Monitoring
Diagnostics
Accounting
Administration
1
Requests device Database
inventory
updates
Diagnostics service
The diagnostics service (DGS) runs diagnostics tests on cards in the network.
Diagnostics test information is useful for detecting and addressing network
problems.
General process to run diagnostics:

1 NetHorizhon requests a diagnostics test to be run a specified number of
times.
2 DGS authorizes the diagnostics request (by way of the ADS).
3 Each repetition, DGS requests (by way of the network service) that the
test be run on the device.

4 The device sends the results of the test (by way of the network service) to
DGS.
5 DGS forwards the response back to the client.
Figure 16 illustrates how DGS collects real-time statistics.
Figure 16: Running diagnostics
Zhone Device
Test Results
NetHorizhon Clients
3 4 5 1
Runs test Reports results Updates client Requests diagnostics
tests
ZMS Server
Network
Configuration
Fault
Performance
Monitoring
Diagnostics
Accounting
2 Administration
Authorizes request
Database

updates

TRAPS AND ALARMS
This appendix describes the ZMS alarms and associated traps. It includes the
following sections:
• ADSL alarms, page 108
• ATM TC sublayer alarms, page 110
• ATM VCL alarms, page 111
• Bitstorm HP alarm ( Bitstorm devices only), page 111
• Bonded G.SHDSL and T1E1 alarms, page 113
• Bulk statistics alarms, page 114
• Card alarms, page 115
• CLI alarms, page 118
• CPE alarms, page 119
• DHCP alarms, page 119
• DS1 and DS3 alarms, page 119
• DSL alarms, page 123
• ELCP alarms, page 123
• Flash card alarms, page 124
• GigaMux TL1 alarms (GigaMux 6400 devices only), page 125
• GR303 alarms, page 126
• IMA alarms, page 131
• IPD 4200 alarms (Paradyne devices only), page 134
• IPD 8800/8620 alarms (Paradyne devices only), page 137
• IPSLA alarms, page 140
• MTAC alarm, page 140
• ONU OMCI alarms, page 141
• ONU dying gasp alarm, page 142
• ZNID 4200 alarms, page 142

Traps and Alarms
• Physical alarms, page 143

• Shelf alarms, page 144
• SNR monitor threshold crossing alarms, page 146
• SONET alarms, page 147
• Subscriber alarms, page 149
• V5.2 alarms, page 149
• ZMS alarms, page 151
• ZRG alarms, page 152
ADSL alarms
ADSL ATUC initialization failure alarms
Alarm Trap Severity
N/A adslAtucInitFailureTrap Minor

adslAtucCurrStatus = 1




Near end modem (ATUC) failure during initialization adslAtucInitFailureTrap Minor

due to bit errors corrupting startup exchange data adslAtucCurrStatus = 6

due to peer ATU not able to support requested adslAtucCurrStatus = 7
configuration

due to incompatible protocol used by the peer ATU adslAtucCurrStatus = 8

ADSL alarms
Alarm Trap Severity

due to no activation sequence detected from peer adslAtucCurrStatus = 9
ATU
Clearing alarm adslAtucInitFailureTrap Minor

Clears:
Near end modem (ATUC) failure during
initialization due to bit errors corrupting
startup exchange data
initialization due to peer ATU not able to
support requested configuration
initialization due to incompatible
protocol used by the peer ATU
initialization due to no activation
sequence detected from peer ATU
ADSL ATUC threshold alarms
Alarm Trap Severity
Errored Second 15-minute interval threshold adslAtucPerfEssThreshTrap Major

reached on near end modem (ATUC)
Loss of Framing 15-minute interval threshold adslAtucPerfLofsThreshTrap Major

reached on near end modem (ATUC)
Loss of Link 15-minute interval threshold reached adslAtucPerfLolsThreshTrap Major

on near end modem (ATUC)
Loss of Signal 15-minute interval threshold reached adslAtucPerfLossThreshTrap Major

Loss of Power 15-minute interval threshold reached adslAtucPerfLprsThreshTrap Major

Minimum transmission threshold for upstream adslAtucMinTxThreshAlarmFailure Major

connection was exceeded (ATUC).

Traps and Alarms
ADSL ATUR threshold alarms
Alarm Trap Severity
Loss of Signal 15-minute interval threshold reached adslAturPerfLossThreshTrap Major

on far end modem (ATUR)
Errored Second 15-minute interval threshold reached adslAturPerfEssThreshTrap Major

Loss of Framing 15-minute interval threshold adslAturPerfLofsThreshTrap Major

reached on far end modem (ATUR)
Loss of Power 15-minute interval threshold reached adslAturPerfLprsThreshTrap Major

Minimum transmission threshold for downstream adslAturMinTxThreshAlarmFailure Major

connection was exceeded (ATUR).
ADSL rate change alarms
Alarm Trap
Near end modem (ATUC) transmit rate changed from adslAtucRateChangeTrap Minor
adslAtucChanPrevTxRate to
adslAtucChanCurrTxRate
Far end modem (ATUR) transmit rate changed from adslAturRateChangeTrap Minor
adslAturChanPrevTxRate to
adslAturChanCurrTxRate
ATM TC sublayer alarms
Alarm Trap Severity
ATM Interface TC Sublayer is currently in the Loss atmInterfaceTCAlarmStateChange Critical

of Cell Delineation defect maintenance state. atmInterfaceTCAlarmState = 2
Clearing alarm atmInterfaceTCAlarmStateChange N/A

atmInterfaceTCAlarmState = 1
Clears:
ATM Interface TC Sublayer is currently
in the Loss of Cell Delineation defect
maintenance state

ATM VCL alarms
ATM VCL alarms
Alarm Trap Severity
State of ATM VCL is unknown atmVclOperStatusChange Major

atmVclOperStatus = 3
Clears:
VCL is down
Clearing alarm atmVclOperStatusChange N/A

Clears:
State of ATM VCL is unknown
Clearing alarm atmVclOperStatusChange N/A

Clears:
VCL is down
State of ATM VCL is unknown
Bitstorm HP alarm ( Bitstorm devices only)

By default, the severity level for Bitstrom HP alarms is Minor. Customer can change
the severity level to Major or Minor.
Alarm Trap Severity
SYS-HOUSEKEEP1 TrapAlmSystemHousekeep1
Housekeeping pin 1 detect an alarm input
SYS-FAN TrapAlmSystemFanFailure
Fan module reports fan failure
SYS-SELFTESTFAILED TrapAlmSystemSelfTestTestFail
A module reports self-test failure
SYS-ABOVETEMP TrapAlmSystemAboveTemperature
Temperature above normal

Traps and Alarms
Alarm Trap Severity
GBE-LOS TrapAlmGBELOS
Loss of signal of the GBE interface
VDSL-LOF TrapAlmVdslLOF
Loss of frame of the DSLAM VDSL
interface
VDSL-LOS TrapAlmVdslLOS
Loss of signal of the DSLAM VDSL
interface
VDSL-LOSQ TrapAlmVdslLOSQ
Loss of signal quality of the DSLAM
VDSL interface
VDSL-LOL TrapAlmVdslLOL
Loss of link of the DSLAM VDSL
interface
VDSL-INIT-FAILURE TrapAlmVdslInitFailure
VDSL Init Failure
VDSL-ESE TrapAlmVdslESE
VDSL Excessive Severely Errored
Seconds of the VDSL interface
VDSL-NCD-SLOW TrapAlmVdslNCDSlow
VDSL No Cell Delination on the slow
channel
VDSL-LCD-SLOW TrapAlmVdslLCDSlow
VDSL Loss of Cell Delination on the
slow channel
VDSL-NCD-FAST TrapAlmVdslNCDFast
VDSL No Cell Delination on the fast
channel
VDSL-LCD-FAST TrapAlmVdslLCDFast
VDSL Loss of Cell Delination on the fast
channel
VDSL-LOF-FE TrapAlmVdslLOFFE
Loss of frame in the downstream
direction
VDSL-LOS-FE TrapAlmVdslLOSFE
Loss of signal in the downstream
direction

Bonded G.SHDSL and T1E1 alarms
Alarm Trap Severity
VDSL-LPR-FE TrapAlmVdslLPRFE
Loss of power in the downstream
direction
VDSL-LOSQ-FE TrapAlmVdslLOSQFE
Loss of signal quality in the downstream
direction
VDSL-NO-PEER-VTU-PRESENT-FE TrapAlmVdslNoPeerVtuPresentFE
VDSL No Peer Vtu Present in the
downstream direction
VDSL-ESE-FE TrapAlmVdslESEFE
VDSL Excessive Severely Errored
Seconds in the downstream direction
VDSL-NCD-FAST-FE TrapAlmVdslNCDFastFE
VDSL FE No Cell Delination on the slow
channel
VDSL-LCD-FAST-FE TrapAlmVdslNCDFastFE
VDSL FE No Cell Delination on the slow
channel
Bonded G.SHDSL and T1E1 alarms

ZMS can retrieve these two bonding alarms on bonded G.SHDSL and T1E1
MALC line cards, ETHX-33xx, and ETH-34xx:
Alarm Trap Severity
zhoneBondedGroupDown alarm linkDown Critical

Alarm description: VarBinds: zhoneTrapAlarmAction: set (1)
All links in the bond group are down, this bond group zhoneTrapAlarmId:
oper status is down. zhoneBondGroupDown (10128)
Clears: Clearing trap:
If one or more links in this bond group are up, the linkUp
bond group oper status is up. VarBinds: zhoneTrapAlarmAction: clear (2)
zhoneTrapAlarmId:
zhoneBondGroupDown (10128)
zhoneBitRateThresholdExceeded alarm zhoneAlarmConfigThresholdTrap Minor

Alarm description: alarmConfigTrapPrefix = 1
Threshold alarm when a bond group rate drops below Clearing trap:
this threshold. zhoneAlarmConfigThresholdClearTrap
alarmConfigTrapPrefix = 2

Traps and Alarms
Bulk statistics alarms
Alarm Trap Severity
collectionInProgress (1) - Indicates that collection of zhoneBulkStatisticsIntervalFailure

statistics are in progress. zhoneBulkStatsSystemOperStatus=1
collectionComplete (2) - Indicates that collection of zhoneBulkStatisticsIntervalFailure

statistics were successfully completed. zhoneBulkStatsSystemOperStatus=2
Collection for the previous interval has not completed zhoneBulkStatisticsIntervalFailure Warning
prior to the start of the current collection interval zhoneBulkStatsSystemOperStatus=3
Collection for the current interval has been aborted zhoneBulkStatisticsIntervalFailure Warning
due to insufficient disk space on the device zhoneBulkStatsSystemOperStatus=4
Collection for the current interval has been aborted zhoneBulkStatisticsIntervalFailure Warning
due to a file IO (write) error on the device zhoneBulkStatsSystemOperStatus=5
Collection for the current interval has completed, but zhoneBulkStatisticsIntervalFailure Warning
the resulting file could not be transferred via FTP to zhoneBulkStatsSystemOperStatus=6
the specified host
Clearing alarm cardMemStatusChange N/A

cardMemStatus = 1
Clears:
RAM low on memory, more than 90% of
RAM is used

cardMemStatus = 3
Clears:
Flash low on memory, not enough flash
for maximum database
Flash out of memory, data no longer
persistent

Card alarms
Card alarms
Card memory alarms
Alarm Trap Severity
RAM low on memory, more than 90% of RAM is cardMemStatusChange Critical

used cardMemStatus = 2
Flash low on memory, not enough flash for maximum cardMemStatusChange Critical
database cardMemStatus = 4
Flash out of memory, data no longer persistent cardMemStatusChange Critical

cardMemStatus = 5

cardMemStatus = 1
Clears:
RAM low on memory, more than 90% of
RAM is used

cardMemStatus = 3
Clears:
Flash low on memory, not enough flash
for maximum database
Flash out of memory, data no longer
persistent
Card services alarms
Alarm Trap Severity
Card service is inactive or unavailable (slot zhoneCardServicesStatusChange Major

SlotNumber) cardServiceStatus = 2
Clears:
Card service in standby mode (slot
SlotNumber)

Traps and Alarms
Alarm Trap Severity
Card service in standby mode (slot SlotNumber) zhoneCardServicesStatusChange Warning

cardServiceStatus = 3
Card service is inactive or unavailable
(slot SlotNumber)
Clearing alarm zhoneCardServicesStatusChange N/A

cardServiceStatus = 4
Clears:
Card service is inactive or unavailable
(slot SlotNumber)
Card service in standby mode (slot
SlotNumber)
Card status change alarms
Alarm Trap Severity
A card has been removed from slot SlotNumber zhoneTrapCardStatusChange Warning

zhoneCardStatus = 1
Clears:
A card has been added to slot SlotNumber
A card has been added to slot SlotNumber zhoneTrapCardStatusChange Warning

zhoneCardStatus = 2
Clears:
A card has been removed from slot
SlotNumber
Timeout on a card zhoneTrapCardStatusChange Major

zhoneCardStatus = 3
Card fault error zhoneTrapCardStatusChange Major

zhoneCardStatus = 4
Card has been reset zhoneTrapCardStatusChange Major

zhoneCardStatus = 5
Clearing alarm zhoneTrapCardStatusChange

zhoneCardStatus = 6
Clears:
A card has been added to slot SlotNumber
Timeout on a card
Card fault error
Card has been reset

Card alarms
Card version alarm
Alarm Trap Severity
Card version CardVersion (SlotNumber) is zhoneTrapCardVersionCheck Major

incompatible with that of active InfoServ card
External relay (environmental) alarms
Alarm Trap Severity
Alarm on External Relay 1 zhoneExternalAlarmTrap Minor

zhoneExternalRelayState = 1 (open) or 2 (closed)
zhoneExternalRelayName = name









Traps and Alarms
Alarm Trap Severity



Card redundancy unsafe alarms
Alarm Trap Severity
Slot slotNumber is not in redundant mode zhoneCardRedundancyUnsafe major

zhoneTrapAlarmAction=set (1)
Clearing alarm zhoneCardRedundancyUnsafe major

zhoneTrapAlarmAction=clear (2)
CLI alarms
CLI blocking alarms
Alarm Trap Severity
At least one CLI session has been unblocked. zhoneZmsBlockCliChange Warning

status = unblocked
All CLI sessions are blocked. zhoneZmsBlockCliChange Warning

status = blocked

CPE alarms
CPE alarms
CPE alarms
Alarm Trap Severity
Zhone CPE connection is down zhoneTrapCpeConnectionDown Critical
Clearing alarm zhoneTrapCpeConnectionUp N/A
DHCP alarms
DHCP alarms
Alarm Trap Severity
An IP address is being offered to a Zhone CPE device dhcpTrapZhoneCpeDetected Warning
DS1 and DS3 alarms

DS1 alarms
Alarm Trap Severity
Far end LOF zhoneLineStatusChange Major

zhoneLineStatus = 2
Far end sending LOF Indication zhoneLineStatusChange Major

zhoneLineStatus = 4
Far End sending AIS zhoneLineStatusChange Major

zhoneLineStatus = 8
Near end sending AIS zhoneLineStatusChange Major

zhoneLineStatus = 16
Near end LOF zhoneLineStatusChange Major

Near end Loss of Signal zhoneLineStatusChange Major


Traps and Alarms
Alarm Trap Severity
Near end is looped zhoneLineStatusChange Major

E1 TS16 AIS zhoneLineStatusChange Major

Far end sending TS16 LOMF zhoneLineStatusChange Major

Near end sending TS16 LOMF zhoneLineStatusChange Major

Near end detects a test code zhoneLineStatusChange Minor

Any line status undefined zhoneLineStatusChange Major

Near end in unavailable signal state zhoneLineStatusChange Major

Carrier Equipment out of service zhoneLineStatusChange Critical

Clearing alarm zhoneLineStatusChange N/A

zhoneLineStatus = 1
Clears:
Far end LOF
Far end sending LOF Indication
Far End sending AIS
Near end sending AIS
Near end LOF
Near end Loss of Signal
Near end is looped
E1 TS16 AIS
Far end sending TS16 LOMF
Near end sending TS16 LOMF
Near end detects a test code
Any line status undefined
Near end in unavailable signal state
Carrier Equipment out of service

DS1 and DS3 alarms
DS3 alarms
Alarm Trap Severity
Receiving Yellow/Remote Alarm Indication dsx3LineStatusChange Major

dsx3LineStatus = 2
Transmitting Yellow/Remote Alarm Indication dsx3LineStatusChange Major

dsx3LineStatus = 4
Receiving AIS failure state dsx3LineStatushange Major

dsx3LineStatus = 8
Transmitting AIS dsx3LineStatusChange Major

dsx3LineStatus = 16
Receiving LOF failure state dsx3LineStatusChange Major

dsx3LineStatus = 32
Receiving LOS failure state dsx3LineStatusChange Major

dsx3LineStatus = 64
Looping the received signal dsx3LineStatusChange Major

dsx3LineStatus = 128
Receiving a Test Pattern dsx3LineStatusChange Minor

Any line status not defined dsx3LineStatusChange Major

Near End in Unavailable Signal State dsx3LineStatusChange Major


Traps and Alarms
Alarm Trap Severity
Carrier Equipment Out of Service dsx3LineStatusChange Critical

Clearing alarm dsx3LineStatusChange N/A

dsx3LineStatus = 1
Clears:
Receiving Yellow/Remote Alarm
Indication
Transmitting Yellow/Remote Alarm
Indication
Receiving AIS failure state
Transmitting AIS
Receiving LOF failure state
Receiving LOS failure state
Looping the received signal
Receiving a Test Pattern
Any line status not defined
Near End in Unavailable Signal State
Carrier Equipment Out of Service
DS3 PLCP alarms
Alarm Trap Severity
DS3 PLCP has received an incoming Yellow Signal atmDsx3PlcpAlarmStatusChange Critical

atmInterfaceDs3PlcpAlarmState = 2
DS3 PLCP has declared a loss of frame (LOF) failure atmDsx3PlcpAlarmStatusChange Critical
condition atmInterfaceDs3PlcpAlarmState = 3
Clearing alarm atmDsx3PlcpAlarmStatusChange N/A

atmInterfaceDs3PlcpAlarmState = 1
Clears:
DS3 PLCP has received an incoming
Yellow Signal
DS3 PLCP has declared a loss of frame
(LOF) failure condition

DSL alarms
DSL alarms
DSL status change alarms
These alarms are applicable to SDSL and SHDSL interfaces only.
Alarm Trap Severity
Noise margin is below minimum or bit-error-rate zhoneDslLineAlarmStatusChange Major

exceeded 1/10000000 on DSL line zhoneDslLineAlarmStatus=4
A forward LOSW alarm has been detected on DSL zhoneDslLineAlarmStatusChange Major

line zhoneDslLineAlarmStatus=6
Endpoint failure during initialization due to paired zhoneDslLineAlarmStatusChange Major

endpoint not able to support requested configuration zhoneDslLineAlarmStatus=7
Endpoint failure during initialization due to zhoneDslLineAlarmStatusChange Warning

incompatible protocol used by the paired endpoint zhoneDslLineAlarmStatus=8
Endpoint failure during initialization due to activation zhoneDslLineAlarmStatusChange Warning

sequence detected from paired endpoint zhoneDslLineAlarmStatus=9
A loopback is currently active at this segment zhoneDslLineAlarmStatusChange Major

endpoint zhoneDslLineAlarmStatus=10
ELCP alarms
ELCP alarms
Alarm Trap Severity
ELCP interface group is down aal2ElcpIgOperStatusChange Critical

Clears: aal2ElcpIgOperStatus = 2
State of ELCP interface group is unknown

Traps and Alarms
Alarm Trap Severity
State of ELCP interface group is unknown aal2ElcpIgOperStatusChange Critical

Clears: aal2ElcpIgOperStatus = 3
ELCP interface group is down
Clearing alarm aal2ElcpIgOperStatusChange N/A

aal2ElcpIgOperStatus = 1
Clears:
ELCP interface group is down
State of ELCP interface group is
unknown
Flash card alarms
Alarm Trap Severity
Flash card removed from first port: zhoneTrapFlashCardStatusChange Major

zhoneFlashCardStatusChange = 2
Clearing alarm zhoneTrapFlashCardStatusChange N/A

zhoneFlashCardStatusChange= 1
Clears:
Flash card removed from first port
Flash card removed from second port zhoneTrapFlashCardStatusChange Major

Clearing alarm zhoneTrapFlashCardStatusChange N/A

Clears:
Flash card removed from second port

GigaMux TL1 alarms (GigaMux 6400 devices only)
GigaMux TL1 alarms (GigaMux 6400 devices only)

GigaMux devices have a different alarm implementation. GigaMux 6400
device does not have seperate traps for each card in SNMP but it has in TL1,
so the complete TL1 trap is encapsulated in a SNMP trap named
otm32TL1AutonomousTrap. This means irrespective of the trap type, ZMS
receives otm32TL1AutonomousTrap only.
For the details, refer to the GigaMux TL1 Command Reference.
Alarm Trap Severity
TCA (Threshold Crossing Alert) otm32TL1AutonomousTrap Warning

Description:
Retrieves the threshold crossing alert.
Local link failure otm32TL1AutonomousTrap Minor

Description:
The local link on the GMOSC-100 has
failed.
Remote link failure otm32TL1AutonomousTrap Critical

Description:
There is a remote link failure.
Gige link down otm32TL1AutonomousTrap Critical

Description:
This facility alarm only applies to the
GM10GE10G card, GM4GE2G5 card
and GMDM10 card. (GMDM10 card will
be supported in future ZMS releases.)
The possible cause is Gigabit Ethernet
link is down.
CPMissing (Circuit Pack Missing) otm32TL1AutonomousTrap Critical

Description:
Circuit pack is missing
LOSINSIG (Loss Of Input Signal) otm32TL1AutonomousTrap Critical

Description:
Loss of input signal
LOSINPWR(Loss Of Input Power) otm32TL1AutonomousTrap Critical

Description:
Loss of input power
CL, TCA Clears: N/A

Threshold crossing alert

Traps and Alarms
Alarm Trap Severity
CL,Link failure Clears: N/A

Local link failure
CL,Link failure Clears: N/A

Remote link failure
CL,Link down Clears: N/A

Link down
CL,CPMissing Clears: N/A

Missing circuit pack
CL,LOSINSIG Clears: N/A

Loss of input signal
CLI,LOSINPWR Clears: N/A

Loss of input power
GR303 alarms
GR303 IG alarms
Alarm Trap Severity
N/A gr303CrvRemoteAdminStateChange Low
N/A gr303CrvStateChange Low
Gr303 IG (IgName IG Name) system time igSystemTimeChange Information

synchronized with RDT
Bad Ami violation (Interface name) isdnTrapAmiViolations Major
Far end code violation (Interface name) isdnTrapFECV Major
Driver receives three successive out of synch frames isdnTrapFrameSyncLoss Major

(Interface name)

GR303 alarms
GR303 CRV remote state alarms
Alarm Trap Severity
Gr303 CRV a fault condition on line (IgName/CRV igCrvRemoteStateChange Critical

IG Name/CRV) igCrvOperStatus = 1
Gr303 CRV object is manually taken OOS for igCrvRemoteStateChange Warning

maintenance purpose (IgName/CRV IG Name/CRV) igCrvOperStatus = 2
Gr303 CRV entity removed from service by switch igCrvRemoteStateChange Minor

(IgName/CRV IG Name/CRV) igCrvOperStatus = 3
Gr303 CRV not equipped (IgName/CRV IG Name/ igCrvRemoteStateChange Major

CRV) igCrvOperStatus = 4
Gr303 CRV line is not connected (IgName/CRV IG igCrvRemoteStateChange Major

Name/CRV) igCrvOperStatus = 5
Clearing alarm igCrvRemoteStateChange N/A

igCrvOperStatus = 0
Clears:
Gr303 CRV a fault condition on line
(IgName/CRV IG Name/CRV)
Gr303 CRV not equipped (IgName/CRV
IG Name/CRV)
Gr303 CRV line is not connected
GR303 TMC state change alarms
Alarm Trap Severity
Gr303 line in permanent signal condition (IgName/ igCrvTmcStateChange Minor

CRV IG Name/CRV) igCrvTmcState = 2
Clearing alarm igCrvTmcStateChange N/A

igCrvTmcState = 1
Clears alarm:
Gr303 line in permanent signal condition

Traps and Alarms
GR303 EOC primary state change alarms
Alarm Trap Severity
Gr303 EOC Primary Service in standby mode igEocPrimaryStateChange Warning

(IgName IG Name) igControlChannelEocPrimarySvcState =
2
Gr303 EOC Primary Service out of service (IgName igEocPrimaryStateChange Major

IG Name) igControlChannelEocPrimarySvcState =
3
Clearing alarm igEocPrimaryStateChange N/A

igControlChannelEocPrimarySvcState =
1
Clears:
Gr303 EOC Primary Service in standby
mode (IgName IG Name)
Gr303 EOC Primary Service out of
service (IgName IG Name)
GR303 EOC secondary state change alarms
Alarm Trap Severity
Gr303 EOC Secondary Service in standby mode igEocSecondaryStateChange Warning

(IgName IG Name) igControlChannelEocSecondarySvcState
Clears =2
Gr303 EOC Secondary Service in standby mode
(IgName IG Name)
Gr303 EOC Secondary Service out of service igEocSecondaryStateChange Major

(IgName IG Name) igControlChannelEocSecondarySvcState
=3
Clearing alarm igEocSecondaryStateChange N/A

igControlChannelEocSecondarySvcState
=1
Clears:
Gr303 EOC Secondary Service in
standby mode (IgName IG Name)

GR303 alarms
GR303 IG operational state change alarms
Alarm Trap Severity
Gr303 IG inoperable (IgName IG Name) igOperStatusChange Major

Clears: igOperationalStatus = 2
Gr303 IG in standby mode (IgName IG Name)
Gr303 IG going out of service (IgName IG Name)
Gr303 IG in standby mode (IgName IG Name) igOperStatusChange Warning

Clears: igOperationalStatus = 3
Gr303 IG inoperable (IgName IG Name)
Gr303 IG coming into service (IgName IG Name) igOperStatusChange Information

igOperationalStatus = 4
Gr303 IG going out of service (IgName IG Name) igOperStatusChange Major

Clearing alarm igOperStatusChange N/A

Clears:
Gr303 IG inoperable (IgName IG Name)
Gr303 IG in standby mode (IgName IG
Name)
Gr303 IG coming into service (IgName
IG Name)
GR303 TMC primary state change alarms
Alarm Trap Severity
Gr303 TMC Primary Service in standby mode igTmcPrimaryStateChange Warning

(IgName IG Name) igControlChannelTmcPrimarySvcState =
Clears: 2
Gr303 TMC Primary Service out of service (IgName
IG Name)

Traps and Alarms
Alarm Trap Severity
Gr303 TMC Primary Service out of service (IgName igTmcPrimaryStateChange Major

IG Name) igControlChannelTmcPrimarySvcState =
Clears: 3
Gr303 TMC Primary Service in standby mode
(IgName IG Name)
Clearing alarm igTmcPrimaryStateChange N/A

igControlChannelTmcPrimarySvcState =
1
Clears:
Gr303 TMC Primary Service in standby
mode (IgName IG Name)
Gr303 TMC Primary Service out of
GR303 TMC secondary state change alarms
Alarm Trap Severity
Gr303 TMC Secondary Service in standby mode igTmcSecondaryStateChange

(IgName IG Name) igControlChannelTmcSecondarySvcState
Clears: =2
Gr303 TMC Secondary Service out of service
(IgName IG Name)
Gr303 TMC Secondary Service out of service igTmcSecondaryStateChange

(IgName IG Name) igControlChannelTmcSecondarySvcState
Clears: =3
Gr303 TMC Secondary Service in standby mode
(IgName IG Name)
Clearing alarm igTmcSecondaryStateChange N/A

igControlChannelTmcSecondarySvcState
=1
Clears:
Gr303 TMC Secondary Service in
standby mode (IgName IG Name)
Gr303 TMC Secondary Service out of

IMA alarms
IMA alarms
IMA
Alarm Trap Severity
Loss of IMA frame detected on IMA link at near end imaFailureAlarm Major
imaAlarmStatus=2
imaAlarmType=1
IMA link is not synchronized with other links within imaFailureAlarm Major
the IMA group at near end imaAlarmStatus=2
imaAlarmType=2
Remote failure indication detected on IMA Link at imaFailureAlarm Major

near end imaAlarmStatus=2
imaAlarmType=3
IMA transmit link is misconnected imaFailureAlarm Major

imaAlarmStatus=2
imaAlarmType=4
IMA receive link is misconnected imaFailureAlarm Major

imaAlarmStatus=2
imaAlarmType=5
Transmit fault detected at near end on IMA link imaFailureAlarm Major

imaAlarmStatus=2
imaAlarmType=6
Receive fault detected at near end on IMA link imaFailureAlarm Major

imaAlarmStatus=2
imaAlarmType=7
IMA transmit link unusable at far end imaFailureAlarm Major

imaAlarmStatus=2
imaAlarmType=8
IMA receive link unusable at far end imaFailureAlarm Major

imaAlarmStatus=2
imaAlarmType=9
IMA far end is starting up imaFailureAlarm Major

imaAlarmStatus=2
imaAlarmType=10

Traps and Alarms
Alarm Trap Severity
IMA far end configuration aborted (Probable cause: imaFailureAlarm Major

far end tries to use unacceptable configuration imaAlarmStatus=2
parameters)
imaAlarmType=11
IMA far end configuration aborted (Probable cause: imaFailureAlarm Major

far end reports unacceptable configuration imaAlarmStatus=2
parameters)
imaAlarmType=12
Less than minimum required IMA transmit or receive imaFailureAlarm Major

links are active imaAlarmStatus=2
imaAlarmType=13
Less than minimum required IMA transmit or receive imaFailureAlarm Major

links are active at far end imaAlarmStatus=2
imaAlarmType=14
IMA far end is blocked imaFailureAlarm Major

imaAlarmStatus=2
imaAlarmType=15
IMA far end transmit clock mode is different than the imaFailureAlarm Major
near end transmit clock mode imaAlarmStatus=2
imaAlarmType=16

IMA alarms
Alarm Trap Severity
Clearing alarms imaAlarmType=1 N/A

For all clearing alarms, imaAlarmStatus=1 Clears:
Loss of IMA frame detected on IMA link
at near end
imaAlarmType=2 N/A
Clears:
IMA link is not synchronized with other
links within the IMA group at near end
imaAlarmType=3 N/A
Clears:
Remote failure indication detected on
IMA Link at near end
imaAlarmType=4 N/A
Clears:
IMA transmit link is misconnected
imaAlarmType=5 N/A
Clears:
IMA receive link is misconnected
imaAlarmType=6 N/A
Clears:
Transmit fault detected at near end on
IMA link
imaAlarmType=7 N/A
Clears:
Receive fault detected at near end on
IMA link
imaAlarmType=8 N/A
Clears:
IMA transmit link unusable at far end
imaAlarmType=9 N/A
Clears:
IMA receive link unusable at far end
imaAlarmType=10 N/A
Clears:
IMA far end is starting up

Traps and Alarms
Alarm Trap Severity
Clearing alarms, continued imaAlarmType=11 N/A

Clears:
IMA far end configuration aborted
(Probable cause: far end tries to use
unacceptable configuration parameters)
imaAlarmType=12 N/A
Clears:
IMA far end configuration aborted
(Probable cause: far end reports
unacceptable configuration parameters)
imaAlarmType=13 N/A
Clears:
Less than minimum required IMA
transmit or receive links are active
imaAlarmType=14 N/A
Clears:
Less than minimum required IMA
transmit or receive links are active at far
end
imaAlarmType=15 N/A
Clears:
IMA far end is blocked
imaAlarmType=16 N/A
Clears:
IMA far end transmit clock mode is
different than the near end transmit clock
mode
IPD 4200 alarms (Paradyne devices only)
Alarm Trap Severity
Communication link is down. linkDown Critical
DSX1 Line Status Changed. dsx1LineStatusChange Major
Loss of Framing 15-minute interval threshold reached adslAtucPerfLofsThreshTrap Informational

on near end modem (ATUC).
Loss of Signal 15-minute interval threshold reached adslAtucPerfLossThreshTrap Informational


IPD 4200 alarms (Paradyne devices only)
Alarm Trap Severity
Loss of Power 15-minute interval threshold reached adslAtucPerfLprsThreshTrap Informational

Errored second 15-minute interval threshold reached adslAtucPerfESsThreshTrap Informational

Loss of Link 15-minute interval threshold reached on adslAtucPerfLolsThreshTrap Informational

near end modem (ATUC).
Loss of Framing 15-minute interval threshold reached adslAturPerfLofsThreshTrap Informational

on far end modem (ATUC).
Loss of Signal 15-minute interval threshold reached adslAturPerfLossThreshTrap Informational

Loss of Power 15-minute interval threshold reached adslAturPerfLprsThreshTrap Informational

Errored second 15-minute interval threshold reached adslAturPerfESsThreshTrap Informational

Near end modem (ATUC) failure during initialization adslAtucInitFailureTrap Informational

due to bit errors corrupting startup exchange data.
Near end modem (ATUC) transmit rate changed. adslAtucRateChangeTrap Informational
Far end modem (ATUC) transmit rate changed. adslAturRateChangeTrap Informational
Severely errored seconds 15 minute interval threshold adslAtucSesLThreshTrap Informational

reached on near end modem (ATUC).
Unavailable Seconds 15-minute interval threshold adslAtucUasLThreshTrap Informational

Unavailable Seconds 15-minute interval threshold adslAtucSesLThreshTrap Informational

Unavailable Seconds 15-minute interval threshold adslAturUasLThreshTrap Informational

reached on far end modem (ATUC).
Unavailable Seconds 15-minute interval threshold adslAturSesLThreshTrap Informational

Loop Attenuation Threshold has been reached or hdsl2ShdslLoopAttenCrossing Informational

exceeded.
SNR Margin has been reached or exceeded. hdsl2ShdslSNRMarginCrossing Informational
Errored Seconds threshold has been reached or hdsl2ShdslPerfESThresh Informational

exceeded.
Severely Errored Seconds threshold has been reached hdsl2ShdslPerfSESThresh Informational

or exceeded.
CRC Anomalies threshold has been reached or hdsl2ShdslPerfCRCanomaliesThresh Informational

exceeded.

Traps and Alarms
Alarm Trap Severity
SOSW seconds threshold has been reached or hdsl2ShdslPerfLOSSWSThresh Informational

exceeded.
Unavailable seconds threshold has been reached or hdsl2ShdslPerfUASThresh Informational

exceeded.
Mismatch between number of repeater of line and the hdsl2ShdslSpanInvalidNumRepeaters Informational

number of units discovered via the EOC.
An endpoint maintenance loopback command failed hdsl2ShdslLoopbackFailure Major

for segment.
Bit setting in powerBackOff status for the endpoint hdsl2ShdslpowerBackoff Major

has been changed.
Bit setting in deviceFault status for the endpoint has hdsl2ShdsldeviceFault Major
been changed.
Bit setting in dcContinuity Fault status for the hdsl2ShdsldcContinuityFault Major

endpoint has been changed.
Bit setting in configInitFailure status for the endpoint hdsl2ShdslconfigInitFailure Major

has been changed.
Bit setting in protocolInitFailure status for the hdsl2ShdslprotocolInitFailure Major

Bit setting in noNeighborPresent status for the hdsl2ShdslnoNeighborPresent Informational

Unit failure due to loss of local power. hdsl2ShdslLocalPowerLoss Major
A File Transfer Event Firmware or Configuration has pdnDevFilXferEvent Informational

occurred.
Configuration Change Occurred. mpeCen Informational
Restart / Self Start partially failed. mpeSelfTestFailure Critical
Contacts State on Alarm Relay input have changed. mpeAlarmRelayInputStateChanged Major
A sensor is operating in excess of its threshold limits. pdnEntPhySensorExtThresholdExceed Informational

edSet
Downstream transmit rate has changed. pdnDslAtmBondAtucRateChange Informational
Upstream transmit rate has changed. pdnDslAtmBondAturRateChange Informational
Operational Status of Group has changed. pdnDslAtmBondGroupStatusChange Major
Loss Of Cell Delineation condition has occurred. atmfM4IfLcdAlarm Informational
Loss Of Signal has occurred. atmfM4IfLosAlarm Informational
A VCL Cross Connection has been deleted. atmIfM4VclXConnDeleted Informational
A VCL Cross Connection has been changed. atmIfM4VclXConnChanged Informational

IPD 8800/8620 alarms (Paradyne devices only)
Alarm Trap Severity
Communication link is down. linkDown Critical
Loss of Framing 15-minute interval threshold reached adslAtucPerfLofsThreshTrap Informational

Loss of Signal 15-minute interval threshold reached adslAtucPerfLossThreshTrap Informational

Loss of Power 15-minute interval threshold reached adslAtucPerfLprsThreshTrap Informational

Errored second 15-minute interval threshold reached adslAtucPerfESsThreshTrap Informational

Loss of Link 15-minute interval threshold reached on adslAtucPerfLolsThreshTrap Informational

near end modem (ATUC).
Loss of Framing 15-minute interval threshold reached adslAturPerfLofsThreshTrap Informational

Loss of Signal 15-minute interval threshold reached adslAturPerfLossThreshTrap Informational

Loss of Power 15-minute interval threshold reached adslAturPerfLprsThreshTrap Informational

Errored second 15-minute interval threshold reached adslAturPerfESsThreshTrap Informational

Near end modem (ATUC) failure during initialization adslAtucInitFailureTrap Informational

due to bit errors corrupting startup exchange data.
Near end modem (ATUC) transmit rate changed. adslAtucRateChangeTrap Informational
Far end modem (ATUC) transmit rate changed. adslAturRateChangeTrap Informational
Severely errored seconds 15 minute interval threshold adslAtucSesLThreshTrap Informational

Unavailable Seconds 15-minute interval threshold adslAtucUasLThreshTrap Informational

Unavailable Seconds 15-minute interval threshold adslAtucSesLThreshTrap Informational

Unavailable Seconds 15-minute interval threshold adslAturUasLThreshTrap Informational

Unavailable Seconds 15-minute interval threshold adslAturSesLThreshTrap Informational


Traps and Alarms
Alarm Trap Severity
Loop Attenuation Threshold has been reached or hdsl2ShdslLoopAttenCrossing Informational

exceeded.
SNR Margin has been reached or exceeded. hdsl2ShdslSNRMarginCrossing Informational
Errored Seconds threshold has been reached or hdsl2ShdslPerfESThresh Informational

exceeded.
Severely Errored Seconds threshold has been reached hdsl2ShdslPerfSESThresh Informational

or exceeded.
CRC Anomalies threshold has been reached or hdsl2ShdslPerfCRCanomaliesThresh Informational

exceeded.
SOSW seconds threshold has been reached or hdsl2ShdslPerfLOSSWSThresh Informational

exceeded.
Unavailable seconds threshold has been reached or hdsl2ShdslPerfUASThresh Informational

exceeded.
Mismatch between number of repeater of line and the hdsl2ShdslSpanInvalidNumRepeaters Informational

number of units discovered via the EOC.
An endpoint maintenance loopback command failed hdsl2ShdslLoopbackFailure Major

for segment.
Bit setting in powerBackOff status for the endpoint hdsl2ShdslpowerBackoff Major

has been changed.
Bit setting in deviceFault status for the endpoint has hdsl2ShdsldeviceFault Major
been changed.
Bit setting in dcContinuity Fault status for the hdsl2ShdsldcContinuityFault Major

Bit setting in configInitFailure status for the endpoint hdsl2ShdslconfigInitFailure Major

has been changed.
Bit setting in protocolInitFailure status for the hdsl2ShdslprotocolInitFailure Major

Bit setting in noNeighborPresent status for the hdsl2ShdslnoNeighborPresent Informational

Unit failure due to loss of local power. hdsl2ShdslLocalPowerLoss Major
AIS Condition has occurred. atmfM4IfAisAlarm Informational
Loss Of Cell Delineation condition has occurred. atmfM4IfLcdAlarm Informational
Loss Of Signal has occurred. atmfM4IfLosAlarm Informational
Loss Of Frame condition has occurred. atmfM4IfLofAlarm Informational
A VCL Cross Connection has been created. atmfM4VclXConnCreated Informational
A VCL Cross Connection has been deleted. atmfM4VclXConnDeleted Major
A VCL Cross Connection has been changed. atmfM4VclXConnChanged Informational

Alarm Trap Severity
A VPL Cross Connection has been created. atmfM4VplXConnCreated Informational
A VPL Cross Connection has been deleted. atmfM4VplXConnDeleted Major
A VPL Cross Connection has been changed. atmfM4VplXConnChanged Informational
At least one fan is non-functional. atmfM4HwFanFailAlarm Major
An ATM SubInterface has been created. atmfM4AtmCellIfCreated Informational
An ATM SubInterface has been removed. atmfM4AtmCellIfDeleted Major
entLastChangeTime has been created. mpeEntPhysicalExtEntityCreated Informational
An instance of Physical Ext Entity has been deleted mpeEntPhysicalExtEntityDeleted Major

from entPhysicalTable.
An instance of Physical Ext Entity has been changed mpeEntPhysicalExtEntityChanged Informational

from entPhysicalTable.
Restart / Self Start partially failed. mpeSelfTestFailure Critical
Configuration Change Occured. entConfigChange Informational
sonetSectionCurrentStatus / sonetLineCurrentStatus / devSonetStatusChange Informational

sonetPathCurrentStatus is changed.
No module is Active. pdnRedunEventNoActiveModule Critical
Hardware in Redundancy Configuration are pdnRedunEventHwIncompatible Critical

incompatible.
One of the modules configured for redundancy is pdnRedunEventStandbyAlarmOrReset Major

either in Standby / Alarm or Reset Test State.
Firmwares in Redundancy Configuration are pdnRedunEventFwIncompatible Critical

incompatible.
Configurations in Redundancy Configuration are pdnRedunEventCfgIncompatible Critical

incompatible.
One of the modules in a redundancy configuration pdnRedunEventLinkDefect Critical

has a link failure condition.
One of the modules in a redundancy configuration pdnRedunEventHwDefect Critical

has a hardware failure condition.
One of the modules in a redundancy configuration is pdnRedunEventHwMissingHwFailure Critical

expecting a piece of hardware which cannot be found.
This notification will be issued when the sfp is inserted into sfpEventInserted Informational
a physical port.
This notification will be issued when the sfp associated sfpEventOperational Informational
with a physical port is detected as being working.
SFP associated with a physical port is detected as sfpEventFaulty Critical

being faulty.

Traps and Alarms
Alarm Trap Severity
SFP has been removed from a physical port. sfpEventRemoved Critical
IMA Failure Alarm. imaFailureAlarm Major
IPSLA alarms
ZMS can now retrieve these three IPSLA alarms based on IPSLA threshold
traps:
Alarm Trap Severity
IPSLA timeout alarm zhoneIpSLATimeoutTrap Minor

zhoneIpSLATrapsPrefix = 1
Clearing trap:
zhoneIpSLATimeoutClearTrap
IPSLA latency threshold crossed alarm zhoneIpSLALatencyTrap Minor

Clearing trap:
zhoneIpSLALatencyClearTrap
IPSLA jitter threshold crossed alarm zhoneIpSLAJitterTrap Minor

Clearing trap:
zhoneIpSLAJitterClearTrap
MTAC alarm
Alarm Trap Severity
Ringer source not detected zhoneRingerStatusAlarm Critical

or zhoneTrapAlarmAction=set
Internal ringer disabled
Clearing alarm zhoneTrapAlarmAction=delete

ONU OMCI alarms
ONU OMCI alarms

ZMS supports the following GPON ONU OMCI alarms.
Alarm Trap Severity
ONT: Powering Alarm on port onuIfName zhoneGponOmciOnuAlarmsTrap Major

zhoneGponOmciOnuAlarmsText
(42, 47, 0, “Ont G”, “Powering Alarm”)
ONT: Physical Intrusion Alarm on port onuIfName zhoneGponOmciOnuAlarmsTrap Minor

(42, 43, 0, “Ont G”, “Physical Intrusion”)
ONT: Battery Low on port onuIfName zhoneGponOmciOnuAlarmsTrap Critical

(42, 15, 0, “Ont G”, “Battery Low”)
ONT: Battery Missing on port onuIfName zhoneGponOmciOnuAlarmsTrap Major

(42, 16, 0, “Ont G”, “Battery Missing”)
ONT: Battery Failure on port onuIfName zhoneGponOmciOnuAlarmsTrap Major

(42, 14, 0, “Ont G”, “Battery Failure”)
ONT: Self Test Failure on port onuIfName zhoneGponOmciOnuAlarmsTrap Major

(42, 41, 0, “Ont G”, “ONT Self Test Failure”)
ONT: Lan LOS on port onuIfName zhoneGponOmciOnuAlarmsTrap Minor

(11, 0, 1028, “PptpEthUni”, “LanLos”)
ONT: LOSS Of Signal on port onuIfName zhoneGponOmciOnuAlarmsTrap Minor

zhoneGponOnuAlarmsText
(12,1,1793,"PptpCesUni","Los")
ONT: Loss Of Frame on port xxxx onuIfName zhoneGponOmciOnuAlarmsTrap Minor

(12,2,1793,"PptpCesUni","Lof")
ONT:Remote Alarm Indication on port onuIfName zhoneGponOmciOnuAlarmsTrap Minor

(12,4,1793,"PptpCesUni","Rai")
ONT: E1 Receive Alarm on port xxxx onuIfName zhoneGponOmciOnuAlarmsTrap Minor

(12,13,1793,"PptpCesUni","2M Rec")
ONT: E1 Alarm Indication Signal on port onuIfName zhoneGponOmciOnuAlarmsTrap Minor

(12,14,1793,"PptpCesUni","2M Ais")

Traps and Alarms
Alarm Trap Severity
ONT: T1 Receive Alarm on port onuIfName zhoneGponOmciOnuAlarmsTrap Minor

(12,15,1793,"PptpCesUni","1.5M Rec")
ONT: T1 Alarm Indication Signal on port onuIfName zhoneGponOmciOnuAlarmsTrap Minor

(12,16,1793,"PptpCesUni","1.5M Ais")
Clearing zhoneGponOmciOnuAlarmsTrap
(42, 0, 0, “Ont G”, None)
ONU dying gasp alarm

Dying gasp alarm provides ONU information to the service provider when
this ONU is about to power down. The dying gasp event is followed by an
ONU down event.
If there is a link down alarm prior to receival of dying gasp trap, link down
alarm will be cleared and dying gasp alarm will be created.
Alarm Trap Severity
PortType communication link is zhoneGponOnuLineStatusChange Minor

down because of dying gasp VarBinds: zhoneGponOnuStatusWord contains dying gasp (12)
(Alias)
Clearing zhoneGponOnuLineStatusChange
VarBinds: zhoneGponOnuStatusWord = no alarm
ZNID 4200 alarms

ZMS supports the following ZNID 4200 alarms.
Alarm Trap Severity
The ZNID is receiving power from commercial znidBatteryRelayNotification Minor

power. This is the normal mode of operation. znidBatteryRelayStatus = 1
The ZNID is receiving power from battery. znidBatteryRelayNotification Minor

znidBatteryRelayStatus = 2
The battery has been reduced to the point that roughly znidBatteryRelayNotification Minor
20% of the available runtime is available. znidBatteryRelayStatus = 4

Physical alarms
Alarm Trap Severity
The battery has failed its periodic test. The battery znidBatteryRelayNotification Minor
should be replaced as system availability has been znidBatteryRelayStatus = 6
compromised.
The battery is disconnected. The ZNID will not be znidBatteryRelayNotification Minor

supported if the commercial power fails. znidBatteryRelayStatus = 8
The UPS unit is disconnected. The ZNID will not be znidBatteryRelayNotification Minor
supported if the commercial power fails. znidBatteryRelayStatus = 16
Physical alarms
Physical link alarms
Note: These alarms apply to all physical connections. Corrective

actions may vary depending on the physical connection.
Link up/ link down
Alarm Trap Severity
Communication link is down linkDown Critical

adminStatus = up
operStatus = down
Clears:
Port has been admin-ed down
Port has been admin’ed down. linkDown Major

adminStatus = down
operStatus = down
Clears:
Communication link is down
Also clears any other line status alarms
on that port.
Clearing alarm linkUp N/A

Clears:
Communication link is down
Port has been admin-ed down

Traps and Alarms
Shelf alarms
Shelf temperature alarms
Trap Alarm Severity
Temperature of the left outlet is over limit zhoneTrapShelfStatusChange Critical

zhoneShelfStatus = 1
Clearing alarm zhoneTrapShelfStatusChange N/A

Clears:
Temperature of the left outlet is over limit
Temperature of the right outlet is over limit zhoneTrapShelfStatusChange Critical


Clears:
Temperature of the right outlet is over
limit
Shelf temperature is under limit zhoneTrapShelfStatusChange Critical


Clears:
Shelf temperature is over limit
Shelf temperature is under limit
Shelf power alarms
Trap Alarm Severity
Power supply A failure zhoneTrapShelfStatusChange Critical


Clears:
Power supply A failure

Shelf alarms
Trap Alarm Severity
Power supply B failure zhoneTrapShelfStatusChange Critical


Clears:
Power supply B failure
Fan power supply A failure zhoneTrapShelfStatusChange Critical


Clears:
Fan power supply A failure
Fan power supply B failure zhoneTrapShelfStatusChange Critical


Clears:
Fan power supply B failure
Shelf fan alarms
Trap Alarm Severity
Fan error zhoneTrapShelfStatusChange Critical

Shelf fan tray is removed zhoneTrapShelfStatusChange Critical


Clears:
Shelf fan tray is removed

Clears:
Fan error

Traps and Alarms
Shelf controller alarms
Trap Alarm Severity
Shelf controller fault zhoneTrapShelfStatusChange Critical

Shelf temperature is under limit zhoneTrapShelfStatusChange Critical


Clears:
Shelf temperature is over limit
Shelf temperature is under limit
Fan power supply A failure zhoneTrapShelfStatusChange Critical

Fan power supply B failure zhoneTrapShelfStatusChange Critical


Clears:
Fan power supply A failure

Clears:
Shelf fan tray is removed
Shelf fan tray is removed zhoneTrapShelfStatusChange


Clears:
Fan error
SNR monitor threshold crossing alarms

Signal to Noise Ration (SNR) line monitoring alarms on MALC
EFM-SHDSL card.

SONET alarms
Alarm Trap Severity
SNR Margin has been crossed efmCuPmeSnrMgnCrossing Minor

Clears:
efmCuPmeSnrMgnCrossingClear
EFM Traffic Disabled efmCuPmeErrorThreshEfmTrafficDisable Minor

Clears:
efmCuPmeErrorThreshEfmTrafficEnable
SONET alarms
SONET line alarms
Alarm Trap Severity
N/A sonetClockTransmitSourceChange Critical
Alarm Indication Signal detected on a Sonet line sonetLineStatusChange Critical

This alarm cannot be manually cleared until the alarm sonetLineCurrentStatus = 2
condition no longer exists.
Remote Defect Indication detected on a Sonet line sonetLineStatusChange Critical

This alarm cannot be manually cleared until the alarm sonetLineCurrentStatus = 4
Clearing alarm sonetLineStatusChange N/A

sonetLineCurrentStatus = 1
Clears:
Alarm Indication Signal detected on a
Sonet line
Remote Defect Indication detected on a
Sonet line

Traps and Alarms
SONET path alarms
Alarm Trap Severity
Loss of Pointer detected on Sonet path sonetPathStatusChange Critical

This alarm cannot be manually cleared until the alarm sonetPathCurrentStatus = 2
Alarm Indication Signal detected on a Sonet path sonetPathStatusChange Critical

Remote Defect Indication detected on a Sonet path sonetPathStatusChange Critical

Sonet path unequipped sonetPathStatusChange Critical

Signal label mismatch detected on Sonet path sonetPathStatusChange Critical

SONET section alarms
Alarm Trap Severity
Loss of Signal detected on a Sonet section sonetSectionStatusChange Critical

This alarm cannot be manually cleared until the alarm sonetSectionCurrentStatus = 2
Loss of Frame detected on a Sonet section sonetSectionStatusChange Critical

This alarm cannot be manually cleared until the alarm sonetSectionCurrentStatus = 4
Clearing alarm sonetSectionStatusChange N/A

sonetSectionCurrentStatus = 1
Clears:
Loss of Signal detected on a Sonet
section
Loss of Frame detected on a Sonet
section

Subscriber alarms
Subscriber alarms
Subscriber alarm
Alarm Trap Severity
Subscriber (Id: SubscriberID, Name: atmVclOperStatusChange Major

SubscriberName) on Vcl (IfIndex: IfIndex, Vpi: VPI,
Vci: VCI) is affected
V5.2 alarms
V5.2 IG alarms
Alarm Trap Severity
None v52IgPortAlignmentNotification Critical
None v52IgProvVariantRequestNotification Critical
None v52LinkBlockNotification Critical
None v52LinkCheckIdNotification Critical
V5.2 C channel status change alarms
Alarm Trap Severity
V5.2 Communication Channel in standby mode v52CchannelStatusChange Critical

(IgName/LgId/ChannelNumber/TimeSlot IG Name/ v52CchannelStatus = 2
Line Group/Channel number/Time slot)

Traps and Alarms
Alarm Trap Severity
V5.2 Communication Channel failed (IgName/LgId/ v52CchannelStatusChange Critical

ChannelNumber/TimeSlot IG Name/Line Group/ v52CchannelStatus = 3
Channel number/Time slot)
Clearing alarm v52CchannelStatusChange N/A

v52CchannelStatus = 1
Clears:
V5.2 Communication Channel in standby
mode (IgName/LgId/ChannelNumber/
TimeSlot IG Name/Line Group/Channel
number/Time slot)
V5.2 Communication Channel failed
(IgName/LgId/ChannelNumber/TimeSlot
IG Name/Line Group/Channel number/
Time slot)
V5.2 C path operational state change alarms
Alarm Trap Severity
V5.2 Communication Path down (IgName/CPathId v52CpathOperStatusChange Critical

IG Name/C path) v52CpathOperStatus = 2
Clearing alarm v52CpathOperStatusChange N/A

v52CpathOperStatus = 1
Clears:
V5.2 Communication Path down
(IgName/CPathId IG Name/C path)
V5.2 IG operational state change alarms
Alarm Trap Severity
V5.2 IG inoperable (IgName IG Name) v52IgOperStatusChange Major

Clears: v52IgOperationalStatus = 2
V5.2 IG in standby mode (IgName IG Name)
V5.2 IG going out of service (IgName IG Name)
V5.2 IG in standby mode (IgName IG Name) v52IgOperStatusChange Warning

Clears: v52IgOperationalStatus = 3
V5.2 IG inoperable (IgName IG Name)
V5.2 IG coming into service (IgName IG Name)

ZMS alarms
Alarm Trap Severity
V5.2 IG service degraded (IgName IG Name) v52IgOperStatusChange Warning

v52IgOperationalStatus = 4
V5.2 IG coming into service (IgName IG Name) v52IgOperStatusChange Information

V5.2 IG going out of service (IgName IG Name) v52IgOperStatusChange Major

Clearing alarm v52IgOperStatusChange N/A

Clears:
V5.2 IG inoperable (IgName IG Name)
V5.2 IG in standby mode (IgName IG
Name)
V5.2 protection C path operational state change alarms
Alarm Trap Severity
None v52ProtectionCPathOperStatusChange Critical

v52ProtectionCPathOperStatus = 1
None v52ProtectionCPathOperStatusChange Critical

v52ProtectionCPathOperStatus = 2
ZMS alarms
ZMS alarms
ZMS cannot reach device
Alarm Trap Severity
The device is not reachable N/A Critical
ZMS login failure alarm support
Enabling the option Generate ZMS Alarm on Login Failure in the Modify
Security Policy Configuration dialog box by admin user is required for ZMS
login failure alarm raising. Every time user fails on the login, a ZMS login
failure alarm will be raised, and an alarm notification email with username

Traps and Alarms
and host IP information will be sent out if alarmMailServer, alarmMailSender,

and zmsAlarmMailRecepients are specified in the property file.
Note: One ZMS login failure alarm for each username.
Note: Multiple login failures will be displayed in the Description

column of the Alarm Viewer window with the number of login
attemps.
For example, Reoccurred(2): Client user login failure.
ZMS can now retrieve the ZMS login failure alarm in this release:
Alarm Trap Severity
Client user login failure N/A Warning
ZMS config sync alarms
A full config sync update has failed

An object in the device configuration database has changed by CLI
modification. A CLI modification activates a partial config sync.
ZRG alarms
Alarm Trap Severity
The ZRG is receiving power from commercial power. zrgBatteryRelayNotification Minor

This is the normal mode of operation. zrgBatteryRelayStatus = 1
The ZRG is receiving power from battery. zrgBatteryRelayNotification Minor

zrgBatteryRelayStatus = 2
The battery has been reduced to the point that roughly zrgBatteryRelayNotification Minor
20% of the available runtime is available. zrgBatteryRelayStatus = 4
The battery has failed its periodic test. The battery zrgBatteryRelayNotification Minor
should be replaced as system availability has been zrgBatteryRelayStatus = 6
compromised.
The battery is disconnected. The ZRG will not be zrgBatteryRelayNotification Minor

supported if the commercial power fails. zrgBatteryRelayStatus = 8
The UPS unit is disconnected. The ZRG will not be zrgBatteryRelayNotification Minor
supported if the commercial power fails. zrgBatteryRelayStatus = 16

MODIFYING ZMS ALARM DESCRIPTIONS
You can customize individual alarm descriptions to include one or more

attribute values by modifying the FSAlarmDescription.properties file.
To add an attribute to an alarm description, use the format
$$attribute_name$$, where attribute_name is an existing attribute on the
object generating the alarm. For example, to identify what particular object
generated an alarm, you can add the object name to the alarm description:
The status of AAL type 2 PVC ($$name$$) (vpi=$$vpi$$/
vci=$$vci$$) has gone down
you would see:
The status of AAL2 PVC pvc_la vpi=0/vci=100 has gone down
For a list of attribute names contact the Zhone Global Service and Support
(GSS).

Modifying ZMS alarm descriptions

INDEX
A configuring server startup file 29

configuring ZMS managers
about this guide 13 configuration synchronization service 38, 39,
account information, description of 77 40, 41
account status for NetHorizhon operators 70, 75 description 30
activating accounts, description of 77 diagnostics service 38
admin password fault manager 32, 44
changing 68 monitoring service 37
administering operator accounts network service 30
creating operator accounts 65 performance manager 37
deleting operator accounts 71, 76 creating operator accounts
description 65 account information 77
modifying operator accounts 70 procedure 65
viewing operator accounts 70 creating operator accounts, description of 77
administration manager
description 20, 89 D
management request 89
alarm forwarding, description of 101 database archive logs, description of 62
alarm log, description of 80 database service, description of 20
alarm notification by e-mail 33 deleting operator accounts, procedure for 71, 76
alarm processor DGS.properties 38
alarm mapping 99 diagnostics service
alarm processing 95 description 105
applying rules 101 running diagnostics 105
description 99
alarms, definition of 95 E
applications
NetHorizhon 13 e-mail notification of alarms 33
ZMS 13 events
audit log definition 95
audit log fields 80 external relay state, setting 44
description 80 external relay, state variable 34
example 80
modifying information displayed 81 F
C fault manager
configuration 32, 44
collecting real-time statistics, procedure for 102 description 20, 94
configuration manager fault processing 94
description 20, 93 fault processing
resource provision 93 alarm processor 99
configuration synchronization service description 94
description 20, 90 trap processing 96
ZMS object activation 90 trap receiver 96

Index
FaultService.properties 32 monitoring service 104

forwarded alarm log, description of 83 performance manager 102
forwarded trap log, description of 84 network elements, management of 89
FSAlarmDescription.properties 32, 46 network service
FSAlarmSeverity.properties 32, 45 configuration 30
NWS.properties 30
G
O
group
creating (as admin user) 69 operator accounts
activating 70, 76
L creating (as admin user) 69
creating (as user administrator) 74
logs, monitoring of 79 deactivating 70, 76
deleting 71, 76
M deleting (as admin user) 71
deleting (as user administrator) 76
modifying operator accounts modifying 70, 76
procedure 70 supplying information to operator 77
when modifications take effect 71, 76 viewing (as admin user) 70
monitoring device status, procedure for 104 viewing (as user administrator) 75
monitoring service Oracle database
description 104 description 26
device status 104 OSS Gateway 19
monitoring ZMS logs
alarm log 79 P
audit log 79
forward trap log 79 password
server log 79 default admin 67
trap log 79 modifying 70, 76
performance manager
N collecting real-time statistics 102
configuration 37
NetHorizhon description 20, 102
administering operator accounts 65 permissions
changing admin password 68 definition 66
client, description of 20 properties files
operator account status 70, 75 configuring 30
operator definition 27 DGS.properties 38
operator user name 69, 75 FaultService.properties 32
product description 13 FSAlarmDescription.properties 32, 46
supplying account information to operators 77 FSAlarmSeverity.properties 32, 45
user, definition of 27 NWS.properties 30
network elements PS.properties 37
administration manager 89 UserDefined_template.properties 44
configuration manager 93 PS.properties 37
configuration synchronization service 90
diagnostics service 105
fault manager 94

R ZMS
administrative tasks 29
reliable traps 95 applications 13, 19
running diagnostics, procedure for 105 architecture 21
configuring server startup file 29
S configuring ZMS managers 30
logs 79
server log, description of 84 network elements 89
setup tasks 27 product description 19
SNMP setup tasks 27
trap storm 36 system components 19
terminology 26
user administrator, definition of 27
T
ZMS Administrator’s Guide
audience 13
task log
contacting customer support 15
description 83
document organization 13
example 83
necessary user knowledge 13
task log fields 83
related documentation 15
terminology 26
ZMS database
trap forwarding, description of 97
description 20, 26
trap log
ZMS managers
description 84
accounting manger 19
example 85
administration manager 20
trap log fields 84
configuration manager 19, 20
trap processing
configuration synchronization service 20
description 96
database service 20
procedure 98
description 19
trap receiver 96
diagnostics manager 19
trap processing 95
fault manager 19, 20
traps
how they manage network elements 89
definition 94
monitoring manager 19
processing 96
performance manager 19, 20
storm, configuring parameters for 36
ZMS server
description 19
U ZMS system components
NetHorizhon client 19
UDAlarmDescription_template.properties 44 Zhone network objects 19
UDAlarmSeverity_template.properties 44 ZMS database 19
user name for NetHorizhon operators 69, 75 ZMS manager 19
ZMS server 19
V ZMS terminology
manager, definition of 26
viewing operator accounts object, definition of 26
procedure 70 permissions, definition of 27
subscriber, definition of 27
Z user, definition of 27
Zhone Management System. See ZMS.

Zhone network objects, description of 20

Index

830-00742-47 ZMS Admin Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

830-00742-47 ZMS Admin Guide

Uploaded by

Copyright:

Available Formats

ZMS Administrator’s Guide

For software version ZMS 2.1

COPYRIGHT ©2000-2010 Zhone Technologies, Inc. All rights reserved.

2 ZMS Administrator’s Guide

About This Guide .............................................................................................................................13

Chapter 1 Overview ....................................................................................................................19

Chapter 2 System Administration........................................................................................29

ZMS Administrator’s Guide 3

Chapter 3 ZMS database server administration ............................................................49

Chapter 4 Administering Operator Accounts ................................................................65

4 ZMS Administrator’s Guide

Chapter 5 Monitoring ZMS Logs ..........................................................................................79

Appendix A How ZMS Manages Network Elements.........................................................89

Appendix B Traps and Alarms.................................................................................................107

ZMS Administrator’s Guide 5

ATM TC sublayer alarms ......................................................................................110

6 ZMS Administrator’s Guide

Appendix C Modifying ZMS alarm descriptions ..............................................................153

ZMS Administrator’s Guide 7

8 ZMS Administrator’s Guide

Figure 1: ZMS environment ........................................................................ 21

ZMS Administrator’s Guide 9

10 ZMS Administrator’s Guide

Table 1: ZMS system terminology .............................................................. 26

ZMS Administrator’s Guide 11

12 ZMS Administrator’s Guide

Zhone Management System (ZMS™) is the network management system that

Read To learn about

Chapter 1, Overview, on page 19. System components and description.

Chapter 2, System Administration, on page 29. Administering ZMS components.

Chapter 3, ZMS database server administration, Administering the ZMS database.

Chapter 4, Administering Operator Accounts, on Administering operator accounts.

ZMS Administrator’s Guide 13

Read To learn about

Chapter 5, Monitoring ZMS Logs, on page 79. Monitoring logs.

Appendix C, Modifying ZMS alarm descriptions, Modifying ZMS alarm descriptions.

Style and notation conventions

Caution: A caution alerts users to conditions or actions that could

Note: A note provides important supplemental or amplified

Tip: A tip provides additional information that enables users to more

WARNING! A warning alerts users to conditions or actions that

WARNING! A warning with this icon alerts users to conditions or

Bold Used for names of buttons, dialog boxes, icons, menus,

Fixed Bold Used in code examples for text typed by users.

14 ZMS Administrator’s Guide

PLAIN UPPER Used for environment variables.

Command Syntax Brackets [ ] indicate optional syntax.

ZMS Administrator’s Guide 15

Raptor Hardware Installation and Configuration Guide describes how to

16 ZMS Administrator’s Guide

Contacting Global Service and Support

The Technical Assistance Center (TAC) is available with experienced support

Hours of operation Monday - Friday, 8 a.m. to 5 p.m, Pacific

If you purchased the product from an authorized dealer, distributor, Value

ZMS Administrator’s Guide 17

If the product malfunctions, all repairs must be authorized by Zhone with a

18 ZMS Administrator’s Guide

This chapter introduces ZMS. It includes the following sections:

ZMS system components

ZMS Administrator’s Guide 19

Configuration services manager (CS) makes configuration changes to

20 ZMS Administrator’s Guide

The actual functionality provided to the operator depends on the operator