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

Discussion in 'Linux Networking' started by Andreas Stallmann, Apr 20, 2009.

  1. 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
     
    Andreas Stallmann, Apr 20, 2009
    #1
    1. Advertisements

  2. They are both correct.
    Both interfaces are in the same VLAN. Either MAC address is correct.
    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
     
    David Schwartz, Apr 22, 2009
    #2
    1. Advertisements

  3. Hello,

    David Schwartz a écrit :
    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, Apr 22, 2009
    #3
  4. Andreas Stallmann

    Joe Pfeiffer Guest

    It's not clear to me why the weak host model would be considered either
    a feature or a bug... why a feature?
     
    Joe Pfeiffer, Apr 23, 2009
    #4
  5. It makes routing possible.

    DS
     
    David Schwartz, Apr 23, 2009
    #5
  6. Andreas Stallmann

    Joe Pfeiffer Guest

    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?
     
    Joe Pfeiffer, Apr 23, 2009
    #6
  7. Andreas Stallmann

    Bill Marcum Guest

    Because it's documented. :)
     
    Bill Marcum, Apr 23, 2009
    #7
  8. 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, Apr 24, 2009
    #8
  9. Andreas Stallmann

    Joe Pfeiffer Guest

    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?
     
    Joe Pfeiffer, Apr 24, 2009
    #9
  10. 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.
    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.
    Because the address is assigned to the host, not the interface.
    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.
    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/magazine/2007.09.cableguy.aspx

    DS
     
    David Schwartz, Apr 24, 2009
    #10
  11. http://cactuswax.net/articles/2006-09-21-arp_ignore.html
    explains this behavior, and how to modify that behavior to
    the way you expect it... long story short:
    echo 2 > /proc/sys/net/ipv4/conf/all/arp_ignore
    echo 1 > /proc/sys/net/ipv4/conf/all/arp_announce

    Hope this helps,
     
    Charles Polisher, Apr 26, 2009
    #11
  12. Andreas Stallmann

    Joe Pfeiffer Guest

    (note that I'm not the guy trying to do it, I'm just pursuing some
    curiosity)

    Thanks -- that's really interesting. arp_ignore 2 is what a naive user
    would expect as default...
     
    Joe Pfeiffer, Apr 26, 2009
    #12
  13. I would think a naive user would expect the default to make all
    reasonable configurations work. Generally, you should have to expect
    to go out of your way to make things not work.

    In my experience, users are very rarely surprised that something works
    when they wouldn't expect it to. But they're very easily surprised
    when things don't work and they might expect they would. Technical
    people to err in the direction of assuming people will expect things
    to break at the drop of a hat, and this is in reality very rarely
    true.

    I'm not sure what will actually happen in this case, but I suspect
    most people would in fact naively expect the system to make it work so
    long as there's physical connectivity.

    DS
     
    David Schwartz, Apr 27, 2009
    #13
  14. Hi!

    Thanks all for your answers. It helped solving the problem.

    TNX,

    A.
     
    Andreas Stallmann, May 7, 2009
    #14
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.