Score:0

APIPA ARP requests are send all over the network

cn flag

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?

v.doro2 avatar
cn flag
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.
Score:1
ru flag

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.

v.doro2 avatar
cn flag
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.
Zac67 avatar
ru flag
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](https://datatracker.ietf.org/doc/html/rfc3927).
v.doro2 avatar
cn flag
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 avatar
cn flag
You never see some packet originating from 169.254.0.0/16 only ARP probes and ARP requests.
Zac67 avatar
ru flag
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.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.