Wireshark · Wireshark-users: Re: [Wireshark-users] Strange ARPs

[Martin Visser <martinvisser99@xxxxxxxxx>]

A couple of things

1. Some of the ARP intervals seem to be at regular spacings of 5 minute and 1 minute, so not so random
2. I presume 10.20.1.1 is your default gateway. When you say you don't get responses for ARPs from 10.26.1.39, you need to determine whether that router has a sane IP network.route knowledge. If it doesn't believe that 10.26.1.39 is directly reachable from the interface it receives it I expect it won't respond.
3. If your multiple NICs are configured as a bond/team/bridge then that could be a reason that ARP requests from 10.26.1.39 could be sent by the 10.20.1.39 interface. If you have some form of clustering software installed it might trigger such behaviour. Sometimes they can use gratuitous ARP http://wiki.wireshark.org/Gratuitous_ARP
4. Just check that NortelNe_01:02:03 is infact unicast (disable MAC name resolution). Some vendors register both unicast and multicast OUIs. The first byte will be even if unicast, odd if multicast.
5. Often other traffic can trigger the ARP. If another protocol has learned about a potential host (through say a DNS response) then this will help you understand why the ARP has occured. ARPs are issued to either learn about what physical address is need to send the next packet, or claim your own MAC address on the wire.

Regards, Martin

MartinVisser99@xxxxxxxxx

On Mon, May 18, 2009 at 12:39 PM, noah davids <ndav1@xxxxxxx> wrote:

This is really a question concerning the behavior of ARP and not a wireshark
question. I apologize to everyone for the misuse of the list but figured
that the readers of this list would be my best bet for getting an answer.

I have a trace captured by tcpdump on a specific interface (but displayed
with wireshark) that shows two behaviors I do not understand.

First there are unicast ARPs to a specific IP address. The destination MAC
address of the ARP requests is that of the ARP's target host. These ARPs
appear to be sent at random times. Second, the system will sometimes switch
to using the source IP address of a different interface on the system, an
interface that is on a different subnet.

I have found some information indicating that unicast pings can be some form
of test packet. But the random times leads me to believe that that is not
the case here I I would think that a test packet would be very regular).
Also I am totally stumped as to why the source IP address would change. The
system is a Red Hat 2.6 Linux kernel

A complete display of the trace and my questions can be found here
http://members.cox.net/ndav1/traces/strange_arps.html but here a couple of
sample packets

 142993 19:30:20.005254   Nec_ab:cd:ef    NortelNe_01:02:03     ARP      Who
has 10.20.1.1?  Tell 10.20.1.39
 144132 19:35:19.305579   Nec_ab:cd:ef    NortelNe_01:02:03     ARP      Who
has 10.20.1.1?  Tell 10.20.1.39
 145323 19:40:19.286200   Nec_ab:cd:ef    NortelNe_01:02:03     ARP      Who
has 10.20.1.1?  Tell 10.20.1.39
 145643 19:41:44.964578   Nec_ab:cd:ef    Broadcast                   ARP
Who has 10.20.1.1?  Tell 10.26.1.39
 145654 19:41:45.996555   Nec_ab:cd:ef    Broadcast                   ARP
Who has 10.20.1.1?  Tell 10.26.1.39

Note that 10.20.1.1's MAC address is  NortelNe_01:02:03 and it does respond
to the unicast ARPs but not to the broadcast ARPs coming from 10.26.1.39..


Noah Davids
=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Serendipity is a function of bandwidth

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe