BNS Platform Hardware
 

PLA-Support>Sun Systems>CommsGBU>Global Signaling Solutions>SN-SND: Tekelec DSR
 
Tools>Type>Guide
 

In this Document

Symptoms

Changes

Cause

Solution

References

Created from <SR 3-13057832851>

Applies to:

Symptoms

Diameter Peer Unavailable alarms on DSR R7.0.

Changes

 N/A

Cause

The alarm are caused by DSR restarts and the restarts are due to a known issue tracked under Bug 24483601.

Bug details:

the DSR's connection layer (DCL) crashes when trying to transmit an error answer generated for a routable request message. This is unlikely to occur with regular traffic, but more likely to occur when the DSR is in congestion.

This happens when a PDU is acquired for a routable Diameter request message from the PDU pool for the first time, and a Diameter answer is generated for that request from DCL. Some portion of such a PDU only gets initialized when it is encoded for the first time, and this encode call is missing in DCL because it (incorrectly) assumes that it will only be using encoded messages. This is true for the most part, but not in this one particular case, and when the uninitialized portion of the PDU is accessed, DCL crashes.

This can happen from:

1. DA-MP overload control processing,
2. if the PDU pool is getting exhausted,
3. if the DRL queue is filling up and DCL cant post to it
4. if the message is corrupted.

Of these cases, the first three are quite possible when the DSR is in congestion, but the fourth one is unlikely for two reasons:

1. Corrupted messages are unlikely in general.
2. Some amount of PDUs from the PDU pool would already have been used, and the DSR will keep cycling through them as they get released because the pool operates in LIFO mode (last-in-first-out).
   If traffic remains steady (i.e. the DSR is not overloaded), it is unlikely for a fresh PDU to ever be required.

In all cases, DCL only generates answers if the routing option set (ROS) associated with the peer sending the message, with the application ID of the message, or the default ROS (in that order) specifies generating an answer message in the “Resource Exhaustion” case.

Solution

Oracle Sustaining Engineering confirmed the issue should not be present DSR R7.1 onwards (Latest release R7.2 is already GA).

Upgrading to DSR R7.1 onwards should resolve this issue.

As a workaround on releases previous to R7.1, it is necessary to set the "Resource Exhaustion" action in the right Routing Option Set (ROS) to "Abandon" instead of "Generate Answer".

References

This solution has no attachment