[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