on 09-Mar-201514:05 - edited on 05-Jun-202322:32 by JimmyPackets
Problem this snippet solves:
This script will report on the impact of 2048bit keys on your BIG-IP infrastructure.
How to use this snippet:
Change is coming with new requirements for 2048-bit keys instead of the current industry-wide usage of 1024-bit keys. This tool will help users gain understanding into whether or not their LTM infrastructure is ready for the change.
2. How it works
This application will report the impact of 2048bit keys on your infrastructure:
It will graph the last 7 days of TPS data by default (24hr and 30day also available)
It will report, based on your existing TPS data, if your platform is undersized for 2048bit keys
genreport.py system1 system2 system3 filename.pdf
4. Supporting Information
Assumes currently using 1024bit keys
Only makes read-only calls for graph data, license, version, and platform information. That said, it's probably best to run this in a maintenance window
Limit each report to 15-20 systems.
Simple math is performed on the 1024bit PLATFORM (not license) maximum TPS. 2048bit maximum TPS will be approximately 20% of 1024bit threshold, so that number is used in this report.
Note:This tool doesn't deal with the sub-second transaction rate (Please see Solution 6475 for more details.) at all - it's completely bound to the RRD information on-box, and as the size of the time frame grows, it'll smooth the max TPS numbers down for that period. This is the script is defaulted to 7 days - it seemed to be a decent compromise. For bursty, sub-second SSL environments: because the script relies on RRD, reporting on smoothed data can be misleading. The best way to handle these environments is to take sample packet captures throughout your peak periods and count handshakes in 10ms windows.