Oracle Communications EAGLE (Software)
 

PLA-Support>Sun Systems>CommsGBU>Global Signaling Solutions>SN-SND: Tekelec Eagle 5
 

Service Set Cards May Become Unavailable for a Brief Period of Time During Release 46.5 Upgrade If Cards Are Not Appropriately Distributed Among Cardsets

In this Document

Description

Occurrence

Symptoms

Workaround

Patches

History

References

Applies to:

Description

During phase 3 of upgrade to EAGLE release 46.5, upgrade may not wait enough time to complete reload of cards in each service cardset before proceeding with the reload of cards in next service cardset.

Each service cardset can contain one or more SCCP, MCPM, IPSM, GLS, ENUMHC, DEIRHC, SIPHC, STC or SLAN cards. Based on number of cards in each service cardset, number of service cardsets configured and the time taken by the particular card type to reload, it is possible that the service provided by the particular card type may become unavailable on the node for a brief period during upgrade phase 3.

Though normally mate node should be handling the traffic during such maintenance window events, such service unavailable events on the node may be avoided or duration of such events can be minimized by spreading the service cards into maximum number of service cardsets allowed.

Occurrence

Due to bug 26805604, upgrade may not wait for service set cards to reload and come back to in-service before proceeding with the next cardset which would take next set of cards out-of-service. This may cause a particular service unavailability for a duration until the initial set of cards reloads fully.

This problem may occur if all of the following conditions are true

1. EAGLE is being upgraded to software release 46.5 (46.5.0.0.0-70.36.1).
2. EAGLE has any of the service cards (SCCP, MCPM, IPSM, GLS, ENUMHC, DEIRHC, SIPHC, STC, SLAN) in system being used. Since IPSM, GLS, STC, SLAN cards take very less time reload it very unlikely to see the service unavailable events for services provided by these cards during the upgrade phase 3, irrespective of their distribution in service cardsets. Since SCCP, ENUMHC, DEIRHC and SIPHC cards take more time to load, it is possible to see service unavailable events for services provided by these cards during the upgrade phase 3.
3. If service cards especially SCCP, ENUMHC, DEIRHC and SIPHC are not appropriately distributed among different cardsets. See Workaround section for more details.

Below capture shows sample configurations.

Symptoms

Below are possible symptoms which may appear in release 46.5 upgrade:

• During the phase 3 of upgrade to EAGLE release 46.5, upgrade may not wait enough time to complete reload of cards in each service cardset before proceeding with the reload of cards next service cardset.
• Each service cardset can contain one or more SCCP, MCPM, IPSM, GLS, ENUMHC, DEIRHC, SIPHC, STC or SLAN cards. Based on cards in each service cardset, number of configured service cardsets and the time taken by the particular card type, it is possible that the service provided by the particular card type may become unavailable on the node for a brief period during upgrade phase 3.
• UAM “<Service> not available” may be raised during upgrade phase 3.

Workaround

Though normally mate node should be handling the traffic during such maintenance window events, such service unavailable events on the node may be avoided or duration can be minimized by spreading the service cards into maximum number of service cardsets allowed.

Below steps can be performed to avoid/minimize service unavailable events on the node during the upgrade phase 3.

• Distribute the service cards appropriately in to multiple service cardsets (maximum up to 10) based on the total number of service cards available. Use maximum number of service sets(srvsets=10) in upgrade configuration(rtrv-upgrade-config) so that service cards gets distributed to maximum number of sets. Go through the examples given below for better understanding. Perform this step during HC2 and make sure no MASP card replacements are done after this before upgrade.
• If MPS is connected to service cards, make sure the ports on service module cards are set to AUTO=Yes and corresponding ports on MPS switches are configured appropriately (1000Mbps or AUTO) to operate at 1Gbps. Use RTRV-IP-LNK:loc=<> command to verify the port configuration and use command pass:loc=<>:cmd=“netstat -i” to verify the operational speed and duplex of MPS ports on SM cards. Please refer EPAP/ELAP documents for more details on switch port configuration. Refer KM 2275062.1 (Recommended Ethernet Port Settings for EAGLE SM Cards and EPAP Switch Ports) for recommended settings. Any correction in port settings should be done prior to HC2 so that this step can be verified in HC2.
• If MPS is connected, Initialize one service module card (init-card:loc=<>) to verify the reload time the service module card takes. This can be verified during HC2 window and during upgrade window before starting upgrade

Cardset configuration examples:

Service cards can be arranged in various service cardsets based on below assumptions.

IPSM, GLS, STC, SLAN : Takes very less time to reload. So very less likely to see an issue even if the all the cards (of each type) are placed in 2 successive service cardsets.

MCPM : May take a little longer time (than the above cards) to reload. We may see service unavailable events if the all the cards are placed in 2 successive service cardsets.

SCCP, ENUMHC, DEIRHC, SIPHC : Takes minimum 7 minutes or more (based on the RTDB size) to load. Definitely will see service unavailable events if the all the cards (of each type) are placed in 2 successive service cardsets.

Example #1: When 10 or more service cards of at least one card type are available. Say there are 10 SCCP cards, 2 ENUM cards, 2 IPSM cards and 2 MCPM cards.

Distribute the service cards in such a way that there is sufficient time between first set of service cards of a particular service come up and next service card of same service is rebooted in phase-3.

Example #2: When there are only 2 SCCP cards, 2 MCPM card and 2 IPSM cards.

If there are only two service cards of a particular service, for example two SCCP cards, move second service/SCCP to last service set. This way there will be sufficient time for first service set card to come up before last service set card gets rebooted.

Patches

Permanent fix is currently targeted for R46.5 maintenance release. Release is available at OSDC.

History

18-Sep-2017 - Initial draft

19-Sep-2017 - Updated based on review comments

20-Sep-2017 - Updated based on review comments

References

This solution has no attachment