<div dir="ltr">Thanks, I will give that a try after I work on filtering out all the regular high volume flows I can find. That has to be the problem.. it makes sense now and I feel exceedingly stupid for not addressing it first. (trying to analyze all traffic...) Whenever we meet you are owed food and drink, or shoot me your paypal. At least I have a good sense of failure conditions now. :> I wonder about current DoS attack methodology on multi-core IDS systems and the associated flow hashing algorithms... what is the minimum volume required and how many flows launched to affect x out of y cores on an IDS to cause partial blindness ? (It is relative to the core speed) Does anyone see such behavior ? I've not heard or read about IDS evasion topics for a long time. I can sleep now...<div>
<br></div><div>--TC</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 14, 2013 at 11:24 PM, Cooper F. Nelson <span dir="ltr"><<a href="mailto:cnelson@ucsd.edu" target="_blank">cnelson@ucsd.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div>You don't have enough memory, you need at least two gigs per core. On<br>
my sensor I have three, so I run with deep ring buffers. So, you need<br>
at least 96 gigs of RAM on your system (I see you have 64 from the top<br>
printout). Try setting your ring size small (like 50000) or getting<br>
more memory.<br>
<br>
Did you restart irqbalance after you updated the driver? I've had a<br>
similar issue in the past that was fixed by restarting irqbalance.<br>
<br>
IF you really have a limit of 32 RX queues, there is an easy fix for<br>
this. Just set the 'threads' section in af-packet mode to '32' and it<br>
will use the first 32 cores only. This will also fix your memory<br>
issues, as only 32 ring buffers will be allocated.<br>
<br>
- -Coop<br>
<div class="im"><br>
On 8/14/2013 11:03 PM, Tritium Cat wrote:<br>
> I tried all of your recommendations and performance is worse. Short of<br>
> having the exact same server and single card there's nothing else I can<br>
> match exactly.<br>
><br>
> ring-size=300000 exhausts memory and swap. Even ring-size=100000 is taxing<br>
> on the system and consumes 56GB ram.<br>
><br>
> Also updated ixgbe to latest version as recommended on the blog. Not sure<br>
> if this is connected but oddly it seems now I am reaching a limit of 32<br>
> CPUs/queues with unused cores at 100% idle. I think there are some errors<br>
> on the blog too with the ixgbe parameters and expectations of queues but<br>
> that is besides the point. (FdirPballoc is for hardware filters and not<br>
> relevant here?)<br>
><br>
> I cannot explain the feeling of how old this is becoming especially when<br>
> all others seem to have success. I guess maybe the answer must be<br>
> filtering out lots of traffic however the traffic profile is definitely<br>
> less than the 1M to 1.5M pps mentioned in the blog. (The blog server is<br>
> less powerful too?)<br>
><br>
> For now I will just be happy with dropping 10-40% and restarting the IDS<br>
> daily, a half working IDS is better than no IDS :p<br>
><br>
> Thanks for the detail it is still helpful. Better luck tomorrow !<br>
><br>
> --TC<br>
<br>
</div><div class="im">- --<br>
Cooper Nelson<br>
Network Security Analyst<br>
UCSD ACT Security Team<br>
<a href="mailto:cnelson@ucsd.edu">cnelson@ucsd.edu</a> x41042<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.17 (MingW32)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
</div>iQEcBAEBAgAGBQJSDHQlAAoJEKIFRYQsa8FW52cH/Ra9hCCkaILihWKhpIozi7Fh<br>
phjTjJckrsPjOAbtHmUvQmA/JY+D4rY3POyLWOgTsoeXdYOXqPs4dLkpSZtGwND0<br>
NLLz5IBDzQk5GRzqryAKbb9q3SXm+c4bOdc6ML/7sTVhfSNDHCjVygzynubHMVbz<br>
6asVSeXUtiEj6OlCtOMlB2B6eJfeYb+lFwpIonK2JZeBI5EgSkhUPj0JNsZLrSsP<br>
Nu+eEFi37kG0YwoqgYvVcTOWkHRNLgd88e0DsaqraM7sVfJ3GGd11IL6aHwk8riF<br>
xLRhiFoyD5sCIHgB7yzEwHJtgHkRGkJ+JAmQ6tWGMkvZmx/i7uZG0cQgM6+TDQE=<br>
=lg89<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div>