linux system is asked for mac address of eth0 and replies withaddress of eth1 - how come?

Hi there!

We've some trouble with a Linux System (a redhead based CISCO server
running kernel 2.4.21-37.ELsmp): We are arping'ing for the eth0 ip
of our system from an other Linux box. Strangely, the first two or three
replies do not contain the mac address of the eth0 interface, but of
the eth1 interface.

Both interfaces are configured and pluged into the same VLAN (there's
just one flat VLAN available unfortunately), but have IPs from two
different subnets. My idea is, that the eth1 interface feels
responsible for routing to the eth0 interface, and thus sometimes
replies to the arp request with it's own mac address. IP forwarding
is off, though.

Is this a bug or a feature? If it's the latter, do you see any chance
to switch this behaviour off? If it's the first, do you know in which
kernel release this has been fixed?

Thanks a lot for your answers.

Cheers,

Andreas
--
Es gibt mehr Ding zwischen Himmel und Erde als Deine Schulweisheit Dich
träumen läßt.

On Apr 20, 8:27*am, Andreas Stallmann <andreas.stallm...@web.de>
wrote:

> We've some trouble with a Linux System (a redhead based CISCO server
> running kernel 2.4.21-37.ELsmp): We are arping'ing for the eth0 ip
> of our system from an other Linux box. Strangely, the first two or three
> replies do not contain the mac address of the eth0 interface, but of
> the eth1 interface.

They are both correct.

> Both interfaces are configured and pluged into the same VLAN (there's
> just one flat VLAN available unfortunately), but have IPs from two
> different subnets. My idea is, that the eth1 interface feels
> responsible for routing to the eth0 interface, and thus sometimes
> replies to the arp request with it's own mac address. IP forwarding
> is off, though.

Both interfaces are in the same VLAN. Either MAC address is correct.

> Is this a bug or a feature? If it's the latter, do you see any chance
> to switch this behaviour off? If it's the first, do you know in which
> kernel release this has been fixed?

It's neither a bug nor a feature, simply a consequence of the way you
have things set up.

http://linux-ip.net/html/ether-arp.html
See the section on ARP flux.

IMO, you should not have two physical interface in the same VLAN with
different configurations. The interfaces should either be redundant,
they should be bridging, or they should serve some other well-defined
and supported purpose. (Or you should just use one interface.)

DS

Hello,

David Schwartz a écrit :
>
> It's neither a bug nor a feature, simply a consequence of the way you
> have things set up.

It is also a consequence of the weak host model enforced by the Linux IP
stack. So I believe this can be considered as a feature.

Pascal Hambourg <boite-a-(E-Mail Removed)> writes:
>
> David Schwartz a écrit :
>>
>> It's neither a bug nor a feature, simply a consequence of the way you
>> have things set up.
>
> It is also a consequence of the weak host model enforced by the Linux
> IP stack. So I believe this can be considered as a feature.

It's not clear to me why the weak host model would be considered either
a feature or a bug... why a feature?

On Apr 22, 6:15*pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:

> It's not clear to me why the weak host model would be considered either
> a feature or a bug... *why a feature?

It makes routing possible.

DS

David Schwartz <(E-Mail Removed)> writes:

>> On Apr 22, 6:15*pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:

>>>Pascal Hambourg <boite-a-(E-Mail Removed)> writes:
>>
>>> David Schwartz a écrit :
>>>
>>>> It's neither a bug nor a feature, simply a consequence of the way you
>>>> have things set up.
>>
>>> It is also a consequence of the weak host model enforced by the Linux
>>> IP stack. So I believe this can be considered as a feature.
>>
>>> It's not clear to me why the weak host model would be considered either
>>> a feature or a bug... *why a feature?
>
> It makes routing possible.

Ah... after reading up on host models, it turns out I was asking the
wrong question. Why is the behavior described (the MAC address of the
"wrong" NIC is the response to an ARP request) a consequence of Linux's
weak host model?

On 2009-04-23, Joe Pfeiffer <(E-Mail Removed)> wrote:
>
>
> It's not clear to me why the weak host model would be considered either
> a feature or a bug... why a feature?

Because it's documented.

On Apr 22, 8:30*pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:

> Ah... *after reading up on host models, it turns out I was asking the
> wrong question. *Why is the behavior described (the MAC address of the
> "wrong" NIC is the response to an ARP request) a consequence of Linux's
> weak host model?

The only reason one NIC would be the "wrong NIC" would be if the other
interface owned the IP address. But in Linux's host model, the IP
addresses belong to the machine, not the interface. So there is no
"wrong NIC".

If the IP address belonged to one interface, yet another interface
responded to an ARP for that address, it would be reasonable to ask
why the "wrong NIC" responded. But since that is not the case, there
is no "wrong NIC".

DS

David Schwartz <(E-Mail Removed)> writes:

> On Apr 22, 8:30*pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
>
>> Ah... *after reading up on host models, it turns out I was asking the
>> wrong question. *Why is the behavior described (the MAC address of the
>> "wrong" NIC is the response to an ARP request) a consequence of Linux's
>> weak host model?
>
> The only reason one NIC would be the "wrong NIC" would be if the other
> interface owned the IP address. But in Linux's host model, the IP
> addresses belong to the machine, not the interface. So there is no
> "wrong NIC".
>
> If the IP address belonged to one interface, yet another interface
> responded to an ARP for that address, it would be reasonable to ask
> why the "wrong NIC" responded. But since that is not the case, there
> is no "wrong NIC".

This is, of course, why I put "wrong" in scare quotes. We'll try again.

Someone has, for reasons of his own, attempted to assign one IP address
to one NIC and another IP address to the other NIC (and we'll note in
passing that ifconfig certainly accepts arguments and displays
configurations in a way that would encourage the unwary to believe that
the IP address is assigned to the particular card).

When ARP requests the MAC address associated with a particular IP
address, the MAC address for a NIC other than that which ifconfig
reports as associated with that particular IP address may be reported.
Why is this behavior a necessary consequence of the weak host model, and
why should it be regarded as a feature rather than simply a fact? For
that matter, why is associating the IP address with the host rather than
the NIC necessary to the weak host model? Or does "weak host model"
mean something here other than I'm finding on the web, i.e. that a host
may respond to IP addresses other than its own?

On Apr 23, 9:12*pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:

> Someone has, for reasons of his own, attempted to assign one IP address
> to one NIC and another IP address to the other NIC (and we'll note in
> passing that ifconfig certainly accepts arguments and displays
> configurations in a way that would encourage the unwary to believe that
> the IP address is assigned to the particular card).

I agree that it's accepted and displayed in a way that encourages
that, but that is in fact not what he has done. In particular, packets
with either address as source or destination may be sent or received
on either interface. As far as the system is concerned, he has
assigned an address to the machine and a network to the interface.

> When ARP requests the MAC address associated with a particular IP
> address, the MAC address for a NIC other than that which ifconfig
> reports as associated with that particular IP address may be reported.

Correct. That IP is in fact reachable through that MAC. It may be, for
all this host knows, the only interface on which that IP is reachable
on that network.

> Why is this behavior a necessary consequence of the weak host model,

Because the address is assigned to the host, not the interface.

> and
> why should it be regarded as a feature rather than simply a fact?

Because it permits the IP address to be reachable even if the
interface isn't. It's part of the host model that makes routing
possible. The idea is that you only have to make the machine reachable
in order to reach it. You don't have to worry about creating
reachability to the "wrong" interface and being unable to reach a
machine.

>*For
> that matter, why is associating the IP address with the host rather than
> the NIC necessary to the weak host model? *Or does "weak host model"
> mean something here other than I'm finding on the web, i.e. that a host
> may respond to IP addresses other than its own?

The definition of a weak host model is that packets addressed to an IP
address assigned to any of the host's interfaces are accepted
regardless of which interface they are received on and packets with
any address assigned to any interface on the machine may be sent from
any interface. This is sometimes described as "associating the IP
address with the host rather than the NIC" because it makes no
difference in any scenario (but interface failure) what interface an
address is assigned on. It's the definition of the weak host model.

http://technet.microsoft.com/en-us/m....cableguy.aspx

DS