Phil, Thanks for the dialogue here. It’s helping me think through things and make sure my ducks are in a row.
The 10:1 number is just in physical ports. We’ll be running 10G SPANs from the building aggregation devices. The optical taps would be 1G (as they would be placed between building aggregation and building access.) So in terms of capacity, it’s closer to 1:1. Further, a typical building is doing around 200Mbps. Of course there are bursts and spikes, but it’s difficult to build a solution that can consume every microburst scenario. Given our traffic profile, even the bursts should fit within the capacity we’re building. In terms of softflowd, this solution is based on my similar experiences with a couple servers, consuming 10G SPANs at the campus border. Both were consuming 5Gbps-ish and generating netflow without loss. I don’t recall the load, but I don’t remember being concerned about hitting any ceilings. This was 3+ years ago and at a former employer, and after several rounds of tweaking PF_RING. I _hope_ this is much easier these days given the prevalence of capture NICs and better linux support. I’m reaching back out to them to see if they’re still running that solution and what their current experiences are. Thanks again for the input/dialogue. It’s very helpful. Especially the comment on RAM. It occurred to me I’d need several cores, but given flow export timers, etc, I will need to adjust my RAM projections. /Ryan Ryan Harden Research and Advanced Networking Architect University of Chicago - ASN160 P: 773.834.5441 > On Aug 5, 2015, at 10:13 AM, Phil Mayers <p.may...@imperial.ac.uk> wrote: > > On 05/08/15 16:07, Ryan Harden wrote: >> Phil, >> >> I agree wholeheartedly. However, due to the nature of what we’re trying to >> capture, optical taps prove to be cost prohibitive. >> In our scenario, we would require roughly 1600 taps and another 1600 >> “TapAgg” ports to collect them. >> >> Using SPANs we would require only 155 ports. One for each campus building >> aggregation device. > > Fair enough, but obviously you'll be contending those SPAN ports at ~ 10:1, > given those numbers, so I think your security teams concern about missing > flows is entirely justified - regardless of what flow generation tool you > use, it can't generate flows for traffic it doesn't see because the SPAN port > drops during e.g. a microburst. > > But you know your own architecture, and if SPAN ports are suitable, fine. > > FWIW: > > I've used softflowd on a farm of busy recursive DNS resolver(s) before, and > it kept up just fine but did need a lot of RAM. > > A while back - >5 years - we did try using an optical tap directed at a fast > server running softflowd to do our border netflow. It comprehensively did NOT > keep up - a lot of dropped flows, very busy box, and of course lost metadata > like the BGP next-hop, AS numbers, etc. > > It's really going to depend on your traffic profile. > > Cheers, > Phil ------------------------------------------------------------------------------ _______________________________________________ Nfdump-discuss mailing list Nfdump-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfdump-discuss
