On 2015-06-29 18:57, Tantilov, Emil S wrote: >> -----Original Message----- >> From: Christian Ruppert [mailto:id...@qasl.de] >> Sent: Friday, June 26, 2015 12:34 PM >> To: Tantilov, Emil S >> Cc: e1000-de...@lists.sf.net >> Subject: RE: [E1000-devel] ixgbe and using iptables/SYNPROXY causes >> random >> system resets >> >> On 2015-06-26 21:15, Tantilov, Emil S wrote: >>>> -----Original Message----- >>>> From: Christian Ruppert [mailto:id...@qasl.de] >>>> Sent: Friday, June 26, 2015 8:43 AM >>>> To: e1000-de...@lists.sf.net >>>> Subject: [E1000-devel] ixgbe and using iptables/SYNPROXY causes >>>> random >>>> system resets >>>> >>>> Hi, >>>> >>>> we have a setup of some E3's with X520 10GE NICs (more details >>>> below) >>>> and we also use the iptables SYNPROXY[1][2] extension. >>>> Details: >>>> CPU: Different E3 Models >>>> NICs: 8086:10fb Ethernet controller: Intel Corporation 82599EB >>>> 10-Gigabit SFI/SFP+ Network Connection (rev 01) (X520-2 8086:0003) >>>> Kernel: Currently a Debian Backports 3.16.0-4-amd64 >>> >>> Just so you know we do not support backported drivers. >>> >>> If you are going to debug it - a trace from stable upstream >>> kernel will be more useful to us than a trace from a Debian kernel. >>> >>> Thanks, >>> Emil >> >> If I get anything useful at all you can get any kernel version you >> want :) >> I also tried several vanilla version btw, up to 3.18.9 at this time. > > If you can provide details about your test we may be able to attempt a > repro > in our labs. > > Thanks, > Emil
What details in particular? It seems like it can be any hardware but the NIC must be a X520 (the mentioned PCI ID/rev) and you must be using iptables >=1.4.21 and Kernel >=3.12 because of the SYNPROXY extensions. You'll have to have at least the >following iptables rules: sysctl -w net.netfilter.nf_conntrack_tcp_loose=0 iptables -t raw -I PREROUTING -p tcp -m tcp --syn -j CT --notrack iptables -I INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460 iptables -A INPUT -m conntrack --ctstate INVALID -j DROP Stuff that is IMHO rather not related: net.ipv4.tcp_max_syn_backlog=2048 net.ipv4.ip_local_port_range=1024 65535 net.core.somaxconn=40960 net.ipv4.netfilter.ip_conntrack_max=17374463 net.netfilter.nf_conntrack_max=17374463 modprobe nf_conntrack hashsize=17374463 The system has a decent amount of memory as it also acts as a loadbalancer and some caches. The traffic, as I said, is pretty common/usual, mostly HTTP(S) and some streaming stuff. It sometimes just takes some seconds/minutes, sometimes hours and sometimes days or even weeks. There must be (IMHO) some kind of a trigger (special packet or so, remote DoS) which I wasn't able to figure out yet. Even doing tcpreplays and so forth did not trigger it. -- Regards, Christian Ruppert ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
