Two interfaces on the same network

AL Chane al_chane at issc.com.tw
Thu Jun 10 03:50:27 UTC 2004


Larry Brown 提到:
> ---------                                       -----------------
> | Linux | 192.168.2.1 --Wireless--> 192.168.2.2 | Wireless User |
> ---------                                       -----------------
> 192.168.1.1
>     |
>     |
>   Wired
>     |
>     |
>     V
> 192.168.1.2
> --------------
> | Wired User |
> --------------
> 
> Sorry, my first ansi drawing.  Why can't you use this?  If the Linux box
> is set up to route traffic between the networks,  Each machine can see
> one another.  Each machine can access the html access on the Linux box. 
> Or if you use a wireless node on the network, you could have wireless
> users coming onto the 192.168.1 subnet and everyone can see everyone as
> they will be on the same subnet for that scenario.  
>

I don't have problem for the setup about. But my setup is different and
linux box is not setup to route traffic between he networks. Please see
details:
_________eth0 172.20.1.30   _______________
|#1 PC  |-----------------> |Wireless AP  |
|Linux  |                   |Router       |->ADSL->Internet
|Http   |eth1 172.20.1.31   |172.20.1.254 |
|Server |...wireless......> |_____________|
|_______|                        ^
                                 |
__________                       |
|#2 PC   |                       |
|Windows |NIC 172.20.1.32        |
|Http    |-----------------------|
|client  |
|________|


Network: 172.20.1.X, netmask: 255.255.255.0


Ping test:
<on #2 PC> c:\ping 172.20.1.31
receive ping reply from #1 PC as long as eth0 is plug
even if wireless path not working.
If eth0 is unplug, c:\ping 172.20.1.31 won't get reply.
Thus, I think all traffic go to eth0 for linux if two
interfaces exist in the same subnetwork.


<if change #1 PC from Linux to Windows>
<on #2 PC> c:\ping 172.20.1.31, unplug eth0's wire won't affect
ping. That is, I think for windows:
ping 172.20.1.30 get reply from eth0, unplug eth1 won't affect ping
ping 172.20.1.31 get reply from eth1, upllug eth0 won't affect ping





                                                                    My
application:
#2 PC's browser can access #1 PC by IP address. I need
to ensure that when #2 PC access http://172.20.1.31,
traffic go thru eth1, not eth0. Can this be done in linux?
Or some commands (route/netmask/etc. settings)?
Or need change linux's IP stack source code a bit?


[root at AL sbin]# ./ifconfig
eth0      Link encap:Ethernet  HWaddr 00:01:29:4C:06:46
          inet addr:172.20.1.30  Bcast:172.20.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:566 errors:0 dropped:0 overruns:0 frame:0
          TX packets:464 errors:12 dropped:0 overruns:0 carrier:24
          collisions:0 txqueuelen:100
          RX bytes:46725 (45.6 Kb)  TX bytes:39630 (38.7 Kb)
          Interrupt:11 Base address:0x7000

eth1      Link encap:Ethernet  HWaddr 00:02:B3:A3:D6:B0
          inet addr:172.20.1.31  Bcast:172.20.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:640 errors:0 dropped:0 overruns:0 frame:0
          TX packets:118 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:94134 (91.9 Kb)  TX bytes:9336 (9.1 Kb)
          Interrupt:11 Base address:0xdc00 Memory:dd021000-dd021038

[root at AL sbin]# ./ip addr show
1: lo: <LOOPBACK> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:01:29:4c:06:46 brd ff:ff:ff:ff:ff:ff
    inet 172.20.1.30/24 brd 172.20.1.255 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:02:b3:a3:d6:b0 brd ff:ff:ff:ff:ff:ff
    inet 172.20.1.31/24 brd 172.20.1.255 scope global eth1

[root at AL sbin]# ./ip route show
172.20.1.0/24 dev eth0  scope link
172.20.1.0/24 dev eth1  proto kernel  scope link  src 172.20.1.31
169.254.0.0/16 dev eth1  scope link
default via 172.20.1.254 dev eth0
default via 172.20.1.254 dev eth1

[root at AL sbin]# ./route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
172.20.1.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
172.20.1.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
0.0.0.0         172.20.1.254    0.0.0.0         UG    0      0        0 eth0
0.0.0.0         172.20.1.254    0.0.0.0         UG    0      0        0 eth1
[root at AL sbin]#




> When the ping is received by the Linux box when two nic's have the same
> subnet, the OS receives the request for ping and looks at the routing
> table for a route back to the sendor.  If the arp tables show his mac
> address on the first card on that network (even though the ping came in
> on the second card on that network), it will send the ping response on
> that first card.  So the windows box can see a ping response coming
> back, but it may be coming from an address other than the one it sent it
> to in the first place and ignores it.  As far as I can tell this is how
> these things were designed for TCP/IP.  M$ doesn't want multiple cards
> on one box on the same subnet either.  The fact that your M$ box is
> doing it is an oversight on their part.  I'm pretty sure they addressed
> that in networking for the MSCE cert.

This is my arp table on linux.

[root at AL sbin]# ./arp -e
Address         HWtype  HWaddress           Flags Mask         Iface
172.20.1.32     ether   00:40:F4:3A:72:B3   C                  eth0
172.20.1.32     ether   00:40:F4:3A:72:B3   C                  eth1
172.20.1.254    ether   00:05:5D:22:74:72   C                  eth1
172.20.1.254    ether   00:05:5D:22:74:72   C                  eth0

Can I say that:

1. Windows does "oversight on their part", but Linux doesn't? Thus,
   Windows NICs back up each other but Linux only use the "default"
   interface in the same subnet?
2. Two interfaces should not be in the same subnet for the original
   TCP/IP design?


Thanks a lot for the helps.

AL





More information about the redhat-list mailing list