sFlow-RT is a programmable external flow cache that handles the packet parsing.
It can be programmed to export IPFIX records.
# start the flow cache
docker run -p 6343:6343/udp -p 8008:8008 -p 4739:4739/udp sflow/sflow-rt
# program a flow that includes ingress / egress switch ports
curl -H "Content-type:application/json" -X PUT --data
sFlow-RT can also stream JSON encoded flow records. They are more flexible and
you might find them easier to process than IPFIX records:
Note: Sampling rates of more than 1-in-10 for sFlow or IPFIX will adversely
affect the performance of OVS (since samples must be passed from the kernel to
user space for caching/export). For a production network, anything more than
1-in-100 isn’t recommended. Values around 1-in-1000 are typical.
> On Sep 21, 2016, at 1:46 AM, Ben de Graaff <c.b.degra...@uva.nl> wrote:
> Hi all,
> I'm currently working on traffic analysis for detecting various security
> events on a network and finding flow paths throughout the network. Part
> of this work includes tracking/visualizing network flows on a
> per-host/per-port basis.
> For this I'm currently working with OVS since it supports OpenFlow (used
> to orchestrate the network), sFlow, and IPFIX, which is working wonderfully.
> One caveat however is that, while IPFIX supports useful features such as
> caching flows and limiting the amount of packet parsing I have to do, it
> does not include the in/out port the flow was seen on.
> On the other hand sFlow *does* include that information (and even the
> OpenFlow port!), but doesn't have the caching feature and requires
> parsing headers at the collector.
> Since we're also experimenting with high sampling rates, I feel it would
> be best if we could avoid that.
> So my question is, is there a specific reason that the IPFIX
> implementation does not include e.g. ingressInterface and
> egressInterface? Could this be added?
> And are there any plans to augment the default IPFIX template, or
> perhaps even allow the user to select from e.g. various detail levels?
> Ben de Graaff
> discuss mailing list
discuss mailing list