<HTML> <HEAD> <TITLE>Re: [Nagios-users] Problem with check_http and a Cisco CSS 11501</TITLE> </HEAD> <BODY> Ok, I’ve got a packet capture. There are three hosts involved: Nagios, CSS and Webserver In a normal session (one that succeeds) the sequence goes like this: Nagios -> CSS [SYN] CSS (impersonating Nagios) -> Webserver [SYN] Webserver -> CSS (impersonating Nagios) [SYN, ACK] CSS -> Nagios [SYN, ACK] Nagios -> CSS [ACK] CSS (impersonating Nagios) -> Webserver [ACK] Nagios proceeds with HTTP GET and session continues normally. The entire process takes about 0.05 seconds When I’m seeing a failure the sequence of events looks like this: Nagios -> CSS [SYN] Webserver -> Nagios [SYN, ACK] Nagios -> Webserver [RST, ACK] ... Pause 5 seconds ... Webserver -> Nagios [SYN, ACK] Nagios -> Webserver [RST, ACK] Nagios -> CSS [SYN] ... Pause until 10 second timeout is reached ... The CSS never seems to respond to the Nagios host, but the Webserver sends packets directly back to the Nagios host, apparently ignoring its default route (that points it to the CSS) Interestingly, this problem seems to only occur if the nagios daemon is running. I shut the daemon down to make the capture easier to read, and just ran the check_http command manually. For awhile I would still get failures, but eventually the command would stop failing completely. On 2/27/07 4:25 PM, "Hugo van der Kooij" <hvdkooij@vanderkooij.org> wrote: <BLOCKQUOTE> I suggest you setup a packet capture and trace the specific sessions. It should tell you exactly if the CSS is just becoming darn slow with replies or it has to do something with your server. ... I would not waste anytime on building a new server untill you know what is going on based on the packet capture. Depending on the exact CSS settings this may just be a CSS noting a DoS condition. Perhaps I need to fire up my old CSS and see what happens. (I actually still have an ArrowPoint CSS ;-) Hugo. </BLOCKQUOTE> </BODY> </HTML>