>On Wed, Feb 21, 2001 at 02:12:30PM -0500, Chris Rapier wrote:
> > Question about the usage of netflow, aside from the lisencing fees
> > doesn't enabling it on a router produce a noticable performance hit? I
> > know that hit can be mitigated by sampling instead of monitoring every
> > packet but how are you getting accurate data on usage that way?
> > Admitedly I don't know much about netflow as we'd never bothered with
> > getting a license for it.
I would never enable any feature before finding out all the caveats on the
platform I was running. Especially in a large environment. But... most
environments aren't large.
We ran a number of tests in our environment (hardware/traffic patterns),
and found the netflow exports to match independent measurements. Some
implementations only sample flow data-- but in theory those will
statistically yield representative numbers. Our gatways are configured to
attempt to forward all flow information. It is always possible to loose
some flows, in fact we deliberately throw away very low bandwidth traffic
to save database access after characterizing our traffic patterns. Lost
flows tend to be low bandwidth because the high bandwidth flows stay in the
cache (depending on your configuration). Texas A&M, I believe, uses a host
on the wire to measure their traffic-- and we might head that direction if
our gateways start having issues, we have also heard from vendors with
dedicate flow hardware.
At 03:06 PM 2/21/2001 -0500, Matthew Davy wrote:
>The performance impact most likely depends on what type of router you're
>running. I just read some documentation on the Cisco 6509 that claims
>there's no impact. On the other hand, I've been told there's a significant
>impact on GSRs. On Junipers you're limited by the 100mbps connection to
>the Routing Engine.
Our ResNet gateway is a Cisco Catalyst 6509 with a Sup 1A/MSFC1. There are
serious netflow/mls issues that need to be engineered carefully-- and
software defects in some versions of supervisor code triggered under high
load/attack and nde export (contact your vendor, I don't get a paycheck
from Ci$co). Watch your supervisor CPU and mls cache in busy
environments-- nde is done by the supervisor under mls, not the msfc. We
are exceeding the capabilities of the Sup1A in our ResNet and are in tests
with the Sup II which is cef and not mls based, although the nde portion
appears to rely on a number of the underlying mls mechanisms no longer used
for routing. The problems have to do with mls cache size and not nde
issues. Bottom line, depending on your nde configurations and traffic
load, there can be issues.
Our campus gatway is a Cisco 7513 RSP4, VIP2/50s, running dCEF, maxed out
with RAM/DRAM. We have had fewer problems with nde on this platform. But
we don't have OC12 either.
-William
|