Searching \ for '[tech]: 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
'[tech]: arp tables'
2008\08\20@070027 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, 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\20@080847 by Adam Field

flavicon
face
ARP and MAC addresses don't exist (for you) outside of your local
network. Your host only needs the MAC of the router and sends packets
there. It's only for your LAN segment, within your netmask, that the
ARP requests work. That's exactly what you're seeing going on.

On Wed, Aug 20, 2008 at 7:00 AM, Justin Richards
<spam_OUTjustin.richardsTakeThisOuTspamgmail.com> wrote:
{Quote hidden}

> -

2008\08\20@085642 by Lee Jones

flavicon
face
> 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.

Yes.

> 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.

You should only send an ARP request for IP addresses where the
network number (IP address AND'ed with net mask) matches your
own network number (on a per-interface basis).  If you want to
send a packet to an IP address which has a different network
number, then you do an ARP request for your default route's IP
address and forward the packet there for onward transmission.
(It's a little more complex if you have complex routing tables,
but this suffices for an end node with a single interface.)

                                               Lee Jones

2008\08\20@092118 by olin piclist

face picon face
Justin Richards wrote:
> but all the info I have
> gathered from the web is that there should be an individual arp entry
> for each ip address.

Why?  That doesn't make any sense.  A node only needs to know what are local
addresses, and what are addresses somone else's problem and who's problem
they are.  In most cases, all the non-local addresses are routed to a single
IP address (often called the gateway address in the IP setup for the node).
If the node can reliably determine what is a non-local address, and these
therefore go to a single IP and therefore a single MAC address, what would
be the point of caching that MAC address for multiple non-local IP
addresses?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\08\20@100929 by M. Adam Davis

face picon face
Your computer has an IP address it wants to contact.

It determines, using the subnet, whether the IP is on the local network or not.

- If it's not on the local network then it forwards the message on to
the gateway, and it never knows or cares what the eventual MAC address
is that is associated with that IP - in this case the ARP is ONLY used
to find the MAC of the gateway device if it is not known.

- If it's on the local network, then it uses ARP to find the MAC
address if an antry does not exist in its routing table already.

On 8/20/08, Justin Richards <.....justin.richardsKILLspamspam@spam@gmail.com> wrote:
> 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.

Only when the desitnation IP address is on the local subnet, as
defined by something similar to 255.255.255.0, where the first 24 bits
of the destination and host IP must match to be considered on the
local network, where the MAC address is required for proper routing.

> 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.

This is what should be happening.

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

This should not be happening.

The ARP is used only to associate a MAC address with an IP address so
that you don't have to have a router between your computer and your
local LAN.  you should not be getting ARP listings for IP addresses
that are outside your subnet.

Check the subnet and all IP settings on each computer and router, and
verify that they all agree on the subnet, gateway, etc.

-Adam

--
EARTH DAY 2008
Tuesday April 22
Save Money * Save Oil * Save Lives * Save the Planet
http://www.driveslowly.org

2008\08\20@101640 by Forrest Christian

flavicon
face
Others have replied as well, but I'll add my explanation as well,
perhaps taking it from a different angle.  Note that some of my guesses
as to most/many/some are just that - educated guesses, so please
interpret my statements like "most stacks", to mean "most of the stacks
I deal with on a daily basis".

When sending an ethernet packet, many TCP/IP stacks (especially in the
Unix world) take the destination IP address and check it against the ARP
table *first* (or perhaps "almost first") before doing any additional
processing on the packet.   If the destination IP address exists in the
ARP table, then the stack encapsulates it in an Ethernet datagram with
the destination address set to the corresponding address found in the
ARP table, and sends it out the corresponding interface, usually also
found in the ARP table.   The importance of this will become apparent a
couple of paragraphs below.

If the destination IP address is *not* found in the ARP table, then the
stack does additional processing to figure out if the packet is local to
the subnet or not.  If it's local, it does an ARP and then populates the
ARP table as appropriate (and sends the packet to that MAC address).  
If it's not local, then it sends the packet to the MAC address of the
default gateway (which may also require an ARP to determine).   Through
this process, the ARP table gets populated with records of local
machines and the default gateway.   In most Microsoft boxes,  you will
only see the local addresses in the table, since they don't do any of
the fancy stuff I'm about to describe.

In the Unix world, the kernel writers tend to be a bit more agressive
about implementing performance-improvements.   One big part of this is
if you can remember where you had to send a packet to last time for a
given IP address, you don't have to figure it out again.   As a result,
it is not uncommon to see the ARP table turn into more of a route cache
table.   Some unixes hide this fairly well (even though it is going on
behind the scenes), and don't show these entries when you do an arp -a,
and others do show the entries.   These will typically have the mac
address of the default router listed if this is going on.

In addition, to the caching of the destination address, another item
also comes into play - and that is the ICMP Redirect messages some
routers generate.   In short, these are generated when a router receives
a packet and realizes that it would be quicker if you would just send
the packet to a different MAC address instead.   It forwards the packet
and then generates an ICMP redirect back towards your TCP/IP stack which
can basically be interpreted as "I handled a packet you sent me which
was destined toward x.x.x.x.   Next time send it to mac address
xx:xx:xx:xx:xx:xx instead."   TCP/IP stacks which honor this generally
install this as an additional arp entry in the ARP table.    That way,
they can remember to send the next packets to the other router
instead.    This is pretty much only common where you either have
multiple subnets on the same physical ethernet, or you have multiple
routers on the same ethernet, or something else is configured weird.

I would guess that your Unix boxes are doing either or both of the last
two, but your Windows box isn't.

-forrest

Justin Richards wrote:
{Quote hidden}

2008\08\20@132640 by William \Chops\ Westfield

face picon face

>> 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 is called "proxy arp" and was originally implemented to allow  
subnetting, back when not all hosts understood subnetting.  Later it  
was generalized as replacement for routing knowledge in hosts in  
general.  Not all routers support full proxy ARP for all nets by  
default (it can cause interesting problems in conjunction with other  
routers, for example.)

As others have said, hosts USUALLY have some slight knowledge of  
routing, so that they will ARP for a router ("next hop") IP address  
rather than the final destination IF they decide that the final  
destination is "not local."  Hosts do not always have accurate  
knowledge of topology, however, so ARPs for non-local addresses can  
still occur.

I think "current philosophy" is still that hosts should never  
participate in actual routing protocols to learn routing...

> generates an ICMP redirect back towards your TCP/IP stack which
> can basically be interpreted as "I handled a packet you sent me which
> was destined toward x.x.x.x.   Next time send it to mac address
> xx:xx:xx:xx:xx:xx instead."

Not quite.  ICMP redirects are an IP-level thing, and do not mention  
nor contain and Mac addresses.  "I handled the packet to x.x.x.x, but  
next time use the router at y.y.y.y instead; it's closer."

The typical hierarchy generally goes like:

1) check arp cache for actual destination (performance hack)
2) check ICMP redirect table for dest.  (get "next hop" router)
3) if (local cable) then nexthop = dest; else nexthop = default_router
4) ARP for next hop.

Some hosts can have their default route point to an interface rather  
than another router, in which case anything that uses the route will  
get ARPed for (assuming that it's an ethernet-like interface, of  
course.)  I'd expect that some or many of the minimalist IP  
implementations avoid the router tables entirely and just ARP for  
everything.  That SHOULD work, given appropriate routers...

BillW


2008\08\20@174803 by Tomás Ó hÉilidhe

picon face

Here's how the routine goes:

* Your computer wants to send a packet to a certain IP address. Let's
say the address is 10.10.10.4

* Your computer consults its Route Table to see how it should get to
10.10.10.4. There are two possible ways:
   i) Straight out on the wire
   ii) Through a specified router

* If it's "straight out on the wire", then your computer sends out an
ARP request for 10.10.10.4

* However, if it's "through a specified router", then your computer
sends out an ARP request for the specified router's IP address (let's
say it's 10.10.8.1).

* When the ARP request is replied to, (whether it be with the MAC
address of the final target, or the MAC address of the immediate
router), the MAC address is used as the destination for sending out the
frame which contains the packet.

That's all there is to it. The only thing that could complicate things
is if 10.10.8.1 (i.e. the address of the router) were not accessible
directly on the wire -- in that case you might need to go through a
router to get to the desired router (admittedly I've never seen such a
setup but I think it's conceivable).

2008\08\22@063555 by Vitaliy

flavicon
face
Tomás Ó hÉilidhe wrote:
> That's all there is to it. The only thing that could complicate things
> is if 10.10.8.1 (i.e. the address of the router) were not accessible
> directly on the wire -- in that case you might need to go through a
> router to get to the desired router (admittedly I've never seen such a
> setup but I think it's conceivable).

If I really understand what you mean, this scenario actually happens all the
time on the internet:

http://en.wikipedia.org/wiki/Address_Resolution_Protocol#Examples

Vitaliy

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