|
Home > Archive > Red Hat Networking > September 2005 > Two NICs in different SubNets
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Two NICs in different SubNets
|
|
| Joachim A. Stuewe 2005-09-30, 7:50 am |
| My connection to the outside world is via a WLAN-Router(, which also
serves as a DHCP-, & DNS-Server) and usually all network traffic runs
via wireless cards. However, I wanted to connect two of my machines
directly via cable NICs (faster & takes load of the WLAN).
The WLAN traffic runs in the 10.0.0.0 network (WLAN-Router default
factory setting) with 10.0.0.138 beeing the Router/Gateway and
DHCP-Clients having IPs in the range 10.0.0.151 to 200. For the cable
connection the NICs have static IPs in the 192.168.0.0 network, namely
192.168.0.9 (LinUx 2.4.26) & 192.168.0.11 (WinXP + CygWin). Thus the two
machines are connected via WLAN as well as cable. Of course they have
different names in the different networks. After I set up everything for
the cable connection, the WLAN still runs as it always did. I can
perfectly ping via the cable in both directions, thus the physical
connection is up and working. However, so far I had no success in
getting any other service to connect, as for example SAMBA (LinUx is the
server and it works via WLAN), FTP (neither direction), SSH (neither
direction) or the like. The only exceptions are X11-applications, which
I start on the LinUx box to actually open on the WinXP machine (of
course I have to have CygWin running there with the appropriate "xhost"
setting).
The routing tables look fine (see below), as they should since PING works.
Kernel IP routing table of machine 192.168.0.9 (LinUx 2.4.26)
Destination Gateway Genmask Flags Metric Ref Use
Iface
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 10.0.0.138 0.0.0.0 UG 0 0 0 eth1
routing table of machine 192.168.0.11 (WinXP + CygWin)
========================================
==================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 06 29 95 5e f1 ...... IBM 10/100 EtherJet CardBus Adapter #2 -
Packet
Scheduler Miniport
0x10004 ...00 02 2d b5 f2 10 ...... Wireless PC Card Model 0104 - Packet
Schedul
er Miniport
========================================
===================================
========================================
===================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.0.0.138 10.0.0.152 30
10.0.0.0 255.255.255.0 10.0.0.152 10.0.0.152 30
10.0.0.152 255.255.255.255 127.0.0.1 127.0.0.1 30
10.255.255.255 255.255.255.255 10.0.0.152 10.0.0.152 30
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.0 255.255.255.0 192.168.0.11 192.168.0.11 20
192.168.0.11 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.0.255 255.255.255.255 192.168.0.11 192.168.0.11 20
224.0.0.0 240.0.0.0 10.0.0.152 10.0.0.152 30
224.0.0.0 240.0.0.0 192.168.0.11 192.168.0.11 20
255.255.255.255 255.255.255.255 10.0.0.152 10.0.0.152 1
255.255.255.255 255.255.255.255 192.168.0.11 192.168.0.11 1
Default Gateway: 10.0.0.138
========================================
===================================
Persistent Routes:
None
Any network guru out there with reasonable suggestions?
Jogy
========================================
=======================================
Dr. Joachim A. Stüwe + Duindoornstr. 1 + NL-2211PH Noordwijkerhout
========================================
=======================================
| |
| Moe Trin 2005-09-30, 8:48 pm |
| In the Usenet newsgroup redhat.networking.general, in article
<433d287f$0$2887$ba620dc5@text.nova.planet.nl>, Joachim A. Stuewe wrote:
Nice obscure news groups your picked. Next time, try the regular group
comp.os.linux.networking.
>My connection to the outside world is via a WLAN-Router(, which also
>serves as a DHCP-, & DNS-Server) and usually all network traffic runs
>via wireless cards. However, I wanted to connect two of my machines
>directly via cable NICs (faster & takes load of the WLAN).
and is a lot more secure.
>The WLAN traffic runs in the 10.0.0.0 network
>For the cable connection the NICs have static IPs in the 192.168.0.0
>network, namely 192.168.0.9 (LinUx 2.4.26) & 192.168.0.11 (WinXP +
>CygWin). Thus the two machines are connected via WLAN as well as cable.
OK - some of our systems have three networks; normal, admin, and backup.
Root is only allowed to connect over the admin net, and the backup net
is used to connect the servers to the system with the tape drives. We do
this for security as well as bandwidth reasons.
>Of course they have different names in the different networks.
Good - that's all that is needed, other than seeing that the names and
addresses get resolved - either by dinking with the name server, or
entering them into both 'hosts' files.
>After I set up everything for the cable connection, the WLAN still runs
>as it always did. I can perfectly ping via the cable in both directions,
>thus the physical connection is up and working.
Great!
>However, so far I had no success in getting any other service to connect,
>as for example SAMBA (LinUx is the server and it works via WLAN), FTP
>(neither direction), SSH (neither direction) or the like.
The problem is that you have these systems trying to talk to each other
using the WLAN names/addresses (which also may be a windoze default - I
don't use windoze or Samba). What happens if you try to 'ftp 192.168.0.9'
or 'ftp hostname_for_192.168.0.9' and similar. This should work assuming
you don't have a on-system firewall problem.
Windoze is designed to work any way it can, no matter how bad the admin
screws things up. It does this with a lot of self discovery traffic,
which has security implications, but that's not microsoft's problem as
they state in their EULA. What you may see is that windoze (and Samba)
use discovery packets to find other systems, and consequently assume
that duplicate routes are irrelevant (and ignored), and configuration
data (such as hosts file) that don't match their discovery are assumed
to be a result of a stupid admin, and they can safely ignore those as well.
Given the average skill of a windoze administrator, this often is a very
good concept - but it falls apart when conditions are more complex than
microsoft envisions. Multiple paths is one of those "it can't happen"
conditions as far as they are concerned. There should be a "I know what
I'm doing - stop trying to help me" switch in there, but as I don't do
winodze, I can't say where.
Old guy
|
|
|
|
|