How to break down traffic in PRTG?

I am using PRTG to monitor traffic coming off of a hub, just before the firewall.  While monitoring the traffic using the Packet Sniffer mode, viewing the graph, I obverve that at various times there is a huge spike in traffic for an extended period of time.  Then traffic goes back to normal.  

The traffic all falls in the "Other" category, and I can't tell where it's coming from.  Is there a way in PRTG to break this down so I know who is generating all the traffic, ideally by IP addresses?
lloydr1lAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

pkutterCommented:
I use MRTG, but have my solution may help as well. If your switches support SNMP just turn on SNMP and have PRTG monitor them as well, then you will find the port that is producing all of the traffic. A packet analyzer such as Ethereal may work well if it is a hub and not a switch, or if your switch has port mirroring. It just depends what hardware you have how you want to go about it.

http://www.ethereal.com/
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
lloydr1lAuthor Commented:
The switches are unmanaged, so port mirroring, etc is off.  I do have a hub setup to capture traffic, and I have been using Wireshark (Ethereal) as well to capture.  But the problem I was having with that program was its graphing capability.  I would like to be able to monitor the traffic graphically and watch for spikes.  Then within those spikes narrow down what is causing it and where from.  I"ve  been researching this a little more and saw where someone suggested using NTOP.
0
jasoncolemanCommented:
With wireshark(ethereal) you can sort the conversations by bytes transmitted / received.  Go to statistics-> conversations and then click on the column you want to sort. That should help you narrow down where it is coming from. You can then narrow down the capture to traffic from that (those) device(s) and get more info.
0
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

lloydr1lAuthor Commented:
jasoncoleman
I've done that, but the problem with conversations, endpoints, etc is they don't show when the bytes transmitted or received takes place.
0
jasoncolemanCommented:
Usually I just run the capture right when the spike is happening and then I can sort out who is responsible at that time - it may not work for you though if the timing is unpredictable. Otherwise its tough without managed switches that you can get reporting from. I've never used ntop, it looks like it may do just what you'd like. Hopefully someone else out there can provide more info on it.
0
lloydr1lAuthor Commented:
OK, just had to say, I've been playing with NTOP now for the last 20-30 minutes, and I really like the look of this program.  So if anyone ever comes across this post wondering the same thing, this looks like it might do the trick.  I'm still checking it out though.

I would still like to know if PRTG has some feature like this.  It seems that one could simply select an area of the graph with the mouse and dig in deeper to obtain more information.  Maybe not.  I know you can select an area in PRTG and it will automatically zoom in, but no more information is given.
0
pkutterCommented:
I'm sure you're probably already aware of this, but the managed switch at least, at the core of your network, would make this problem much easier to troubleshoot. I was able to justify to management the reason for purchasing a managed switch was to cut down the amount of time that I spent troubleshooting network issues, and also to prove to software vendors that we didn't have a "Network Problem" when it was really a bug in their software. Just some additional thoughts.

Good Luck
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Networking

From novice to tech pro — start learning today.