Post by thread:[EE]: arp tables

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

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.

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_listTakeThisOuTlavabit.com> wrote: {Quote hidden}> > 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. > >

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

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 <.....mailinglist4KILLspam@spam@farcite.net> wrote: {Quote hidden}> 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 > > -

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

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

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