Advanced grep filters for F5 logs

grep X number of lines after matching pattern is found

[root@ltm02:Active:Standalone] config # zless /var/log/ltm* | grep -A 2 "16:03:23" -n
230:May  3 16:03:23 ltm02 notice bigd[5171]: 01060001:5: Service detected UP for ::ffff:172.16.4.10:80 monitor /Common/site1-http-mon.
231-May  3 16:03:24 ltm02 notice bigd[5171]: 01060001:5: Service detected UP for ::ffff:172.16.4.20:80 monitor /Common/site1-http-mon.
232-May  3 16:03:24 ltm02 notice mcpd[4647]: 01070727:5: Pool /Common/site1.dc1.networkology.net member /Common/172.16.4.10:80 monitor status up. [ /Common/site1-http-mon: up ]  [ was down for 3hrs:25mins:55sec ]

The above example greps 2 lines after the matching pattern “16:03:23” is found.

  • -A denotes to print lines after the line of matching pattern and it takes a number argument. In this case, the number 2 was specified as the argument for -A, so it printed the immediate 2 lines after the pattern was found.
  • -n prints the line number as per the number of lines in the input file ltm*
  • The colon in 230: denotes the matching line
  • The hyphen in 229- and 228- denotes the line number of the next two lines printed after the matching line

grep X number of lines that come before the line where matching pattern is found

[root@ltm02:Active:Standalone] config # zless /var/log/ltm* | grep -B 2 "16:03:23" -n
228-May  3 12:37:29 ltm02 notice mcpd[4647]: 010719e8:5: Virtual Address /Common/64.25.36.10 monitor status changed from UP to DOWN.
229-May  3 12:37:29 ltm02 err tmm[12029]: 01010028:3: No members available for pool /Common/site1.dc1.networkology.net
230:May  3 16:03:23 ltm02 notice bigd[5171]: 01060001:5: Service detected UP for ::ffff:172.16.4.10:80 monitor /Common/site1-http-mon.

The above example greps 2 lines before the matching pattern “16:03:23” is found.

  • -B denotes to print lines before the line of matching pattern and it takes a number argument. In this case, the number 2 was specified as the argument for -B, so it printed the immediate 2 lines before the pattern was found.
  • -n prints the line number as per the number of lines in the input file ltm*
  • The colon in 230: denotes the matching line
  • The hyphen in 229- and 228- denotes the line number of the previous two lines printed before the matching line

grep logs between a range of time

zless /var/log/ltm* | grep "May\s*3 [1][2]:[2][0]:[3-4][0-9]" 
zless /var/log/ltm* | grep "MONTH\s*DATE [H][H]:[M][M]:[S-S][S-S]" 

The above will display log events between 12:20:30 and 12:20:49 on May 3.

  • \s* – this matches one or more white space characters between the month and the date.
  • To print range of logs between 12:15:00 and 12:24:59, the minutes section needs to be broken down into 10 minute intervals by keeping the place value of ‘tens’ constant in each range to accurately use this method of grepping;

12:15:00 to 12:19:59
12:20:00 to 12:24:59

This results in having two grep patterns for each of the above range;

zless /var/log/ltm* | grep "May\s*3 [1][2]:[1][5-9]:[0-9][0-9]\|May\s*3 [1][2]:[2][0-4]:[0-9][0-9]"

The beauty of this command is that your pattern does not have to match a specific keyword because your pattern matches a range of keywords (or numbers in this case).

Let me know if there’s a better way to grep without worrying about the multiple ranges to be created!

grep logs between a specific range of time

zless /var/log/ltm* | grep "/May *3 12:20:42/,/May *3 12:25:38/"

This is a pretty easy one to run but the problem with this grep format is you have to know the specific time to match or else it won’t return any output.

Troubleshooting SSL handshake in F5 BIG-IP LTM – Part 1 (SSL/TLS Protocol Mismatch)

 

How to identify if there is an SSL/TLS protocol mismatch between Client and F5 LTM?

 

1.  Check the protocol version used by the client in wireshark captures under the “Client Hello” packetprotocol mismatch wireshark capture

2.  Check the SSL/TLS protocol version supported by the LTM for a particular VIP

  • Run curl checks if possible from a remote server
curl -Ik https://site1.dc1.networkology.net --sslv2
curl -Ik https://site1.dc1.networkology.net --sslv3
curl -Ik https://site1.dc1.networkology.net --tlsv1
curl -Ik https://site1.dc1.networkology.net --tlsv1.0
curl -Ik https://site1.dc1.networkology.net --tlsv1.1
curl -Ik https://site1.dc1.networkology.net --tlsv1.2
  • Check if any protocol is negated in ciphers under client-ssl profile;

Continue reading

F5 iRules – Unconditionally redirect based on host header content and close initial connection #0

when HTTP_REQUEST {
 if { [string tolower [HTTP::host]] equals "site2.lab.com" }
 {
       HTTP::respond 302 noserver -reset Connection close Location http://site3.lab.com }
}

With the above iRule, the initial connection to site2.lab.com is closed when the redirect message is sent to the client. Check out the below output from curl which validates the same.

Continue reading

F5 iRules – Unconditionally redirect to another VIP based on host header content and initial connection stays intact

when HTTP_REQUEST {
    if { [string tolower [HTTP::host]] equals "site2.lab.com" } {
        HTTP::redirect "http://site3.lab.com"
    }
}

With this iRule, the initial connection to site2.lab.com is not closed and kept in memory until it times out. Check out the below output from curl which validates the same.

Continue reading