SM Networks

The SM networks carry provisioning data from the Real Time Databases (RTDBs) on the EPAP to the RTDBs on the Service Module cards. The networks also carry reload and maintenance traffic to the Service Module cards. Each network connects EPAP A and EPAP B to each Service Module card on a single EAGLE platform.

The EAGLE supports more than one model of Service Module card. The cards differ in the size of database and the transactions/second rate that they support. In this manual, the term Service Module card is used to indicate any model of Service Module card, unless a specific model is mentioned. For more information about the supported Service Module card models, refer to Hardware Reference.

Network speeds when installed Service Module cards are a mix of E5-SM4G cards and E5-SM8G-B cards:

• Main SM network - 1 Gbps (1000 Mbps), full duplex

• Backup SM network - 1 Gbps (1000 Mbps), full duplex

Refer to the "Switch Configuration" procedure in Upgrade/Installation Procedure for EPAP.

The first two octets of the EPAP network addresses for this network are 192.168. These are the first two octets for private class C networks as defined in RFC 1597. The fourth octet of the address is selected as follows:

• If the EPAP is configured as EPAP A, the fourth octet has a value of 100.

• If the EPAP is configured as EPAP B, the fourth octet has a value of 200.

Table 2-3 summarizes the derivation of each octet.

The configuration menu of the EPAP user interface contains menu items for configuring the EPAP network addresses. See EPAP Configuration Menu.

EPAP Sync Network

The EPAP Sync network is a point-to-point network between the MPS servers. This network provides a high-bandwidth dedicated communication channel for MPS data synchronization. This network operates at full-duplex Gigabit Ethernet speed.

The first two octets of the EPAP IP addresses for the Sync network are 192.168. These are the first two octets for private class C networks as defined in RFC 1597.

The third octet for each EPAP Sync network address is set to 2 as the default. This octet value can be changed using the option 2 in Configure Network Interfaces Menu.

The fourth octet of the EPAP Sync network IP address is 100 for EPAP A, and 200 for EPAP B.

Customer Network

The customer network, or provisioning network, carries the following traffic:

• Customer queries and responses to the PDB (using PDBI)

• Updates between PDBAs on mated EPAP systems

• Updates between PDBAs and RTDBs when the PDBA and the RTDB are not on the same platform - This occurs if the RTDBs on one EPAP system cannot communicate with their local PDBA. These RTDBs would then attempt to communicate with the PDBA on the mate EPAP system.

• RTDB reload traffic if the Active PDBA is not located on the same EAGLE as the RTDB - This occurs if the RTDBs on one EPAP system cannot communicate with their local PDBA. These RTDBs would then attempt to communicate with the PDBA on the mate EPAP system.

• PDBA import/export traffic (file transfer)

• Traffic from a PDBA reloading from its mate

• EPAP and PDBA user interface traffic

A dedicated network is recommended, but unrelated customer traffic can also use this network.

Understanding Universal Time Coordinated (UTC)

Universal Time Coordinated (UTC) is an official standard for determining current time. The UTC is based on the quantum resonance of the cesium atom. UTC is more accurate than Greenwich Mean Time (GMT), which is based on solar time.

The universal in UTC means that the time can be used anywhere in the world and is independent of time zones. To convert UTC to local time, add or subtract the same number of hours used to convert GMT to local time. The coordinated in UTC means that several institutions contribute their estimate of the current time. UTC is calculated by combining these estimates.

UTC is disseminated by various means, including radio and satellite navigation systems, telephone modems, and portable clocks. Special-purpose receivers are available for time-dissemination services, including Global Position System (GPS) and other services operated by various national governments.

Because equipping every computer with a UTC receiver is too costly and inconvenient, a subset of computers can be equipped with receivers to relay the time to a number of clients connected by a common network. Some of these clients can disseminate the time, in which case these clients become lower stratum servers.

Understanding Network Time Protocol

Network Time Protocol (NTP) primary servers provide time to their clients that is accurate within a millisecond on a Local Area Network (LAN) and within a few tens of milliseconds on a Wide Area Network (WAN). This first level of accuracy is called stratum-1. At each stratum, the client can also operate as a server for the next stratum. A hierarchy of NTP servers is defined with several strata to indicate how many servers exist between the current server and the original time source external to the NTP network:

• A stratum-1 server has access to an external time source that directly provides a standard time service, such as a UTC receiver.

• A stratum-2 server receives its time from a stratum-1 server.

• A stratum-3 server receives its time from a stratum-2 server.

• This NTP network hierarchy can continue up to a stratum-15 server which receives its time from a stratum-14 server.

Client workstations do not usually operate as NTP servers. NTP servers with a relatively small number of clients do not receive their time from a stratum-1 server. At each stratum, redundant NTP servers and diverse network paths are required to protect against failing software, hardware, or network links. NTP works in one or more of these association modes:

• Client/server mode - A client receives synchronization from one or more servers, but does not provide synchronization to the servers.

• Symmetric mode - Either of two peer servers can synchronize to the other to provide mutual backup.

• Broadcast mode - Many clients synchronize to a single server or to a few servers. This mode reduces traffic in networks that contain a large number of clients. IP multicast can be used when the NTP subnet spans multiple networks.

The Tekelec MPS servers are configured to use the symmetric mode to share their time with their mate MPS servers. For an EPAP system, MPS servers are also configured to share their time with their remote PDBA server.

ITU Duplicate Point Code Support

The EPAP Support of EAGLE ITU Duplicate Point Code feature allows point codes to be provisioned in the PDB using a two-character group code. This feature works with the EAGLE ITU Duplicate Point Code feature, which allows an EAGLE mated pair to route traffic for two or more countries with overlapping (identical) point code values. The EPAP Support of ITU Duplicate Point Code feature allows group codes to be entered for Network Entity (SP or RN) point codes using the PDBI. The PDBI supports the provisioning of a two-character group code having a suffix to a point code of a PDBI network entity.

For example, a point code of 1-1-1 can be provisioned in the PDBI as 1-1-1-ab, where 1-1-1 is the true point code and ab is the group code. This usage allows the EAGLE to discriminate between two nodes in different countries with the same true point code. The EAGLE uses the group code to distinguish between the two nodes. The group code is used internally in the EAGLE only and is assigned to an incoming message based on the linkset on which it was received.

For example, Figure 2-3 shows a network that includes two countries, Country 1 and Country 2. Both countries have SSPs with a point code value of 2047.

Figure 2-3 Network Example with DPC and Group Codes

Users must divide their ITU-National destinations into groups. These groups are usually based on the country. However, one group could have multiple countries within it, or a single country could be divided into multiple groups. The requirements for these groups are:

• No duplicate point codes are allowed within a group.

• ITU-National traffic from a group must be destined for a PC within the same group.

• The user must assign a unique two-letter group code to each group.

In the network example shown in Figure 2-3, Country 1 can have only one point code with a value of 2047. Traffic coming from SSP 2047 in Country 1 can be destined only to other nodes within Country 1. In this network example, the user assigns a group code of ab to Country 1, and a group code of cd to Country 2.

When the user enters an ITU-National point code, he or she must also enter the group code, using the format “point code - group code”. This group code must be used for any command that uses an ITU-N point code.

The ITU Duplicate Point Code Support feature for EPAP and PDBI allows group codes to be entered for a Network Entity (SP or RN) point codes via PDBI commands. These commands are described in Provisioning Database Interface User's Guide.

The PDBI supports the provisioning of a two-character group code suffixed to a point code of a PDBI Network Entity (NE). You can provision a group code to any valid NE, for example, RN or SP.

All routing for PDB-based features specify group codes stored with the NE's point codes in accord with the EAGLE Duplicate Point Code feature.

For more information about group codes, refer to Group Codes in Database Administration - SS7 User's Guide.

Potential Lag Introduced by Asynchronous Replication

Lag means that the database level of the standby PDB is lower than the database level of the active PDB. With any asynchronous data replication scheme, the receivers of replicated data may lag behind. The standby PDB and, depending upon the homing policy in effect, the RTDB applications are susceptible to lag.

During continual provisioning traffic, the active PDB is expected to be a small number of levels ahead of the standby PDB. Also, any RTDB that is homed to the standby PDB is expected to have a level lower than the active PDB. For more information, refer to Selective Homing of EPAP RTDBs.

Asynchronous Replication Alarms

If the replication lag between PDB database levels increases to a value deemed unacceptable by EPAP, the following alarms are raised.

• PDBA Replication Failure (REPLERR) is a major alarm that indicates a failure of PDBA replication. The user must contact My Oracle Support.

• Standby PDBA Falling Behind is a minor alarm that signals that one EAGLE of the pair may have received updates at a longer interval than the other EAGLE. This alarm condition does not indicate data loss or corruption.

This feature permits all RTDBs within an MPS system, which includes both nodes of a mated pair or multiple nodes within several mated pairs, to always receive updates from a specific PDB, the active PDB, or the standby PDB. Updates are always be received from the selected PDBA process, regardless of whether the PDBA is the local PDBA or remote PDBA.

An EPAP configuration option allows the user to select whether the RTDB of an EPAP will normally receive updates. The RTDB is homed to a specific PDBA, the active PDBA , or the standby PDBA. If the user selects specific homing for the RTDB, that RTDB will receive updates from the specified PDBA, regardless of whether the PDBA is active or standby.

If the RTDB cannot communicate with the specified PDBA, the RTDB will automatically begin to receive updates from its alternate PDBA. Before the Selective Homing of EPAP RTDBs feature, updates were received from the remote PDBA.

The homing of each RTDB is independently selectable and allows some RTDBs to be homed to their local PDBA, to the active PDBA, or to the standby PDBA.

Terminology used in Configuration Descriptions

specific PDBA

Specific PDBA is used instead of local PDBA because the architecture can result in an MPS without a PDB on EPAP A. In this case, the RTDBs on that node have no local PDBA. Selective homing specifies the IP addresses of the MPSs with the first and second choices of PDBA. In a two-node MPS system, this corresponds directly to local homing. With more than two nodes, the user selects a specific PDBA without designating the PDBA as local or remote.

active PDBA

Active PDBA is the PDBA selected by the user to receive updates from the user’s provisioning system using the PDBI.

remote PDBA

For a given RTDB, the remote PDBA is a PDBA on a different MPS node. This PDBA may or may not be the active PDBA.

preferred PDB

Preferred PDB is the PDB selected by the RTDB. The RTDB is homed to the preferred PDB. For more about standby PDB homing, see Asynchronous Replication Serviceability Considerations. When specific RTDB homing has been selected, the RTDB will receive updates from the alternate PDB if the preferred PDB is unreachable.

alternate PDB

Alternate PDB is the PDB that is not selected. When either active or standby PDB homing is selected, the RTDB has the option to receive updates from the alternate PDB if the preferred PDB is unreachable.

active homing

If the user selects active homing for the RTDB, that RTDB always receives updates from the active PDBA. If the RTDB loses its connection with the active PDBA, the RTDB will automatically begin to receive updates from a standby PDBA; the reverse is true for ‘standby’ homing. This automatic switchover is a configurable option. See Switchover PDBA State.

Possible RTDB Configurations

These are the possible configurations of each RTDB in the system. Each configuration is also described in detail in the following sections.

• Specific PDB Homing with Alternate PDB

• Active PDB Homing with Alternate PDB

• Active PDB Homing without Alternate PDB

• Standby PDB Homing with Alternate PDB

• Standby PDB Homing without Alternate PDB

Specific PDB Homing with Alternate PDB

This RTDB configuration specifies the IP address of the PDB from which the RTDB receives updates. If the specified PDB is not reachable, the RTDB receives updates from the alternate PDB. Table 2-4 shows the condition of each possible connection to the PDB from the RTDB perspective. The shaded cells indicate the PDB from which the RTDB receives updates.

See RTDB Homing Considerations to determine if this configuration is the most appropriate match for your installation.

Active PDB Homing with Alternate PDB

This RTDB configuration specifies that the RTDB receives updates from the active PDB. If the active PDB is not reachable, the RTDB receives updates from the standby PDB. Table 2-5 shows the condition of each possible connection to the PDB from the RTDB perspective. The shaded boxes indicate the PDB from which the RTDB receives updates.

See RTDB Homing Considerations to determine if this configuration is the most appropriate match for your installation.

Active PDB Homing without Alternate PDB

This RTDB configuration specifies that the RTDB receives updates from the active PDB. No alternate PDB is specified. Table 2-6 shows the condition of each possible connection to the PDB from the RTDB perspective. The shaded boxes indicate the PDB from which the RTDB receives updates.

See RTDB Homing Considerations to determine if this configuration is the most appropriate match for your installation.

Standby PDB Homing with Alternate PDB

This RTDB configuration specifies that the RTDB receives updates from the standby PDB. If the standby PDB is not reachable, the RTDB receives updates from the active PDB. Table 2-7 shows the condition of each possible connection to the PDB from the RTDB perspective. The shaded boxes indicate the PDB from which the RTDB will receive updates.

See Asynchronous Replication Serviceability Considerations to determine if this configuration is the most appropriate match for your installation.

Standby PDB Homing without Alternate PDB

This RTDB configuration specifies that the RTDB receives updates from the standby PDB. No alternate PDB is specified. Table 2-8 shows the condition of each possible connection to the PDB from the RTDB perspective. The shaded boxes indicate the PDB from which the RTDB receives updates.

See Asynchronous Replication Serviceability Considerations to determine if this configuration is the most appropriate match for your installation.

General Homing Considerations

The Selective Homing of EPAP RTDBs feature requires additional configuration during installation and when new non-provisionable nodes are added. The configuration of all affected sites must be planned before the installation process begins.

Each MPS must be configured as provisionable or non-provisionable. Each network has two provisionable MPSs. (See Figure 2-4.) These MPSs must then be configured with a replicated PDB, which is described in EPAP Software Configuration. If non-provisionable MPSs are used, the non-provisionable MPSs are added after the provisionable MPSs are installed and configured.

Before the first MPS can be installed, the answers to these questions must be available:

• How many MPSs are involved?

• Which sites will be provisionable?

• How will each RTDB be homed?

For the configuration on each site, the answers to these questions must be available:

• What are the IP addresses of the A sides of the two provisionable sites?

• What is the RTDB homing policy for this site?

RTDB Homing Considerations

Although RTDB homing allows a wide variety of configurations, two overall configurations cover the needs of most customers.

1. Configuration for Load Sharing and High Availability

   In this configuration, all RTDBs are configured for specific RTDB homing. The alternate PDB is an acceptable provisioning source if the preferred PDB is unavailable. The RTDBs at the provisionable MPS prefer the local PDB. The remaining non-provisionable MPSs are divided evenly to prefer one PDB or the other. See Specific PDB Homing with Alternate PDB for more information on this RTDB Homing configuration.

2. Configuration for Deterministic Provisioning

   In this configuration, all RTDBs are configured for active homing. The alternate PDB is not an acceptable provisioning source. See Active PDB Homing without Alternate PDB for more information about this RTDB homing configuration.

Asynchronous Replication Serviceability Considerations

The type of RTDB homing policy selected affects serviceability by the user. Tekelec recommends for asynchronous PDB replication that Standby PDB Homing (RTDB configuration 4 or 5) is used. Although this policy may result in a slightly longer propagation time for updates from the PDB to the RTDB, the increased delay is beneficial in disaster recovery situations.

Keeping the RTDB homed to the standby PDB ensures that, except for external intervention, every level present in the RTDB is also present in both PDBs. Both active and specific RTDB homing methods will continue to be valid. The homing methods provide proper function under all normal operating circumstances. Under these homing policies, the RTDB can possibly reach a database level that is higher than the PDB to which it may home to in response to a PDBA switchover. If this occurs, the RTDB must be recreated from the PDB to which the RTDB currently points.

Active and specific homing may create complications in disaster situations. For instance, if a failure forces the active PDB to become unavailable for a non-trivial amount of time and the user forces switchover to Standby (bypassing the protocol that syncs the databases prior to switchover), the dataset of the RTDB can possibly conflict with the dataset of the only remaining PDB. This situation requires a RTDB reload from the remaining PDB, which can be a time-consuming process for any PDB with a large amount of data.

Asynchronous replication has one important effect on EPAP behavior. PDBA switchover can no longer be forced when the PDBAs are able to communicate and the standby is not current. Switchover involves allowing a definable amount of time for the standby PDB to be brought up to the level of the active PDB. If the standby PDB fails to achieve the equal database level in the allotted time, switchover does not occur and the standby PDB returns with the number of levels still remaining to be replicated. This approach prevents database inconsistency. If the standby PDB cannot reach the active PDB to determine its level, the EPAP allows PDBA switchover to be forced.

Socket-Based Connections

The EPAP receives PDBI messages through a TCP/IP socket. The client application is responsible for connecting to the PDBA well-known port and being able to send and receive the defined messages. The customer’s provisioning system is responsible for detecting and processing socket errors. Tekelec recommends that the TCP keep alive interval on the customer’s socket connection be set to a value that permits prompt detection and reporting of a socket disconnection problem.

There is a limit to the number of PDBI connections; the default is 16 clients. If an attempt is made to connect more than the current client limit, a response is returned to the client:

PDBI_TOO_MANY_CONNECTIONS

After the response is returned, the socket is automatically closed.

Although the default limit is 16 PDBI connections, Tekelec is able to configure and support up to 128 connections. If more than 16 connections are required, contact My Oracle Support for information.

Import Files

Manual import and automatic import are the available import file options. Both import options accept data only in the PDBI format.

Valid commands to include in an import file are:

• ent_sub
• upd_sub
• dlt_sub
• ent_entity
• upd_entity
• dlt_entity
• ent_eir
• upd_eir
• dlt_eir

Do not include rtrv_sub, rtrv-entity, or rtrv_eir commands in an import file. The inclusion of rtrv commands causes an import to take a long time to complete. A write transaction lock is applied during the entire import for a manual import, and is applied intermittently during an automatic import. While the write transaction lock is in place during either type of import, no other updates to the database can be made.

Manual Import

Automatic Import File Setup

The manual import mode is used to import data on a one-time or as-needed basis. The manual import mode is configured with the Import File to PDB Screen. The selected file is processed immediately. A manual import locks the PDB write transaction; other users will not be able to obtain the write transaction until the import operation is complete.

When the PDB is active, the automatic import searches the /var/TKLC/epap/free/pdbi_import directory for new files on a remote system for import every five minutes. If a file exists in the directory and the file is not being modified or in the process of being transferred when it is polled, the import will run automatically at that time. If the file is being modified or is in the process of being transferred, the automatic import tries again after five minutes.

The automatic import option can import up to 16 files at one time. The number of files imported is limited by the available number of PDBI connections. If more than 16 files exist in the directory, another file is started after a previous file completes until all files have completed. The files are imported sequentially. The results of the import are automatically exported to the remote system specified by the Configure File Transfer Screen.

After the import is complete, the data file is automatically removed and a results file is automatically transferred to the remote system.

An automatic import obtains the PDB write transaction and processes ten of the important file commands. Then the write transaction is released, allowing other connections to provision data. An automatic import obtains the write transaction repeatedly until all of the import file commands are processed.

Automatic Import Status

When using the automatic import function, the following informational banner messages is displayed on the UI browser screen in the Message Box described in Figure 3-21.

Import of <filename> in progress - xx.xx%( while in-progress)

Import of <filename> completed (when complete)

If the import fails when the PDBA is not running and the automatic import was started by cron, the following informational banner message is displayed on the UI browser screen in the Message Box described in Figure 3-21.

Import of <filename> failed - no PDBA

If the import fails when the connection to the PDBA is lost while the automatic import is in progress, the following informational banner message is displayed on the UI browser screen in the Message Box described in Figure 3-21

Import of <filename> failed - PDBA died

If an automatic import fails, an automatic retry will occur every five minutes.

Export Files

The manual export and automatic export are the available export file options. Data can be exported in both PDBI and CSV formats. Refer to Provisioning Database Interface Guide for more information. The Manual File Export allows data to be exported to a specified location on a one-time or as-needed basis, and is configured by the Export PDB to File Screen.

If the export file needs to be automatically transferred to a remote server, the file name should start with "pdbAutoExport".

For example: "pdbAutoExport_<hostname>_<YYYYMMDDhhmm>".

For instance, if the following files are present in the /var/TKLC/epap/free/pdbi_export directory:

pdbExport_Arica-A_202411251131.tar.gz

pdbAutoExport_Arica-A_20241125113147.tar.gz

testPdbFile.tar.gz

Only pdbAutoExport_Arica-A_20241125113147.tar.gz will be automatically transferred to the remote server (if Configure File Transfer is enabled). The rest will remain in the directory for manual or other intended use.

Automatic File Export

The Automatic File Export function allows scheduling the data export for a specific day and time. The export can be scheduled at a specific time for each of the following repeat periods: every N (up to 365) number of days, specified days of the week, specified day of the month, or specified day of the year. The Schedule Export screen displays any existing PDB export tasks and is used to create a task by specifying the type, export format (PDBI CSV), export mode (blocking, snapshot, or real-time), the time and repeat period. In addition, a comment field is available to describe the task. While performing the "Export PDB to File", the output filename format is pdbAutoExport_<hostname>_<YYYYMMDDhhmmss>, which will save the file in pdbi_export. The PDBA must be active at the scheduled time of export for the file to be exported.

EPAP Automated Database Reconciliation Example

Starting with PDBAs in the following current configuration.

Updates 701, 702, and 703 on Node 1 have not been replicated to Node 2.

Assume that a fault that takes down the Node 1 PDBA before the replication process is complete. Node 2 has become the Active PDBA and is now receiving provisioning updates.

• Updates 701-703 on Node 1 have not been replicated to Node 2.

• Updates 701-703 on Node 1 are different from updates 701-703 on Node 2.

The PDBA that received an update with the latest timestamp (in this example, Node 2 PDBA) will automatically become the Active PDBA and continue accepting provisioning updates. The Node 1 PDBA is put in a REPLERR state and PDBA Replication Failure alarm initiates on Node 1 PDBA.

A replerr file (REPLERR PDBA) with the replication log lists from the Node 1 PDBA is created. This file contains the lost Node 1 provisioning updates (701-703) and is in the format of a PDBI import file. The customer can examine the file and decide whether to reapply these updates to the Active PDBA.

After the Node 1 PDBA becomes available, the customer must temporarily suspend provisioning and perform a PDB copy of the Node 2 PDBA to the Node 1 PDBA to reconcile the PDBs before the Node 1 PDBA can be made active again.

The EPAP Automated Database Recovery feature is enabled through the text-based EPAP user interface.

EPAP PDBA Proxy Feature Requirements/Limitations

Some requirements and limitations of the EPAP PDBA Proxy feature are:

• The customer provisioning system loses connection to the PDBA:
  • When the EPAP PDBA Proxy feature is first initiated upon server failure and switchover to the backup PDBA
  • During recovery when service is being restored to the PDBA on the sever that had failed

  When the connection is lost, it must be re-established to the same VIP address.

• Both provisioning VIP addresses (the local or active EPAP VIP and the remote or standby EPAP VIP) must be configured using the text-based EPAP user interface. See Configure Provisioning VIP Addresses.
• The Change PDBA Proxy State procedure must be performed on both active and standby MPS-A PDBAs. See Change PDBA Proxy State.
• The EPAP PDBA Proxy feature does not provide PDBA connection redundancy in the case of PDBA (application) failure. The EPAP PDBA Proxy feature provides PDBA connection redundancy only after failure of the active EPAP A.
• The EPAP PDBA Proxy feature does not initiate in response to a Switchover PDBA State. A manual switchover requires the operator to change the provisioning VIP address in operator provisioning software.
• The EPAP PDBA Proxy feature does not require activation of the Automated Database Recovery (ADR) feature
• The EPAP PDBA Proxy feature is not supported for Standalone PDB EPAP.
• SSH tunneling does not work with the PDB proxy feature as SSH tunneling works with server IP and not with VIP.

EPAP PDBA Proxy Example

During normal provisioning operations:

• Operator provisioning system sends provisioning updates to the Active PDBA on Node 1 using the active provisioning VIP address (192.168.0.1).

• Active PDBA checks syntax and writes to the Active PDB.

• Active PDBA writes to a replication log on the EPAP A and local EPAP B.

• Active PDBA sends an ACK response to the operator provisioning system.

• Standby PDBA on Node 2 queries the EPAP A replication logs on Node 2 and updates the PDB on Node 2.

A fault (server failure) on the Node 1 with the active PDBA is shown in Figure 2-5:

• With the EPAP PDBA Proxy feature enabled, the system continues using the active provisioning VIP address (192.168.0.1).

  Note:

  During the switchover to the PDBA on Node 2, the customer provisioning system loses connection to the PDBA. The connection must be re-established to the same VIP address.
• If the Standby PDBA on Node 2 is reachable, EPAP B on Node 1 transmits replication logs to the Node 2 PDBA.
• When the Node 2 PDBA has all the replication logs from the EPAP B on Node 1, the Node 2 PDBA becomes the Active by-proxy PDBA.
• Operator provisioning continues using provisioning VIP address 192.168.0.1 because EPAP B on Node 1 proxies provisioning data to the newly Active PDBA on Node 2.

  Figure 2-5 Failure of Active PDBA

  
  
  

When the Node 1 PDBA is restored to service:

• Updates sent to Node 2 PDBA while the Node 1 PDBA was down are forwarded to the Node 1 PDB.
• Records are replicated. Node 1 becomes the Active PDBA and Node 2 reverts to Standby status.

  Note:

  During recovery when the PDBA on Node 1 is being restored to service, the customer provisioning system loses connection to the PDBA. The connection must be re-established to the same VIP address.

This feature is enabled through the text-based EPAP user interface. See PDB Configuration Menu.

MPS RTDB Audit

This audit maintains the integrity of the RTDB on the MPS. This audit cycles through the entire RTDB within a 24-hour period and reports any anomalies in the form of an alarm. If the RTDB is determined to be corrupt, provisioning is stopped and a data reload is required.

The audit is controlled through the MPS GUI Menu field Maintenance:RTDB Audit. The state of the audit can be viewed, enabled, or disabled through this control. See Maintenance Menu.

When this audit is enabled, the RTDB validates the CRC32 values per record entry within all tables. If corruption is encountered, an alarm is set on the MPS scrolling banner. All provisioning from the PDB is halted until the condition is corrected with an RTDB Reload.

EPAP-to-DSM Network Card DB Level

Each Service Module card validates its own database level against the received EPAP database level. An inconsistent alarm is generated at the EAGLE for each inconsistent Service Module card. The command rept-stat-db displays the database on the Service Module card as Diff level. See Table 2-12.

card

EAGLE DSM Audit of MPS Databases

This audit is responsible for maintaining the integrity of the RTDB on the Service Module card. This audit cycles though the entire RTDB within a 24-hour period, reporting any anomalies in the form of alarms and may attempt to repair a corrupted record with a valid record from a mate Service Module card.

The STP Options (chg-stpopts) command is used to set up this audit with the dsmaud parameter which has three states: off,on, and ccc. When the dsmaud parameter is set to off the auditing capabilities on each of the Service Module cards is disabled from auditing the RTDB Databases. Setting the dsmaud parameter to on enables the auditing capabilities which produce an alarm if a corrupted record is detected. Setting the dsmaud parameter to ccc enables the cross correction capabilities, which provide a method for repairing a corrupt record when it is encountered.

When corruption is encountered, this sequence occurs.

1. The RTDB is set to Corrupt status.

2. A UAM (Table 2-13) is sent to the OAM

3. The corruption is logged and stored in a memory array with this information:

   1. Table ID

   2. Record number

   3. Table high-water-mark

   4. Old CRC32 value

   5. New CRC32 value

   6. Record address in memory

   7. Record entry contents

      Table 2-13 Corrupted RTDB Database Alarm

      UAM#	Severity	Message Text	Output Group (UI Output Direction)
      443	Minor	RTDB database is corrupted	card

A maximum of 250 log entries is permitted within an audit cycle. When this maximum is exceeded, the first 25 corrected records are output to the DB output group and the card initiates a Full Reload.

Service Module cards in the corrupted state continue to receive updates from the MPS and continue to service MSU traffic.

All records received from the MPS are validated through the CRC32 routines prior to being written to memory. If a corrupted record is encountered, data is collected and different events will occur based on the loading phase state. See Table 2-14

Corruption Cross Correction

If a record within the RTDB on any card becomes corrupted, a mate Service Module card can supply the correct data for the record. Corruption Cross Correction occurs across the IMT. For each corrupted record encountered, a single broadcast message is sent from the affected Service Module card to all mate Service Module cards. When a Service Module card receives a request for Corruption Cross Correction, the current database level and requested record are evaluated for consistency. If the request is validated, a response is sent to the original Service Module card. Otherwise, the request is discarded. This would occupy no more than 26 messages on the IMT bus for each corrupted record encountered. When a Corruption Correction Response is received, it is evaluated for correctness and applied after being passed to the Service Module card. Subsequent messages received for the same correction are discarded.