On Fri, 21 May 2010 04:18:31 -0400, Kevin Cullimore <kcullimo@xxxxxxxxxx>
wrote:
> On 5/20/2010 5:15 PM, Jaap Keuter wrote:
>> On Thu, 20 May 2010 10:23:39 -0500, "mike@xxxxxxxxxxxx"
>> <mike@xxxxxxxxxxxx> wrote:
>>
>>>> My suggestion/comment was based upon the notion that the bulk of
the
>>>> resources responsible for ultimately grinding a system to a halt
are
>>>> consumed not by the act of capturing, but by the act of analyzing a
>>>> given
>>>> packet/set of packets to provide the "what's going on" information
>>>> (an
>>>> action which i'm informally equating with the term "decoding"). If
>>>> this
>>>> is
>>>>
>>> Don't know, I only know that on a 4GB memory server, it eventually
tells
>>> me it is out of memory and wireshark dies. That's if I just leave it
>>> running while going off on something else.
>>>
>>>
>>>> in fact accurate, this would be the wrong tool to implement in an
>>>> attempt
>>>> to provide insight without consuming resources.
>>>>
>>> I understand, just wondered if there was an option to monitor without
>>> capturing.
>>>
>> Hi,
>>
>> And I still don't know what you mean by 'not capturing'?
>>
>> Definitions:
>> capture: to acquire and collect network frames.
>> monitor: to passively observe a phenomenon.
>>
>> So, how do you monitor and network without capture?
>> What I think you mean is '...to monitor without dissection resulting in
>> state being build up eventually exhausting my platform resources."
(phew)
>>
>> So there you have it, you need capture, but can't have statefull
detailed
>> dissection.
>> That's where tools like CACE Pilot, or ntop and the like come in. Or
>> devices which spit out netflow or sflow info.
>>
>>
> Allow me to explicitly restate the assumption (based upon the posts of
> others within other threads) that motivated me to post to this thread:
> -you CAN capture (collect packet data) without "state being built up"
> via dumpcap or similar tools
True. I've done that in a hospital network for months, without a glitch.
> -you can NOT montor/watch the packets using wireshark without
> 1. collecting packet data
> 2. building up state
True. As anyone who (accidentily) left Wireshark running while capturing
knows.
> Do inaccuracies lurk within that set of statements?
I don't think so.
So there's a gap which is filled by the other mentioned tools.
Thanks,
Jaap