Updated: Nov 21, 2019
Note - SGOS 220.127.116.11 has been released resolving the issues discussed in this blog.
Recently a Cyber Vigilance customer encountered a Memory handling bug in their Advanced Secure Gateway (ASG) deployment. This bug causes the reporting of memory pressure in the Content Analysis engine on the ASG to report as high (80% and higher). Symantec have told me that the bug is caused by a process incorrectly reporting the current memory utilisation in the Content Analysis engine and appears to affect all versions of SGOS 6.7.4.x to 18.104.22.168. With the memory utilisation being reported in as 80% and above, adding user traffic to the situation means there is only 20% memory ‘remaining’ for allocation to the handling of traffic, which unfortunately for our customer was not enough. Once the Memory reached 100% the device then started to freeze and required a cold power cycle to bring the device back to life.
A hint that things are about to go south on an ASG can sometimes be seen when the ProxySG module on the ASG starts entering the warning state due to the “cas.bluecoat-local-request” and/or “cas.bluecoat-local-response” health checks failing.
Taking a look at the Content Analysis “CAS” log will also show lines stating, “no slave process available”.
For most customers, the memory pressure rising will not be obvious. The reason for this is because there is no health monitoring or alerting offered in the ASG to track the memory pressure of the Content Analysis engine. The CPU and Memory statistics typically present in a standalone Content Analysis devices management console is removed from the ASG equivalent.