all TCP RST packets.)Īnd this clearly showed us… nothing.
This is a command to run TCPdump, without name resolution (which can slow it down) with verbose output, to show all packets that have tcp flags, where the tcp-rst bit is set. So – what application got the RSTs? At this point, we could try to look in various log files (hoping the application in question logs this information, and logs it in a place we’d think to look) – or we can just look at the RSTs on the network.Īs this server was a linux box, we’ll use TCPdump – but you can do the same things on Windows with Wireshark. (If you really want to understand all the intricacies of TCP – and there are many, and they are good to understand – I recommend TCP/IP Illustrated, by Stevens – an oldie but a goodie.) OK, maybe that’s not the best explanation – but basically it’s saying that a TCP application sent a SYN to try to open a connection, but got a RST back. The graph line explains (via a mouse over) that it was showing “The number of times TCP connections have made a direct transition to the CLOSED state from either the SYN-SENT state or the SYN-RCVD state, plus the number of times TCP connections have made a direct transition to the LISTEN state from the SYN-RCVD.” A quick look at the graph of TCP connections show this was a new issue: OK – so what is the next step? First thing we did was see whether this was a recent change, or had been going on for a while. This could be caused by incorrect application backlog parameters, or by There are now 2.01 per second failed connections, putting the host in a warn level. Recently, one of our servers in the lab triggered this alert: The host Labutil01 is experiencing an unusual number of failed TCP connections, One relatively common case – an alert about failed TCP connections. While LogicMonitor is great at identifying issues that need attention, sometimes figuring out what exactly the solution is can be a bit harder, especially for network issues.
0 kommentar(er)
