Strange kernel messages?

Kevin O'Connor kevin at
Tue Aug 10 13:27:48 BST 2004

>-----Original Message-----
>From: Pete French [mailto:pete at]
>Sent: 10 August 2004 12:53
>To: freebsd-users at; kevin at
>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
>answer too:
>>>arp: 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 ? The ifconfig output says that only IP
>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
>I understand that in order to get to from the other network
>then it needs to pass through that interface, but it does so by routing
>the packet to 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
>me :-)
This is the full explanation I've high lighted the important bits 
With !!!!
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 mailing list