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.
I wonder how do you map your netflow data to applications? (if I understood correctly what you´re saying) Pete
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".
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
On Tue, 2003-08-19 at 16:12, Jack Bates wrote:
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*
-Jack --
Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering friz@corp.ptd.net RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --------------------------- "Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world." -- Albert Einstein [1879-1955]
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
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
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 On Tue, 2003-08-19 at 15:55, 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?
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-
-- Paul A Bradford Senior Network Engineer Adelphia Cable Communications 814-274-6663
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 Tue, Aug 19, 2003 at 12:55:33PM -0700, 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?
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?
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 -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
participants (10)
-
Aaron D. Britt -
alex＠pilosoft.com -
Jack Bates -
james -
Jared Mauch -
Jason Frisvold -
lance_tatman＠agilent.com -
Mark Borchers -
Paul A. Bradford -
Petri Helenius