Forum Discussion
VB_95896
Nimbostratus
NimbostratusProb with CPU + Attack Sign + Sync Delay
As I mentioned before (Performance forum), I have got a problem with 2 units “Big-IP ASM" (platform "4100") running version "9.4.5" (+ Hotfix “HF2”) in an Active-Active configuration (HA pair with CMP enabled).
First of all, let’s rehearse a few things (BTW, thank you Aaron for your help).
My tests showed that a config sync could produce a high CPU load:
In a scenario with 2 HTTP virtual servers, 2 active security policies (one blocking, the other not), and absolutely no traffic, a config sync (the first sync after adding the 2nd security policy to unit-2) took around 15 minutes and produced a peak of 80% on CPU-0. I couldn’t find any way to estimate the duration of this peak (the graph on the configuration utility simply showed a triangle…). After a reboot, I performed several config sync : they took around 7 minutes each (which seems still very long for a simple configuration).
Besides that config sync related issue, I discovered 2 other problems:
-- A -- It seems that CPU-1 is never used on my units.
-- B -- After a power-off / power-on, none of the previously available attack signatures is present on the “application security Configuration utility” (before power-off, they were present and able to block attacks). Even more tricky : the “Attack Signature Sets” screen does not contain any set of signatures (Path = Option > Attack Signatures > Attack Signature Sets ; URL = …/dms/policy/negsig_sets.php)... and no “Attack Signature Update” is possible (it used to work).
QUESTION (1) :
- Why is CPU-1 never used and how to change that?
- Why did my attack signature sets disappear and how to recover them?
- How to interprete the peak in CPU consumption during the config sync ? Does it mean that, even in an active-standby configuration, one has to keep the load under 60% of the total CPU (CPU0 + CPU1) to avoid a crash?
QUESTION (2) :
Could those problems be related to :
- the use of Clustered Multi-Processing (CMP) ? (It seems that it is not recommended with ASM...despite the fact it is enabled by default !!!)
- the use of encryption for the config sync ?
- the use of a (VLAN) failover timeout = 5 seconds ?
- my license (how to make sure it is activated properly) ?
QUESTION (3) :
- How to get all possible performance reports on Big-IP ASM (platform 4100) ?
I wish I could find a report such as the one attached to this message (change .txt into .rar) but dedicated to ASM-4100.
Any info is welcome.
VB
strongarm_46960I don’t expect CPU1 to be used since all you did was a simple sync, not much traffic there, more actual processing of data than sending HTTP traffic. No surprise there at all, CPU1 should not be used.
As for the Sudden CPU0 reaching 80% I would tie this down to the times between your devices are probably out of sync by 2 digits, if you are using NTP, test to make sure nothing is blocking. Compare both dates/time. Did you see any error from the config sync?
check your gatewasy & routing table, it not going through the net inorder to sync is it?
Make sure these unit running the same hotfix, did you manually add a route prior to upgrade. Check to make sure your static route file is still present after reboot. my guess is the upgrade failed on one of the boxes.
The use of encryption should not affect or cause these problems, my friend if you didn’t activate your license you couldn't get this far.
I have never seen performance reports for these units; even if i did i would never rely on reports conducted by third parties, different situation, CPU temp, different Cache/ compression settings etc etc will produce different results.
I would rather download HTTPerf for free and run my own test cases to suite my own performance objectives, just keep an eye on your LTM CPU/Mem whilst running HTTPerf.