Are operators frequently using netflow nowadays? I assume that if you are, you turn it on only for
some limited duration to collect your data and then go back and do your analysis. Is this assumption correct?
What are you looking at when you analyze this data? I've seen uses such as
top 10 destination AS's for peering evaluations. What else? Billing?
-Lance-
What are you looking at when you analyze this data? I've
seen uses such as top 10 destination AS's for peering
evaluations. What else? Billing?-Lance-
Also to get some application-specific bandwidth utilization
numbers.
lance_tatman@agilent.com wrote:
Are operators frequently using netflow nowadays? I assume that if you are, you turn it on only for
some limited duration to collect your data and then go back and do your analysis. Is this assumption correct?
Netflow overhead is relatively low considering what it does. I keep mine on at peering points.
What are you looking at when you analyze this data? I've seen uses such as
top 10 destination AS's for peering evaluations. What else? Billing?
Number one use for netflow, scan detections. I detect most users infected with a virus before remote networks can auto-gen a report. I also detect mail being sent from various customer machines. High volume traffic flags me so I can investigate if it's spam or not.
I can tell you (well, I won't without a court order, but I could) the username, or customer name (if static), of every worm infected user on my network at any given point in time. 50+ inactive flows for an IP address is definite worm sign. If you want to be more specific, do sequential scan checks on the flow data. Has been very useful in dealing with Blaster.
Netflow is particularly useful when utilizing NAT, as it's much easier to collected netflow data than translation tables.
On a cold, boring day, you can setup aggregates and generate cute little statistics for all sorts of things, and I hear it's useful in some scenarios.
-Jack
Well,
On ciscos, we use it to track down DOS attacks in a put it on,
troubleshoot, take it off manner. Works great on not Catalyst stuff...
put it on.. wait 30 seconds look for anything with K packets and you've
got your bad guy, hopefully.
Thanks,
Paul
i've seen netflow used in a few situations:
1) it's actually kinda useful for DoS situations, you can easily
look at the data flowing through the router and get some general idea
of what the traffic looks like without a fancy sniffer, etc.. You can
also do "sh ip ca flow | inc K" to see large flows which are useful
in a flooding situation.
2) i personally use netflow on my home network (with the max cache
size) to get an idea of what was going on a few minutes ago. i have
a low enough set of traffic that this works.
3) i've seen others use netflow for peering analysis in the past
but with transit costs so low, and other things unless you're peering
now it's not really worthwhile to try and get into that marketspace
as there's not a lot of money to be made.
4) i've seen people feed the netflow data into various sql based
systems for analysis. this allows them to track trends, any large
upticks in traffic (proto0, proto255, icmp, tcp/445 tcp/135) they are
seeing on their network and generate alerts if it exceeds some pre-existing
thresholds.
you can always do more interesting things, the problem comes in
storage of data, insuring you are doing 1:1 sampling, etc.. (hard on
big pipes)
- jared
> What are you looking at when you analyze this data? I've
> seen uses such as top 10 destination AS's for peering
> evaluations. What else? Billing?
>
> -Lance-Also to get some application-specific bandwidth utilization
numbers.
I wonder how do you map your netflow data to applications?
(if I understood correctly what you�re saying)
Pete
Number one use for netflow, scan detections. I detect most users
infected with a virus before remote networks can auto-gen a report. I
also detect mail being sent from various customer machines. High volume
traffic flags me so I can investigate if it's spam or not.
Cool.. I never thought of using it for this...
I can tell you (well, I won't without a court order, but I could) the
username, or customer name (if static), of every worm infected user on
my network at any given point in time. 50+ inactive flows for an IP
address is definite worm sign. If you want to be more specific, do
sequential scan checks on the flow data. Has been very useful in dealing
with Blaster.
Worm Sign... Dune... Cool 
We used ip accounting the other night to detect and disable a large
number of worm infected users that took out the router completely.. I
think net flow would have been too much overhead at the time... Once we
were down to a more manageable number of infected users, we used netflow
to pinpoint them immediately... (Note, we don't leave netflow on all
the time)
Netflow is particularly useful when utilizing NAT, as it's much easier
to collected netflow data than translation tables.On a cold, boring day, you can setup aggregates and generate cute little
statistics for all sorts of things, and I hear it's useful in some
scenarios.
Sounds like fun... I wish I had slow boring days... *grin*
> > What are you looking at when you analyze this data? I've
seen uses
> > such as top 10 destination AS's for peering evaluations.
What else?
> > Billing?
> >
> > -Lance-
>
> Also to get some application-specific bandwidth utilization numbers.
>
I wonder how do you map your netflow data to applications?
(if I understood correctly what you�re saying)
The caveat is that Netflow is useful for this purpose on a
smallish test/research network, in which port numbers and/or
combinations of port numbers and server addresses correllate to
an application, which is what I happen to be doing. Naturally
on a public backbone you'd want to substitute "port-specific"
for "application-specific".
Jason Frisvold wrote:
We used ip accounting the other night to detect and disable a large
number of worm infected users that took out the router completely.. I
think net flow would have been too much overhead at the time... Once we
were down to a more manageable number of infected users, we used netflow
to pinpoint them immediately... (Note, we don't leave netflow on all
the time)
One method for limiting netflow accounting to manageable ammounts is to access-list the port involved. This is why I did institute 135 blocking. This flags the flow as inactive which only holds it for like 15 seconds on default. Of course, this still may not be enough for some routers. I just happen to have prepared for this actual event due to constant DDOS attacks about nine months ago (reverse view, change rule matches).
-Jack
I am considering transporting back-up traffic through a non-LEC for a
possible DR design initiative using a couple DS3 transfer arrangements
that terminate through a 3rd parties network full time, allowing that
same 3rd party to redirect these same ports, during a disaster, to
various hot sites within their domain.
I was told by various sources that unless the vendor of my choosing is a
LEC of some sort, they cannot back-haul production traffic as a private
network, and that this is a FCC restriction regarding LEC licensing for
traffic/long distance etc. These various sources do not have actual
data to substantiate these claims, but have created enough questions in
my mind to research this subject further.
Does anyone have any good information regarding these FCC rules and
regs? I am mainly concerned with the limitations set upon private
networks to back-haul production traffic internationally. There is some
legal grey area here, that I do not wish to tread on without some facts
or at least some pointers in the right directions to research these
claims appropriately.
Very interesting stuff here, and I am not able to get any nibbles from
google, hoping that someone here might have some 'blues clues' they
would like to share.
-Aaron
I was told by various sources that unless the vendor of my choosing is a
LEC of some sort, they cannot back-haul production traffic as a private
network, and that this is a FCC restriction regarding LEC licensing for
traffic/long distance etc. These various sources do not have actual
data to substantiate these claims, but have created enough questions in
my mind to research this subject further.
It's the other way around.
RBOCs (note, not ILECs) cannot move inter-lata traffic without being
approved by PUC in each state for "interstate long distance". (I believe
this is part of 1984 MFJ).
CLECs have no restrictions on that. Neither do non-CLEC ISPs.
-alex
On a day like today, Net Flows was very useful to clue me into
by some dial up users were dead in the water. 500kbs of incoming ICMP.
James Edwards
Routing and Security
jamesh@cybermesa.com
At the Santa Fe Office: Internet at Cyber Mesa
: what sort of tools are you using to interpret netflow, other than cflowd
: (which I've found overly complex and not graphical enough)
CUGrapher.pl