Hello- I need help in understanding connection/s threshold in DoS/Zone protection profiles & packet rate .
sh session info displays super high packet rates at times with cps still within close to 400 to 700 connections per sec. (VM 300 on ESXi)
target-dp: *.dp0
--------------------------------------------------------------------------------
Number of sessions supported: 819200
Number of allocated sessions: 238277
Number of active TCP sessions: 27957
Number of active UDP sessions: 210299
Number of active ICMP sessions: 21
Number of active GTPc sessions: 0
Number of active GTPu sessions: 0
Number of pending GTPu sessions: 0
Number of active BCAST sessions: 0
Number of active MCAST sessions: 0
Number of active predict sessions: 8192
Number of active SCTP sessions: 0
Number of active SCTP associations: 0
Session table utilization: 29%
Number of sessions created since bootup: 48187976
Packet rate: 100426/s
Throughput: 224118 kbps
New connection establish rate: 672 cps
When the packet rate is high CPU is 100 % . If I need to protect resources & applying Zone/DoS protection, I don't see if Packet rate can be define any where. Only see connection/s , which is not convincing to be applied as cps is not that high when CPU spikes to 100 %.
Secondly what is the good formula/logic to define threshold in these profiles ?
if you app override the flow that is generating a vast amount of packets, processing will be slightly faster because you skip layer7 and on a hardware platform the session will be able to go into hardware offloading
packet buffer protection can also help as it will protect the firewall's low level buffers from getting flooded with too high packet rate, indeed
A zone/dos protection profile works by preventing new connections from taking up more resources than expected. A syn flood works by taking up an excessive amount of 'sockets' or sessions in the session table (for each received syn, the recipient needs to reserve memory space and send an ack back, waiting for the final ack to complete the handshake. Rendering the socket unusable until a timeout has occurred) Zone protection therefore protects 'connections per second' as cps are succesfull establishments of a full (new) session, per second Pps or packets per second, can be two different things - an influx of new packets, which ZP protects against - the number of packets per second exchanged over an established session, for which there is no real defence The latter is where you have some sessions that are very chatty and causing high DP CPU load. Since these sessions already exist they will not show up in cps It can be tricky to find which sessions are causing high pps rate. You can look at ACC and play with final counters to tune in on the culprit. Once found there's several avenues to tackle the issue : forced offloading (app override), local outbreak, firewall upgrade, tuning the server packetrate,...