[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 2 nics, 1 network, puzzle?



    "Shawn" == Shawn Yarbrough <shawn@nailstorm.com> writes:

    Shawn> I have an x86 server computer containing two network cards:
    Shawn> eth0 --> 192.168.1.130 eth1 --> 192.168.1.131

    Shawn> Both cards work fine alone.  As you can see, both cards are
    Shawn> on the same network.  The subnet mask is 255.255.255.0.  I
    Shawn> can disable either card with ifdown and sucessfully ping
    Shawn> the other card from elsewhere on the network.

    Shawn> The puzzle comes when both cards are up at the same time.

    Shawn> The kernel seems to pick one of the cards (somewhat
    Shawn> arbitrarily) and starts answering pings to BOTH addresses
    Shawn> on the ONE card!  Could this be some kind of ARP bug?  I
    Shawn> can physically pull the plug out of the other card (the one
    Shawn> that the kernel appears to not be using anymore) and the
    Shawn> system still answers pings to both addresses!


    Shawn> I first noticed this strange behavior by watching the
    Shawn> indicator lights during pings.  Pings to both addresses are
    Shawn> clearly going thru only one of the cards.  The other card
    Shawn> remains idle.

Hi Shawn,

I don't think there is anything wrong or strange. The system knows
that there are two routes to the network, and it is free to use either
one as it pleases. Your best bet would be too look carefully at the
output of 'netstat -r' to see why it makes the choices it does.

Maybe I misunderstood you, but as I see it you don't actually have a
problem, you just noticed that pings don't get replied from the
interface you expect (but the ping works, right?). Look at this way:
the kernel's job is to find a route for your packet. It's obvious
there are two routes to 192.168.2.0/24, and the kernel is doing it's
best to keep packets flowing (like it should IMHO).

To be honest, I'm surprised it work so well ;-), since the machine you
are pinging from is obviously updating it's ARP cache pretty quickly.

If I'm wrong, hit me over the head....

Cheers!
Shyamal



-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: