Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!olivea!apple!agate!ucbvax!LCS.MIT.EDU!MAP From: MAP@LCS.MIT.EDU (Michael A. Patton) Newsgroups: comp.protocols.tcp-ip Subject: An INTERESTING problem Message-ID: <9101101835.AA24211@gaak.LCS.MIT.EDU> Date: 10 Jan 91 18:35:33 GMT References: <9101100248.AA01030@desktalk.desktalk.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 78 You were almost clever enough... Date: Wed, 9 Jan 91 18:48:55 PST From: rlg@desktalk.com (Richard L. Gralnik) We have a network which resembles a wheel with spokes Actually your later description sounds like spokes, but no wheel. Given the critical nature you describe later you may want to consider interconnecting the ends of the spokes to actually create a "wheel". There are many cases where single failures can take out multiple lines and at least having the ability to route all around the outside means only one of the spokes into the hub needs to be operational for connectivity to exist everywhere (of course, that one link will get quite loaded). We have thought of 3 solutions - But you missed a fourth that is probably the one you want... 1. Use more than 8 bits for the subnet mask. I agree with your reasons against this one. 2. Use different size subnet masks This is very iffy. Exactly what you can accomplish with variable subnets depends on what vendors equipment you are using. There may be restrictions that prevent use in this application. It may be very hard to get right if you want to allow for competitive sourcing of the equipment you use. 3. Use our Class B network number for the central net and for the remote office nets with the 8-bit subnet mask, and use subnetted Class C addresses for the serial lines. We think this is very clever I agree it seems clever, but it doesn't work... However there is something that does (and is related). This doesn't work because of the contiguous network assumption. You may find some vendors implementation that happens to operate the way you want today, but since the specs imply networks are contiguous, this may not continue to be available. However, most vendors of IP routers will let you run the serial line between two routers as an unnumbered subnet. Even if it's not directly supported, this is easy to simulate (see below). This feature is intended to address problems just such as yours. The main disadvantage is that you cannot address these unnumbered ports directly (say to ping them), but with SNMP you still get the information so this may not be a problem at all. This will eliminate all the waste of addresses for these lines. If your vendor doesn't support this (or for some reason you don't want to rely on that support), there is a simple way to simulate it. All you do is allocate one subnet of your class B address and use it for all the serial lines. That's right, you just made a discontiguous subnet. The only reason a discontiguous subnet is a problem is that you don't know how to route to it but, as described before, you don't need to address the serial line side! I have, in fact, tested this configuration, by accident, and found it to work fine. The way to accidentally get this configuration is with a spine subnet that partitions in such a way that the parts still work, and the two partitions are interconnected through some back door. In your case, you could think of all the serial ports being on one super-subnet that just happens to be broken into partitions of size 2. There are some minor complications if multiples of these "partitions" need to feed into a single router, but a little thought can generally configure a setup for this case. __ /| /| /| \ Michael A. Patton, Network Manager / | / | /_|__/ Laboratory for Computer Science / |/ |/ |atton Massachusetts Institute of Technology Disclaimer: The opinions expressed above are a figment of the phosphor on your screen and do not represent the views of MIT, LCS, or MAP. :-)