On Wed, 30 Nov 2011, in the Usenet newsgroup comp.os.linux.networking, in
article <PYwBq.1841$(E-Mail Removed)>, DylanC wrote:
>DylanC wrote:
>> OK, this is not really a Linux related post, but OS independent
>> networking. If that bothers you, stop reading.
comp.dcom.lans.misc Local area network hardware and software.
comp.protocols.tcp-ip TCP and IP network protocols.
but the groups are only marginally active.
>> My company will be installing a new industrial control panel at a
>> municipal water treatment plant. The panel will have several components
>> (PLC, HMI, AC motor drives, etc.) connected via ethernet. The panel
>> will also contain a fully managed ethernet switch with DHCP and VLAN
>> capabilities
Sounds like fun - be sure to control access from un-trusted systems to
avoid a ``repeat'' of the alleged r00ting in Illinois and Texas (watch
the line wrap on the URL):
http://www.infoworld.com/t/network-security/
us-water-plants-reportedly-hit-cyber-attacks-179456
>> For obvious reasons, the folks at the plant do not want this panel to
>> take 5+ IP address from the top level network, so they've asked that
>> this panel be configured as a subnet.
Not sure why (other than security), but OK, we can do that.
>> I've set up quite a few (BASIC) home networks, and this task doesn't
>> really seem like it should be that hard.
Correct - you _may_ be making it more complicated than necessary.
>> Also, I've read quite a few articles explaining the binary aspects of
>> IP addresses and how subnet masks work, but its not really sinking in.
>> Can somebody point me in the direction of a practical walkthrough
>> showing how this can be accomplished?
http://tldp.org/guides.html
* The Linux Network Administrator's Guide, Second Edition
version: 1.1 authors: Olaf Kirch and Terry Dawson
last update: March 2000 ISBN: 1-56592-400-2
available formats: 1. HTML (read online)
2. HTML (tarred and gzipped package, 690k) 3. PDF (1.5MB)
This book was written to provide a single reference for network
administration in a Linux environment. Beginners and experienced
users alike should find the information they need to cover nearly
all important administration activities required to manage a Linux
network configuration. The possible range of topics to cover is
nearly limitless, so of course it has been impossible to include
everything there is to say on all subjects. We've tried to cover the
most important and common ones. We've found that beginners to Linux
networking, even those with no prior exposure to Unix-like operating
systems, have found this book good enough to help them successfully
get their Linux network configurations up and running and get them
ready to learn more.
The 'ISBN' says it's an O'Reilly dead-tree, and there's actually a third
edition as ISBN: 0-596-00548-2 from February 2005 at your favorite
technical bookstore for US$34.95.
>The system is only partly working and I'm not sure if its an issue of
>how they are physically connected or a setting somewhere.
settings - but what you are showing has too many typ0s to say what/where.
>The basic settings:
>Primary Router:
Some of this makes no sense
>Secondary Router:
OK
>Computer A: 192.168.1.104
>Computer B: 192.168.2.100
OK
>As it sits now, I am able to use computer B to connect to the internet,
>ping the primary router and access the (web based) configuration, ping
>computer A, access a webserver on computer A, and access shared folders
>on computer A. I can also Access the secondary router (ping and web
>based configuration) through IP 192.168.2.1, but not using 162.168.1.6.
'B' is the stub - and everything is working properly. Not being able to
connect to "162.168.1.6" (assumed 192.168.1.6) suggests either a firewall
issue on the secondary router, or something screwy there.
> From computer A, I have no access to computer B or to the secondary
>router.
But you do - from 'B', you can connect to 'A' - so that says packets
can go from 'B' to 'A' AND THE REPLIES COME BACK FROM 'A' to 'B'. Ergo,
you've got connectivity.
I'm a networking guy, so I'd be getting out my packet sniffer on each
subnet to see what packets are going where. Is this a DNS issue?
(Can you connect by IP rather than name?) The only other thing I can
think of is a NAT issue (IP masquerade in Linux-speak) on the second
router. The fact that 'A' can _REPLY_ to 'B' says basic networking
is OK, and 'A' knows how to send packets back. I don't do windoze,
but I'd be looking at the ARP cache on 'A' to see who it can talk to,
and specifically (while 'B' is pinging 'A') who is 'A' talking to NOW.
>After doing some more reading, I'm guessing that I can't do what I want
>with the hardware I have. Maybe someone can correct me, but I think I
>need a third router with both the primary and secondary router connected
>to it. Then, this new router would have an address of 192.168.0.0 and a
>subnet mask of 255.255.0.0. This router would then handle all traffic
>between the X.X.2.X and X.X.1.X subnets.
You have LAN 'A' consisting of a bunch of hosts on 192.168.1.x. You
have a second LAN named 'B' with hosts on 192.168.2.x. You need _ONE_
router with an interface on 192.168.1.x (let's say 192.168.1.200) and a
second on 192.168.2.x (let's say 192.168.2.200). All hosts on LAN 'A'
have to know that to talk to hosts on LAN 'B' they send the packets to
the router 192.168.1.200 (and vice-versa). The routing table on LAN 'A'
hosts should look like this:
[host-a ~]$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 4198 eth0
192.168.2.0 192.168.1.200 255.255.255.0 UG 0 0 2165 eth0
0.0.0.0 192.168.1.248 0.0.0.0 UG 0 0 2673 eth0
[host-a ~]$
This says "192.168.1.x is local - talk direct". "192.168.2.x is reachable
by sending packets to 192.168.1.200". EVERYTHING ELSE is reachable by
sending packets to the default router (route to the world?) on
192.168.1.248".
On LAN 'B', it might look like
[host-b ~] /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 3350 eth0
192.168.1.0 192.168.2.200 255.255.255.0 UG 0 0 1533 eth0
[host-b ~]
if LAN 'B' shouldn't be talking to the world. (If LAN 'B' is allowed to
do so, it might look like
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 3350 eth0
0.0.0.0 192.168.2.200 255.255.255.0 UG 0 0 1533 eth0
but that may be a security issue - "Y'all be careful, ya heah.")
Using Linux notation for interfaces, the router between the two LANs
might look like this:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 4198 eth0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 3350 eth1
0.0.0.0 192.168.1.248 0.0.0.0 UG 0 0 2673 eth0
which is to say "LAN 'A' is on hose 1, LAN 'B' is on hose 2, and the
default route to the world is via 192.168.1.248 on hose 1". The default
route isn't needed/wanted if LAN 'B' shouldn't talk to the world. Your
windoze boxes will have something similar (I'm told the command to run
is "route print"), except that microsoft believes in the "baffle 'em with
bullshit" mode, and uses st00pid notations and techno-babble in their
routing tables. The routers may also have a strange nomenclature, and
may require routing rules. Using a _dynamic_ routing protocol like RIP
should not be necessary. Also, if the two LANs are physically within
Ethernet range (say 100 meters / 330 feet), there's no VLAN or anything
special needed - a clapped out desktop PC with two network cards can do
the job of the router. Don't over-complicate things.
Old guy
Similar Threads
Linear Mode
