Oracle Communications Diameter Signaling Router (DSR)
 

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

SCTP connections to a peer traversing a NAT firewall are not supported in DSR, and can cause other connections to fail to enable.

In this Document

Symptoms

Changes

Cause

Solution

References

Created from <SR 3-11806212241>

Applies to:

Symptoms

The first symptom of this problem appears when a new or existing SCTP peer connection--behaving in a responder capacity--fails to enable.  This connection may have been new, previously administratively disabled, or its connectivity dropped due to a network event but is now attempting to establish.

A second symptom of this problem can be confirmed via protocol capture (Wireshark or similar) of the SCTP handshake.  The DSR--acting as responder--receives INIT from the peer, to which DSR responds with INIT_ACK.  Peer responds with a COOKIE_ECHO, and DSR responds with immediate ABORT.  No clear reason is evident.  As the connection continues to re-attempt to enable, the handshake continually fails with this same cycle.

Changes

The known change to the DSR network that triggers this condition is the introduction of one or more SCTP peer connections configured in the DSR where the remote peer is employing Network Address Translation (NAT) to resolve the destination address.  Such NAT'd connections will fail to come up, as DSR does not support connections through NAT.

The EFFECT of this network environment change is manifest on other [valid] SCTP responder connections that attempt to (re-)establish after these invalid NAT connections are introduced.  Those valid connections will fail to come up as well, exhibiting the symptoms described previously.

Cause

The suspected cause of this condition is addressed by a Bug resolved in DSR 6.0 and later software. 

The Bug addresses a postulated situation wherein a processing failure occurs at a certain point in the code exercised during the initial SCTP handshake.  This failure produces a situation where a critical counter in the code for SCTP socket establishment goes from zero to its maximum value, and does not get cleaned up.  Subsequent SCTP responder connections that attempt establishment will fail, with ABORT sent by the DSR immediately after receipt of COOKIE_ECHO.

The NAT'd connections appear to be triggering the processing failure condition postulated by the Bug.  The NAT'd connections should fail natively, as DSR does not support such connections.  But thereafter the critical counter in the software remains at its maximum value, and subsequent non-NAT'd connections [SCTP responder type] that attempt establishment will fail handshake with the ABORT sent in response to the COOKIE_ECHO.

Solution

DSR 6.0 and later software releases contain a permanent fix addressing this problem.

If the condition is encountered in pre-DSR 6.0 software, the following steps should be taken:
- All introduced NAT'd connections should be administratively disabled from both ends. NAT'd connections are not valid on DSR.
- Any MP hosting a [valid] connection that is failing to complete SCTP handshake as described will need to be restarted through the NOAM GUI [Main Menu / Status & Manage / Server / select (highlight) server / <Restart>]. This WILL cause all connections hosted on that MP server to go down; they will re-establish on other available MP servers.
- Do not re-introduce or re-enable the NAT'd connections.

References

This solution has no attachment