Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Visualizing LAN traffic



On Fri, Jan 20, 2012 at 12:24:26PM -0500, David Blank-Edelman wrote:
> On Jan 19, 2012, at 5:34 PM, Tom Metro wrote:
> > I've heard of tools that let you listen to LAN traffic, where supposedly
> > you can easily hear the differences when something unusual happens. But
> > I'd expect such a tool to get annoying fast.

I'm inclined to agree with this, though I must admit I find the idea
somewhat intriguing...  I'm wondering if anyone has actually used this
for real monitoring.  If so, how did you find it?

> You are thinking of Peep (which has as its goal not to be too annoying):

Perhaps so.  Still, this kind of tool strikes me as most useful when
the computing environment being monitored is large enough to require a
team to do the job, and I think therein lies the trouble.  I expect
many people probably could block out the background noise, whereas
others might have a great deal of trouble.  I'd imagine the specific
noises emitted would affect that balance; different people react
differently to different types of sounds, much as different people
appreciate different types of music.  I suspect it would take some
experimentation and quite a bit of luck to find a set of noises which
would not irritate at least one member of your team.  This seems like
a potentially serious drawback, though it likely depends on the
composition of your team.

The paper discusses the idea that typical network monitoring tools are
reactive and therefore interrupt-driven, and that they only provide
negative feedback, and no positive feedback.  But I'm not sure I
really see a difference:  Traditional tools provide positive feedback
in the form of silence, much like most command line tools in a Unix
environment.  No news is good news.  Peep is still reactive in that
when things sound "normal" there's nothing for the engineer to do;
only when the sounds change in a way that sounds abnormal must one
then react and investigate what is happening.

It seems to me that another downside is that one must learn to
interpret what the sounds mean.  There are potentially dozens or even
hundreds of events which could happen on your network that might need
their own sounds assigned.  With traditional tools, any reasonably
technical person can simply read the alert/page/whatever and see what
the problem is, without having to memorize some kind of unintuitive
code that represents the problem.  Paging or some sort of audible
alerting can be used to trigger action, so that only infrequent active
monitoring, or even none at all, is required.

My impression is that this mostly is a clever hack without much
practical value.  But if anyone is using this (or some similar tool)
with some degree of effectiveness, I'd certainly like to hear about
your experience.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org