Strange kernel messages?
kevin at ziptek-technologies.co.uk
Tue Aug 10 13:27:48 BST 2004
>From: Pete French [mailto:pete at twisted.org.uk]
>Sent: 10 August 2004 12:53
>To: freebsd-users at uk.freebsd.org; kevin at ziptek-technologies.co.uk
>Subject: RE: Strange kernel messages?
>> This answer is very simplistic and is only designed to allow you to
>> visualize the problem. To fully understand the problem you will need to
>> quite a bit of reading.
>Hmmm. Now I thought I understood this (and I even implemnted ARP once
>upon a time). So I have a very simple question which I do not see the
>>>arp: 10.0.0.100 moved from 00:c0:4f:26:a8:83 to 00:08:c7:3b:67:93 on fxp0
>How can ether card 00:08:c7:3b:67:93 ever be giving an ARP response
>for 10.0.0.100 ? The ifconfig output says that only IP 192.168.254.100
>is on that hardware. Arp maps IP addresses to ether addresses regardless
>of layer 3 the way I understood it, so an entry of 00:08:c7:3b:67:93 is
>not correct for 10.0.0.100.
>I understand that in order to get to 10.0.0.100 from the other network
>then it needs to pass through that interface, but it does so by routing
>the packet to 192.168.254.100 and arping for *that* address on the
>ether surely ?
>Quite happy to go do "quite a bit of reading" - but I thought I had done
>all the necessary reading back in the 1980's so this is kind of surprising
This is the full explanation I've high lighted the important bits
On a network that supports ARP, when host A (the source) broadcasts
an ARP request for the network address corresponding to the IP
address of host B (the target), host B will recognize the IP address
as its own and will send a point-to-point ARP reply. Host A keeps
the IP-to-network-address mapping found in the reply in a local
cache and uses it for later communication with host B.
If hosts A and B are on DIFFERENT physical networks, host B will not
receive the ARP broadcast request from host A and cannot respond to
it. However, if the physical network of host A is connected by a
gateway to the physical network of host B, the gateway will see the
ARP request from host A. Assuming that subnet numbers are made to
correspond to physical networks, the gateway can also tell that the
request is for a host that is on a different physical network from
the requesting host !!!!!BUT YOU HAVE BOTH!!!! . The gateway can then
respond for host B !!!! WITH IT'S MAC ADDRESS !!!!!!
saying that the network address for host B is that of the gateway
itself. Host A will see this reply, cache it, and send future IP
packets for host B to the gateway. The gateway will forward such
packets to host B by the usual IP routing mechanisms. The gateway
is acting as an agent for host B, which is why this technique is
called "Proxy ARP"; we will refer to this as a transparent subnet
gateway or ARP subnet gateway.
When host B replies to traffic from host A, the same algorithm
happens in reverse: the gateway connected to the network of host B
answers the request for the network address of host A, and host B
then sends IP packets for host A to gateway. The physical networks
of host A and B need not be connected to the same gateway. All that
is necessary is that the networks be reachable from the gateway.
With this approach, all ARP subnet handling is done in the ARP
subnet gateways. No changes to the normal ARP protocol or routing
need to be made to the source and target hosts. From the host point
of view, there are no subnets, and their physical networks are
simply one big IP network. If a host has an implementation of
subnets, its network masks must be set to cover only the IP network
number, excluding the subnet bits, for the system to work properly.
More information about the Ukfreebsd