Searching \ for '[EE]: arp tables' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/mems.htm?key=table
Search entire site for: 'arp tables'.

Exact match. Not showing close matches.
PICList Thread
'[EE]: arp tables'
2008\08\21@083204 by Justin Richards

face picon face
Hi Folks,

my understanding of arp tables is that when a layer 3 packet is
destined for a given ip an arp request is sent out the adapter.

The arp request is in the form of 'who has ip 192.168.0.1'.  If that
host 192.168.0.1 is on the network segment then it will reply with its
mac address.  This is then added to the arp table and the packet is
encapsulated with the layer 2 frame with the destination mac it just
learnt.

If the destination host is via a router then the router will respond
with its mac address and the packet is encapsulated with that mac
address and the router takes care of it.

This appears to agree with the info when googled.

I am experincing conflicting results on what appears to be identicle
setups as follows:-

1. Any destination ip address handled by the gateway device does NOT
result in an arp entry but all local ip address are added.
2. Any destination ip address handled by the gateway device does
result in an arp entry but all local ip address are added.

Perhaps this should not go to the piclist and not [EE], but all the info I have
gathered from the web is that there should be an individual arp entry
for each ip address.

Any explaination as to why a setup would behave one way or the other.

Platforms
2 x TRU64 on Alpha1400's where i get both results
1 x XP profession where I dont get an entry for remote hosts.

I am using pings to test and I know there are connections to other remote hosts.



Cheers Justin

2008\08\21@105810 by Tomás Ó hÉilidhe

picon face

I've already responded to this under the "OT" tag so take a look at that
reply if you're interested.

For the meantime, I'll reply in sequence below:


Justin Richards wrote:
> Hi Folks,
>
> my understanding of arp tables is that when a layer 3 packet is
> destined for a given ip an arp request is sent out the adapter.
>  


Yes, the purpose of the ARP request is to figure out what MAC address
the frame should be sent to.


> The arp request is in the form of 'who has ip 192.168.0.1'.  If that
> host 192.168.0.1 is on the network segment then it will reply with its
> mac address.


Correct.


>   This is then added to the arp table and the packet is
> encapsulated with the layer 2 frame with the destination mac it just
> learnt.
>  


Correct.


> If the destination host is via a router then the router will respond
> with its mac address and the packet is encapsulated with that mac
> address and the router takes care of it.
>  


If you go through a router such as 10.10.10.1, then you send out an ARP
request for 10.10.10.1, you do *not* send out an ARP request for
192.168.0.1.

In order to find out which router you should go through to get to a
particular address (or even if you need to go through a router at all),
you consult your Route Table.


> I am experincing conflicting results on what appears to be identicle
> setups as follows:-
>
> 1. Any destination ip address handled by the gateway device does NOT
> result in an arp entry but all local ip address are added.
>  


Correct. But it *will* results in the router's address being added to
the ARP table.


> 2. Any destination ip address handled by the gateway device does
> result in an arp entry but all local ip address are added.
>  

You'll never see an ARP table entry for a device that isn't on the same
Ethernet wire. (Please don't bring up the topic of VPN's haha)

I tried to give an explanation of how it all works in my other "OT" reply.

2008\08\21@134334 by Justin Richards

face picon face
Hi Tomás,

thankyou very much for your assistance here.  For some reason i did
not get the [OT] reply.

As you have pointed out I failed to realise that the arp request and
resulting arp enrty will be/should be for the gateway/router and not
for the destination IP.

Therefore the only conclusion I can draw is that the default gateway
is not configured on the install that has the extensive arp table  ie
an arp table that clearly has an arp entry for every remote device
that it connects to.

Does this sound plausable?.

For interest sake, each of these arp table entries has the ip address
of the remote device but the mac address of the gateway.  The other
install only has an entry for devices on the wire as (in my hindsight)
expected.

I will check the default gateway settings out tomorrow.  The install
that is behaving strange is out of my admin domain (5000kms away) but
from what I can gather they are having other problems that may be
related.  This is why I ended up with a capture of their arp table.

Thankyou once again.

Cheers Justin


On Thu, Aug 21, 2008 at 10:57 PM, Tomás Ó hÉilidhe <spam_OUTtoe_listTakeThisOuTspamlavabit.com> wrote:
{Quote hidden}

>

2008\08\21@172408 by Herbert Graf

flavicon
face
On Thu, 2008-08-21 at 20:31 +0800, Justin Richards wrote:
> Hi Folks,
>
> I am experincing conflicting results on what appears to be identicle
> setups as follows:-
>
> 1. Any destination ip address handled by the gateway device does NOT
> result in an arp entry but all local ip address are added.
> 2. Any destination ip address handled by the gateway device does
> result in an arp entry but all local ip address are added.

Please correct me if I'm wrong, but I think you're confused as to the
purpose of "arp".

ARP is only used for "local" addresses, that means IPs that match your
subnet mask.

So, say your IP is 192.168.1.1, your default gateway is 192.168.1.254,
and your subnet mask is 255.255.255.0

If you try to send something to 192.168.1.45 the following occurs:

1) The subnet mask check will result in 192.168.1.45 being identified as
being on your local subnet.
2) An ARP request will be sent out asking for the MAC of the owner of
192.168.1.45
3) An ARP response will be received, the MAC will be added to the local
table, and the packet will be sent to that MAC.

Now, if you try to send something to 192.168.2.45:

1) the subnet mask check will result in 192.168.2.45 NOT being on the
local subnet
2) as a result, the packet will be sent to the default gateway
192.168.1.254. If the default gateway's MAC isn't "fresh", and ARP
request will be sent for the GATEWAY's IP, NOT 192.168.2.45.
3) the packet destined for 192.168.2.45 will instead be sent to the MAC
of the gateway, which we assume will forward it on to wherever it needs
to get to.

Basically, anything on your local domain is sent directly to that
machine, anything else is sent to the gateway to your domain, which will
then forward it on as necessary in order to reach the final desination.

Note: I am ignoring some more "complicated" network configs that could
muddy up what I've described. Also, VPNs are a special case where all
this sort of stuff becomes a little more complicated (although not much
more so).

TTYL

2008\08\21@180033 by Justin Richards

face picon face
Hi Graf,

my understanding is inline with yours.  Or at least it is now but I
still see an anomaly.

I perhaps didnt describe the problem too well using the 2 conflicting
behaviours below of two hosts that were apparently configured
identically.

And in your dicussion below I am curious as to what would be found in
the arp table if there was no gateway address configured.
I guess in this case the host has the choice of either destination
unreachable or put an arp request on the wire for the ip that is not a
match with  that hosts netmask.  And then if the router responds the
packet will be sent.

The hosts in question are Apha 1400 running tru64.

Cheers Justin

On Fri, Aug 22, 2008 at 5:24 AM, Herbert Graf <.....mailinglist4KILLspamspam@spam@farcite.net> wrote:
{Quote hidden}

> -

2008\08\22@140700 by Herbert Graf

flavicon
face
On Fri, 2008-08-22 at 06:00 +0800, Justin Richards wrote:
> Hi Graf,
>
> my understanding is inline with yours.  Or at least it is now but I
> still see an anomaly.
>
> I perhaps didnt describe the problem too well using the 2 conflicting
> behaviours below of two hosts that were apparently configured
> identically.
>
> And in your dicussion below I am curious as to what would be found in
> the arp table if there was no gateway address configured.
> I guess in this case the host has the choice of either destination
> unreachable or put an arp request on the wire for the ip that is not a
> match with  that hosts netmask.  And then if the router responds the
> packet will be sent.

I don't know what every OS will do in that case, and I also am not sure
if there is an RFC to cover it.

That said, I know my linux boxes, when there is no default gw
configured, immediately respond with a "destination unreachable", I
don't think an ARP request goes out.

In fact (and I might be completely wrong here), I'd personally find that
if a stack sent out an ARP request for a NON local address (an address
that doesn't match the netmask) that would be a sign of a broken stack.
It just doesn't make sense. It's like looking for New York state on a
map of France.

If that's what you're hardware is doing I suppose you'll have to figure
something out.

TTYL

2008\08\22@145421 by William \Chops\ Westfield

face picon face

On Aug 22, 2008, at 11:06 AM, Herbert Graf wrote:

> In fact (and I might be completely wrong here), I'd personally find  
> that
> if a stack sent out an ARP request for a NON local address (an address
> that doesn't match the netmask) that would be a sign of a broken  
> stack.

It's somewhat debated just how much "hosts" are supposed to know  
about routing, and it's not THAT uncommon for a host to just ARP for  
everything.  A well-behaved router will answer appropriately (ie it  
lies!) if it has a route to the ARPed host...

Prior to well-working DHCP (Dynamic Host Configuration Protocol),  
this was one of the few ways to get a host working on a network  
without having to know lots of little details that end users weren't  
likely to know (What's my subnet mask?  What IS the default router?)  
A host can also guess wrong about which destinations are "local" due  
to thinks like variable length subnet masks, issues of network class,  
multiple subnets on one cable and so on.  For example, cisco terminal  
servers (when they're not also routers) have also been willing to  
utilize ARP for ALL destinations since forever, and cisco routers  
will happily answer such ARP requests.  It's also nice for minimal IP  
implementations on very small hosts.

ARP started out as a way to resolve a local IP address to a physical  
ethernet address, but it works quite well as a generalized "What is  
the physical destination for this high-level address" protocol.  I  
like it when a protocol shows that much flexibility.  It's a MUCH  
better idea than having hosts try to listen to routing protocol  
messages.  I have particularly fond memories of "ARP Storms", and the  
one well-meaning host/router that responded an arp for an IP  
broadcast address with the HW broadcast address...
(Host that thinks the IP broadcast address is 0.0.0.0 gets a packet  
(via broadcast) for 255.255.255.255.  "Hah!", it thinks.  "I'm a  
router and someone wants me to forward this packet, or surely I would  
not have received it.  I do not have this particular route, so I will  
ARP for it!" (Note that ALL similarly configured (early desktop unix)  
workstations get the broadcast and do the same thing; that's a  
"broadcast storm.")  Now if some somewhat differently mis-configured  
says "idiot. 255.255.255.255 maps to FFFF:FFFF:FFFF", and all the  
first set happily forward their packet there... Instant meltdown!  
Whee!)

BillW


2008\08\22@160732 by Robin D. Bussell

flavicon
face
Along these sort of lines, does anyone know of any nifty protocol tricks
that could be used to ascertain the IP address of a device (that has no
interface other than Ethernet) given, say , a packet sniffer and a means
of injecting packets?
I did manage to use ARP in this way once, but only because the device in
question would send out an ARP request on power up and thus gave its IP
away.

Cheers,
    Robin.


{Original Message removed}

2008\08\22@162457 by Charles Craft

picon face
www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094adb.shtml

As I understand the setup you have two identical machines at two locations so they are talking to different routers?
Easiest way to diagnose things at this level are to stick a sniffer or a host with Wireshark out there.

Is there a chance that Proxy Arp is enabled on only one of the routers?

thanks
chuckc


{Original Message removed}

2008\08\22@184518 by William \Chops\ Westfield
face picon face

On Aug 22, 2008, at 1:07 PM, Robin D. Bussell wrote:

> does anyone know of any nifty protocol tricks
> that could be used to ascertain the IP address of a device (that  
> has no
> interface other than Ethernet) given, say , a packet sniffer and a  
> means
> of injecting packets?

Broadcast ICMP PING packets.  Useful things; we fought hard to keep  
them allowed when they talked about making them illegal...

BillW

2008\08\22@190636 by Charles Craft

picon face
Broadcast ping is great for filling the ARP cache for network discovery.
Unless you're looking for Windows boxes - they don't respond.

"            An ICMP Echo Request destined to an IP broadcast or IP
           multicast address MAY be silently discarded.

RFC1122                      INTERNET LAYER                 October 1989

           DISCUSSION:
                This neutral provision results from a passionate debate
                between those who feel that ICMP Echo to a broadcast
                address provides a valuable diagnostic capability and
                those who feel that misuse of this feature can too
                easily create packet storms.
"

William "Chops" Westfield wrote:
{Quote hidden}

2008\08\22@203952 by peter green

flavicon
face
Charles Craft wrote:
> Broadcast ping is great for filling the ARP cache for network discovery.
> Unless you're looking for Windows boxes - they don't respond.
I'm pretty sure they do if the firewall is off, of course that is
increasingly rare nowadays.

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...