IMO its more than nice to have, but not invaluable. I use this to find the bad guys as much as throughput and other info. Agree with you about stuff working - I have a few issues myself but need to get on the latest code before I ask for help.
----- Original Message ----- From: [email protected] <[email protected]> To: [email protected] <[email protected]> Sent: Tue Feb 24 22:22:36 2009 Subject: Re: [Ntop] [SQSPAM] - Re: Network Traffic Map - Email has differentSMTP TO: and MIME TO: fields in the email addresses Good point... This really does come under the heading of "nice to have". It's not a fatal issue in my deployment. I'm just a firm believer that if something works it should work all the time. I did frame the whole conversation as a "suggestion". Best Regards, Jim -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Gary Gatten Sent: Tuesday, February 24, 2009 10:40 PM To: [email protected] Subject: [SQSPAM] - Re: [Ntop] Network Traffic Map - Email has different SMTP TO: and MIME TO: fields in the email addresses You can get similar info by looking at "host contacts" is the Summary -> Hosts page. The host contacts column is sortable so its easy to get the top host contacts at the top of the list, then drill down from there to see what's up. ________________________________ From: [email protected] To: [email protected] Sent: Tue Feb 24 21:25:27 2009 Subject: Re: [Ntop] [SQSPAM] - Re: Network Traffic Map - Email has differentSMTP TO: and MIME TO: fields in the email addresses Mel, The network map provides an interesting interface... Yes it can get big, but one of the things it does well is show hosts that are chatting with an abnormally large number of remotes. My ntop is configured to only show my local network flows to the internet so if I were to see a local host talking to say 50 or more internet hosts I might look more closely at it, with the idea that it may be infected with something. This would be glaringly obvious on the network map. Unfortunately the way things are the Map fails at anything over 800. Beyond that I'm kind of a purist... If something is worth putting in, it should be put in in a way that doesn't involve arbitrary limitations, if possible. This seems to be something that can be done (somewhat simply) in a slightly different way that would make it work irrespective of the number of hosts. Best Regards, Jim ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Mel Beckman Sent: Monday, February 23, 2009 10:01 PM To: [email protected] Subject: [SQSPAM] - Re: [Ntop] Network Traffic Map - Email has different SMTP TO: and MIME TO: fields in the email addresses What value do you get out of a local map with that many hosts? The diagram might be fun to look at but is there really any useful info there at that density? These maps tend to grow wide quickly and this you'd have a lot of horizontal scrolling to examine it in detail. -mel via cell On Feb 23, 2009, at 6:26 PM, "Jim Richard" <[email protected]> wrote: All: I've been running ntop for about 3 weeks. I'm running on a Dell 1750 with a pair of 3.2 Ghz processors. I'm running ntop 3.3.6 sourced from the RedHat EPEL yum repository. After figuring out and installing all the requirements my Local Network Map works fine as long as there are < 500 hosts. After that it becomes hit or miss. At > 800 hosts all I get in the browser is a broken image file. With large numbers of hosts (> 800) dot runs at 100% of cpu for 2-3 minutes. When it ends all I get in the browser is a broken link. I'm not getting any errors in my logs. I have a suggestion about the Local Network Map: This feels like a timeout of one sort or another. It seems to me that instead of regenerating the image map every time the networkMap.html URL is hit, a better approach would be to run these updates in the background, generate static objects then pass these to the browser. That way the browser/server are not subject to timeouts or volume related issues and the user gets reasonably current data. The thread/process could even be "niced" down so as to not effect other workloads. Perhaps the frequency of update could be configurable, with a reasonable default like 300 seconds. If there is a workaround for this apparent capacity problem please let me know. Other then that TIFWIW. This is not a critical feature (to me) just a "Nice to have", though it would be "Nicer to have" during my peak periods. :) Best Regards, Jim _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
_______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
