Re: 2 nics, 1 network, puzzle?
> For a machine that is multihomed (has more than one IP network interface
> assigned an IP address), any of the IP addresses for the machine are
> valid and equally useable. I think your Linux system is responding in a
> reasonable way as both network interfaces are receiving ICMP echo
> requests, and both are apparently answering. I don't think there is a
> bug here.
For when the system is replying to a ping, I can see what you are saying.
Because... the reply to a ping request is just an IP packet (ICMP packet?)
which I assume does have to be routed somehow inside the kernel. I could
understand the kernel just picking any available route to the destination
in question, even if it's not the same route that the ping request
originally came in on. So a ping to .131 that came in on interface .131
could conceivably be replied to from interface .130, and I wouldn't be too
surprised by that behavior.
What is blowing my mind is that the ping request is actually entering the
system on the wrong interface, presumably because the system is responding
to my switch's ARP query on the "wrong" interface.
I think that if I unplug the network cable attached to .131, nobody on the
network should be able to ping the .131 interface anymore, unless perhaps
I was doing some really tricky (and *explicit*) proxy-ARP magic, which I'm
not, or maybe if the system was a router, which it isn't.
Even if my two-card-one-network configuration is outside the bounds of
standardized IP practices, the kernel still has to deal with this case
somehow, and I can't see why it would ever make sense to arbitrarily
answer ARP requests on the wrong interface -- even when that wrong
interface happened to be on the right network.
----------
Other information:
The two network cards are 3Com 3C905CX-TX-NM cards for 100BaseTX.
I also want to have these multiple interfaces so that my users can see the
system as being multiple systems, each with their own IP addresses (at
least as far as the users can tell). I know that IP aliasing can solve
that problem by providing multiple virtual interfaces. But I decided to
spend a little extra and just have multiple "physical" interfaces,
thinking that way it would be easier to configure and would give me
redundancy to boot. (Oops).
I tried out tcpdump (although I'm new to using it) and saw the following:
This was with: tcpdump -q -t -l -p -i eth0
(eth0 is 192.168.1.130, eth1 is 192.168.1.131)
Receiving a single ping to 192.168.1.130
----------------------------------------
192.168.1.1 > 192.168.1.130: icmp: echo request
192.168.1.130 > 192.168.1.1: icmp: echo reply
192.168.1.130.32773 > 192.168.1.1.domain: udp 43 (DF)
192.168.1.1.domain > 192.168.1.130.32773: udp 115
Receiving a single ping to 192.168.1.131
----------------------------------------
192.168.1.1 > 192.168.1.131: icmp: echo request
192.168.1.131 > 192.168.1.1: icmp: echo reply
192.168.1.130.32773 > 192.168.1.1.domain: udp 45 (DF)
192.168.1.1.domain > 192.168.1.130.32773: udp 117
192.168.1.130.32773 > 192.168.1.1.domain: udp 43 (DF)
192.168.1.1.domain > 192.168.1.130.32773: udp 115
All I see from this is that the ping which is going out on eth0 (.130)
is forged to appear to be coming from (.131). Using tcpdump on eth1
instead of eth0 shows nothing even when .131 is pinged.
On Tue, 26 Mar 2002 09:22:57 -0800 (PST)
"Stephen A. Witt" <sawitt@electra.rsc.raytheon.com> wrote:
> On Tue, 26 Mar 2002, Shawn Yarbrough wrote:
>
> > I have an x86 server computer containing two network cards:
> >
> > eth0 --> 192.168.1.130
> > eth1 --> 192.168.1.131
> >
> > Both cards work fine alone. As you can see, both cards are on the
> > same network. The subnet mask is 255.255.255.0. I can disable either
> > card with ifdown and sucessfully ping the other card from elsewhere on
> > the network.
> >
> > The puzzle comes when both cards are up at the same time.
> >
> > The kernel seems to pick one of the cards (somewhat arbitrarily) and
> > starts answering pings to BOTH addresses on the ONE card! Could this
> > be some kind of ARP bug? I can physically pull the plug out of the
> > other card (the one that the kernel appears to not be using anymore)
> > and the system still answers pings to both addresses!
> >
> >
> > I first noticed this strange behavior by watching the indicator lights
> > during pings. Pings to both addresses are clearly going thru only one
> > of the cards. The other card remains idle.
> >
>
> First, an observation:
>
> I don't think your installation is considered to be "standard" or
> "customary" in the IP world. I think I understand what you are trying to
> achieve, but I believe IP philosophically is based on having one network
> interface per IP network. When one starts to do things outside of the
> standard or customary, then differences in the implementations of IP
> stacks begin to show up. In other words, there is no "tight"
> specification for an IP implementation, and the many different IP stacks
> do things a little differently. There is a wonderful book "TCP/IP
> Illustrated, Volume 1", by Rich Stevens that shows how differently the
> leading (at the time of the writing of the book) OS's IP stacks handle
> different situations.
>
> In order to really find out what is happening, I think you need to use
> some better diagnostic tools, like 'tcpdump'. This will allow you to
> capture the datagrams that each network interface is seeing and you can
> better understand what is happening. I don't think the lights on the
> Ethernet cards are really useful for diagnosing what is going on.
>
> For a machine that is multihomed (has more than one IP network interface
> assigned an IP address), any of the IP addresses for the machine are
> valid and equally useable. I think your Linux system is responding in a
> reasonable way as both network interfaces are receiving ICMP echo
> requests, and both are apparently answering. I don't think there is a
> bug here.
>
> > This is a Debian Woody system (freshly installed and not currently in
> > use for anything). The behavior is identical running either kernel
> > 2.2.20 or kernel 2.4.18. In /etc/network/options the ip_forward
> > setting is no.
> >
> > This is NOT a router-type computer. It's just a server that I really
> > want to have on the same network, twice. And I'd rather not use IP
> > aliasing + one card. I really want two cards for convienence and
> > redundancy. (ex: in theory if one card failed or was misconfigured I
> > should still be able to reach the machine through the other card).
> >
> >
> > Anyone got a clue what's going on here? Thanks,
> >
>
> I'm not sure how to achieve the redundancy that you desire. Perhaps with
> the load-sharing facility (I think there is a HOWTO on this), but that
> may be only for point-to-point links. My experience is that Ethernet
> cards are one of the more reliable components of a PC and if there is
> going to be a failure, something else like a power supply, harddisk, or
> even a motherboard will go before an Ethernet card. Of course, Ethernet
> cards do fail, so I'm not trying to say your quest is in vain. Also,
> people do a lot of things that aren't "standard" IP so I'm not trying to
> discourage you there either.
>
>
>
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: