Multiple NICS on same subnet

Hi,

I'm trying to understand the behavior of a configuration where I have
multiple NICs on the same subnet. (I know, its wrong, I'm just trying
to understand.)

Here's the configuration:

eth0 : 172.16.11.4
eth1: 129.143.4.5
eth2: 129.143.4.6

$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window
irtt Iface
129.143.4.0 0.0.0.0 255.255.255.0 U 0 0
0 eth1
129.143.4.0 0.0.0.0 255.255.255.0 U 0 0
0 eth2
172.16.11.0 0.0.0.0 255.255.255.0 U 0 0
0 eth0
0.0.0.0 129.143.4.254 0.0.0.0 UG 0 0
0 eth1

eth2 is not cabled. eth0 and eth1 are cabled.

When you ping the address of eth2 (129.143.4.6), you get a response.
If you look at the arp entry on the machine that originated the ping
for 129.143.4.6, you get the MAC of eth0, which isn't even on the same
logical network. No proxy ARP is turned on.

Can someone explain what is happening inside the stack to make this
happen?

Thanks,

-- Andrew Bell
andrew.bell.ia@gmail.com

On 14 Mar 2006 13:09:19 -0800, andrew.bell.ia@gmail.com wrote:

>I'm trying to understand the behavior of a configuration where I have
>multiple NICs on the same subnet. (I know, its wrong, I'm just trying
>to understand.)

Who cares? We've been through this already ;)

Grant.
--
Testing can show the presense of bugs, but not their absence.
-- Dijkstra

Grant wrote:
> On 14 Mar 2006 13:09:19 -0800, andrew.bell.ia@gmail.com wrote:
>
> >I'm trying to understand the behavior of a configuration where I have
> >multiple NICs on the same subnet. (I know, its wrong, I'm just trying
> >to understand.)
>
> Who cares? We've been through this already ;)

No arm twisting here. If you don't care, you don't have to respond.

If anyone can point me to a previous discussion that explains this, I'd
appreciate it.

-- Andrew Bell
andrew.bell.ia@gmail.com

andrew.bell.ia@gmail.com wrote:
>Hi,
>
>I'm trying to understand the behavior of a configuration where I have
>multiple NICs on the same subnet. (I know, its wrong, I'm just trying
>to understand.)
>
>Here's the configuration:
>
>eth0 : 172.16.11.4
>eth1: 129.143.4.5
>eth2: 129.143.4.6
>
>$ netstat -rn
>Kernel IP routing table
>Destination Gateway Genmask Flags MSS Window
>irtt Iface
>129.143.4.0 0.0.0.0 255.255.255.0 U 0 0
>0 eth1

The fact that this entry for eth1 comes before the next entry, for
eth2, means that (since the routing is identical), all packets to
the 129.143.4.x subnet are routed via eth1, and none are routed to
eth2.

>129.143.4.0 0.0.0.0 255.255.255.0 U 0 0
>0 eth2

No packets are *ever* route to this interface.

>172.16.11.0 0.0.0.0 255.255.255.0 U 0 0
>0 eth0

All packets to the 172.16.11.x subnet are routed to this interface

>0.0.0.0 129.143.4.254 0.0.0.0 UG 0 0
>0 eth1

This is a "default" route, which sends anything not matched by the
above routes to IP address 129.143.4.254 via the eth1 interface.

>eth2 is not cabled. eth0 and eth1 are cabled.

That will be fine, given the above route table.

>When you ping the address of eth2 (129.143.4.6), you get a response.

If sent on the same machine, the packet actually goes to the lo
device, not the eth2 device! The internals of the TCP/IP stack
are of course aware of any address assigned to an interface on
this machine, and any packet routed to an IP on the machine goes
to the lo device. (Do and "ifconfig lo" command, note the
counters, do a ping to any local IP address, and then check the
couters again with ifconfig. You'll see that they increment
nicely...)

>If you look at the arp entry on the machine that originated the ping
>for 129.143.4.6, you get the MAC of eth0, which isn't even on the same
>logical network. No proxy ARP is turned on.
>
>Can someone explain what is happening inside the stack to make this
>happen?

Sounds as if you have IP forwarding enabled, and the machine
from which you sent the ping is gatewayed to 129.143.4.6 via
eth0 (172.16.11.0).

Ping that address again, and check to lo device counts as described
above. Interesting...

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

On 14 Mar 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<1142370559.063621.306260@e56g2000cwe.googlegroups .com>,
andrew.bell.ia@gmail.com wrote:

>I'm trying to understand the behavior of a configuration where I have
>multiple NICs on the same subnet. (I know, its wrong, I'm just trying
>to understand.)

Simple version - routing issue. The kernel will use the last NIC
configured when two routes lead to the same place.

>Here's the configuration:
>
>eth0 : 172.16.11.4
>eth1: 129.143.4.5
>eth2: 129.143.4.6

If you are grabbing IP addresses out of your a.. to munge your own addresses,
please use 192.0.2.x which is the famous "example.com" network. See RFC3330.
129.143.0.0 is the Academic Network of the German state of Baden-Wuerttemberg,
and 129.143.4.5 is a real live host.

>eth2 is not cabled. eth0 and eth1 are cabled.

For fun and games, unplug the cable from eth1, and plug it into eth2.

>When you ping the address of eth2 (129.143.4.6), you get a response.
>If you look at the arp entry on the machine that originated the ping
>for 129.143.4.6, you get the MAC of eth0, which isn't even on the same
>logical network. No proxy ARP is turned on.

The kernel knows the IP addresses. It is responding to a valid request.
It's sending it out the hose that leads to the destination. Because there
are two, it assumes that you made an initial mistake, and really meant to
use the second bit of data you provided. If you want to get around this,
see the Adv-Routing-HOWTO.

Old guy