sFlow-RT is a programmable external flow cache that handles the packet parsing.
It can be programmed to export IPFIX records.
http://blog.sflow.com/2016/05/sflow-to-ipfix.html
<http://blog.sflow.com/2016/05/sflow-to-ipfix.html>
# 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
'{"keys":"inputifindex,outputifindex,ipsource,ipdestination,tcpsourceport,tcpdestinationport","value":"bytes","ipfixCollectors":["10.0.0.162"],"activeTimeout":10}'
http://localhost:8008/flow/tcp/json <http://localhost:8008/flow/tcp/json>
sFlow-RT can also stream JSON encoded flow records. They are more flexible and
you might find them easier to process than IPFIX records:
http://blog.sflow.com/2013/08/restflow.html
<http://blog.sflow.com/2013/08/restflow.html>
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?
>
>
> Regards,
> Ben de Graaff
>
> _______________________________________________
> discuss mailing list
> discuss@openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
