• May 22, 2012, 10:31:29 PM
Welcome, Guest. Please login or register. Registration is free.
Did you miss your activation email?

Author Topic: how to find application/services/process causing broadcast ???  (Read 329 times)

0 Members and 1 Guest are viewing this topic.

Offline dekdek

  • Jr. Member
  • **
  • Posts: 37
hi everyone,

i know it's not a typical Avaya question but who knows ? maybe someone
could give me an answer or share his knwonledge/experience.
thanks in advance.

i've recently created a shell script who listen (via tcpdump) ethernet broadcast and
then tell me to the top 10 arp talkers on our LAN (maybe i should post in the script section).
It's based on finding "ARP, Request who-has" into the captured frames.
i've created this script because i noticed that in Cacti RRD graphs (showing Passport fiber port non-unicast frames),
non-unicast frames increased every hour abnormally.

and i've found 10/15 hosts who send every hour many ARP Request to all the IP range. It's about 50 broadcast per second
coming from these 10/15 hosts , every hour and for about 15 minutes. After 15 minutes, broadcast stop and back again
next hour.

I did not found the way on these hosts (Windows XP mainly) to determine the application that cause
broadcast flow. I've tried :
 1/ scan (virus, worm, trojan) and nothing was found
 2/ disable services one by one and broadcast did'nt stop
 3/ task manager and process manager during a broadcast sending and i've seen nothing really obvious.
 4/ start a new topic in my favorite ever forum....

Cris


Offline Michael McNamara

  • Administrator
  • Hero Member
  • *****
  • Posts: 2517
    • Michael McNamara
Re: how to find application/services/process causing broadcast ???
« Reply #1 on: December 05, 2011, 11:22:14 PM »
Hi Cris,

I just noticed your post... sorry about that. Are you still experiencing broadcast traffic issues?

I usually monitor the broadcast traffic (non-unicast frames) utilizing MRTG (similar to RRD). When I notice there's a problem I usually manually perform a packet trace and examine the trace to understand what's going on. It's a very manual process.

Cheers!
We've been helping network engineers, system administrators and technology professionals since June 2009.
If you've found this site useful or helpful, please help me spread the word. Link to us in your blog or homepage - Thanks!