From multiple external IP addresses, we receive a number TCP ACK messages, from there our internal openSUSE server with an exponentially higher volume of dup ack reply messages (I’m reading more than 700,000 reply dup ack messages from my internal host in a single session!)
Does anyone know of any bugs that might be causing so many dup ack outbound messages in a single session?
I’ve attempted to make the changes, however, my version of openSUSE 13.1 “Bottle” does not have the tcp_abc file in the /proc/sys/net/ipv4/ directory.
I can see the file exists in one of my enterprise SUSE installs.
Does anyone know if I can just create the file, or if there is a way to verify the correct location?
If you’re running openSUSE as a “real” server, you will need to modify a number of TCP parameters, including
TCP/IP Congestion Control algorithm. The default assumes end-user usage which is typically tiny files typically about 3kb in size, only a very small, limited number of connections. If you transfer large files and especially over speeds Gigabit speeds, possibly involving a network connection that’s not 802.3 (Fast Ethernet) you should change this.<br>
TCP/IP buffers. The default assumes limited connections in short bursts. If you have sustained connections, large number of simultaneous, transfer large files, etc then you need to re-allocate system resources to support these kinds of connections.
I did a write-up on this years ago for an earlier openSUSE, but all recommended settings and other changes are still applicable in 13.1 (and for the forseeable future). Should include all the info you need to know to make <intelligent> decisions.
I have tested an older version of OpenSUSE (12.1) and the TCP_ABC flag is present. I believe this flag has been removed as is no longer required, because "Linux already implements other better window protection
heuristics"1.
In my case I am still getting inbound DUP Ack attacks, however, the issue with the exponentially large number of replies from my host is fixed–and so I am able to combat the attack.
The outbound reply issue was due to, I believe, a combination of VMXNET3 drivers in the VM and a NIC issue on my VMware host.
In VMware, the primary NIC in my port group was offline and it was using the standby. Something here caused the DUP messages, I had other VMs on the same host that did not experience the issue.
So I believe it was a combination of VMXNET and the port group configuration. As soon as the offline NIC was removed from the port group the DUP error disappeared. I would not expect this behaviour, but that’s how it went…