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

Debug health monitor for a single pool member in F5 LTM

Here’s an old post that shows how to debug bigd that gets you the debugs of all the health monitors that are running on the system. The rule of thumb with debugs is that the files get too large and may have an impact on other important services that may need that extra space.

What if you want to enable the debugs for just one pool member to see what’s going on with the health monitor associated with the pool member?

Monitor logging option is a better approach than debugging the bigd for this purpose.

You can find this setting under Local Traffic > Pools > pool_name > Members > Monitor Logging

Capture

Continue reading

Using curl for troubleshooting

View only response headers

curl -I only retrieves the header of the resource. The ‘I’ is case sensitive.

root@ubnsrv01:/etc/ssl/certs# curl -I https://site3.lab.com
HTTP/1.1 200 OK
Content-Length: 191
Content-Type: text/html
Last-Modified: Thu, 17 Aug 2017 21:14:18 GMT
Accept-Ranges: bytes
ETag: "40d9a1c99d17d31:0"
Server: Microsoft-IIS/7.5
Date: Sat, 02 Sep 2017 22:58:54 GMT

View response headers and content

curl -i includes the HTTP header in the output along with the site content. Since this URL is terminating on an F5, the HTTP header reports that a redirect is configured for this URL but doesn’t redirect it automatically to the URL. The ‘i’ is case sensitive.

Continue reading