hans@duttnph.UUCP (Hans Buurman) (05/09/89)
Some time ago, I asked about my university's policy regarding their B-net. The question was whether to go for subnetting or not. This message includes the summary I promised. Note that I am not in charge here, I am just a worried user. All responses I got were in favour of subnetting, although the way things were put varied. However, the people in charge here had the following arguments: (in random order) - Management tools have improved in the same way as clever routers, and we are able to track down problems rapidly. We will be able to manage the unsubnetted B-net. - Several protocols are used within faculties. This means that between faculties and the backbone we would have to use smart routers, which is much more expensive than bridges. - All protocols are the same up to layer two. The differences are in layer three, where ip is just one of the protocols. All investments that are done now must be made in anticipation of a coming ISO standard protocol for layer three. If we would buy smart routers now, they would be useless when we went over to that standard. (I hope I phrase this well, it is not an area that I am familiar with. It may be that the European situation for standards differs from the American). As a consequence of this, Delft University has an unsubnetted B-net since May 1st. The fake-o subnets mentioned below have been implemented. So far, things are working well. Some very old tcp/ip implementations seem unable to cope with the increased traffic (or variety of packets) on the net. We are working on that. I would like to thank all those who responded. If nothing else has been gained, I have learned a lot. The responses are below. Hans ----------------------------------------------------------------------------- Hans Buurman | hans@duttnph.UUCP Pattern Recognition Group | Faculty of Applied Physics | mcvax!hp4nl!dutrun!duttnph!hans Delft University of Technology | tel. 31 - (0) 15 - 78 46 94 =============================================================================== Question: My university has recently been appointed a B-class network, and is now moving towards an unsubnetted B-net. The reason to do things unsubnetted, I am told, is the fact that there are other protocols than tcp-ip on the net. I am not sure, but from a unix point if view this looks like an unpleasant solution. We will have bridges separating busy branches of the net, but these will be transparent to broadcasts so that these will be seen everywhere. I am not a networking wizard, I just use unix machines (suns, mostly) and like to do NFS mounts between different faculties. Would others like to comment on our solution or other solutions ? I'll summarise to the net. =============================================================================== From: aks@hub (Alan Stebbens) <aks%nowhere@hub.ucsb.edu> From my point of view, a subnetted Class B network is preferred to an unsubnetted network. In case you are not aware of the distinction, a subnetted network is one where part of the "official" host portion is used as a "subnet" number. In the case of a Class B, where the top 16 bits are the network number, and the bottom 16 bits are the host number, the host number is further split into two parts: the subnet number, and the "real" host number. In order for this to work, the routing software in IP must be conditioned to recognized the case of a subnet, using a subnet mask, usually 0xFFFFFF00, which extracts the complete "network number", with which routing is performed. Note that only the IP-type Ethernet packets are treated this way. The router software can either totally ignore other protocols (most do), or propogate them (most don't). This is a real win for separating IP networks from the Ether-hog DECNET. The reason subnetted networks are preferred to non-subnetted is that traffic within a subnetted network is contained, unless it needs to be routed further. Whereas, in an unsubnetted network, any traffic to a machine, no matter how logically "close", is transmitted needlessly to all other networks. Bridges are useful sometimes, but less so than routers, which can be implemented with multiple Ethernet interfaces in your computers. For example, in the College of Engineering, each of our file servers (Sun 3/260) is also an IP-packet router with two Ethernet interfaces. The clients are all contained within the subnet, so that all client NFS traffic is "contained" by the subnetted Ethernet, and no one else suffers the load. Of course, cross mounts sometimes brings NFS traffic around to the other subnets, but the root and swap NFS packets do not ever escape the subnet. Multiple interfaces on Sun 3/260's are *much* cheaper than either bridges or routers, and a spare Ethernet interface benefits all such servers. To provide similar redundancy with bridges and file servers would require spare Ethernet boards and a spare bridge. Multiple bridges also must be running the same kind of learning algorithm or your bridges could cause broadcast explosions or loops. If your bridges do not have a learning algorithm, then they are not as useful, and your network load becomes prohibitive. Almost all flavors of Unix these days support subnetted IP networks; their configuration is really pretty easy. > Would things change very much > if there were a couple of other protocols on the net ? In our case > we have at least IBM and DEC protocols that I know of, and maybe > others. We have DECNET in Physics, ITP, Geography, and Chemistry (from DEC VAX/VMS), and XNS (from Ungermann-Bass Net/One), as well as mostly TCP/IP. The few cases where non-TCP/IP packet-type routing is needed is taken care of by the appropriate software features in the routers installed at the various "entry-points" for each department. Our topology has a "backbone", to which nothing but gateways (routers) are attached. Each department specifies and configures their own router, which makes them responsible for whatever kind of routing they require. In the Physics et. al. departments, they have routers which understand routing for both TCP/IP and DECNET. In the Engineering departments, we have placed a router which understands only TCP/IP, and thus we suffer neither the XNS nor DECNET packets; Appletalk is supported as "encapsulated-IP". The only "noisy" subnet is our backbone Ethernet, a kind of "watering hole" for all of our subnets. Our philosophy is that each department routes only the desirable kinds of packets into their subnets. Since most departments tend to be packet-type homogenous, this saves much network bandwidth overall. The opposing philosophy is to route all kinds of packets everywhere (via bridges), and let each host choose what kind to listen to. Our feeling is that this would tend to waste network bandwidth within each subnet. =============================================================================== From: dutrun.uucp!ucbcmsa.bitnet!CLIFF@rutgers.edu (Cliff Frost {415} 642-5360) Hi, It would be ridiculously short-sighted to build one gigantic ethernet segment. You can, right now, buy routers from Cisco and Proteon that will route IP, DECNet, XNS, and many other protocols. Cisco has a router that will keep up with a LANBridge 100 on ethernet to ethernet packet pushing. The Cisco will even 'bridge' DEC's LAT packets and 'route' everything else. I don't know if the Proteon's do. There used to be some semi-reasonable arguments for building one big (multi-hundreds of hosts) ethernet instead of using routers and multiple segments. If there remain *any* reasonable arguments for doing it I haven't heard them. The technology has changed dramatically in the last few months, so what was "common sense" a year ago is not at all trustworthy today. Do you really want to deal with broadcast storms on a 10 building ethernet? =============================================================================== From: steve@umiacs.UMD.EDU Whether or not you do subnetting (or something that looks like it) has no effect on whether or not other protocols can push packets between cables. The only thing that matters here is whether or not the boxes that connect different cables can forward more than just one protocol. If you have bridges (or routers that can forward more than one protocol), your multi-protocol traffic will show up everywhere that it's appropriate. Bridges have the problem of forwarding too many packets; I don't like to see broadcasts (or ARP wars, or any other garbage) from networks I don't control, just because someone has screwed up. (I do think that bridges are a good idea inside of a particular administrative domain.) Still, I suppose this is a religious issue and, depending on the protocols you use and the money you have available, you may not have any choice. One thing that you can do is allocate 'slushy' subnets. For each cable or administrative entity or whatever, allocate some part of the address space to that cable/entity/whatever. Then make sure that address in that area are allocated from within that address space. You should probably still leave your netmask at the Class B default (255.255.0.0), and your broadcast address at the most backward-compatible value possible (unsubnetted, all-zeroes). Note that in the latter case, you will have to set the broadcast address at ifconfig time on newer machines. It is better to do that (and, thus, to be compatible with older software that doesn't know subnetted broadcasts from a hole in the ground) than it is to suffer from a multi-cable ARP war... Let's look at an example. Consider a fictional clone of umdnet, 128.8. Let's say that all cables are bridged together, so all traffic is still seen everywhere, and we don't want to turn on any sort of subnet routing. Let's assume a 'fake-o' subnet mask of 255.255.255.0. We might say, then, that the CS Department gets addresses 128.8.128.1 through 128.8.128.254. Similarly, the EE folks might get 128.8.133.1 through 128.8.133.254, the campus computing folks might get 128.8.10.1 through 128.8.10.254, and so on. This way, if you really need to put IP routers in to replace your bridges, all you have to do is set the subnet masks to the fake-o value (and, if you desire, change the broadcast addresses) everywhere, and you're all set. This is *much* less painful than changing a few hundred IP addresses. I hope this is useful, and I'd be interested in any other comments that others might have. =============================================================================== From: hedrick@geneva.rutgers.edu I agree with you. Our experience is that it is good to isolate departments behind a real router. I would not want to have a whole campus connected by bridges. There are routers that can handle several different protocols. cisco even has a box that will act as a router for IP and a bridge for other protocols. I suggest that you look carefully at what protocols you really have to support, and choose something that will route IP and also support the other protocols. =============================================================================== From: TKSJMI@UBVM.bitnet Hi Hans - we use Wellfleet Communications router/bridges with success. The boxes can route ip and decnet and bridge everything else, so LAT will interoperate in yur environment, too. Is Wellfleet in Europe? Hope this helps, JoAnn =============================================================================== From: dutrun.uucp!cbmvax!swatsun!pomeranz@uunet.UU.NET (Hal Pomeranz) I think our situation mirrors your situation (albeit on a smaller scale), and maybe you can profit from some of what's been going on with us. In the middle of last year, we got our official class B status. Now we have essentially three different computing groups on our campus: the CS department (the Sun-3's which I'm helping to run), the engineering department (which uses Apollo workstations of various varieties), and the general academic systems (a bunch of VAXes and MicroVAXes). Now the Suns and the Apollos run TCP/IP and the VAXen are a mixed bag of DECNet and IP hosts (actually our Suns have a lame version of DECNet, but we really don't use it). However, a piece of brain-damage on Apollo's part has made it necessary for us to subnet the engineering nodes. Despite the fact that we have multiple protocols (well, two anyway) running around on our ethernet, the subnetting has not been a problem. In addition, our bridges are NOT broadcast transparent, and we're still OK. I hope this helps you convince the powers that be to be somewhat more flexible... =============================================================================== From: aronson@julessun.nlm.nih.gov (Jules P. Aronson) Other protocols on the net should not affect the TCP/IP and in particular the type of TCP/IP network. The decsision to use or not use subnetting rests entirely on the TCP/IP protocol and on particlular the interaction of the other systems and gateways on your network which use TCP/IP. Most, if not all of the current implimentations of TCP/IP handle subnetting. =============================================================================== From: dutrun.uucp!auspex!bootme!guy@uunet.UU.NET (Guy Harris) That sounds a bit bizarre. Considering the addresses in question are IP addresses, and that all protocols running on top of IP can survive on a subnetted network as long as the IP implementation can handle it, I don't see why the existence of other protocols (meaning DECNET or ISO protocols or XNS or ..., I presume?) should make a difference. > I believe that there are non-ip protocols on the net, such as an IBM > protocol (between pcs and mainframes) and an Apollo protocol. > Unfortunately I cannot name them. > > Could this be correct ? Yes, there probably are non-IP protocols on the net; however, since subnetting affects only IP addresses, whether you use subnets or not shouldn't affect those protocols. (Now *those* protocols may have their *own* notion of subnetting, but I presume that'd be independent of IP subnetting.) There may well be a problem with subnetting due to those other protocols; however, I don't see what it would be, since the protocols I know of that you'd run on the network would either: 1) run on top of IP, in which case they should, in principle, not care whether the network is subnetted or not - they let IP do the work and care about it or 2) not run on top of IP, in which case they shouldn't, in principle, even know whether IP considers the network subnetted or not. It may be that the IBM protocol is something like NETBIOS on top of IP, and the IP implementations there may not be able to handle subnetting, in which case you might not be able to subnet - but that's not because there are "protocols other than TCP/IP on the net", it's because there is an IP on the net that can't handle subnetting. =============================================================================== From: ajw@manatee.cis.ufl.edu Our campus network has over 500 nodes in about 50 building at this time. I've been the network "project leader", so to speak. It's not part of my official duties as manager of the comp. sci. department, but it's something that I could do. There has been alot of pressure from other groups about protocols and architectures and all that. However, if I had it to do it "all over again", in some official capacity, I would not hesitate to require the following: 1) The official campus protocol is TCP/IP. 2) All connections to a campus backbone(s) are through dedicated routers (ie. subnetting) 3) Only the official network management team will have access to these routers. If you do it this way, you won't be disappointed. It's just SOOO much easier. TCP/IP is available everywhere and can do anything the other protocols do. Why fool around with anything else? If some shop would like to run, say, Novell, locally, fine. But I would NOT build support in for various protocols at the campus layer. Support just one between buildings. And go for subnets. Absolutely.