I was just sorting out how to graph IPv6 versus others, obviously the classic MRTG methods use SNMP MIB2 Objects ifInOctets and ifOutOctets, which are protocol-blind, so that’s not going to help.

After recent fiddling with libpcap programming, I found that small, custom programs perform much better than decode-intensive off-the-shelf things like tcpdump and tshark (part of wireshark), and etc. As I was evaluating options, I made a capture file with a million packets in it, and then ran it through some capture programs to see how long it took.

tcpdump took 1 minute 57 seconds
ipgrep.pl, a perl script I wrote took about 4 minutes
but a small, lightweight Perl script took 14 seconds!

Another cool thing about the little program is that you can set a pcap (nee bpf) filter expression to give it exactly what you want to see, and then it has to work even less…

When you use libpcap, the capture device keeps stats, of packets received and dropped.

So this morning while I was dreading doing diffs between our RRD graph data and some sort of cap file, it hit me —
Why not do a lightweight program that doesn’t even examine packets, but opens a pcap device simply for the stats? Run one each for v4 and v6, and voila…

So far, this “minimalism” is interesting. I have typed entire stanzas of code and then realized that I didn’t need that feature in the minimal program, that all of the elements were in the data to do it later. It really shines a light on how our eyes can be bigger than our stomachs when it comes to throwing in the kitchen sink while programming.

Look at tcpdump for instance. It does more decodes and automatic stuff than it did 20 years ago. Why use up the increase in power with more process? Sometimes you need a swiss army knife — no scratch that, sometimes you need one element of a swiss army knife, sometimes you need a sharpened stick.