I ran a packet capture on my wired network today. Each floor is separated into a /23 space and we're not even at 50% usage (many users prefer wireless). The capture I ran showed anywhere between 15-75% of total packets were ARP requests. The source/destination ip's vary, but for example if I filter by one arp destination address, I see one host querying for another every 1.2 seconds or so and making up 0.5% of the total packets captured. Obviously no one is replying to this host, so it is sending out the same ARP query over and over. Other hosts are also querying for the same destination host as well, and there are multiple destinations being queried for. It's not all the same source/destination. I could enable broadcast storm-control on our switches, but I don't think that would solve the root of the problem, which seems to be that we're seeing so much of this type of traffic. What is strange here is that the hosts being queried for appear to be DHCP clients or standard users, so I'm not sure why other clients are querying for them. Any thoughts on this traffic, or what could be done to stop it? asked 13 Jul '16, 16:42  pwz |
One Answer:
Did you use a Monitor/SPAN port, or just captured plugged in into a random port? Because if you do not did not mirror traffic you'll only see broadcast and multicast. That also explains why you see no ARP answers, because they are unicast and you won't see them without a montior/SPAN session. See this page for more information about how to capture: https://wiki.wireshark.org/CaptureSetup/Ethernet answered 13 Jul '16, 16:45  Jasper ♦♦ edited 13 Jul '16, 16:47 |
Hi Jasper,
That is a good point -- I did only capture from a random switch port which captured broadcasts visible, but not unicast arp replies. Still, it is my understanding that arp requests unanswered would prompt another arp request, which is what we are seeing.
Tomorrow I plan to perform a SPAN session with the user who brought the original issue to our attention. I hope to be able to compare their traffic to my own, and potentially find the root cause of the original issue.
Thank you for replying, it is the correct answer for the question I asked and I will mark it as such.
pwz
if you have the SPAN session you should see the ARP answers. If not you need to find out why not (the most common reasons is a wrong subnet mask, meaning that the source node thinks it can reach the destination directly while it can't). If you see the answers you need to find out why they aren't cached.