Valid peer connections may fail to (re-)establish after new SCTP NAT'd connections are introduced in DSR configuration
Last updated on MAY 12, 2017
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.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms