Login  Register

Re: [FIRMWARE] Itus Networks Shield Firmware Upgrade *WIP*

Posted by Roadrunnere42 on Jun 28, 2019; 3:48pm
URL: https://itus.accessinnov.com/FIRMWARE-Itus-Networks-Shield-Firmware-Upgrade-WIP-tp1726p1786.html

Hi
It's starting to go above my knowledge level but found this git hub page about afpacket hash fault on some linux kernels, may be worth a look before spend time with afpacket-fanout

just had a look at the snort conf files and when the Shield is in bridge mode (snort_bridge.conf) it uses afpacket
config daq: afpacket
config daq_dir: /usr/lib/daq/
config daq_mode: inline
config daq_var: buffer_size_mb=300

but when in router mode (snort7.conf and snort8.conf) it uses  nfq
config daq: nfq
config daq_dir: /usr/lib/daq/
config daq_mode: inline
config daq_var: queue=7

Not sure why Itus used the two different methods, but I was told by one of there tech guys that they needed to get the Shield delivered and then sort things out with software updates.

Roadrunnere42


On Thu, 27 Jun 2019 at 18:01, Grommish [via Itus Networks Owners Forum] <[hidden email]> wrote:
Roadrunnere,

I'm beginning to suspect your assumption on why there were 2 snorts might be right.  The configurations seem identical, which you wouldn't suspect would be the case if they were actually different.

I did find some interesting things though.

If I switch from nfq to afpacket, I can span the interfaces (eth0:br-lan) and do a spread.

      PACKET_FANOUT (since Linux 3.1)
              To scale processing across threads, packet sockets can form a fanout group.  In this mode, each matching packet is
              enqueued onto only one socket in the group.  A socket joins a fanout group by  calling  setsockopt(2)  with  level
              SOL_PACKET  and  option  PACKET_FANOUT.  Each network namespace can have up to 65536 independent groups.  A socket
              selects a group by encoding the ID in the first 16 bits of the integer option value.  The first packet  socket  to
              join  a  group implicitly creates it.  To successfully join an existing group, subsequent packet sockets must have
              the same protocol, device settings, fanout mode and flags (see below).  Packet sockets can leave  a  fanout  group
              only by closing the socket.  The group is deleted when the last socket is closed.

              Fanout supports multiple algorithms to spread traffic between sockets, as follows:
              *  The  default mode, PACKET_FANOUT_HASH, sends packets from the same flow to the same socket to maintain per-flow
                 ordering.  For each packet, it chooses a socket by taking the packet flow hash modulo the number of sockets  in
                 the group, where a flow hash is a hash over network-layer address and optional transport-layer port fields.

              *  The load-balance mode PACKET_FANOUT_LB implements a round-robin algorithm.

              *  PACKET_FANOUT_CPU selects the socket based on the CPU that the packet arrived on.

              *  PACKET_FANOUT_ROLLOVER processes all data on a single socket, moving to the next when one becomes backlogged.

              *  PACKET_FANOUT_RND selects the socket using a pseudo-random number generator.

              *  PACKET_FANOUT_QM  (available  since  Linux 3.14) selects the socket using the recorded queue_mapping of the re‐
                 ceived skb.

              Fanout modes can take additional options.  IP fragmentation causes packets from the same flow  to  have  different
              flow  hashes.   The flag PACKET_FANOUT_FLAG_DEFRAG, if set, causes packets to be defragmented before fanout is ap‐
              plied, to preserve order even in this case.  Fanout mode and options are communicated in the second 16 bits of the
              integer  option value.  The flag PACKET_FANOUT_FLAG_ROLLOVER enables the roll over mechanism as a backup strategy:
              if the original fanout algorithm selects a backlogged socket, the packet rolls over to the next available one.

I was going to specify config daq_var: fanout_type=lb and config daq_var: fanout_flag=defrag, although some of the other ones might be worth looking at.  

Does anyone have any way to stress-test Snort to test for throughput?



If you reply to this email, your message will be added to the discussion below:
http://itus.accessinnov.com/FIRMWARE-Itus-Networks-Shield-Firmware-Upgrade-WIP-tp1726p1785.html
To start a new topic under Technical Discussion, email [hidden email]
To unsubscribe from Itus Networks Owners Forum, click here.
NAML