It's probably either some legitimate device probing for active addresses, or it's an attack, probing for active addresses. It must be fairly consistent, since arp cache entries generally time out after four hours. Running debug arp isn't really going to help pin down where the packets are coming from that are causing all of these addresses to be probed...
What you need is debug ip packet with an acces list, and then make certain you can see the traffic that's coming through causing the arp requests. So, say you have some ethernet segment that has 10.1.1.1, 10.1.1.2, 10.1.1.3, and 10.1.1.4 on it, and you keep getting a bunch of incomplete arp's in the table. The way to catch the packets causing these incomplete arp's being built is:
access-list 101 deny any host 10.1.1.1
access-list 101 deny any host 10.1.1.2
access-list 101 deny any host 10.1.1.3
access-list 101 deny any host 10.1.1.4
access-list 101 permit any 10.1.1.0 0.0.0.255
debug ip packet 101
Now, this should work with cef enabled (I just tried it in the lab, and it worked on a 2600 and a 7200), since packets with no adjacency table entry in the cef table should be punted for processing, and then fail encap. They should look like this:
1w0d: IP: s=208.0.10.4 (Serial0/0), d=208.0.6.101 (FastEthernet0/0), g=208.0.6.101, len 100, forward
1w0d: IP: s=208.0.10.4 (Serial0/0), d=208.0.6.101 (FastEthernet0/0), len 100, encapsulation failed
Note the second ecnap failed. The access list should prevent you from seeing any legitimate traffic to known hosts on the network. Once you know what the source of the traffic it, you can try to figure out what sort of traffic it is, and if you need to try and keep it from continuing to come into your network.
Russ.W
