Forum Discussion
NimbostratusHealth monitor
Hi,
I have created health monitor on next-hop router as HTTP monitor since the connected router is blocking ICMP protocol. What I have done here: 1.Create monitor type as HTTP with Send String (GET /\r\n\r\n). Receive String (HTTP/1.1 200). 2.Create pool with one member (member IP for next-hop router). 3.Add the created monitor to this pool.
What I face that the pool member become down and seems not receiving the string that it should get it. Please I need some advises for how to monitor this link while it blocking ICMP and what the cause that make the member down.
Many Thanks.
5 Replies
Michael_JenkinsCirrostratus
Does the device you're trying to connect to allow for http requests at all? If you try to do a
on the pool member, do you get a response?curlIf so, and you want to see some monitor logging, you can follow one of the answers I posted in this question (the last entry) to enable monitor logging, and see what's going on.
Brad_ParkerCirrus
You could setup a transparent monitor to something upstream to monitor the router as well. https://support.f5.com/kb/en-us/solutions/public/8000/900/sol8971.html
Ed_SummersAgree with Michael J regarding the end device's HTTP server status and using curl to test. My humble addition: Based on your receive string your expecting HTTP 1.1. HTTP 1.1 requires the 'HOST' header in the send string. It is fine if the header is blank, but it must be there. Example send string: GET / HTTP/1.1\r\nHost: \r\nConnection: Close\r\n\r\n You can also review the health monitor traffic using 'tcpdump' which can quickly show if the server is rejecting your Send String - server will usually send back a 'Bad Request' response if it doesn't like the syntax. -Ed- Omnix_TIMS_4122
Hi ,
Thanks all for your replys. I just need to say that when i use send GET /\r\n\r\n and receive string is HTTP/1.1 and do tcpdump I see:
IP 10.18.231.245.7995 > 10.18.231.241.http: S 912105303:912105303(0) win 5840 out slot2/tmm1 lis= flowtype=130 flowid=CD17940 peerid=CCD4D00 conflags=626 inslot=0 inport=0 haunit=0 peerremote=00000000:00000000:0000FFFF:0A12E7F5 peerlocal=00000000:00000000:0000FFFF:0A12E7F1 remoteport=38785 localport=80 proto=0 vlan=2001
Can you see anything useful here?
- Ed_SummersDo you get anything else in the tcpdump? I only see one SYN here, normally there will be multiple attempts before the client gives up. Running under the assumption that you're not receiving a reply (SYN ACK) from the destination, and both hosts appear to be on the same network, I'd first look at the destination. My first two checks would be to verify that the destination indeed has an HTTP server running, and it does not have any access-controls blocking your monitor attempts. Let's go back to Michael J's suggestion to use curl. Likely you'll get nothing back (or a "cannot connect" or "connection refused"). If that is the case, then the device is not accepting requests - either the service isn't running or an access-control on the device is blocking your monitor. You'll need to shift troubleshooting to the device at that point. You can also try 'curl -kvv https://10.18.231.241' to see if they're running an HTTPS server instead of HTTP. Good luck! -Ed
