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: 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: 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: 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. Continue reading
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” packet
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;
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
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
Last-Modified: Thu, 17 Aug 2017 21:14:18 GMT
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.