Sniffer :: Detect user that contribute problem to network

i'm sniff small network and below are the result::





Question
...............

1) From the pic, it show that the highest broadcast is 31...is that host can contribute problem to the network?
2) Is it a range to compare normal host and problem host? ..example normal user broadcast from 1-10 only..problem host broadcast more than 10..
3) From the pic, are the in packet and out packet behave normal?
4) Jabber is broken NIC that contribute broadcast to the network.. is it true?
5) CRC error is cause by failure fiber/cable..is it true?

Some parts of your questions I don't understand, but I will attempt to answer them to the best of my ability.

1.)How long did you sniff the network for during that capturing phase? If that was somewhat of a long time(which I doubt), then you have nothing to worry about broadcast congestion wise. Perhaps you could post more information as to what protocol is being broadcasted by that particular host. If your on a cable network, then it is nothing unusual to see a flood of ARP broadcasts hitting your network, so if possible, set up a syntax filter to filter those out when you sniff.

2.) This was the question that I didn't really get, but from I can glean you are wondering if there is a threshold for how much broadcasts a host can do before it becomes a problem. To compute that, I would need some more information, such as the bandwidth capacity and how long you were sniffing for.

3.) For a small network your inbound data is going to overweigh the outbound in most circumstances(unless your running a server of some sort) so yes that looks normal to me.

4.) Jabber is caused when signals on a NIC are handled improperly due to a faulty NIC or an improperly terminated cable jack which can cause the NIC to send out rapidly incoherent data and sometimes can bring a network to it's knees if collision domain is large enough.

5.)A crc is a hash used to calculate a number based on the data inside a frame. This CRC is recalculated by devices along the way and then is compared to the originally derived value. If they don't match, then the frame is discarded. The only issue I can think that would cause a CRC to fail by the cable is some sort of interference that scrambles the original signal, thus changing it and making the CRC by an intermediary device fail. I think the sniffer is just checking to see if any CRC's fail. I have no clue what sniffer your using so I couldn't tell you what those values are for. Check the documentation on that particular protocol analyzer for more indepth answers.

I would suggest checking out another protocol analyzer that is far more powerful, more useful and from what I can see from your sniffer, better interface. It's called ethereal and you can find it here. Hope this helps.

Farewell,
David

1) i'm sniffing for about 15 minutes..but the most btroadcast host is probly my office server gateway..so it's normal..is it?

2) yes..that what i mean it...sorry to make you confuse...internal bandwith is 100Mbps and internet bandwith is 1Mbps..i just monnitoring for 15minutes..

i'm willing to learn ethereal but it quite confusing to me..maybe i will posting capture screen shoot from ethereal..so we will discuss how to use it..thanks

It's worth it, especially if you learn berkley packet filter syntax.. it becomes unmatched for it's price and functionality. But from your bandwidth and the amount of time you snapped for, your network is way below full capacity.