0

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:

https://networkengineering.stackexchange.com/questions/5848/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
    8(sourceIPv4Address:4)           192.168.2.1
    12(destinationIPv4Address:4)     192.168.2.2
    7(sourceTransportPort:2)         37512
    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?

Pete
  • 111
  • 3

1 Answers1

0

A colleague found my error... My test hosts were not really attached to my bridge, although I was certain they were. Once we properly connected the test hosts, I "automagically" saw the exports I was hoping to see.

That's the problem with virtualization, isn't it? Sometimes you can't see the most obvious problems... Thanks to all who read and considered my post.

Pete
  • 111
  • 3