Oracle Communications User Data Repository
 

PLA-Support>Sun Systems>CommsGBU>Broadband Network Solutions>SN-SND: Tekelec UDR
 

In this Document

Goal

Solution

Applies to:

Goal

This document provides customer instructions on how to update MIBs following OCUDR software upgrades.

Simple Network Management Protocol
Simple Network Management Protocol (SNMP) is a communication protocol that provides a method of managing TCP/IP networks, including individual network devices, and devices in aggregate. SNMP was developed by the IETF (Internet Engineering Task Force), and is applicable to any TCP/IP network, as well as other types of networks.

SNMP is an Application Program Interface (API) to the network, so that general-purpose network management programs can be easily written to work with a variety of different devices. SNMP defines a client/server relationship. The client program (called the network manager) makes virtual connections to a server program (called the SNMP agent). The SNMP agent executes on a remote network device and serves information to the manager about the status of the device. The database (referred to as the SNMP Management Information Base or MIB) is a standard set of statistical and control values that is controlled by the SNMP agent.

Through the use of private MIBs, SNMP allows the extension of the standard values with values specific to a particular agent. SNMP agents can be tailored for a myriad of specific devices such as computers, network bridges, gateways, routers, modems, and printers. The definitions of MIB variables supported by a particular agent are incorporated in descriptor files that are made available to network management client programs so that they can become aware of MIB variables and their usage. The descriptor files are written in Abstract Syntax Notation (ASN.1) format. Directives are issued by the network manager client to an SNMP agent. Directives consist of the identifiers of SNMP variables (referred to as MIB object identifiers or MIB variables), along with instructions to either get the value for the identifier or set the identifier to a new value.

The SNMP Standard
SNMP can be viewed as three distinct standards:

• A Standard Message Format - SNMP is a standard communication protocol that defines a UDP message format.
• A Standard Set of Managed Objects - SNMP is a standard set of values (referred to as SNMP objects) that can be queried from a device. Specifically, the standard includes values for monitoring TCP, IP, UDP, and device interfaces. Each manageable object is identified with an official name, and also with a numeric identifier expressed in dot-notation.
• A Standard Way of Adding Objects - A standard method is defined to allow the standard set of managed objects to be augmented by network device vendors with new objects specific for a particular network.

SNMP Message Types
Four types of SNMP messages are defined:

• A get request returns the value of a named object. Specific values can be fetched to determine the performance and state of the device, without logging into the device or establishing a TCP connection with the device.
• A get-next request returns the next name (and value) of the next object supported by a network device given a valid SNMP name. This request allows network managers to review all SNMP values of a device to determine all names and values that an operant device supports.
• A set request sets a named object to a specific value. This request provides a method of configuring and controlling network devices through SNMP to accomplish activities such as disabling interfaces, disconnecting users, and clearing registers.
• A trap message is generated asynchronously by network devices, which can notify a network manager of a problem apart from any polling of the device. This typically requires each device on the network to be configured to issue SNMP traps to one or more network devices that are awaiting these traps.

The four message types are all encoded into messages referred to as Protocol Data Units (PDUs), which are interchanged with SNMP devices.

Standard Managed Objects
The list of values that an object supports is referred to as the SNMP Management Information Base (MIB). MIB can be used to describe any SNMP object or portion of an SNMP hierarchy. The various SNMP values in the standard MIB are defined in RFC-1213, one of the governing
specifications for SNMP. The standard MIB includes various objects to measure and monitor IP activity, TCP activity, UDP activity, IP routes, TCP connections, interfaces, and general system description. Each of these values is associated with an official name (such as sysUpTime , which is the elapsed time since the managed device was booted) and with a numeric value expressed in dot-notation (such as '1.3.6.1.2.1.1.3.0', which is the object identifier for sysUpTime).

About SNMP Configuration

SNMP configuration architecture is based on using traps to notify a network management system of events and alarms that are generated by the OCUDR application software, and those that are generated by the underlying platforms. Alarms and telemetry data are continuously collected from the entire User Data Management network and stored on the OCUDR NOAMP system. Alarms will then cause a trap to be sent as a notification of an event

Supported OCUDR MIBs

Management Information Base (MIB) contains information required to manage a product cluster and the applications it runs. The exact syntax and nature of the parameters are described in the version of each MIB that you are loading on your NMS.

At a minimum, the following MIBs must be compiled into the management station that will be receiving traps from the User Data Management systems in the network in the following order:

1. tklc_toplevel.mib
2. COMCOL-TC.mib
3. UDR-MIB.mib
4. UDR-TC.mib
5. NET-SNMP-MIB.txt
6. NET-SNMP-AGENT-MIB.txt

Solution

 OCUDR Specific MIB Files

Whenever the OCUDR is upgraded with new software,new MIBs are installed during the upgrade process via Tekelec Proprietary Distribution (TPD) and OCUDR Application Software.

Customers are required to export these MIBs to update 3rd party SNMP monitoring platforms so proper notification is received.

1. To allow the SNMP Manager to properly decode SNMP traps you will need to copy the appropriate MIB files from the OCUDR system under test to the SNMP Manager server.
   
   
2. Validate your SNMP server, ensure it has the latest MIBs for your UDR release, go to the following SNMP server path: /usr/share/snmp/mibs
   
   The following MIBs are for OCUDR:
   
   tklc_toplevel.mib                             Directory: /usr/TKLC/plat/etc/snmp/mib
   COMCOL-TC.mib                             Directory: /usr/TKLC/TKLCcomcol/cm?.??/prod/share/snmp/mibs (where ?.?? refers to the COMCOL software release that is in use on the system)
   UDR-MIB.mib                                  Directory: /usr/TKLC/udr/mibs
   UDR-TC.mib                                    Directory: /usr/TKLC/udr/mibs
   NET-SNMP-MIB.txt                           Directory: /usr/share/snmp/mibs
   NET-SNMP-AGENT-MIB.txt                Directory: /usr/share/snmp/mibs
   
   
   
3. Compare the date of these and any other UDR MIBs under this path with the MIBs on the active NO under test at location
   
   
4. Repeat validation process for all MIBs listed in Step 2.
   
   
   1. If the date and time stamps of the files are the same then the SNMP server has the latest UDR MIBs and no actions are required.
      
      
   2. If the MIB files on the SNMP server are older than the files on the OCUDR NOAM server then the MIB files will need to be copied over to the SNMP server by executing the copy command below.
      
      
   3. The MIBs must be compiled in the following order:

      tklc_toplevel.mib
      COMCOL-TC.mib
      UDR-MIB.mib
      UDR-TC.mib
      NET-SNMP-MIB.txt
      NET-SNMP-AGENT-MIB.txt

5. From the active primary OCUDR NOAM server, as root and SCP the files from Source Directory to customer SNMP server:
   
   scp -p /usr/TKLC/plat/etc/snmp/mib/tklc_toplevel.mib /usr/TKLC/<PROD_NAME>/mibs/*.mib root@<SNMP_IP>:/usr/share/snmp/mibs/
   
   where:
   <PROD_NAME> is the name of the product under test. For example, udr. Navigate around the path of your server under test to determine the exact path name.
   <SNMP_IP> is the IP address of the SNMP Manager server
   
   Example command for copying mibs from Active OCUDR NOAMP to its associated test SNMP server:
   
   scp -p /usr/TKLC/plat/etc/snmp/mib/tklc_toplevel.mib /usr/TKLC/udr/mibs/*.mib root@(ip address):/usr/share/snmp/mibs/
    
   
   
6.  Validate SCP was successful by validating the checksum, by following this sub-process
   Validation of mibs files using md5sum utility:

a.  Login to NOAMP UDR server using root user.
b.  Check the md5sum value of below files:

tklc_toplevel.mib /usr/TKLC/plat/etc/snmp/mib
COMCOL-TC.mib /usr/TKLC/TKLCcomcol/cm?.??/prod/share/snmp/mibs (where ?.?? refers to the COMCOL software release that is in
use on the system)
UDR-MIB.mib /usr/TKLC/udr/mibs
UDR-TC.mib /usr/TKLC/udr/mibs
NET-SNMP-MIB.txt /usr/share/snmp/mibs
NET-SNMP-AGENT-MIB.txt /usr/share/snmp/mibs

Example:

c.  Login to SNMP Manager server.
d.  Navigate to the directory where above files are resides.
e.  Check the currently used mibs files md5sum value on SNMP Manager server.

Example:

f.  Make sure that md5sum value captured in step(6b) matches exactly with value found in step(6e).
g.  If the md5sum value does not match then latest files from UDR needs to be copied over to SNMP Manager server.

7. Ensure Traps are in a readable format.

 END OF PROCEDURE.

This solution has no attachment