Oracle Communications EAGLE (Software)
 

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

In this Document

Symptoms

Cause

Solution

Created from <SR 3-13509708971>

Applies to:

Symptoms

Only one DSM card out of nine DSM card was unavailable and yet some messages were not processed.

Judging by the parameter "MSU USAGE" from output rept-stat-sccp, it was not high.

Traffic degradation implies absence of routing SCCP messages, passing through the interface cards, that listed in the field «CARDS DENIED SCCP SERVICE» from command rept-stat-sccp.

Cause

1. One of the VSCCP cards rebooted when you had the issue:
   
   8508.0013 ** CARD 3305 VSCCP Card is isolated from the system
    16-06-20 18:35:36
2. This card did not produced any obit which means it was abnormally disconnected from the Eagle.
3. According to the timestamps, 2 x traffic cards were likely working with the DSM card 3305 at the time when this DSM card suddenly "disappeared" from the system.
   As a result, the service has been denied for both cards.
   
   8508.0013 ** CARD 3305 VSCCP Card is isolated from the system
    16-06-20 18:35:36
     8521.0336 ** SCCP SYSTEM LIM(s) have been denied SCCP service
    16-06-20 18:35:36
4. Another card (3318) has been impacted for the Class1 messages sequencing at this exact time. This is reported by the below trouble:
   
   Card 3318 Module sequence.c Line 494 Class 0001 Severity 1
    f0 02 74 9e 00 01 43 01 43 17 5d 06 02 02 fe 02 ..t...C.C.].....
    ff ff ff ff 00 00 00 00 6e 6f 6e 65 01 00 01 2b ........none...+
    00 21 10 02 00 00 00 0c .!......
     Report Date:16-06-20 Time:18:35:36
5. The measurements indicate the counter MUSLOST3 being pegged, which indicates some MSU discards.

Conclusion:

1. The card 3305 is suspicious as it became isolated over a long period of time without obitting.
2. The isolation of the card 3305 may also be due to one of the IMT cards 3309 or 3310.

Solution

I would recommend to physically re-seat the card 3305 to be sure it is properly connected into the shelf or replace it, and check the cards 3309 and 3310 are strongly inserted in the shelf.

The thing is that the traffic cards 3303 and 3304 were still thinking that the DSM card 3305 was still present.

Rebooting both cards, which were still trying to work with the DSM card 3305, solved the issue as by rebooting them they refreshed the status of the cards on the bus.

This is a very unexpected case.

There is maybe a hardware issue with the card 3305 or with the slot 3305 or with one of the HIPR2 cards 3309 or 3310 for the port on which the card 3305 is connected to.

This is why I recommended to reinsert the card 3305 and do it firmly.

You can run this command once a day to check if some cards are denied :

In this part of the output, filed named "SVC DENIED" :

This solution has no attachment