Netflow / J-flow / S-Flow... all them flows...

[deanwebb]

Someone comes up to you and says, "Hey man, I need some Netflow info from all the L3 devices."

Before you say, "Sure thing, not a problem!" (lol), what are the questions you want to first ask that someone? Questions beyond what's the IP address to send it all to...

[Otanx]

Are they sure they want it from *all* the L3 devices? This can be overkill. For example if I give you Netflow from my DC cores then you probably don't need it from my edge routers. 95% of the traffic hitting my edge routers hits my DC cores. The other 5% I can get you from other devices without giving you a ton of duplicate data. Also this can be fun if I send you Netflow from my edge and core the Netflow traffic from my edge will cross the core generating a Netflow record for sending the Netflow.

What sampling rate do they want? 100%? Then I go and see if my gear can support that sampling rate. Newer gear should be able to do 100% without an issue, but older gear may not be able to do it. Also verify if i need licensing. Some Cisco gear I ran into needed licensing to do full Netflow. I think it was the 3650s? Not sure.

What format do they want/support? If Netflow v9 then what fields do they want. Then I see if my systems can support it.

I am sure there are more, but that would be my starting questions. Outside of your questions, but I prefer to offload my Netflow generation. If you have any Gigamon applicances they can generate Netflow based on the traffic being sent to them.

-Otanx

[deanwebb]

Yes, we need netflow data on the netflow, so we can see if netflow is a top talker. OK, maybe not *that*.

Let's say no Gigamon in place... keep it tricky. Let's also say this is for a network segmentation effort: we want to see what's typical traffic over a 30-day period. Do we need 100% sampling for that? Let's assume also older gear, but with the right license for Netflow.

So in this scenario, we'd like core switch traffic... also distro closet east-west traffic at the remote/campus sites. If we have small sites with just one switch and a WAN router, then do we want Netflow from the WAN router at the remote site or at the WAN concentrator in the DC?

[Dieselboy]

Interesting thread on this. What netflow system are you using? Is it a combined logging / netflow system? I am in the market for something.

[wintermute000]

Well there are dedicated flow solutions, those integrated into bigger/wider products, and roll your own. I would have guessed you'd go for roll your own lol.

Shiny and resource intensive
https://docs.elastiflow.com/docs/
The OG mom-and-pop-telco/msp solution, raw as guts but 'works'
http://nfsen.sourceforge.net/
And then all the commercial solutions - Plixer Scrutinizer, PRTG, etc.

[icecream-guy]

How many devices?
What is the NetFlow collector?   Will it support the huge influx of data being thrown at it, without going titsup
Where is this net flow collector in the network topology?   in someone's office under a desk?
How much traffic is expected?
Will all the switches in the path support the amount of traffic without dropping?
How is this NetFlow collector connected to the network ?  A 1G link probably will not suffice,  more like a 10G link

[deanwebb]

So what's a good rule of thumb for calculating flow traffic requirements?

[Otanx]

So what's a good rule of thumb for calculating flow traffic requirements?

That will depend on what data you want about each flow. Netflow v9 lets you customize the fields. Just the basics; byte count, packet count, protocol, source ip/port, dest/ip port is 21 bytes per flow for IPv4, 53 bytes per flow if you also have IPv6 flows. So how many flows do you expect? There is some other overhead, and if you want more than just the basics it will go up as well. This can get very large. You can even have Netflow send packet data from the flow (I don't know why you would do this, but you can).

Let's say no Gigamon in place... keep it tricky. Let's also say this is for a network segmentation effort: we want to see what's typical traffic over a 30-day period. Do we need 100% sampling for that? Let's assume also older gear, but with the right license for Netflow.

So in this scenario, we'd like core switch traffic... also distro closet east-west traffic at the remote/campus sites. If we have small sites with just one switch and a WAN router, then do we want Netflow from the WAN router at the remote site or at the WAN concentrator in the DC?

I am not sure on sampling rates. All my Netflow stuff is for the security guys, and they always want 100% sampling. If you are trying to do core, and remote sites then you probably want a product that supports multiple collectors. That way you can deploy a collector to each site and query the data when needed instead of having to send all the flow data over the WAN all the time.

-Otanx

[deanwebb]

Multiple collectors looks like the best way to go, and then a concentrator kicks out the data to the rest of the world.

Biggest concerns, though, are at customers that don't have it turned on in the first place and where they fear what it might do to their network.

[Otanx]

If they are worried about CPU or something on the devices that is when you offload Netflow generation to another device. Give it a SPAN/TAP of the traffic, and generate the flow records on a dedicated system. Like I mentioned earlier Gigamon has that capability, but if all you want is Netflow you won't like the price. I think you can do it with nfsen, Probably quite a few options. If they are worried about the bandwidth requirements you can always start small and ramp up. Distributed collectors helps with that as well. No single collector needs to get everything, and you can place them to reduce the impact.

-Otanx

[wintermute000]

even with NFSen on my old mom-and-pop ISP where I implemented it we would be getting tens of gigs a day from just maybe 3 dozen routers.It was always a battle with the SAN guys how much storage we were allocated.
A commercial vendor should be able to give you some mechanism to have a stab at quantifying the storage requirements.