Todd Crane wrote:
This maybe outside the scope of this list but I was wondering if anybody had advice or lessons learned on the whole sFlow vs netFlow debate. We are looking at using it for billing and influencing our sdn flows. It seems like everything I have found is biased (articles by companies who have commercial offerings for the "better" protocol)
There is a lot of religion floating around about this subject. Netflow was designed to measure flows, and it turned out that the design was robust enough for it to be more-or-less good enough for billing purposes. It's "more or less" because on larger routers, you can't do 1:1 data export and you end up needing to do traffic sampling, at which point you're billing based on realistic estimates rather than exact data. That's fine if your contract with your customer says it's ok. Netflow works by tracking individual flows in the data plane. This is pretty complicated in practice and requires dedicated hardware to handle it at line rate. You generally end up with two packet forwarding engines on a hardware-forwarded router: one to handle the forwarding, and the other to categorise and handle the flow data. This means that netflow is expensive to design, build and run. Sflow is a simple packet header sampling mechanism. The only thing it does is to pick out every 1 in N packets, and to try to figure out where the headers stop and the data begins. The header is then forwarded to the sflow collector, which is where all the smart stuff is done. If your netflow / sflow packet sampling mechanism is accurate and your router is configured appropriate for the quantity of flow data being exported (i.e. it isn't dropping data samples due to overload), then for the most part, there will be no substantial difference between using sflow and sampled netflow (depending on the data flow type), assuming that each protocol provides the data you're looking for. Obviously, if your sampling mechanism is broken or your exporter is overloaded, then both sflow and netflow will produce trash. If you're using unsampled netflow, then netflow will be more accurate, assuming you don't end up overflowing the netflow data export mechanism. Anything which uses sampling - regardless of whether it's for netflow or sflow - needs to be profiled before being pushed into production, because you need to understand the limits of the sampling mechanism. Hardware sampling often doesn't work properly or plateaus off at a certain stage, dropping packets in the process. This can cause unwelcome surprises. Without knowing anything more about your requirements or your choice of equipment, I'd suggest that sflow would probably be a better choice for SDN tuning and probably netflow would be better for billing, but YMMV. Nick