Capture

Capture, Analytics, and Solutions

scottcschweitzer Capture, networking

My first co-op job at IBM Research back in 1984 was to help roll out the IBM PC to the companies best and brightest. It wasn’t long into that position, perhaps a month, when we noticed a large number of monochrome monitors had a consistent burn-in pattern. A horizontal bar across the top, and a vertical bar on the left. Now I was not new to personal computers having purchased my own TRS-80 Model III a year earlier, but it was apparent that a vast number within Research were all being used to do the same thing. So I asked, VisiCalc (MS Excel’s great-grandfather).

At the time personal computers were still scarce, and seeing one outside a fortune 100 company was akin to a unicorn sighting, so the subtlety between tool and solution was lost on this 21-year-old brain. Shortly after the cause of the burn-in was understood I had the opportunity to have lunch with one of these researchers and discuss his use of VisiCalc. That single IBM PC in his lab existed to turn experimental raw data that it directly collected into comprehensible observations. He had a terminal in his office for email, and document creation, so this system existed entirely to run two programs. One that collected raw data from his lab equipment, and VisiCalc, which translated that data into understandable information which helped him make sense of our world.

Recently Solarflare began adding Analytics packages to their open network packet capture platform as they ready it for general availability later this month. The first of these packages is Trading Analytics, and it wasn’t until I recently saw an actual demo of this application that the real value of these packages kicked in. The demo clarified for me this value much like the VisiCalc ah-ha moment mentioned above, but perhaps we need some additional context.

Imagine a video surveillance system at a large national airport. Someone in security can easily track a single passenger from the curb to the gate, without ever losing sight of them, now extend that to a computer network where the network packets are the people. The key value proposition of a distributed open network packet capture platform is the capability to gather copies of what happened at various points in your network while preserving the exact moment in time that that data was at that location. Now imagine that data being how a company trades electronically on several different stock exchanges. The capability to visualize the exact moment when an exchange notified you that IBM stock was trading at $150/share, then it updated you every step of the way showing you the precise instant that each of the various bits in your trading infrastructure kicked in. The value of being able to see the entire transaction with nanosecond resolution can then be monetized, especially when you can see this performance over hundreds, thousands or even millions of trades. Given the proper visualization and reports, this data can then empower you to revisit the slow stages in your trading platform to further wring out any latency that might result in lost market opportunities.

So what is analytics? Well, first it’s the programming that is responsible for decoding the market data. That means translating all the binary data contained in a captured network packet into humanly meaningful data. While this may sound trivial, trust me it isn’t, there are dozens of different network protocol formats and hundreds of exchanges worldwide that leverage these formats so it can quickly become a can of worms. Solarflare’s package translates over two dozen different network protocols, for example, NYSE ARCA, CME FIX and FAST into a single humanly readable framework. Next, it understands how to read and use the highly accurate time stamps attached to each network packet representing when those packets arrived at a given collection point. Then it correlates all the network sequence ID numbers and internal message ID numbers along with those time stamps so it can align a trade across your entire environment, and show you where it was at each precise moment in time. Finally, and this is the most important part, it can report and display the results in many different ways so that it easily fits into a methodology familiar to its consumer.

So what differentiates a tool from a solution? Some will argue that VisiCalc and Solarflare’s Trading Analytics are nothing more than a sophisticated set of fancy hammers and chisels, but they are much more. A solution adds significant, and measurable, value to the process by removing the mundane and menial tasks from that process thereby allowing us to focus on the real tasks that require our intellect.

Next Generation Network (NGN) Forensics

scottcschweitzer Capture, networking, Security

In two weeks I’ll be hosting two events: one near the NSA at the Courtyard Fort Meade on the 27th, and the second a few miles from the CIA at the Hilton Mclean Tyson Corner. Both will start at 4 PM, have a considerably strong Network Forensics agenda, and then wrap up by 7 PM. Both events are identical, they’re free to attend, and we’ll be providing beer, wine & soda along with appetizers.

Below is the current agenda, but it’s still somewhat fluid at this point as it’s the first NGN we’re doing that is focused on Network Forensics, and is setup for the Intelligence Community. The dozen or so prior NGNs, and another later that week have been centered on the Financial Trading market where our leadership in low latency is well known. Here is the current agenda:

  • 3:30 – 4:00  Registration, drinks and snacks
  • 4:00 – 4:05  Welcome & Introductions – Paul Bravo, Solarflare VP US/OEM Sales
  • 4:05 – 4:35  Keynote Speaker – David Riddoch, Founder, Solarflare
  • 4:35 – 4:50  Dell – Cameron Chehreh, CTO Federal
  • 4:50 – 5:35  Panel: Deep Packet Inspection (Snort, Suricata & Bro)
  • 5:35 – 5:45  Reservoir Labs – Alison Ryan, VP Business Development
  • 5:45 – 6:15  Advances in Capture – Ron Miller, Director Technical Marketing, Solarflare
  • 6:15 – 6:45  Open Q&A of all speakers
  • 6:45 – 7:30  Reception & Demonstrations

I’ll moderate the panel on Deep Packet Inspection which will include:  Eileen Donnelly, US Government, Erik Mogus Director Sales Engineering for Reservoir Labs, and someone to be named shortly. The purpose of the panel is to compare and contrast the different approaches to packet inspection so someone familiar with one can see different perspectives on the other two.  The audience will also be encouraged to ask questions of the panelists.

To sign up for either event please use one of the links below:

Tuesday, October 27th l Time: 3:30-7:30 PM
Courtyard Marriott Fort Meade, 2700 Hercules Rd, Annapolis Junction, MD
Click to attend
Wednesday, October 28th l Time: 3:30-7:30 PM
Hilton McLean Tysons Corner, 7920 Jones Branch Drive, McLean, VA
Click to attend

 

Cookbook: Installing & Updating SolarCapture on CentOS

scottcschweitzer Capture, networking

By: Justin Borland, Equifax

Below is a document describing how to update/install Solarflare’s SolarCapture drivers on the SolarFlare 71xx NICs for a CentOS system. Note this document was user created and has not yet been reviewed by Solarflare’s Technical Support.

Requirements:
First, acquire the following software from Solarflare support:

Implementation steps:
SolarFlare SDK install:

# unzip solar_capture_sdk-.zip
# rpm –Uvh sfutils-*.rpm

OpenOnload build:

# tar –xf openonload-.tgz
# cd openonload-
# onload_uninstall && ./scripts/onload_install

Note that if any capture processes are already running (i.e. Moloch, Bro, Snort or Suricata) kill them before reloading, and keep them off until the end of this install.

# onload_tool reload
# cd ..

SolarCapture Core installation:

# rpm –Uvh solar_capture-core-.rpm

SolarCapture Python install:

# yum install rpm-build
# rpmbuild –rebuild solar_capture-python-.src.rpm
# rpm –Uvh /root/rpmbuild/RPMS/x86_64/solar_capture-python-.rpm

SolarCapture Pro installation:

# rpm –Uvh  –replacepkgs solar_capture-live-.rpm solar_capture-pro-.rpm

Update the NIC firmware

# sfupdate –write

Note that you should answer ‘Y’ for each NIC.

Restart capture services

# /wherever/your/capture/script/lives_start.sh


Verify Install:
Check installed packages

# rpm –qa | grep capture

You should now see this:

solar_capture-core-1.3.1.11-0.x86_64
solar_capture-pro-1.3.1.11-0.x86_64
solar_capture-python-1.3.1.11-0.x86_64
solar_capture-live-1.3.1.11-0.x86_64

Check NIC licensing

# sfkey

Which should then look like this:

2-interface adapter: eth4, eth6
Product name:        Solarflare SFN7122F SFP+ Flareon Ultra Server Adapter
Part number:         SFN7122F
Serial number:       712200210071141137100559
MAC addresses:       00-0F-53-xx-xx-xx, 00-0F-53-xx-xx-xx
Installed keys:      Onload
Active keys:         Onload
Blacklisted keys:    0
Invalid keys:        0
Unverifiable keys:   0
Inapplicable keys:   0

One final note, Solarflare Support has not yet validated the above steps so please use at your own risk.

Performance 10GbE Capture & Time Stamping

scottcschweitzer Capture

From the Sony to Park-n-Fly, we’re seeing the impact data breaches can have on corporations. Towards that end, many companies are beginning to consider looking at all the data that both enters & leaves their enterprise in an attempt to thwart breaches as they occur. At the heart of this effort lies wire-rate lossless 10GbE capture. Furthermore, some customers are seeking highly accurate time stamps on all captured packets so performance can be measured, and issues can easily be tracked and collated across an enterprise against the backing of a solid, trusted temporal (time-based) infrastructure. So to capture both received and transmitted packets on two 10G interfaces in parallel, and with time stamps you only have one choice for those looking for an adapter/software bundle under $5K and that is Solarflare’s SFN7142Q-SCP. This is Solarflare’s SFN7142Q adapter with a PPS bracket kit, a Precision Time Protocol (PTP), and a SolarCapture Pro license. Note you will need to order a pair of QSA modules separately, due to agency certification issues.

So why has Solarflare gone to the trouble of bundling together all of these parts? Simple, to make it easier for potential customers to try out precision packet capture with highly accurate time stamps. Let’s take a moment, and decompose this bundle into its component pieces to fully appreciate why this is so important.

First, we’ll start with the network server adapter, the Solarflare SFN7142Q. This board is driven by a single Solarflare dual core ethernet controller chip. Each ethernet controller core on this chip has multiple packet engines for both receive and transmit queues. This enables the adapter to support wire-rate lossless packet capture even with huge bursts of the smallest sized packets (64 bytes each). Furthermore, this adapter has the capability to also transmit wire-rate 64-byte packets at the same time, on the same interface. Solarflare’s capture bundle also includes the PPS (Pulse Per Second) bracket kit that provides the necessary mini-BNC connectors that attach the adapter to an external master clock. Unlike similar adapters, there is also a second mini-BNC connector to support daisy chaining the clock signal out of the adapter into another adapter. The SFN7142Q includes a highly precise clock chip, the Stratum 3, this ensures that time stamping is accurate to within 50 nanoseconds from the PTP master. This is 30X more precise than a competing adapter that only captures and time stamps inbound packets.

While the SFN7142Q sports two 40GbE QSFP ports, to ensure wire-rate lossless packet capture Solarflare provides two QSA modules (which you must order separately) that convert the QSFP socket into 10G SFP+ sockets. This enables each of the two ethernet controller cores on the adapter to each focus on a single 10GbE interface.

Three software license keys are preloaded in the SFN7142Q adapter, and they are OpenOnload (OOL), Precision Time Protocol (PTP), and SolarCapture Pro (SCP). OpenOnload is Solarflare’s user space stack that permits it to do a zero copy bypass of the operating system, and place the captured data directly into the memory connected to the core processing that particular data flow. Precision Time Protocol is a method whereby the external pulse per second master clock can be rationalized to the real time of day then distributed to other applications or servers. Finally, we have SolarCapture Pro. When it comes to capturing, SolarCapture Pro is arguably the best. Unlike some other solutions it also captures transmitted packets and can time stamp both in-bound & out-bound packets, all features only found in higher priced FPGA based solutions. Also, SCP can be initialized in cluster mode to spawn multiple capture instances, one per core delivering the data in Libpcap format, then flow-hash the data across all of the cores within the cluster. Flow-hashing is the process of looking at several key fields in the packet header then routing all the traffic from a given source & destination always to the same core so security applications like Snort, Bro & Suricata see all the data for a given network flow.

So if you’re looking to get into packet capture for performance monitoring, or security programs please consider contacting Solarflare, and asking about their SFN7142Q-SCP. You’ll be pleasantly surprised how it performs when compared to much more expensive FPGA based solutions. Finally, in a future post, we’ll talk about Capture SolarSystem that leverages all the above to deliver an appliance tuned for high volume packet capture.

Building a Mobile 10G Capture Platform

scottcschweitzer Capture, networking

Someone asked Tuesday if there exists a mobile platform for capturing traffic on a 10GbE link for analysis in real time. Although I’d not heard of anyone selling such a device or bundle I thought it might be an interesting exercise to outline the parts required, estimate the cost, and review what one might need to install.  Note this is all theoretical as I’ve not the parts or the lab at this time to test this out. Also, and this is important, everything below could also be used to build an inexpensive packet generator for network testing. Here are further instructions for doing this activity as well.

With regard to equipment, the first criteria would be a laptop with a high-performance Core i7 processor with plenty L3 cache, considerable main memory, and sporting at least one Thunderbolt port. I’m partial to Apple platforms, but recently HP and others have jumped on the Thunderbolt bandwagon.  Here are several options:

  1. Apple Macbook Pro 15″ with Retina Display, 2.8Ghz, Quad-core Intel Core i7, Turbo boost up to 4Ghz, 16GB memory, 1TB PCIE Flash disk. $3,199 from Apple.
  2. HP ZBook 15″ with Quad-core Intel Core i7-4800MQ, 32GB memory, 256GB SATA Flash Drive. $3,810 from CDW.
  3. Lenovo Thinkpad W540, 15.6″ display, Intel Core-i7-4700MQ, 8GB of memory, 500GB of disk, from Lenovo for $1,119.
While the Apple platform has only half the memory it has four times the disk, with a high-speed PCIe flash interface that is considerably faster than the SATA interface used by HP, so all things should balance out. I added the Lenovo as it too has a Thunderbolt interface, but with only 8GB of memory, and a spinning disk the overall system performance with regard to capture will be impacted, consider this the solution on a budget. After some additional checking the Thinkpad W540 can be easily be upgraded to 16GB for $166. Since this system has four memory sockets you can actually buy two of these kits and run it up to 32GB, which for what would then be a $1,500 laptop would be pretty sweet.
Next, we need an enclosure with an internal PCIe interface to house a 10GbE capture card.  My favorite is the mLogic mLink which sells for $399, and can be purchased from several resellers or directly from Apple.  This enclosure has a PCIe 16 lane socket inside, but only 4 lanes of PCIe Gen2 are actually wired up, which is fine. Thunderbolt is a 10Gbps connection and 4 lanes of PCIe Gen2 is theoretically 16Gbps, but after overhead is more like 12Gbps.
For a capture card, I’d use the Solarflare SFN7122F which can be purchased from CDW for $1,055. This is a dual port 10G card that includes the necessary Open Unload license so you can also run Solarflare’s SolarCapture Pro capture driver (SFS-SCP) which is also available from CDW for $233. Finally, if you want to leverage accurate time stamping of packets via Precision Time Protocol you should buy a PTP (SFS-PTP) license also from CDW for $194.
Finally, every Boy Scout knows you should always be prepared & carry you own two meter 10GbE Direct Attach cable, also $82 from CDW. Ok, now for setup…
First, install Linux on the laptop, these are the supported versions of the capture driver: RHEL 5 & 6, SLES 10 & 11. I’d suggest something with a 2.6.32 or newer kernel.
After making yourself comfortable with the system, installing optional stuff, customizing, updating everything, etc…  You’ll need to visit the SolarCapture support page at Solarflare to install the capture driver & supporting code. First, you need to install Open Onload 201310-u1 or newer. I’d suggest at least 201405-u1. For good measure, I’d also install the Linux Utilities RPM on this page (version 4.1.2.1009 or newer).  Finally, there is the SolarCapture SDK (version 1.3.0.31).  All this covered in the SolarCapture Pro User’s Guide (SF-108469-CD) which can also be found on the same webpage. That includes setting up and configuring the software.
So for roughly $5K you can build a pretty robust mobile workstation that can record 10G traffic at wire-rate…

Trick or Treating and Why Failing Open is Failing Safe

scottcschweitzer Capture, networking

This article was originally purchased in October of 2012 on 10GbE.net.
Revised on 11/1 with additional technical details found at the end.

Tomorrow children across the US will be going door to door begging for candy, my teenager will be one of them.  Suppose you weren’t home, would you appreciate it if they let themselves in, and rummaged through your home looking for treats?  How about if they also stole your extra front door key, and used your home to party whenever you weren’t home. This is what botnets do. Some years ago it was demonstrated that a new “out of the box Windows PC” without updates survived exactly 20 minutes when attached directly to the Internet.
 
Some network hardware vendors consider this approach acceptable.  They’ve gone to great lengths to design hardware so that when the server dies the network “fails-closed” (in the electrical sense) meaning that traffic continues to flow through the network unchecked.  Now if this approach was used to enhance the networking experience, perhaps traffic shaping or load balancing, I could see how this might be a selling point. What we need to avoid is having engineers design security appliances that “fail-closed”. Security adapters should always “fail-open” or “fail-safe”. Today unknowingly our firewalls, and systems are probed & assaulted hourly as pawns in a cyber war waged by individuals, corporations & nation states. I bring this up because we recently came across a line of Intrusion Prevention Systems (IPS) that offered this as a feature, seriously.
 
Imagine you hire a doorman to increase the safety of your home, and early on Halloween evening he dozes and falls off the porch into the bushes sound asleep. This is “failing-closed”. I’d rather if my doorman was to fall asleep that he slumped against the door totally blocking entry “failing-open” or “failing-safe”. How does your 10GbE IPS or IDS fail?
 
Additional Technical Details
I’ve been asked how “failing-closed” actually works. The simple analogy is a single lens reflex camera. These are the big bulky cameras that professional photographers have used for decades. How they work is simple, light enters through some very expensive lenses on the front of the camera. A mirror reflects that light up to an eye piece so you can compose your picture. When the camera is on, and you depress the shutter release that mirror quickly flips out of the way to expose your film or the CCD in your digital SRL, then the mirror flips back much like the shutter in even older style cameras.
 
With network adapters that fail open consider the first network port as the lens and the second network port as the eye piece. When the card is powered off it is in bypass mode, “failing-closed”, a mirror (actually an optical MEMS) takes the light entering the first port and sends it to the second and vice-versa. When the network adapter is fully powered on, and the drivers have all successfully loaded the mirror can be flipped open and the 10GbE ASIC chip sees all the traffic and can selectively pass traffic back and forth between the ports. It can also send traffic up to the server, and the server can then send traffic out one or both ports. It’s a very flexible approach, but the use case is not very common and the cards are often priced five times higher than competing dual port cards.
 
Thanks to Gary Archer from Emulex for suggesting this topic.

Can Your Arista Switch Capture User Traffic

scottcschweitzer Capture, networking

This article was originally posted in October of 2012 at 10GbE.net. 

This falls into the category of “just because you can do something it doesn’t mean you should.” First I welcome comments from the folks at Arista Networks and will update this entry accordingly as I learn anything new.

Next, I’d like to set the stage a bit. Myricom makes a lossless packet capture driver, Sniffer10G, designed to run on our 10GbE network adapters. Recently several people have said that Arista switches have a similar function, and why shouldn’t they just capture and analyze all the user traffic right on the switch. On the surface, this appears a very reasonable question.
Switches have two basic types of data that flow into and through them: user packets & management packets.  User packets are what make up emails and the stuff we see in our browsers, like this blog entry, these are also called data plane traffic.  Management packets, know as control plane traffic, are used to configure networks and tell switches how to route packets, rules to follow, etc…
 
A switch administrator can easily install the program TCPDump on EOS, the operating system that runs on an Arista switch, and quickly capture and analyze these management packets.   This will NOT by default allow them to capture and analyze user traffic.  This can be done though.  Since EOS is Linux based, and Arista permits external programs to be installed on the switch Arista has created a recipe for accessing and capturing user traffic as well. For the adventurous, I’ll attach that link below.
 
It should be noted though that they strongly warn against doing this on a production switch as it can quickly consume the CPU of the switch, which is not a good thing.  In Arista’s example, they are only sampling 1 out of every 16,383 packets (that’s 0.006% of the traffic) and they mention that the impact on the host CPU is significant and warn against doing it on a switch with more than 50Mbps of total traffic.
 
So yes you can do this, but again it is not recommended for a production switch, and frankly, if you’re only looking at 6/1000ths of 1% of the traffic what’s the point? Configure your Arista switch with a spanning port and connect a Myricom or Emulex 10GbE adapter with FastStack Sniffer10G. Then you can look at ALL THE TRAFFIC at 200X the Arista recommended maximum data rate suggested above.
 
One final note, the newest line of Arista Networks switches includes FPGA technology. If the FPGA is properly programmed, a non-trivial effort, then their capture and analysis performance could be substantially improved.
 
Here is the Arista link covering Collection and Analysis:
 

Black Hat USA 2012 – Emulex FastStack Sniffer10G Product Demo Shows 2x Suricata Performance Gain

scottcschweitzer Capture, networking, Security

This article was originally published in July of 2012 at 10GbE.net. 

At Black Hat USA this week at Caesars Palace in Las Vegas, Emulex & Myricom will be demonstrating Sniffer10G as it greatly improves Suricata performance by a factor of two. Suricata is a high-performance open source application for creating an intrusion prevention (IPS) or intrusion detection system (IDS). Snort is the leader in this space, but Suricata is the popular new application looking to capture early and mass adoption. While Snort was designed as a single threaded application, Suricata was built from the ground up to support multi-core servers. Sniffer10G takes this one step further, leveraging the processor found on Myricom and Emulex NX adapters to provide multiple capture buffers that can then be pinned to specific CPU cores.

This blog entry specifically outlines how to accomplish a 2X performance improvement for Suricata by using to Sniffer10G. First, you will need to purchase a high-performance dual port 10GbE adapter with Sniffer10G: Myricom dual port 10GbE (P/N 10G-PCIE2-8C2-2S+SNF2) or an Emulex NX adapter (P/N OCe12102-DX-SNF2). One of these cards is required to run Sniffer10G which is also required for performance gain. Both adapters can be purchased for $1,000.00.  This price includes Sniffer10G software. 
For the sake of this posting, we will assume you know how to install the server, the network adapter, and the OS. Prior to deployment, and for testing purposes only we will use a single DA cable to connect together both 10GbE ports. Also, make sure a gigabit ethernet port is connected to the independent server so we can download the software and a test suite. 
 
If you’ve not already downloaded Sniffer10G, then contact help@myricom.com and request a userid and password to access this product. Once downloaded issue the following command to install the product:
# rpm -i myri_snf-2.0.6.50271-2831.x86_64.rpm
 
This should put all the interesting stuff in /opt/snf. At this point, you should validate that you have purchased a card with the Sniffer10G license and that it’s ready to go. To do this issue:
 
# /opt/snf/sbin/myri_license
 
and it should return something similar to this: 
 
2 boards found
NIC 0 serial = 423691
License keys:
395e-e403-6a05-1a8f:2:423691:SNF:V2: # SNF, V2
NIC 1 serial = 423691
License keys:
395e-e403-6a05-1a8f:2:423691:SNF:V2: # SNF, V2
 
The reason it says two boards found is that each port is treated as a separate adapter. Next, you should confirm that the Sniffer10G code is running. The command to do this is myri_start_stop, you can use start, stop or restart. 
 
# myri_start_stop restart
Restarting Sniffer10G
Removing myri_snf
Loading myri_snf
 
Next, confirm that the system thinks things are ok by checking dmesg:
 
# dmesg | grep myri_snf
…
myri_snf INFO: 2 boards found and initialized
myri_snf INFO: eth4: Link0 is UP
myri_snf INFO: eth5: Link0 is UP
 
Now let’s confirm that traffic can pass easily between the ports. Here you’ll need two console windows open to your server, let’s call them Window-A and Window-B. On Window-A run the following command, it will setup your first port to receive traffic forever from the second port:
 
# /opt/snf/bin/tests/snf_simple_recv -p0 -t 1
snf_recv ready to receive
 
On Window-B run this command to generate one billion 60 byte packets on port 1:
 
# /opt/snf/bin/tests/snf_pktgen -p1 -s 60 -n 1000000000
 
Now in Window-A, you should see traffic along the following lines:
 
8650979 pkts (519058740B) in 1.001 secs (8641948 pps), Avg Pkt: 60, BW (Gbps): 4.148
14892539 pkts (893552340B) in 1.001 secs (14876784 pps), Avg Pkt: 60, BW (Gbps): 7.141
14894309 pkts (893658540B) in 1.001 secs (14878894 pps), Avg Pkt: 60, BW (Gbps): 7.142
…
 
Use Ctrl-C in both windows to stop things and in Window-B you should see:
 
Size Mbps Mpps Efficiency
60 7141.26 14.878 99.98%
 
This confirms that Sniffer10G is setup and working perfectly. Now on to Suricata.
 
Here are the steps to install Suricata, and build in the Sniffer10G libraries, note I’m not showing the output of the commands because it can be extensive:
 
 
# yum install file-devel
 
# tar -xvzf suricata-1.3.tar.gz
 
# mv suricata-1.3 suricata
 
# cd suricata
 
#./configure –with-libpcap-includes=/opt/snf/include/ –with-libpcap-libraries=/opt/snf/lib/ –prefix=/usr –sysconfdir=/etc –localstatedir=/var
 
# make
 
# make install-full
 
# cp classification.config /etc/suricata
 
# cp reference.config /etc/suricata
 
# cp suricata.yaml /etc/suricata
 
At this point we should confirm where Suricata is and if it was in-fact built with Sniffer10G. To do that use the following commands:
 
# which suricata
/usr/local/bin/suricata
# ldd /usr/local/bin/suricata | grep snf
libpcap.so.1 => /opt/snf/lib/libpcap.so.1 (0x00007f4359199000)
libsnf.so.0 => /opt/snf/lib/libsnf.so.0 (0x00007f4358b53000)
 
Now you need to edit your “suricata.yaml” file to make use of Sniffer10G. Suppose you have a dual socket system with eight cores per socket, you can then change your “suricata.yaml” file’s pcap section to look like this:
 
pcap:
– interface: eth4
threads: 16
buffer-size: 512kb
checksum-checks: no
 
We are assuming here that eth4 is your snf0 interface, you’ll need to confirm the actual interface names using “ifconfig”. Now to start Suricata and leverage all 16 cores, each with their own 512KB buffer use this command:
 
# SNF_NUM_RINGS=16 SNF_FLAGS=0x1suricata -c /etc/suricata/suricata.yaml -i eth4 –runmode=workers
 
For now, since the same system is both generating traffic and consuming it you should consider cutting this number back to 8 or 12 cores instead of all 16. During our testing, we typically use two systems connected back to back so we’ve not had to balance generation and consumption on the same system. 
 
This above command will start Suricata up, but the problem is where do you get traffic from. If you use Window-A for starting Suricata and Window-B for generating traffic then in Window-B we should first download some reasonable traffic. To do this use the following command from your home directory:
 
 
# mv 54 example.com-3.pcap
 
Then once suricata is running to generate test traffic you can use:
 
# /opt/snf/bin/tests/snf_replay -v -p0 -R 0.18 -i 2500 example.com-3.pcap
Thread 0> Packets: 5122500
Thread 0> Bytes: 1660497500
Thread 0> Rate: 0.27 Mpps
Thread 0> Throughput: 0.695 Gbps in 19.122 secs
 
Attached are three command output files:
 
 
and the two Suricata configuration files that were used for our testing:
 
 
These prove out the 2X performance improvement mentioned in the opening paragraph. It is possible to see gains well in excess of 2X, but those require additional tuning and tweaking of the suricata.yaml file beyond what was discussed above.