How many times have you had to log in to BIG-IP, copy/paste the tcpdump commands in, look at the file name, scp the file down or away, then rinse/repeat with other key files or re-capture something because you got the syntax wrong? I wanted to see how far I could take automation with efforts like this. On Last Week's episode of The Core, I walked through a proof of concept I built that does the following:
Prompts the user for the virtual server under test, the client IP where test traffic will come from, and the support case number this traffic is being collected for. I will refactor the code in the future to make some of this optional via command-line flags.
Creates the appropriate iRule from K12783074, uploads it, and applies it to the specified virtual server.
Updates a tcpdump string as appropriate to the specified virtual server, the case number, and the current date, and starts tcpdump, at which point the test traffic can be executed to reproduce the issue.
Removes the iRule that was uploaded from the specified virtual server and deletes it.
Creates a TLS key file using the appropriate commands from K12783074.
Creates a qkview archive.
Downloads all three files created in the process, then deletes them from the BIG-IP.
The code for this proof of concept is here on GitHub. This was prep work to begin experimenting with pyshark, scapy, and other tools to programmatically handle a lot of the "first steps" of packet analysis. Currently on the roadmap:
Utility to decrypt downloaded BIG-IP captures
Utility to match and visualize clientside/serverside BIG-IP flows using f5ethtrailer details