Resolving mismatch between SNMP and packet based traffic stats

Daily traffic totals as seen from Trisul

We recently encountered an interesting problem with a leading cloud based financial services provider who uses Trisul for deep monitoring of application and bandwidth usage. Hope this helps other folks facing a similar problem.

The problem

Our customer is a cloud based financial services company which  buys bandwidth in bulk from an upstream provider. The upstream provider gives them rough SNMP based traffic reports for each day.  From their end,  the financial services company uses Trisul to break up the traffic and provide much more fine grained reports to their end users. The problem was that the SNMP based numbers did not match Trisul’s packet based numbers. Trisul always showed a 3%-4% smaller number daily. For their volumes this added up to $80 daily.

What happened to the missing packets

We banged our heads for a couple of days trying to figure out what was going on. We confirmed the following

  • Trisul wasnt dropping any packets (even at a moderately high sustained rate of 30-40,000 pps) – neither was the kernel.
  • Trisul was in inline mode w/ hardware bypass, not hanging off a tap or span.
  • The cable directly connected the switch from upstream end to Trisul
  • The cable was brand new in a high quality data center

It turns out the SNMP stats were produced by polling the ifHCInOctets/ifHCOutOctets counters in mib-2 interfaces group.  For Ethernet interfaces this is what RFC 3635 says.

The Interface MIB octet counters, ifInOctets, ifOutOctets,

ifHCInOctets and ifHCOutOctets, MUST include all octets in valid frames sent or received on the interface, including the MAC header and FCS, but not the preamble, start of frame delimiter, or extension octets.

 

Note that the 7 byte preamble + 1 byte SFD isnt included, just the 4 byte CRC.

Trisul of course did not see the CRC because we were relying on the PF_PACKET mechanism to supply packets.  Once we added the 4 bytes to every packet we found that the numbers tallied.

How to compensate for FCS

We find that only folks who use Trisul to check or implement billing care about matching the SNMP counters. So we introduced a new option on a per interface basis called AddEthernetFCS.  This is disabled by default. When enabled it will add 4 bytes to the reported packet length. To use this option Login as admin and select Manage Capture Profiles > Select an interface > Enable the AddEthernetFCS option.

————————

 

 

Trisul Network Analytics is an exciting new platform for gaining excellent visibility into all network activity. It has a unique engine that records all traffic, flows, and even packets for future analysis.

It is totally free for monitoring a recent 3-day window. Get it now.

New Trisul builds released – fixes CPU usage issues

We just uploaded a new build of Trisul 2.4.1089. Users are advised to upgrade their Trisul servers to this or a later version. The Web Interface is unchanged. The main issues fixed are :

  1. CPU Usage is cut by 40-60% for heavy workloads
  2. A bug was fixed in 32-bit versions of Trisul (eg Security Onion distro). This bug would cause Trisul to stall after processing 4 Billion packets ! The bug was in a concurrent data structure that shipped with Intel TBB.

Please sign in and get your packages now.

Awesome new flow features in Unsniff

The latest release of Unsniff Network Analyzer features two nifty features for working with TCP Flows.

Detect packet loss in captured stream

Dropped packets could completely jeopardize content reconstruction which is what a lot of people use Unsniff for. It is very difficult to eyeball a packet capture and tell if some TCP sessions have missed packets. To help here, Unsniff adds a new column to the list of TCP Sessions called “Loss Flags”.  For each TCP flow, Unsniff performs a hole analysis using an infinite window. If any holes are detected in either direction it will be flagged here. See the image below for a sample.

Built in packet loss analysis

Export a flow to a separate capture file with a single click

We found this extremely useful while working with a lot of troublesome captures. Typically you are interested only in a single or handful of flows out of dozens. Previously you could export an entire flow by Copy > Paste as new file  This was a bit tedious, now you can just right click on a flow and select Pull out as new capture file

Pull out a flow as a separate capture file
Pull out a flow as a separate capture file

 Several more

There are several huge improvements in Unsniff in the past month. If you havent updated it , please download the latest build and give it a try.