Two interfaces on the same network

Larry Brown larry.brown at dimensionnetworks.com
Thu Jun 10 21:57:10 UTC 2004


Why do you have a wireless connection to the same device you have a
wired connection to?  You should be able to have wireless devices
connect to your "Wireless AP Router" which should provide an IP address
to the wireless device on the 172.20.1.0 network.  

On Wed, 2004-06-09 at 23:50, AL Chane wrote:

> 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