[c-nsp] Sampled netflow on 6500/7600

[Tim Durack]

On 7/3/06, Oliver Boehmer (oboehmer) <oboehmer at cisco.com> wrote:
> Tim Durack <> wrote on Sunday, July 02, 2006 4:03 AM:
>
> > Wonder if Cisco could be convinced that sFlow is a good idea.
>
> I guess we're not convinced about sFlow, will rather follow IETF's IPFIX
> approach.

Enjoy the wait...

> > Exporting 1-in-n packet headers seems pretty easy for network
> > equipment. The load is then moved to the collector to rebuild the
> > flows. You sacrifice some accuracy of course. But you get actual
> > packet headers instead of just flow data.
>
> Tim has already mentioned that the current Cat6k/7600 hardware is not
> that well suited for sampling, but take a look at the GSR, CRS-1 or the
> software-based platforms for a "real" sampler (random or deterministic),
> where the forwarding hardware only takes 1-in-n packets for analysis.

Apparently the Cat6.5k/7.6K platform isn't well suited to Netflow either.

Seems strange that Cisco dropped Netflow as a forwarding mechanism
some time ago due to scalibility problems, but sticks with it for data
collection.

Not that I have anything against Netflow - we use whatever is
available. But as soon as a technology requires maintaining state,
it's going to be difficult to keep scaling it.

> Flexible NetFlow (just released in 12.4T for SW-forwarding platforms,
> see
> http://www.cisco.com/en/US/products/ps6441/products_configuration_guide_
> chapter09186a00805a5f35.html) is the way forward, and it is being
> developed for other platform as well.

Interesting, but complicated looking.

Rather the forwarding platform do something simple like sampling, and
let the collector do all the hard work. I can throw memory and disk
arrays at the collector to keep it scaling.

I keep wondering why my $1500 L2 switch is capable of this when my
$100k L3 switch isn't.

Tim:>

p.s. This isn't meant to be inflamatory - I am genuinely interested in
where Cisco and others think collection/monitoring technology is
headed.