1

I’m new to OVS and trying to get IPFIX working on my OVS bridge. I’m building off the great information in this previous post:

How to get ipfix working with openvswitch?

The good news is I have gotten my OVS switch to export IPFIX flows to my collector. The bad news is the switch isn’t exporting the flows I want. Instead of exporting the flow records describing traffic between my test hosts, the switch is only exporting records that describes traffic between the switch and collector… which is the traffic I’m NOT interested in.

To describe my proof-of-concept environment in a nutshell: I have an OVS switch with three VMs; two tests hosts and one collector:

root@OVSHost# ovs-vsctl list bridge
_uuid               : 2fb2fa30-e1ed-4cbf-a365-7462e5f83cbc
...
name                : "myBridge"
...
ports               : [1940fd00-2dcb-4c85-a077-bae1653d9841, 279e489d-a940-4056-b753-2213fd46d5fd,
31258106-589b-40b9-94c9-a29711991a91, ee38080d-3446-4760-a297-801c5ffe76bb]
root@OVSHost#

I’ll be the first to admit that I don’t know which ports support the test hosts and which support the collector. I’ve set up libIPFIX (a free IPFIX collector) on the collector VM. Finally, I enabled IPFIX exporting on my OVS bridge by running these two commands:

ovs-vsctl clear bridge myBridge ipfix
ovs-vsctl -- set Bridge myBridge ipfix=@i -- --id=@i create IPFIX targets=\"192.168.2.2:4739\" obs_domain_id=123 obs_point_id=456 sampling=5

Once the above commands were in place, I saw flow records arrive at my collector. But on closer inspection, I realized the flows I was seeing described traffic between the bridge (192.168.2.1) and the collector (192.168.2.2). Here’s one such record, processed with a python script I wrote for troubleshooting:

   RECORD 123, using Template 284
     138(observationPointId:4)            456
     61(flowDirection:1)                  0
     4(protocolIdentifier:1)              17
     17)  8(sourceIPv4Address:4)          192.168.2.1
     18)  12(destinationIPv4Address:4)    192.168.2.2
     19)  7(sourceTransportPort:2)        37512
     20)  11(destinationTransportPort:2)  4739

At first, I thought my collector software must be misconfigured, but then I ran tshark on the collector VM and saw the same thing. (Edited to make it concise):

root@6bfcec0a4bd8:/# tshark -f 'port 4739' -d udp.port==4739,cflow -V -i eth1
Capturing on 'eth1'
Frame 64: 314 bytes on wire (2512 bits), 314 bytes captured (2512 bits) on interface 0
...
Ethernet II, Src: 32:fa:b2:2f:bf:4c (32:fa:b2:2f:bf:4c), Dst: 82:9e:f8:b2:e7:27 (82:9e:f8:b2:e7:27)
...
Internet Protocol Version 4, Src: 192.168.2.1, Dst: 192.168.2.2
...
User Datagram Protocol, Src Port: 37512, Dst Port: 4739
...
Cisco NetFlow/IPFIX
        Flow 1
            Observation Point Id: 456
            IfName: myBridge
            Protocol: UDP (17)
            SrcAddr: 192.168.2.1
            DstAddr: 192.168.2.2
            SrcPort: 37512 (37512)
            DstPort: 4739 (4739)

See what I mean? My bridge seems to be reporting flow information on the IPFIX export itself. Which is fine…

…except 100% of my flow records look like the above. When I run test traffic between my two test hosts, I never see a single record describing that traffic. Never. Its like the bridge is only exporting flow data when the flow describes traffic destined to the collector and ignoring all other traffic.

So at this point, I am assuming the commands I am using to export flows from the OVS bridge are only exporting records related to bridge-collector traffic? Can I modify those commands to include or focus exclusively on the test hosts?

1
  • Unfortunately, your switch manufacturer doesn't offer optional paid support, a requirement to be on-topic here. You could try to ask this question on Server Fault for a business network, or on Super User for a personal network.
    – Ron Maupin
    Oct 19 '18 at 2:47

Browse other questions tagged or ask your own question.