Nickita Moroz
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER