Valid peer connections may fail to (re-)establish after new SCTP NAT'd connections are introduced in DSR configuration
(Doc ID 2085353.1)
Last updated on AUGUST 27, 2020
Applies to:Oracle Communications Diameter Signaling Router (DSR) - Version DSR 4.0 to DSR 5.1 [Release DSR 4.0 to DSR 5.0]
Information in this document applies to any platform.
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.
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.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document