[Oisf-users] af_packet and rss queue count

[erik clark]

If you set a symmetric queue (posted elsewhere in some thread), I believe
you do not see issues with reordering. We have seen output from pf_ring and
af_packet as being near identical in logged connections, events, so unless
pf_ring is also mangling connectings the same way as if_packet/AF_PACKET,
we can assume this is a non-issue. Packet loss is actually substantually
lower for both suricata and bro using a symmetric key, proper udp/tcp
hashing, and af_packet compared to pf_ring on identical hardware. It comes
at cost of cpu over memory however.


On Thu, Jan 26, 2017 at 9:56 AM, Seth Hall <seth at icir.org> wrote:

>
> > On Jan 26, 2017, at 8:29 AM, erik clark <philosnef at gmail.com> wrote:
> >
> > This is going into RHEL7.4, which is a 3.10 branch. We will be staying
> on RHEL7 as we have a full support contract with them, and to be honest,
> their engineers are amazing.
>
> I would still be concerned about the packet reordering issue coming from
> the NIC with having multiple queues enabled.  This appears to be an actual
> hardware behavior and not fixable through software.  The effects from it
> can be fairly hard to discern too, but you may see an inflated capture_loss
> (in Bro, I forget what the Suricata equivalent is called) due to the packet
> reordering.  It can also more directly effect things in UDP DNS query and
> reply matching.
>
> Sorry for the Bro stuff on the OISF mailing list, but I thought it was
> relevant since Erik is running Bro as well as Suricata on his system and I
> assume that Suricata would also have the same or similar issues with
> reordered packets.  It's not an easy problem to diagnose.
>
>   .Seth
>
> --
> Seth Hall
> International Computer Science Institute
> (Bro) because everyone has a network
> http://www.bro.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20170126/9c5e78fe/attachment-0002.html>