Alcatel OmniPCX Enterprise

SNMP Management

NOTE:
Product specifications contained in this document are subject to change
without notice. Products and services described in this document may not be
offered in every country. For the most current information, please contact
your Alcatel representative or your Alcatel equipment provider.
Copyright (c) 2006 Alcatel. All rights reserved for all countries. This
document may not be reproduced in whole or in part without the express
written permission of Alcatel.
Alcatel and the Alcatel logo are registered trademarks of Alcatel. All other
trademarks are the property of their respective owners.

The CE mark indicates that this product conforms to the following Council
Directives:
- 89/336/CEE (concerning electro-magnetic compatibility)
- 73/23/CEE (concerning electrical safety)
- 1999/5/CE (R&TTE)


  


  


Chapter 1
Overview



SNMP management ............................................................................... 1.1

Operation ................................................................................................... 1.1






Autodetect and Topology ........................................................................... 1.1

Processing alarms ....................................................................................... 1.1
Implementation on the OmniPCX Enterprise ............................... 1.2




CPU ............................................................................................................... 1.2

IP-Phones ..................................................................................................... 1.3

Chapter 2
PCX SNMP configuration



Management principle .......................................................................... 2.1

General management ............................................................................ 2.1




On the main node ........................................................................................ 2.1

On each supervised node ........................................................................... 2.2
Incident filter default settings ............................................................ 2.2





 
 

Managing individual incident filters ................................................ 2.3

Additional management ....................................................................... 2.3
Data linked with the application ................................................................. 2.3
Declaring supervisors ................................................................................. 2.3

  


0-1

  





Managing the Call Server SNMP server ......................................... 2.4

IP-Phones .................................................................................................. 2.5

Chapter 3
MIB Description



Introduction .............................................................................................. 3.1

MIB description ....................................................................................... 3.1





Standard prefix ............................................................................................ 3.1

Proxy Agent MIB prefix ............................................................................... 3.1
Proxy Agent MIB groups ............................................................................. 3.2
Traps description ................................................................................... 3.8



Chapter 4
CPU SNMP agent




Targets ....................................................................................................... 4.1

Standards .................................................................................................. 4.1
Implementation specificities .............................................................. 4.1





SNMP ............................................................................................................ 4.1

CPU specificities ......................................................................................... 4.1
SNMP tools ................................................................................................... 4.2

Chapter 5
TSC-IP and IP-Phone Agent


0-2

Targets ....................................................................................................... 5.1

  


  





Standards .................................................................................................. 5.1

Implementation specificities .............................................................. 5.1





SNMP ............................................................................................................ 5.1

TSC-IP (v1/v1S) ............................................................................................ 5.1
IP-phones specificities ................................................................................ 5.2

Chapter 6
HPOV station configuration





Installing the NMChpov package on the HPOV station ............ 6.1

Standard configuration ........................................................................ 6.1
PBX topology ........................................................................................... 6.1
NMC remote startup .............................................................................. 6.2

  


0-3

  


0-4

  






1.1

SNMP management
The standard SNMP protocol allows the OmniPCX Enterprise to be supervised by a network
management platform, referred to as the "hypervisor" in this document.
Integrating a hypervisor provides a solution to manage voice and data transiting on a company
network.
Integrating a hypervisor allows two main aspects to be covered:

1.2

Global network tracking: this is a common standard offered by the supplier of the
hypervisor and Alcatel. The client uses a customized hypervisor with standard hypervisor
capabilities. Global network tracking is provided by means of an overview of the network
(Topology Map). The topology can cover all network elements and applications. These
items are displayed according to their alarm status (icon color changes). The hypervisor
does not provide the capability to configure the OmniPCX Enterprise (or other equipment
such as IP-Phones): Only SNMP "Get" requests are allowed.

Processing specific alarms: this is a customized solution specifically configured by the

client. The client processes all network alarms with an internal tool. For this purpose,
specific development is usually performed for the client.

Operation
The features provided vary depending on the hypervisor.

1.2.1

Autodetect and Topology

IP components are detected by the hypervisor, using "ping" and "SNMP Get". A response to
SNMP Get with an Alcatel-specific Object ID or a specific extended attribute allow Alcatel IP
components to be found and represented using specific Alcatel icons in the topology.
A hypervisor can "track" IP devices to ascertain their "status" to display their icon on-screen in
the appropriate color.
In order to communicate, the hypervisor and the SNMP agent in the Call Server must share
the same community name. This community name acts as password.

1.2.2

Processing alarms
Alarms are sent by IP components, using SNMP traps. Alcatel uses specific SNMP traps, as
specified in the SNMP standard, to allow the equipment supplier to create patented alarm
traps to notify the hypervisor of alarms.
Alarm processing by the hypervisor requires specific SNMP agents to be developed. A list of
relevant alarms can be supplied to Alcatel partners for SNMP agent development.
Trap format is described in the corresponding SNMP MIB. Received SNMP alarm traps can be
viewed in the event management window.

          !"

1-1

Chapter

  !"

Dedicated SNMP agents can be constructed by partners to process Alcatel SNMP traps.
SNMP agents usually provide features such as:
-

Links between alarms and the corresponding on-screen icons (color changes): in this case,
notification is performed in real time.

A more explicit alarm display in the event manager window.

Alarm statistics.

Generation of an order of priority.

...

When the icons, SNMP MIB, and SNMP agents have been configured and implemented by
Alcatel, they are provided to the hypervisor supplier. They can then be directly integrated in
and delivered with the hypervisor.
Note: No configuration command can be performed on the OmniPCX Enterprise from the hypervisor
using SNMP protocol.

1.3

Implementation on the OmniPCX Enterprise

The SNMP protocol used is SNMP v1.
Attribute status is not provided for an IP-Phone or a remote ACT because there would be a
CPU alarm when the remote ACT or IP-Phone were lost and CPU attribute status would
change as a result.

1.3.1

1-2

CPU
-

SNMP Trap:
SNMP event trap
The OmniPCX Enterprise provides alarms using the CMIP standard. The OmniPCX
Enterprise allows network alarms to be centralized on a node. Notification of such
alarms is performed using the B or D channel (depending on network configuration) of
an ABC F2 link.
On the centralized node, or each network node if alarm centralization is not used, the
PCX agent converts CMIP alarms into SNMP traps and transmits them to the
hypervisor. All CMIP alarms are converted into a single SNMP trap (called an "event
trap"). CMIP alarm attributes are converted into event trap parameters.
SNMP event traps can be sent in two different formats (configurable):
Compact format: this format is for information only. It can be used to display alarms
in an event window on the hypervisor.
Extended format: this format is used to process alarms for dedicated applications.
This is the case, for example, of clients with specific management.
SNMP status trap
The PCX agent also calculates the status of each network node (or node status if
alarms are not centralized) and generates an SNMP trap containing the node status
parameter (these traps are called "status traps"). Status traps can be used in a
topology display.

Response to an SNMP Get request using MIB 2 (with no extended status attributes).
See the module SNMP management - CPU SNMP agent .
In R5.0 Ux, PCX status information can be sent to the local SNMP agent.

          !"

  !"

1.3.2

IP-Phones
-

Response to an SNMP Get request using MIB 2.

See the module SNMP management - TSC-IP and IP-Phone Agent .

          !"

1-3

Chapter

1-4

  !"

          !"



 


2.1

Management principle
SNMP management has two aspects:
1. Management of transmission of incidents in the form of traps, performed by MAO
management:
In the Incident manager object: general management applying to all incidents except
those for which a specific filter is specified.
In Incident Filter sub-objects: management on an incident per incident basis.
To simplify management, a default list of incidents to be reported is stored on the PCX.
This list, activated by default, can be deactivated and reactivated in management.
Deactivating (or activating) the list automatically deletes (or creates) the corresponding
incident filters.
2. Management, as SNMP agent:
Of the Call Server, performed using the netadmin command: see Managing the Call
Server SNMP server .
Of the IP-Phones: a contact number can be entered in their domain parameters, see
IP-Phones .

2.2

General management
Incidents to be sent in SNMP trap form are managed in the Incident manager object.
The following steps must be performed to manage centralization of sub-network incidents on
the main node:

2.2.1

On the main node

-

Declare nodes in the Supervised Node object.

1. Select Applications > Incident manager > Supervised nodes
2. Review/modify the following attributes

Network Number

Network number

Node No.

Node number

3. Confirm your entries

-

Manage (configure) SNMP parameters.

1. Select Applications > Incident manager
2. Review/modify the following attributes

SNMP
Severity

Select the level of severity from which local node

incidents are transmitted as SNMP traps.

  #  $! %  &'  ( )!

* !(

2-1

Chapter

&'  ( )!
* !(

Network Severity

Only meaningful if the Network attribute is set to

"Yes".
Select the level of severity from which incidents from
other network nodes are transmitted as SNMP traps
(by the main node).

Topology

Yes: local topological incidents are transmitted (and

network incidents if the Network attribute is set to
"Yes"), whatever their level of severity, in the form of
SNMP traps.

RMA

Yes: RMA incidents are transmitted (and network

incidents if the Network attribute is set to "Yes"),
whatever their level of severity, in the form of SNMP
traps.

Network

Select "Yes: incidents from other network nodes can

be sent to the main node that will report them in the
form of SNMP traps (depending on their level of
severity, declared above).

3. Confirm your entries

2.2.2

On each supervised node

Manage the Network Severity parameter.
1. Select Applications > Incident manager
2. Review/modify the following attributes
Network Severity

Minimum level of severity from which incidents are

reported to the main node.

SNMP
Network

Select No: incidents from other network nodes are

not transmitted as SNMP traps by this node.

3. Confirm your entries

On supervised nodes, incident reporting to the main node is managed as standard (see
module Management of system messages - Configuration procedure ).
Incidents are only converted into SNMP traps on the main node.
Only the network parameter needs to be managed in the SNMP section for supervised nodes.

2.3

Incident filter default settings

When the empty database is created, the default incident list is activated. The incidents
concerned are:

2-2

  #  $! %  &'  ( )!

* !(

&'  ( )!
* !(









 
 















 






 
 

 
    

 
 
 
 
 
 

   
       

  
   
 
   

   


 
      

To deactivate (or activate) the list, select Applications > Incident manager, then select
Delete SNMP Default (or Set SNMP Default).
For each incident in the list, activating the list results in creation of an instance of the Incident
Filter object with the SNMP Incident attribute set to "Yes".

2.4

Managing individual incident filters

1. Select Applications > Incident Manager> Incident Filter
2. Review/modify the following attributes
Incident Number

Enter the number of the incident to be filtered.

SNMP Incident

Yes: the incident is transmitted as an SNMP trap.

3. Confirm your entries

2.5

Additional management

2.5.1

Data linked with the application

The administrator can manage the correspondence between incident severity levels on the
OmniPCX Enterprise and severity levels recognized by the SNMP supervisor.
1. Select Applications > Incident manager > SNMP Application
2. Review/modify the following attributes
Severity
Indeterminate

By default: Critical

Critical

By default: Critical

Major

By default: Major

Minor

By default: Minor

Warning

By default: Warning

Cleared

By default: Normal

3. Confirm your entries

2.5.2

Declaring supervisors
1. Select Applications > Incident manager > SNMP Supervisor
2. Review/modify the following attributes

  #  $! %  &'  ( )!

* !(

2-3

Chapter

&'  ( )!
* !(

Name

Enter supervisor name.

IP Address

Enter supervisor IP address.

Community

Enter the name of the community to be entered in

traps. When traps are received a check is
performed that the community name of the
supervisor matches that in the trap.

Trap State

Yes: the supervisor receives event and status

traps.
No: the supervisor only receives event traps.

Trap Type

Select:
Compact: traps transmitted in compact form.
Extended: traps sent in developed form for
application use.

Language

Select:
United Kingdom: English.
France: French.

3. Confirm your entries

2.6

Managing the Call Server SNMP server

The SNMP server, located in the Call Server, is managed with the netadmin tool.
Note 1: The terms "SNMP agent" and "SNMP server" refer to the same thing.

To access the managing menu of SNMP server:

  

Select option 13 from the main menu.

   !"
###########################
 $%  &"%"
 '('' &!)
 *!+  &!)

 "%!& !
,- & +!" - .

1. This option displays the current status of the SNMP server and allows to activate or
deactivate it.
For example:
/-  &"%" & !""0+ 1/ $*/'2$/34
4 +! 5  % -  &"%" 6+7 !0 & 8 .

The answer 'y' activates, and the answer 'n' deactivate the SNMP server.
2. This option allows to view or modify MIB information.
MIB setup sub-menu:
'('' !)
#################
 25
 *"79) '('' &!)

 "%!& !
,- & +!" - .

MIB information:

2-4

  #  $! %  &'  ( )!

* !(

&'  ( )!
* !(

PCX manager data (e-mail address, phone number, etc.): this corresponds to the
branch &+&&+&*
in the MIB structure.
The physical location of the node: this corresponds to the branch
&+&&+&:
in the MIB structure.

3. This option allows to view and modify the community name.

3" 5 "&& !+  6!0 ;)!<0;8

Note 2: As of R6.2, the community name is required to activate the SNMP server on the OmniPCX
Enterprise. However, to prevent service interruption, in case of a migration to a release R6.2 or
higher, the SNMP server is still activated after migration and telephone startup, even though no
community name is defined.
Note 3: There is no link between this community name and the community name used by SNMP
traps.

For more information on netadmin tool see: module netadmin - Operation .

2.7

IP-Phones
The IP domain fields have a Contact Number field. This number is sent to the IP-Phones in
the domain to be saved in their MIB at the location &+&&+&*
.
1. Select IP > IP Domain
IP Domain Number

Enter the number of the IP domain.

Contact Number

The directory number entered is sent to the IP-Phones and allows

the SNMP field &+&&+&*
in their MIB to be
completed.

2. Review/modify the following attributes

3. Confirm your entries

  #  $! %  &'  ( )!

* !(

2-5

Chapter

2-6

&'  ( )!
* !(

  #  $! %  &'  ( )!

* !(



 

3.1

Introduction
This document describes the OmniPCX Enterprise notification MIB used to convert CMIP
events into SNMP traps. These traps are intended to be sent to a management platform to
draw topology maps and to get events.
A description of notification MIB can be found on the PCX :
-

R5.0 Ux : in directory 7-7&)7<&7=)", file />$'(=,

R5.1 and later : in directory 77&)7<&7=)", file />$'(=.

3.2

MIB description

3.2.1

Standard prefix

3.2.2

Proxy Agent MIB prefix

%        +, -.! !(

3-1

Chapter

3.2.3

+, -.! !(

Proxy Agent MIB groups

These groups correspond to the CMIP notification parameters and to the reduced format of
these parameters.

3.2.3.1

3-2

ObjectClass group

%        +, -.! !(

+, -.! !(

It provides the possibility to identify the class of the object which is notified.

)*0&& 1(?3*//@3
@/$A '/3B3>
CC# D <E*0&& F
<&*0&& 1(?3*//@3
@/$A '/3B3>
CC# D <E*0&&  F

TopClass identifier gives the possibility to identify the system (e.g. the value 89 identifes
OmniPCX Enterprise PBX).
BaseClass identifier gives the possibility to identify the concerned object in the system (e.g.
the value 23 identifies an OmniPCX Enterprise board).

3.2.3.2

ObjectInstance group
This group gives the possibility to identify the Instance of the concerned object. It gives
information on the contents tree and the object names at different hierarchy levels.

3.2.3.2.1 OmniPCX Enterprise contents tree

%        +, -.! !(

3-3

Chapter

+, -.! !(

3.2.3.2.2 Instance identification

The SNMP objects described in this document correspond directly to the CMIP arguments.

"4)- 1(?3*//@3
@/$A '/3B3>
CC# D<E'&  F
"20!& 1(?3*/ '43/'G'3> CC# D <E'&  F
" 1(?3*/ '43/'G'3> CC# D "20!& F
0&&' 1(?3*//@3
@/$A '/3B3>
$**3 "0+
/$/9 "+
CC# D " F
"20! 1(?3*//@3
@/$A 1*/3/ />'B
$**3 "0+
/$/9 "+
CC# D "  F

The rdnDepth value gives information on the depth of the concerned object class (per alarm) in
the contents tree of the PBX node (e.g. for an OmniPCX Enterprise board, the value of
rdnDepth is 3). The rdnDepth value corresponds to the number of valid parameters of
rdnValues (in the example, rdn1, rdn2 and rdn3).

3.2.3.2.3 Voicelds objet

It contains the number which gives the possibility to identify a PBX.

3-4

%        +, -.! !(

+, -.! !(

The objectNumber value gives the PBX number and the parentNumber gives the PBX
sub-network number.

3.2.3.3

EventTime object
It gives information on the date & time at which the notification is detected.

%/ 1(?3*//@3
@/$A 1*/3/ />'B
43*>'/'1 HB"0I/ @@@@44JJH
CC# D )3%$"  F

3.2.3.4

EventType object
It gives information on the OSI type of notification.

%/+) 1(?3*//@3
@/$A '/3B3> D !$0" 68K
%"0$0" 68K
L!)$0" 68K
)"&& 3"""$0" 6
8K
L!0+1"%$0" 6 8
F
CC# D )3%$"  F

3.2.3.5

Severity object
It gives information on the OSI severity level of the notification.

%        +, -.! !(

3-5

Chapter

+, -.! !(

&%"+ 1(?3*//@3
@/$A '/3B3> D
" 6 8K
"0 68K
E" 68K
" 68K
5" 68K
0" 68
F
$**3 "0+
/$/9 "+
CC# D )3%$"  F

3.2.3.6

ProbableCause object
It gives information on the OSI probable cause of the notification

3-6

%        +, -.! !(

+, -.! !(

)"<<0*!& 1(?3*//@3
@/$A '/3B3> D
9M5 6
8K
$)"3""" 6 8K
$))0!<&+&G0!" 68K
(,->! 68K
*003&<0&-3""" 68K
*!&"03""" 68K
*!&!<&+&G0!" 68K
* !"1"*!&I3""" 68K
* & 6 8K
*""!)4 68K
*)!*+0&:3= 6
8K
41"3""" 6 8K
4 " 0 6 8K
4/3N4*3'"3""" 6 8K
30&!"4"1) 6 8K
3L!)0G! 6 8K
3=&&%2<" 6 8K
G03""" 6 8K
G"4 6 8K
G04 6 8K
G" 3""" 6
8K
J 20*0 +&"<0 6 8K
J!+9)<0 68K
')!1!)!4%3""" 68K
')!4%3""" 68K
:$3""" 68K
:M4 68K
:0/"&&&3""" 68K
:&&1G" 6 8K
:&&1 0 68K
"0!))0+3=-!& 6
8K
!0)0=""<0 6 8K
1!1"+ 68K
1!)!4%3""" 68K
""4 " 68K
5""<0 68K
"&&!"9)<0 68K
"&&""<0 68K
!)G0!" 6 8K
O!!I3= 68K
>%G0!" 6
8K
>%"G0!" 6 8K
>/"&&&G0!" 68K
>&!"$1"" *)+ 68K
>&)&/3=&&% 68K
>"&&&>3=&&% 68K
5"3""" 68K
5"" "$<"00+/" 68K
5"" "3""" 6 8K
" *)+"<0 68K
/)"!"9)<0 6
8K
/-"&-0*"&& 6 8K
/ "<0 68K
/=:M4 68K
/"&G0!" 68K

%        +, -.! !(

3-7

Chapter

+, -.! !(

/"&"G0!" 68K
9"0+ >&!"9%0<0 68K
2"&&- 68
F
$**3 "0+
/$/9 "+
CC# D )3%$"  F

3.2.3.7

PackedForm object
It contains the reduced format of a part or the totality of the CMIP notification arguments.
Selection of these arguments is made from the Alcatel OmniPCX Enterprise.

)MG" 1(?3*//@3
@/$A 1*/3/ />'B
CC# D )3%$"  F

3.2.3.8

Notificationld object
It contains the number allowing to identify the alarm.

0 1(?3*//@3
@/$A '/3B3>
CC# D )3%$" F

3.3

Traps description
The enterprise object ID of traps sent by the proxy agent is nmcProxyTraps(2) under
nmcProxyAgent(1). The agent distinguishes traps by their specific type.
Traps are sent by a proxy agent running on the Alcatel OmniPCX Enterprise. There are three
kinds of traps :
-

3-8

Event traps : are used to convert CMIP events to SNMP format

packedCmipTrap (specific type 1) : human readable description of CMIP events.
Variables are :
openViewSeverity (integer) : severity corresponding to the initial event. It makes
the event appear with this severity in the HPOV Event Browser,
packedForm.
cmipTrap (specific type 3) : it describes a CMIP event. Variables are :
objectClass.topClass, objectClass.baseClass,
objectInstance.rdnDepth,
objectInstance.rdnValues.rdn<n>.classId<n>,
objectInstance.rdnValues.rdn<n>.rdnValue<n> (with <n> in [1..5]),

%        +, -.! !(

+, -.! !(

eventTime, eventType, severity, probableCause, notificationId.

State traps : store the objects' state calculated by an agent

topClassStateTrap (specific type 7) : it gives the state of a top class object (i.e.
OmniPCX Enterprise). Variables are :
classId1,
rdnValue1,
severity : the object state which is the greater severity of all active events occurring
on any part of the object,
objectNumber : the PBX number,
parentNumber : the PBX subnetwork number.

Management traps: are used by the proxy agent to give information about export itself
startOfResyncTrap (specific type 2) : sent whenever an event resynchronization start,
startProxyTrap (specific type 4) : sent when the proxy agent start,
stopProxyTrap (specific type 5) : sent when the proxy agent stop,
eventLostTrap (specific type 6) : sent when the trap receiver has possibly missed
traps.
Example

loosing an OmniPCX Enterprise interface board (incident 2042)

-

topClass
1'4 C "=+$ )3%$" <E*0&&)*0&&

%0! C 

The value 89 of topClass index corresponds to an OmniPCX Enterprise node.

-

baseClass
1'4 C "=+$ )3%$" <E*0&&<&*0&&

%0! C 

The value 23 corresponds to an OmniPCX Enterprise board.

-

rdnDepth
1'4 C "=+$ )3%$" <E'&"4)-

%0! C 

The level of a board in the hierarchy of OmniPCX Enterprise objects is 3.

It means that the name of all board instance is composed of 3 parts.
-

rdnValues (3 levels)
1'4 C
"=+$ )3%$" <E'&"20!&" 0&&' 

%0! C 
1'4 C
"=+$ )3%$" <E'&"20!&" "20! 

%0! C HH

The value 89 of rdnl.classIdl corresponds to an OmniPCX Enterprise node, rdln.rdnValue1

gives its name node2.
1'4 C
"=+$ )3%$" <E'&"20!&"0&&'

%0!C 
1'4 C
"=+$ )3%$" <E'&"20!&""20!

%0!C P
H

The value 29 of rdn2.classId2 correspond to an OmniPCX Enterprise board shelf which

has a number rdn2.rdnValue2=0.

%        +, -.! !(

3-9

Chapter

+, -.! !(

1'4 C
"=+$ )3%$" <E'&"20!&"0&&'

%0!C 
1'4 C
"=+$ )3%$" <E'&"20!&""20!

%0! C HH

The value 23 of the rdn3.classld3 index which is at the end of OID corresponds to an
OmniPCX Enterprise board which has a number rdn3.rdnValue3=9.
-

eventTime
1'4 C "=+$ )3%$" %/

%0! C H 

H

The date at which the alarm is detected on the managed node is October 14th 1997 at
10h26mn.33s.
-

eventType
1'4 C "=+$ )3%$" %/+)

%0! C 

This is a line equipment alarm.

-

eventType
1'4 C "=+$ )3%$" %/+)

%0! C 

This is a line equipment alarm.

-

severity
1'4 C "=+$ )3%$" &%"+

%0! C 

It is an alarm with severity = Major.

-

probableCause
1'4 C "=+$ )3%$" )"<<0*!&

%0! C 

The probable alarm is: not enough memory.

-

notificationId
1'4 C "=+$ )3%$" '

%0! C 


It is the loss of an interface board.

3-10

%        +, -.! !(




 


4.1

Targets
The goal of the CPU SNMP agent is to be seen as a standard IP device by an SNMP
administration station.
For example, IP devices have to respond to SNMP requests in order to be identified by the
network SNMP supervisor (often polling equipment with SNMP requests). The network
administrator may also use SNMP information to know more precisely equipment
characteristics (type of equipment, user, physical location, administrator, ) and globally to
supervise IP address assignment.

4.2

Standards
SNMP version 1 and 2c (SNMP-V1 and SMI-v2) are supported (RFC 1157 and RFC1442).
Version 2p and Version 3 of the SNMP protocol are not supported.
The information which can be queried by SNMP manager are described in MIB-II
(Management Information Base Version 2) specified in RFC 1213.
There is no additional MIB information available (neither VoIP specific nor proprietary
variables) in TSC-IP or IP-phones.

4.3

Implementation specificities

4.3.1

SNMP

4.3.2

Traps
There is no SNMP trap sent by the CPU agent to the SNMP administration station
(typically no cold start or enterprise specific traps). The call handling SNMP-Trap manager
is in charge of sending PBX incident using SNMP traps to the SNMP administration
station.

Communities
Community is a character string that is a clear text password sent by the manager to the
agent. The default string community public may be used, as all other community. As of
R6.2, the community name is checked. When the check fails, the request is aborted.

Access
Only READ (snmp-get, snmp-get-next) accesses are allowed. No WRITE (snmp-set) can
be performed.

Configuration
The agent is not activated by default. The PBX responsible must activate the service,
configure the sysContact and sysLocation OIDs, using the Netadmin tool (Menu 13
SNMP Configuration) in order to be seen by any supervision station.

CPU specificities

%     (   &/  



4-1

Chapter

&/  


system.sysDescr.0: Chorus <cpu_name> MiX V.3.2r4.1.5 r4.1.5 COMP-386

Identifies the Operating system found on this node.

system.Contact.0: Me mail:Someone@Somewhere.net tel:(+33)00.00.00.00.00

This default value is settable via Netadmin in the SNMP menu.

system.sysLocation.0: Bat. D3 Floor 2 Room 1245

This default value is settable via Netadmin in the SNMP menu.

system.sysName.0: <cpu_name>
This value returns the CPU name as configured with Netadmin.

system.sysServices.0: 72
Default value that should be set to 76 if a IP/X25 Tunnel is offered.
72 = 64+8 = 2^(7-1) + 2^(4-1)
76 = 64 + 8 + 4 = 2^(7-1) + 2^(3-1) + 2^(4-1)
7 : Application (e.g. : supports the SNMP)
4 : End-to-end (e.g. : supports the TCP)
3 : Internet (e.g. : supports the IP)

system.sysObjectID.0: .1.3.6.1.4.1.637.64.4400.1.1.255
where:
- 637 stands for Alcatel
- 64 stands for ABS
- 4400 stands for 4400 boards
- 1 stands for CPU
- 1stands for agent version
- 255 is for Chorus OS.

Note: any future proprietary MIB entry point for the PABX CPU will be located under the MIB-tree
.1.3.6.1.4.1.637.64.4400.1.

4.3.3

SNMP tools
The SNMP agent comes with a few tools usable on the CPU board. These are accessible from
any UNIX account (e.g. : mtcl, ).

4.3.3.1

snmpget
This tool can be used to query any SNMP device reachable by the CPU for any single OID.
*-"!& &)  Q% 00-& )!<0 &+&&+&*

&+&&+&*
# ; 0CR5-" 0C6S8

4.3.3.2

snmpwalk
This tool can be used to query any SNMP device reachable by the CPU for any complete
SNMP branch.

4-2

%     (   &/  



&/  


*-"!& &)50M Q% 00-& )!<0 )

))G"5" 
# "5" 6 8
))4!0//:
# 
))'>%&
#  
))'J"3"""&
#

))'$"3"""&
#  
))G"54 "&
#

))'9M5"&
#



4.3.3.3

MIB text files

These tools can query any SNMP equipment, a PBX CPU board or any other SNMP device.
MIB 2 text files can be found on the PCX :
-

R5.0 Ux : in directory 7-7&)7<&,

R5.1 and later : in directory 7!&"7&-"7&)7<&.

The text file of the MIB used for PCX status (R5.0 Ux only) can be found on the PCX :
-

R5.0 Ux : in directory 7-7&)7<&7=)", file $

*9'(=.

R5.1 and later : in directory 7!&"7&-"7&)7<&, file $

*9'(=.

%     (   &/  



4-3

Chapter

4-4

&/  


%     (   &/  





 
 

! "

5.1

Targets
The goal of TSC-IP and IP-phones SNMP agent is to be seen as a standard IP device by an
SNMP administration station.
For example, IP devices have to respond to SNMP requests in order to be identified by the
network SNMP supervisor (often polling equipment with SNMP requests). The network
administrator may also use SNMP information to know more precisely the equipment
characteristics (type of equipment, user, physical location, administrator, ) and globally to
supervise IP address assignment.

5.2

Standards
Only SNMP version 1 (protocol specified in RFC 1157) is supported. Version 2 or version 3 of
SNMP protocol are not supported.
The information which can be queried and set by SNMP manager are described in MIB 2
(Management Information Base) specified in RFC 1213.
There is no additional MIB information available (neither VoIP specific nor proprietary
variables) in TSC-IP or IP-phones.

5.3

Implementation specificities

5.3.1

SNMP

5.3.2

Traps
There are no SNMP traps sent by CPU agent to SNMP administration station (typically no
cold start or enterprise specific traps). The call handling SNMP-Trap manager is in charge
to send PBX incident using SNMP traps to SNMP administration station.

Communities
Community is a character string that is a clear text password sent by the manager to the
agent. The default string community public may be used, as all other community. There is
no check performed on community strings to identify requests.

SNMP set requests

Although SNMP write requests are allowed for specific variables in MIB, these values are
volatile because they are not stored locally in the equipment.
For security reasons and for administration conveniency the PBX system is in charge of
setup at equipment initialization with UA specific message SET-PARAM in particular for
user name, contact and location information.

802.1 p/q VLAN tagging is enabled on IP-device. SNMP requests may be tagged or not.
Current VLAN value is used. Null priority (low priority) is always used in 802.1 tags for
outgoing SNMP packets.

TSC-IP (v1/v1S)

0        1&+   +2(  $



5-1

Chapter

1&+   +2(  $


Default values of MIB 2 system variables

MIB2.System.Description : ALCATEL 4098 FRE-Voice over IP enabler
Or
MIB2.System.Description : ALCATEL 4098 RE-Voice over IP enabler
MIB2.System.Objected = 1.3.6.1.4.1
MIB2.System.Contact : ALCATEL
MIB2.System.Name : TSCIP v1
MIB2.System.Location : Here
MIB2.System.Service : 9 = (2^(11)+2e^(41)) = Physical + End to end layers
Default values are always present during TSC-IP initialization. Underlined parameters may be
overwritten at the end of TSC-IP initialization by the system with SET_PARAM message.

5.3.3

IP-phones specificities
MIB2.System.Description : ALCATEL VoIP terminal
MIB2.System.ObjectId = 1.3.6.1.4.1
MIB2.System.Contact : ALCATEL
MIB2.System.Name : IP-PHONE
MIB2.System.Location : Here
MIB2.System.Service : 9 = (2^(11)+2e^(41)) = Physical + End to end layers
Default values are always present during IP-phone initialization. Underlined parameters may
be overwritten at the end of IP-phone initialization by the system with SET_PARAM message.
The internal loopback interface counters are available in IP-phone's MIB 2 variable.

5-2

0        1&+   +2(  $





#
$  

6.1

Installing the NMChpov package on the HPOV station

This application can only be installed on HP-OpenView 6.1 in Windows NT 4.
The application is delivered on a CDROM (HPOV Faults and Alarms Rf. 3BA57422) with a
standard installation procedure. Display the contents of the CD-ROM with the Explorer and run
the installation program (setup). Follow the instructions given to complete setup.

6.2

Standard configuration
The standard configuration allows NMC traps to be received in the event window.
From the MS-DOS command prompt, register the application with the following command:
CT %5 0&

Run HPOV by selecting Start # Programs # HP OpenView # Network Node Manager.

6.3

Load the Alcatel MIB via the menu Options # Load/Unload MIBs: SNMP. In the dialog box,
click Load ... and select the item alcatel_nmc. Then click OK in all the other dialog boxes.

Create an event category via the menu Options # Event Configuration. Click Edit #
Configure # Event Categories. Enter NMC Events and click Add , then Close.

In the same window, customize events by clicking nmcProxyTrap. In the list of trap types,
double-click on each type of trap and enter the corresponding parameters:

Trap

Category

Severity

Event Log Message

packedCmipTrap

NMC Events

Normal

$2

startOfResyncTrap

NMC Events

Normal

Start of resynchronization from $A

startProxyTrap

NMC Events

Normal

Start of NMC proxy $A

stopProxyTrap

NMC Events

Normal

End of NMC proxy $A

eventLostTrap

NMC Events

Critical

Event lost from $A

PBX topology
PBX topology has to be created manually.
-

When HP OpenView starts up, an NMC icon is displayed in the root map. Double-click this
icon and select OK to create the NMC submap.

If the PBXs are not managed by an NMC platform, skip (ignore) this item. Otherwise, in the
NMC submap, create a Server class and NMC subclass symbol from the menu Edit # Add
Object. Set its label to <nmc> and its selection name to NMC:<nmc> (with <nmc> being
the name of the NMC station).

Double-click the server icon to create the submap. Create subnet icons by adding Network
class and PBX Net subclass symbols. The "selection name" object must be
PBX_net:<subnet_name>. Specify the attributes of the Alcatel NMC application.

#)        34 .  !( ( )!

* !(

6-1

Chapter

6.4

34 .  !( ( )!
* !(

Create subnet submaps by clicking the symbols and creating PBX symbols of Computer
class. The "selection name" object must be PBX:<name>. The label symbol must be the
name of the PBX. Specify the attributes of the Alcatel NMC application.

NMC remote startup

An NMC 4760 can be remote started using a Web browser if the HP station is configured for
use with a Web interface.
Start the HP OpenView Web interface.
Enter the URL (with a 4760 URL).

6-2

#)        34 .  !( ( )!

* !(