Collecting flows at an IXP

Tue Jun 26 09:32:12 UTC 2012

On 26/06/2012 07:06, Graham Beneke wrote:
> Just to clarify - there are 3 switch fabrics involved here. One from vendor
> C, one from vendor J and a third new fabric from an unchosen vendor.
> 
> So ideally something that can accept the flows from various vendors.
> 
> I'm also hoping for some insight on flows support and caveats with the
> various vendors and platforms since the this third vendor still must be
> chosen and it would be handy to quantify the flows support of the proposed
> platform.

Graham,

INEX has open-sourced its IXP provisioning system (github.com/inex), and
part of that, is an sflow stats munging system which we use to present
member to member data flows, split out by ipv4 / ipv6 traffic, pps and
bits/sec.  It would be easy enough to put in more graphing options.  We
haven't released the sflow stuff yet, but it's certainly there and in
production, and shoudn't be too much trouble to get into git.

Your difficulty is going to be that you're mixing and matching two
different systems with completely different characteristics.  sflow is easy
because you can multiply the sample rate by the packet size (and possibly
by an offset constant) and get a statistically representative sample of
what's happening on the switch.  But netflow is much more messy to handle.
 Mixing them together will be a lot of fun.

Further to this, if you're using Cisco PFC3 based system (sup720 / rsp720 /
etc), then this isn't going to work because Cisco WS-X67xx cards don't
export mac addresses in netflow data.  This is a hardware limitation;
nothing you can do about it.  This breaks point to point traffic analysis.

Nick