Last Modified: May 23, 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.1.0, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206
14.0.0, 220.127.116.11, 18.104.22.168
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 will be stuck in this state until they timeout and expire. In this state UDP connections will queue inbound packets. If the client application continues to send packets, the connection may never expire. The queued packets will accumulate consuming memory. If the memory consumption becomes excessive, connections may be killed and "TCP: Memory pressure activated" and "Aggressive mode activated" messages will appear in the logs.
Excessive memory consumption that leads to dropped connections.
A 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 will be killed and any queued packets will be discarded. If the client application resends packets they will be treated as a new connection.