Unruly Health Monitor

Run a tcpdump on the server vlan, filtering for the self-IP address of the active LTM and one of the servers to which the monitor is applied.

 

 

You should be able to see the request & response on the wire. If you don't see both, check L2/L3 path (arp table, routing). If you see both, you might be able to see the problem (server error, redirect, HTTP version issue...)

 

 

If that doesn't help you resolve it, post back with your monitor config (b monitor monitorname list) and tcpdump of one request / response & maybe we can help further.

 

 

/d

The app may be looking for a valid host header. If you have access to HTTPWatch or Fiddler(IE) or Live HTTP Headers (Firefox), you can see what the browser is actually sending and replicate that in your send string.

Also you can use curl from the LTM command line to try the same send string and see what response you are actually getting back at the LTM.

 
 curl -H "Host:" http:///ms/alive.txt 
 

(curl uses HTTP 1.1 by default)

Denny

Thanks.. I will reply back with my finding first thing in the morning..

Just to illustrate, here's the output when I don't send a host header:

 
 [root@xxxxx:Active] config  curl -H "Host:" http://10.241.34.107/ms/alive.txt 
  
  
 400 Bad Request 
  
 Bad Request 
 Your browser sent a request that this server could not understand.
 
  
  
 

versus when a valid host header is sent (the URI is invalid in both cases for this app server but that doesn't matter at this stage)

 
 [root@xxxxx:Active] config  curl -H "Host: xxxx.com" http://10.241.34.107/ms/alive.txt 
  
  
 The requested URL was not found on this server. 
  
  
 

So with a valid URL I would expect the 2nd one to have returned the correct content, whereas without a host header I get a 400 Bad Request.

Denny

Another thing to consider is replacing the \n's (LF) with \r\n (CRLF). HTTP header lines should be separated with a carriage return and a line feed--not just a line feed.

 

 

Aaron

was wondering about that myself (\n v. \r\n)

 

 

I ran across this solution double checking, and question its accuracy:

 

SOL2167: Writing full HTTP commands for Extended Content Verification (ECV) or Extended Application Verification (EAV) health monitors: Click here

 

 

seems i remember there were diffs betw 4.x & 9.x specifically regarding line term chars, & this doc makes no distinctions re: version, but does re: creation of EAV v. ECV monitors (without defining either).

 

 

This solution seems less confusing, and may be more accurate:

 

SOL3224: HTTP health checks may fail even though the node is responding correctly: Click here

 

 

Please advise if these or any other solution on the topic needs updating. Details much appreciated...

 

 

/d

RFC2616 states:

HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all

protocol elements except the entity-body (see appendix 19.3 for

tolerant applications).

I didn't know about any automatic translation of \n to CRLF in previous versions. 9.4.6 doesn't seem to do this:

 
  b monitor http_1.1_test_monitor list 
 monitor http_1.1_test_monitor { 
    defaults from http 
    recv "200 OK" 
    send "GET / HTTP/1.1\nHost: \nConnection: Close" 
 } 
 

tcpdump shows the \n (0a) are not translated to \r\n (0d0a):

0x0030 18d5 dcf9 e6d2 22c6 4745 5420 2f20 4854 ......".GET./.HT

0x0040 5450 2f31 2e31 0a48 6f73 743a 200a 436f TP/1.1.Host:..Co

0x0050 6e6e 6563 7469 6f6e 3a20 436c 6f73 650d nnection:.Close.

0x0060 0a0d 0a ...

Annoyingly enough, two CRLF's are automatically appended to the send string regardless of whether it's legal for the specific HTTP request or not.

Aaron

hmmmmm, thanks for the input.

 

guess it's time to hit the lab for some solution updates.

 

 

Annoyingly enough, two CRLF's are automatically appended to the send string regardless of whether it's legal for the specific HTTP request or not.If you could provide some specifics, I will also look into this & include as applicable.

 

 

thx

 

/d

 

 

Hi Deb,

 

 

Thanks for checking. I got a CR for this early last year:

 

 

 

CR97857

 

 

DETAILED DESCRIPTION:

 

We add a CRLF to the user-defined send string for a http or tcp monitor. This causes problems in some cases, such as when the user defines an http post command, which should not be terminated with a CRLF. In order to supported existing behavior, where we append a CRLF to all send strings, we should add a no-crlf-append option to the tcp and http monitors so users can avoid this behavior when desired

 

 

 

 

Aaron

I got the monitor to work with SOL3224 (GET /servertest.html HTTP/1.1\nHost: \nConnection: Close\n)

 

 

 

 

Thanks everyone for your options.