[j-nsp] Traffic Information
Tommy Perniciaro
TPerniciaro at accuvant.com
Wed Mar 4 13:38:06 EST 2009
NetQos or Arbor Networks, Mazu Networks
----- Original Message -----
From: juniper-nsp-bounces at puck.nether.net <juniper-nsp-bounces at puck.nether.net>
To: juniper-nsp <juniper-nsp at puck.nether.net>
Sent: Wed Mar 04 06:44:14 2009
Subject: Re: [j-nsp] Traffic Information
Hi!
I think this is the right topic to ask this. I am on CeBIT tomorrow
and I have the mission to get information about Flow accounting. So
does anyone know of any companies I could pay a visit there? Have
found Wildpackets for example. Any further tips?
Regards,
Matthias
Am 04.03.2009 um 06:59 schrieb Stefan Fouant:
> On Tue, Mar 3, 2009 at 9:45 PM, Brendan Mannella
> <bmannella at teraswitch.com> wrote:
>> Wondering what the best/preferred method of capturing network
>> traffic for analysis is. Using a mirrored port or actually sending
>> the flows directly to a collector. Looking for pros and cons of
>> each approach.
>>
>> Also if you can give me some examples of whats used as a collector.
>> I have been looking at ntop on the open source side and inmon
>> traffic sentinel on the commercial side.
>
> The best/preferred method is to use both methods, if you can :)
> Sending flows directly to a collector definately has it's benefits -
> it usually scales a lot better and there are many tools out there that
> provide for excellent statistical analysis using sampling ratios as
> low as 1/100 or even 1/1000 - however unless your using some of the
> latest flow collection mechanisms, like Netflow v9 coupled with
> templates, most flow collection mechanisms are relegated to strictly
> Layer 3 and Layer 4 data. Often times this provides more than enough
> data, especially when dealing with your general run of the mill
> SYN/UDP/ICMP DoS flooding attacks. However, other times Layer 3/4
> data just simply doesn't provide enough usable information for the
> network operator to properly understand what is happening on the
> network. This is where having a box running tcpdump sitting on a
> mirrored or span'd port comes in handy. Usually, most operators rely
> on their flow analysis tools to trigger some type of alert based on
> statistical analysis of baseline activity to inform them of an anomaly
> which requires more active investigation. From there, the network
> operator can run tcpdump or their tool of choice in order to more
> fully understand the nature of the traffic. The point is there are no
> golden arrows or singular technology which is going to provide you
> with what you need, and you are going to want to have a wide variety
> of tools in your arsenal.
>
> In terms of commercial applications for Netflow collection and
> analysis - if you're only dealing with a small number of flows,
> something like Netflow Analyzer by Manage Engine or even Orion from
> Solarwinds would probably do. If you are dealing with a large number
> of flows throughout your network and need intelligent functions like
> data de-duplication and factoring of things like the sampling ratio in
> use on your devices then opt for something like Peakflow X or SP from
> Arbor.
>
> Regards,
>
> --
> Stefan Fouant
>
> Windows XP crashed.
> I am the Blue Screen of Death.
> No one hears your screams.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
More information about the juniper-nsp
mailing list