asked on
TCP-connection related issue.
TCP-connection related issue.
We currently investigating the TCP-connection drops issue between two peers. While dumping on router we have ~120k packets per conversation (dumping about one minute). Dump on host (tcpdump) shows ~140k packets (filtering the TCP-flow in Wireshark). We don't observe any drops or congestion on interfaces of switches between two hosts. Where is the rest of packets? The connection itself related to communication of specific protocols of mobile operators, but based on TCP.
We currently investigating the TCP-connection drops issue between two peers. While dumping on router we have ~120k packets per conversation (dumping about one minute). Dump on host (tcpdump) shows ~140k packets (filtering the TCP-flow in Wireshark). We don't observe any drops or congestion on interfaces of switches between two hosts. Where is the rest of packets? The connection itself related to communication of specific protocols of mobile operators, but based on TCP.
Networking
Last Comment
David Favor
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Thanks, I will try to check all interfaces and update the post.
There should be observable retransmissions: anything on timing around those?
Any missing ARP? Did the router also dump ARP packets, or just transit.
Any problems with performance of a server?
Does logging code try to do a reverse lookup on IP addresses for names?
Lets start here and see where it goes.
Any missing ARP? Did the router also dump ARP packets, or just transit.
Any problems with performance of a server?
Does logging code try to do a reverse lookup on IP addresses for names?
Lets start here and see where it goes.
If you're talking about Linux as the send side of the TCP connection... I remember reading through recent Kernel Changelog notes about a TCP rewrite to use timing wheels, rather than send as fast as possible.
The reasoning behind this was the major TCP rewrites across the 3.18+ + 4.X Kernels had speeded up TCP so much, problems with massive retransmit storms occurred when a string of Linux machines all sending packets hit a slow machine, packets started circling the drain.
If you're using Linux for any machines involved, be sure you're running latest stable Kernel 4.20 to pickup this most recent round of TCP changes.
Might be something completely different + best to run latest Kernel, if you're working with high speed connections.
The reasoning behind this was the major TCP rewrites across the 3.18+ + 4.X Kernels had speeded up TCP so much, problems with massive retransmit storms occurred when a string of Linux machines all sending packets hit a slow machine, packets started circling the drain.
If you're using Linux for any machines involved, be sure you're running latest stable Kernel 4.20 to pickup this most recent round of TCP changes.
Might be something completely different + best to run latest Kernel, if you're working with high speed connections.
I think David is refering to this....
https://www.systutorials.com/linux-kernels/754477/merge-git-git-kernel-org-pub-scm-linux-kernel-git-davem-net-next-linux-4-15/
And the issue was very big transfer windows on high speed cards... (100Gbp)....
So 4.15+ would be sufficient.
https://www.systutorials.com/linux-kernels/754477/merge-git-git-kernel-org-pub-scm-linux-kernel-git-davem-net-next-linux-4-15/
And the issue was very big transfer windows on high speed cards... (100Gbp)....
So 4.15+ would be sufficient.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.