2

I have a situation that would like to clarify with the experts here. I am no network expert so maybe it's normal, but i rather ask.

We are trying to diagnose a problem between two servers, both are virtual servers, one is windows and the other is Linux.

What I find weird is that looking at the traffic between the two servers (as seen on the Windows virtual server by using Wireshark), is this particular sequence of TCP packets:

  1. Linux server sends a FIN, ACK
  2. Windows server responds with ACK
  3. Windows server sends a FIN, ACK
  4. Linux server responds with RST

Between 3 and 4 the Windows server sends an ARP broadcast asking for the linux server (who has "linux ip"? tell "windows ip").

I could also mention that:

  1. Linux virtual server runs on top a linux host, that has bonded interfaces presented to the linux virutal server
  2. Windows virtual server runs on top of a VMWare platform
  3. Both Windows and Linux server are in the same VLAN

So the question is; is this behavior normal or is there something we should look into?

Here is an image of the log file; .46 is the Linux server and .167 is the Windows server. Wireshark capture

Patricio Téllez
  • 19
  • 1
  • 2
  • 1
    Probably OK, but what is the original problem you're troubleshooting? – Ron Trunk May 04 '16 at 15:55
  • I'm fairly sure this is an intentional (but practically harmless) violation of the spec in Linux, but I don't have the reference to hand. – Michael Hampton May 04 '16 at 16:03
  • We are trying to find the root cause of some low performance issues on a BPMS server installed in the Windows machine. The problems seems related to the interaction with the ECM server (Alfresco) on the Linux machine, so we took a look into the comunication between the two. We only found this that could be labeled as "weird", but since it's a closing connection, it should be harmless. Anyway I wanted to be sure and asked for some help here... – Patricio Téllez May 04 '16 at 18:13
  • Odd is that there are 45s between FIN/ACk and ARP and RST – eckes Oct 22 '17 at 04:15
  • The sequence numbers are important here, they could be duplicate acks due to one side not getting the message. My guess is that Linux server is sending a reset because it’s getting a fin to a connection it views as already closed bur that’s wild speculation with better data. Can you take a screenshot of the capture and add to your question? – Nath Mar 28 '18 at 02:42

2 Answers2

0

You should check you linux TCP setting, especially: net.ipv4.tcp_fin_timeout. The default value is 60s. Your system might have different value. After step 2), Linux will mark this connection as "FIN-WAIT-2", and will auto-close it after 60s (based tcp_fin_timeout). if your step 3) is late than 60s, Linux server will NOT be able to return ACK to close connection gracefully because it has been shutdown, so RST will be returned.

ScottWu
  • 1
-1

Finally we didn't see a problem in this behaviour and we looked to a full capture of the use case and this only appeared on the end of the test, not during it. So I guess that's only weird but not a real problem.

What we finally did was export the Wireshart capture to a PDML file, and we parsed that with a program we built to analize and correlate information using the TCP Streams. With that we were able to know how long a server took to respond to a HTTP request, and that helped a lot to get some insight of the root problem.

Patricio Téllez
  • 19
  • 1
  • 2