Last Modified: Jun 17, 2019
See more info
Known Affected Versions:
12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 12.1.4, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 13.1.1, 220.127.116.11
14.0.0, 18.104.22.168, 22.214.171.124
Opened: Mar 05, 2018
When inbound or hairpin connections require a remote Session DB lookup, and the lookup request or response messages get lost, the connections can get stuck in an embryonic state. They remain stuck in this state until they time out and expire. In this state, UDP connections queue inbound packets. If the client application continues to send packets, the connection may never expire. The queued packets accumulate, consuming memory. If the memory consumption becomes excessive, connections may be killed and 'TCP: Memory pressure activated' and 'Aggressive mode activated' messages appear in the logs.
Excessive memory consumption that leads to dropped connections.
-- An LSN pool with inbound and/or hairpin connections enabled. -- Lost Session DB messages due to heavy load or hardware failure. -- Remote lookups are more likely when using PBA mode or NAPT mode with default DAG.
There is no workaround at this time.
When Session DB messages are lost, the connection is killed and any queued packets are discarded. If the client application resends packets, they are treated as new connections.