peters@CC.MSSTATE.EDU (Frank W. Peters) (01/31/89)
Hello,
A recent posting by Tom Corsetti brought to mind several questions
which we wrestled with and often left unanswered.
We, like Mr. Corsetti, have a large un-subnetted class B network.
Addresses on this network are assigned in a subnetted fashion (that is,
all of the nodes in a given building have the same third octet to allow
for subnetting at a later date).
In a couple of buildings on campus we have Sun servers with two
ethernet cards and diskless workstations 'behind' them to provide nfs
traffic isolation. Each network of clients has its own 'subnet' of the
campus class B network.
We are not exactly sure about how to configure the gateway suns
to allow them to be subnetted (for the clinets on one side) and still
have full connectivity with the unsubnetted campus network.
As it now stands we have the following problems:
(1) Broadcast Addresses: As it now stands, the subnetted machines address
broadcasts to (say) 130.18.64.255 instead of the common address of
130.18.255.255. Is there any reason why we can't take advantage of
the broadcast option of the UNIX ifconfig command to have a subnet mask
of 255.255.255.0 and a broadcast of 130.18.255.255? should the broadcast
be the same on BOTH sides of the gateways? Does it matter if its the
same? That is, can the broadcast be x.x.255.255 on the campus side and
x.x.y.255 on the client side?
As it now stands, every time a subnetted machine on the 130.18.64.0 net
(which is really part of the unsubnetted campus net) sends a broadcast
the subnetted machines on (say) the 130.18.48.0 net (which is also part
of the same campus net but, because of subnetting, THINKS its on a
seperate subnet) don't recognize the broadcast and attempt to arp the
130.18.64.255 broadcast address.
(2) Routing (1): Given a gateway sun that is on the unsubnetted campus backbone
but that THINKS it is on a subnetted network, how do we convince it that
it can reach a machine directly that is not on its 'subnet'? That is,
how do we convince a subnetted gateway machine on the 130.18.64.0 portion
of the backbone that it can directly reach a machine on the 130.18.48.0
portion? As it is now configured all packets of this sort are routed to
our proteon routed...which turns right around and sends it back out the
same interface. Gross huh?
(3) Routing (2): Are there any options besides proxy arp to allow the gateway
suns to grab packets off of the backbone and routing them through their
client sides? This is basically the common problem of an unsubnetted
machine sending a packet to a machine that is not REALLY on the same wire.
We have a public domain proxyarpd package for suns but can't get it to
compile on a sun 4.
(4) Sorta-Subnetting: This is a possibility that may solve all of our
problems if I only understood it. I note that (on a Sun at any rate) it
is possible to assign subnet masks (and subnetting alltogether) on an
interface basis. What would it mean to have a gateway with two subnets
for the same network on two different interfaces? Would it help? Would
it WORK? How about one interface subnetted and one not (thats pretty much
what we logically want)?
Any comments or suggestions would be welcome. Please don't suggest
subnetting the campus backbone though. We just don't have the budget for
the routers yet.
Thanks
Frank Peters
=====================================================================
Systems Programmer | Mississippi State University
Phone: (601) 325-2942 | Computing Center and Services
Internet: peters@CC.MsState.Edu | Post Office Drawer CC
BITNET: PETERS@MSSTATE.BITNET | Mississippi State, MS. 39759
=====================================================================hedrick@geneva.rutgers.edu (Charles Hedrick) (02/01/89)
OK, you've got a central network with 130.18.1 to 130.18.63, and a Sun connecting this network to a small Ethernet with 130.18.64 on it. What I think you want to do (and I confess I haven't tried this) is: on the interface to your small Ethernet, leave things as a normal subnet, i.e. subnet mask 255.255.255.0, and broadcast address 130.18.64.255. on the interface on the central network, set the broadcast address (it's a parameter to ifconfig) to 130.18.255.255. I think you want to leave the subnet mask as 255.255.255.0. If you try to use a subnet mask of 255.255.0.0 on this interface, routing is likely to get very confused. route add 0 <your address on the main network> 0 run the proxy ARP daemon. (I'm sure I heard somebody say there was a version that worked under 4.0. It's got to be completely different than the 3.2 version.) The "route add" will cause your Sun to treat any address it doesn't know about as being attached directly to your main network. This assumes that any gateways you have to connect you offsite will respond to ARP requests for addresses offcampus. If your exterior gateway doesn't have a complete proxy ARP implementation (I've heard rumors that this is true for Proteon), then you're going to have to do route add 130.18.1.0 <your address on the main network> 0 route add 130.18.2.0 <your address on the main network> 0 ... for all subnets on the main network. Or if you have one gateway somewhere that knows all your subnets, run routed and get routes from it. I don't see any way to make things work unless you can get proxy ARP running. However if you have a Sun (or other system with similar facilities) anywhere else on the network, you can do arp -s <hostname> <etheraddress> pub for every host on your subnet. This causes the machine to do a kind of hard-wired proxy ARP. When it sees an ARP request for <hostname> it will respond with <etheraddress>. <Etheraddress> should be the address of the Sun that's acting as the gateway to your subnet. You can't do this on that Sun itself, because it needs to know the actual Ethernet addresses of those machines. By the way, I'm not sure that this whole business is really the right way to do things. The moment you have different machines on your main network with different subnet masks, things will get very exciting. The ICMP subnet mask broadcasts will tend to cause machines to randomly change subnet masks. I think I'd set up every machine that knows about subnet masks to use a mask of 255.255.255.0. Then use the "route add 0" commands as described above to tell it to use the main network for all the subnets.
martillo@cpoint.UUCP (Joacim Martillo) (02/02/89)
I am not sure I understand the problem. Perhaps, I am wrong but I would consider subnetting a useful administrative kludge when I have several physical networks but one network number. With such understanding gateways between two subnets of one network number should not behave much differently than gateways between two networks with two different network numbers. I would not want my gateway to forward IP broadcast packets from one network or subnet to the other network or subnet. That just allows little sins to turn into big sins. Now if I have hosts that understand subnets and hosts that do not understand subnets on the same physical network. I would expect the hosts that understand subnets to use the subnet IP broadcast and hosts that do not understand subnets to use the standard network IP broadcast. I would expect the subnet understanding hosts to understand all IP broadcasts while the hosts which do not subnet would not understand subnet IP broadcasts. Such is life and may be acceptable, otherwise you have to run subnetting software on all machines. Now if I understand the case presented, you have gateways which understand subnetting and on one side of each gateway you have hosts which understand subnets while on the other side of each gateway you have hosts which do not understand subnets and there is but one network for all the hosts which do not understand subnets. On the subnetted side, life is simple. A given host either arps IP address on the subnet or sends IP packets to the gateway when the destination IP address is not on the same subnet. On the unsubnetted side, life is rotten. Suppose a host which does not understand subnets wants to send IP packets to a subnetted host. This host will assume that the subnetted host is on the same physical network and will arp it. Unless the gateway on the subnet host can do proxy arp, there will be no response to the original arp request and the IP address will not be resolved. If the non-subnetted hosts can be pursuaded to send IP packets with unresolved IP addresses to a gateway, it would be possible to establish communication but there would be no obvious basis on which to choose to which gateway to send the packet. I suppose you could depend on ICMP redirect to fix this but it seems rather gross and lots of hosts ignore ICMP redirect so that an IP packet might always be sent to the wrong gateway first which would then send the packet to the right gateway. The bottom line really is that in your network hosts which do not have a subnet address should still be doing subnet routing, and until you get the appropriate software you will have problems. As for the gateways, as long as they understand subnet routing properly, it should be possible for one interface to be attached to a subnetted physical network with appropriate subnet mask while the other interface is attached to an unsubnetted physical network. By the way, subnetting should be just as possible on a class C network as on a class B network.