m21827@mwunix.mitre.org (Ken Stillson) (06/05/91)
hi. Here's the situation: our "server" has two ethernet controllers,
each with its own inet address. One goes to the main internet network,
the other to our lab. We want to seperate lab traffic, and don't care
if local users must log though the server to get outside.
So- The outside world needs to know the server as 128.29.22.1, and is
attached to contrller ie1. The lab knows the server as 128.29.22.7, and
is attached to ie0. Here what I tried in rc.local:
# ie0 to local net as -gw:
ifconfig ie0 128.29.22.7 netmask 128.29.22.255 broadcast 128.29.255.255
# ie1 to mitre net as srv:
ifconfig ie1 128.29.22.1 netmask 255.255.0.0 broadcast 128.29.255.255
It almost works. The outside can see the server, but not the lab
stations (that's good), the lab can see the server, but not the outside,
(still fine), and the server can get to the outside (good), but the
server cannot get to the lab! After watching the little blinking lights
on the control boxes, I realized that the packets I intended to go to
the lab are being sent to the ie1 controller. This is conformed by the
fact that if I "ifconfig ie1 down" then the server gets to the lab fine.
Can anyone lend me a hand in getting this sun 4.1.1 server to grasp the
desired network design? I can provide any additional information you
need, and would _really_ appreciate some help in getting this solved.
Thanks in advance.
- Ken Stillson, stillson@mitre.org
--
panic: cannot read .signature file for kds@uiuc.edu
Abort, Retry, Ignore, Explode? torek@elf.ee.lbl.gov (Chris Torek) (06/28/91)
(Warning: oversimplified explanations of routing appear below.) In article <m21827.675646891@mwunix.mitre.org> m21827@mwunix.mitre.org (Ken Stillson) writes: ># ie0 to local net as -gw: >ifconfig ie0 128.29.22.7 netmask 128.29.22.255 broadcast 128.29.255.255 If nothing else, this is a completely bogus netmask. In general, the internet `address match' function looks like this: if ((addr1 & netmask) == (addr2 & netmask)) /* addr1 and addr2 are on the same network */ ># ie1 to mitre net as srv: >ifconfig ie1 128.29.22.1 netmask 255.255.0.0 broadcast 128.29.255.255 This is a much more reasonable network mask (a conventional Class B mask). Unless you use subnetting, both interfaces should have the same (Class B) network mask (128.29 is a Class B internet address). If you do use subnetting (and you certainly do), you should set ie0's netmask to, e.g., 255.255.255.0. This would mean that ie0 can take only things that match 128.29.22.*. (More on this in a moment.) Note that if ie0 and ie1 both have netmask 255.255.0.0, the search for an interface on which to send a packet will go more or less like this: I want to send to 128.29.22.33, so first I will see if I have a route directly to 128.29.22.33 (probably not). If not, I will find some arbitrary interface such that (interface dst addr & interface netmask) == (128.29.22.33 & interface netmask) Unfortunately, there is no way to say *which* arbitrary interface will be chosen (well, you can poke around in the routing code and see what order it uses to search; SunOS probably has the old BSD hash table method). In this case, both ie0 and ie1 can match that address, and there is no way to know which will get it. Now, if you had 8-bit subnets on both interfaces you would have the following: ie0, netmask 255.255.255.0, dst addr 128.29.22.7 ie1, netmask 255.255.255.0, dst addr 128.29.22.1 This does not help at all: again, 128.29.22.33, when masked against either interface's netmask, matches that interface's dst-addr. The normal setup, then, is for a subnetted network gateway/router% to have two *different* subnets, not the *same* subnet, as its two different interfaces. For instance, you might make your server be 128.29.22.1 on the `local' Ethernet cable interface, and 128.29.250.70 on the `wire that connects disjoint subnets' interface. The (internal) network number of the `connects disjoint subnets' network would then be 128.29.250.*, and the internal network number of your own Ethernet would be 128.29.22.*. The `conencts disjoint subnets' network would have a broadcast Internet address of 128.29.250.255. The overall topology of your network-of-networks would look something like this: 128.29.250.* ===+=======================+============== . . . | 128.29.17.1 | 128.29.22.1 | | 128.29.17.* 128.29.22.* where the `===' line represents the `backbone network' (which carries inter-net traffic only) and the | lines represent the subnets (which carry only intra-net traffic). The gateways between the backbone and each subnet would be the only machines with more than one network interface, and thus the only machines that need to understand connecting between disjoint networks, i.e., `routing'. ----- % `Gateway' and `router' are sometimes used interchangeably. Different people put different `fine points' on them, but this is beyond the scope of this posting. ----- In general, machines that make good hosts make lousy routers, and vice versa. The modern trend is to use one machine specifically as a router (often from a company that makes `routers', such as Proteon or Cisco) and others specifically as a host. Part of the reason for this is that routers need to be more sophisticated (need to understand routing protocols); part is just silliness. I have arbitrarily numbered all the routers `.1'---this is a handy convention when trying to think about your network: pick some magic number, like 1 or 128 or 250 or something, that represents each router, and then when someone says `x.y.z.1' you instantly know that this is one of those special machines, one that has the .1 interface on its subnet and some other interface on the backbone net. It is possible to decompose a network further (so that you have a `backbone of backbones' each with their own networks). A tree topology is generally easiest to work with; arbitray meshes require considerably higher power routing. For *many* more details, see any of the various Network Architecture and/or Internet textbooks (e.g., Doug Comer's). -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov