0

I’m struggling to understand my IPFIX flow data.

To explain: I have an Ubuntu (16.04.2 LTS Xenial Xerus) box, and within that box, I have a single Linux bridge:

root@Ubuntu1:~# ovs-vsctl show
527530c2-6f42-498f-92a6-67dc43d931bc
    Bridge "myBridge"
        Port "eth1"
            Interface "eth1"
                type: dpdkvhostuser
        Port "eth2"
            …etc…
    ovs_version: "2.9.3"
root@Ubuntu1:~#

Okay: I’ve enable IPFIX exports on this bridge:

ovs-vsctl -- set bridge myBridge ipfix=@i -- --id=@i create IPFIX targets=\"10.0.0.10:4739\" obs_domain_id=1234 obs_point_id=5678 sampling=5

And the bridge is successfully exporting flows to the 10.0.0.10 collector. From a number of posts (like here) I understand that the “octetDeltaCount” is the raw number of bytes in a given flow. I wanted to verify that, so I set up two VMs, A and B, and used iPerf3 to send test traffic from A to B across my Linux bridge. My results were discouraging:

                                    iPerf3           IPFIX's
                                    Transferred      octetDeltaCount                    
iPerf3 test                         (bytes)          reported           Delta
=========================================================================================
iperf3 -c 168.161.114.16 -n 1K      28,700           69,195             -40,495
iperf3 -c 168.161.114.16 -n 250K    303,700          637,345            -333,645
iperf3 -c 168.161.114.16 -n 500K    559,000          975,425            -416,425
iperf3 -c 168.161.114.16 -n 1M      1,060,000        962,286            97,714
iperf3 -c 168.161.114.16 -n 250M    216,700,000      1,016,687          215,683,313
iperf3 -c 168.161.114.16 -n 500M    500,100,000      1,143,102          498,956,899
iperf3 -c 168.161.114.16 -n 1G      1,000,000,000    1,348,778          998,651,222
iperf3 -c 168.161.114.16 -n 10G     10,000,000,000   3,721,548          9,996,278,452

(A note on that second column: When I specified that iPerf send “1K” of traffic, iPerf actually send 28,700 bytes. But that’s okay, I’m more concerned about how IPFIX reports what iPerf is sending.)

Okay, the bad news here should be evident. IPFIX is not accurately reporting byte counts, not by a long shot. I can accept the results for the 1 Mbytes flow, but the others are way too off-mark. Something’s out of whack here.

In particular, the reported “octetDeltaCount” becomes crazy-inaccurate after I send more than 1Mbytes/flow. Look at those deltas!

If you look at the ovs-vsctl command I’m using to enable IPFIX exports from the Linux switch, you’ll note that I’ve set flow sampling to N=5, meaning the switch is looking at every fifth packet. My collector doesn’t know about this, it simply reports the raw data that it gets from the switch. But obviously, multiplying the “octetDeltaCount” column by five will offset this problem. There’s something else at work here.

Anyone had to grapple with an issue like this before? I’m curious to know if you did what I did but then did get accurate numbers. If so, then perhaps my IPFIX collector isn’t very good. Or does OVS report IPFIX data on a logarithmic scale or something?

Any information or advice will be wildly appreciated.

  • I am not familiar with OVS. Does tcpdump not work for your check process? And I think sampling rate 5 is too short. It may be necessary to have a good HW and a good Flow Collector. How about trying a sampling rate of 64 and so on. – Roger Sanghee Gold May 21 at 1:16
  • @RogerSangheeGold Thanks Roger! tcpdump and wireshark does allow me to see the exported flow data, but doesn't scale well when I'm looking at large data flows. Your idea of using a bigger N is intriguing. I can certainly try it; why do you think N=64 is better than N=5? Curious... – Pete May 21 at 14:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.