Forum Discussion
Heath_Parrott Reading the document it seems that if the security group allows all inbound and outbound connections then this tracking and blocking of connections wont occur.Correct me if i am wrong.I enabled all traffic on our big ip VE on AWS but still the jmeter tests shows the same errors.Am i missing something here?
What is the SG config on both BIG-IP and the backend application (also how many application servers are in the pool)?
What is the instance type on the backend?
You will have connection tracking limits in all scenarios unless the SG reads permit 0.0.0.0/0 ANY in both directions.
Here are the areas that you can exhaust network resources based on how you described the situation and possible mitigation:
AWS Security Group Flow table full | Set all instances and all SGs to 0.0.0.0/0 ANY permit or change to a much larger instance |
SNAT port exhaustion (you have not indicated this by the log messages) | Add pool members, add more secondary IPs to the instance and create a snat pool |
Burstable instances on backend (T2/T3) | change to a non-burstable instance type or add more. |
Backend sending TCP RST to new connections from BIG-IP | Open security group, add instances, increase instance size |
Few clients generating traffic | increase number of clients. Modern linux OS have a port stride of 2 for outbound connections. This can lead to all traffic being pinned to a subset of TMMs (you need to look at individual CPU graphs). |
Using a rate limited license | For rate limited licenses you can have a scneario where you are not hitting the limit but you are hitting the limit/# of TMMs and your flows are pinned to that number of TMMs (example 25Mb/S license, 4 TMMs, all flows pinned to one TMM and you can hit a rater limiter about 6.x Mb/S). Increase client diversity for actual load test to spread flows over TMMs. Increase license used etc. Open support case for tunning options. |
The easiest things to narrow down the issue
1. SG changes
2. Increase all instances to larger types and / or add more instances to the pool
3. Run a load test with client side entropy (many source IPs) if you are not.