Discovery/Monitoring Issue

Thanks Marc.

 

 

This all looks reasonable, and it’s good to know that the ping to the F5 device would never be disrupted. I wouldn’t worry about the telnet sessions being closed on those ports after a while. That would be expected behavior, if there’s no activity going on.

 

 

From the traceroute it looks like the only hardware between the monitoring box and the F5 device is the default gateway. Is this an F5 device (Load Balancer) by any chance? What kind of equipment is it? At this point I would run a network packet analyzer (TCPdump / Wireshark) to capture the packets back and forth between the monitoring server and the F5 device, for the SSL communication. It’s possible that the disruption that we’re experiencing is a connection reset (possibly showing up as a RST flag at the TCP packet level) issued either from the gateway or the F5 device itself. It would be interesting to find out.

 

 

Here’s what I would suggest:

 

 

- Find out which network interface is used by the F5 device to communicate with our monitoring server (run the ifconfig command on the F5 device);

 

- Based on the interface, issue a tcpdump (on the F5 device), to monitor the SSL communication with the remote host (monitoring server), with a syntax similar to: tcpdump –i external host x.x.x.x and port 443 > tcpdump.log

 

- Monitor the traffic for a while, between the monitoring server and the F5 device, to capture the network disruption;

 

- Pack and zip the tcpdum.log file and send it to us (or you can also analyze it using Wireshark for example) and look for anything that may point to the RST flag and who’s initiating it (and why).

 

 

In the meantime I’ll take a look also at the Qkview dump you sent me to see if there might by anything wrong with the F5 device, that I can tell (before probably submitting it to a BigIP expert).

 

 

Thanks.

 

Julian