Webinar: Top Tips for Effective Cyber Threat Hunting Watch Now
FlowTraq > Blog > Tech Thoughts > Configuring NetFlow Export on Open vSwitch SDN

Configuring NetFlow Export on Open vSwitch SDN

Dr. John Murphy
By | October 14, 2013


Open vSwitch is a popular open source SDN solution that can be run on any Linux-based virtualization platform, and supports a wide variety of systems such as KVM, VirtualBox, ProxMox VE, Xen Cloud Platform, XenServer, and others. Despite the intricacy of these networks, it is very easy to configure NetFlow export from any number of virtual switches.

Configuration of an Open vSwitch system is accomplished via its vswitchd database. The ovs-vsctl command-line tool provides an interface to the vswitchd configuration database via the ovsdb-server process, and can be used to configure NetFlow, IPFIX, and sFlow. Monitoring is accomplished by attaching NetFlow configurations to individual defined bridges; you’ll need to configure each bridge with a configuration in order to monitor all of the traffic flowing through your vSwitch.

There are two steps involved in attaching a NetFlow monitor to a bridge: defining the monitor, and linking a bridge to it. Because vSwitch is aggressive about cleaning unlinked database records, the definition of the NetFlow configuration should be done at the same time as its first attachment.

Breaking this down into two steps for the sake of explanation, we must make a change to the Bridge table for the specific bridge being affected:

−− set Bridge [bridge] netflow=@[netflow conf ID]

The second step is to create a named entry in the NetFlow table (page 46 in the database schema). There are several columns described there, but at the very least there must be at least one collector (IP address and UDP port)

−− id=@[netflow conf ID] create NetFlow targets=\"[collector IP address]:[port]\"

Also useful is the add_id_to_interface (boolean) column. If it is set to false (default), then it sets the ingress and egress interface numbers to the OpenFlow ports. If it is true, then the 7 most significant bits in each field will be assigned to the engine_id column for this record (a number between 0-255).

The primary reason for the add_id_to_interface field is that you will probably have multiple monitored bridges, each with its own NetFlow exporter, but all of which are reporting the same IP address. Setting this field to true allows for easier disambiguation, at the cost of having large numbers identifying your interfaces.

Another field of interest is active_timeout (integer, time in seconds). When this is not set to -1 (disabled), your device will send updates for NetFlow records that are still active. The default timeout is 600 seconds.

Configure bridge br0 to send NetFlow records to UDP port 2055 on host, keeping the OpenFlow port numbers as iface numbers (the — separates commands, and is needed for the id designation):

ovs−vsctl set Bridge br0 netflow=@nf0 -- −−id=@nf0 create NetFlow targets=\"\" add_id_to_interface=false

If you need to break this over multiple lines, remember to add a \ at the end of the lines, like so:

ovs−vsctl set Bridge br0 netflow=@nf0 \
-- −−id=@nf0 create NetFlow targets=\"\" \


Once the configuration is created, you can change any of the fields directly via the set command, referenced by the bridge to which it is attached. For example to force it to send updates on ongoing sessions at least once a minute:

ovs−vsctl set NetFlow br0 active_timeout=60

The single NetFlow configuration, once defined, can be used by other bridges, referenced by the uuid of the netflow field:

ovs-vsctl set Bridge br1 netflow=[_uuid]

ovs-vsctl set Bridge br2 netflow=[_uuid]

To see a list of the current NetFlow configurations (such as after making changes to our bridge configurations, or to look up a uuid), type:

ovs-vsctl list NetFlow

Finally, you can remove the NetFlow monitor from a virtual switch just by clearing the netflow field in the corresponding Bridge table entry (there is no need to delete the NetFlow table entry)

ovs-vsctl clear Bridge br0 netflow

For further reading on Open vSwitch configuration, Scott Lowe’s article on the subject is highly recommended.