0

We have ~200 hosts running windows 10 and ~40 ip cameras all working with ip addresses from 10.100.0.0/16 almost all of them sending arp requests to 169.254.0.0/16. We have also virtual machines running on VMWare equipment and some of them are also sending those requests. print screen from wireshark

Ip cameras are known to have some weird network behavior, but regular PC's all together requesting apipa - is very strange.

Our theory was:

  1. May be one host starts requesting apipa - and the rest get involved.
  2. Broken NIC driver or OS image or some software generating those requests

What is Your thoughts?

Improve this question
1
  • As it turned out - software ( license manager client service ) was generating those arp packets, for no reason. The best tool to analyze it on Windows - Microsoft Message Analyzer ( retired but still do the job). To solve - apply IPSecurity rule through GPO.
    – v.doro2
    May 19, 2022 at 3:09

1 Answer 1

Reset to default
1

ARP generally uses broadcasts that are propagated throughout the broadcast domain. If you think there's too much ARP traffic you'll need to split the broadcast domain (usually by VLANs).

Zeroconf/APIPA/link-local addressing is commonly a sign for missing DHCP - either a server is missing/malfunctioning, the scope is exhausted, or the clients/hosts lack DHCP support. With DHCP you can specify a lease time and the clients should significantly reduce their duplicate address detection via ARP.

To check whether there's a specific client or type sourcing all those ARP requests, capture the packets and check the source MAC addresses for their origin devices. While you're at it, verify that DHCP is working correctly as well.

Improve this answer
5
  • All devices have ip addresses assigned via dhcp or static ( cameras ). Subnet not appear to be exhausted /16=65535 hosts available we have maybe 1000 at most. All devices working properly - internet access, lan, smb - everything works - just this strange behavior - very interesting to resolve the source of this issue.
    – v.doro2
    Feb 7, 2022 at 13:50
  • So those device send ARP requests for 169.254.0.0/16 addresses without actually using any of those? That can be considered broken/buggy. If you assign those addresses statically or per DHCP, that is not allowed per RFC 3927.
    – Zac67
    Feb 7, 2022 at 13:55
  • Yes, PCs have DHCP assinged addresses from 10.100.0.0/16 pool. IP cameras have static ip addresses from the same subnet. Cameras have even more strange behavior - they send ARP probes for their own address - that they already have and APIPA ARP probes and requests. Our license servers - VMs on VMWare also send APIPAs every now and then. We do not assign those addresses ( apipas ) via DHCP - it would be totally wrong of course.
    – v.doro2
    Feb 7, 2022 at 14:06
  • You never see some packet originating from 169.254.0.0/16 only ARP probes and ARP requests.
    – v.doro2
    Feb 7, 2022 at 14:07
  • ARP probing their own address (duplicate address detection) by ARP is correct and useful when a link is coming up or a DHCP lease is (re)new(ed). Excessive ARPing is a bug - open a ticket with the vendor or, as a workaround, try to filter those ARP requests on the access ports. Moving those devices out of the production LAN and into a separate zone (IoT) should also be a good idea.
    – Zac67
    Feb 7, 2022 at 14:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .