["noah davids" <ndav1@xxxxxxx>]

Thank you Martin,

I agree that some of the ARPs happen at 5 min intervals - which is the ARP 
cache timeout, but why are the rest occurring and why are there gaps, 
instead of at every 5 minute interval (I know that pings are sent every 5 
minutes so that it is not an issue of no arp is necessary because there is 
no traffic).

Yes 10.20.1.1 is the default gateway. And no the route is not connected to 
10.26.1.0/24. I agree I would not expect it to send a reply. But then again 
using arping I have sent ARPs using IP addresses from bogus networks and 
gotten replies from other devices. It appears that they just swap the IP 
addresses in the ARP packet, add in their own MAC address, and send the 
reply back to the Ethernet address without caring that technically the IP 
address is unreachable. Of course this device has every right to behave 
differently. Unfortunately I cannot test 10.20.1.1 that way.

There are 4 NICs, two are bonded to crate 10.20.1.39 and two are bonded to 
create 10.26.1.39. The individual NICs do not have an IP address. No 
clustering software.

Good idea unfortunately it is 00 12 83 01 02 03 which I believe is unicast



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

----- Original Message ----- 

> Message: 3
> Date: Tue, 19 May 2009 10:46:11 +1000
> From: Martin Visser <martinvisser99@xxxxxxxxx>
> Subject: Re: [Wireshark-users] Strange ARPs
> To: Community support list for Wireshark
> <wireshark-users@xxxxxxxxxxxxx>
> Message-ID:
> <b3739b0c0905181746s44445da3m6220583e2e59c368@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="utf-8"
>
> 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