terry@hq.af.mil (Terry Bernstein) (07/31/90)
We manage the Air Force LAN in the pentagon. It consists of a broadband running throughout the building, with numerious ethernet segments bridged off of it. We currently have 1 office (office A) running Banyon vines. They have 2 offices, each with their own ethernet, connected together over the broadband. To the vines system, it just looks like 1 big ethernet. Now another office (office B) wants to do the same thing -- use the broadband to expand their local vines network to another office. The problem is that we don't want this office to use office A's servers (routing servers ??). As I understand it, when turned on, the PC sends out a request for a routing server. Whichever server answers first is it. We would like it so that only the servers from that PCs office answer. Is there a way to do this in Banyon Vines????/ If not, the only alternative would be to filter addresses at the ethernet level -- only allowing a particular office's PC get to its server (or vice versa), but this would be a pain to manage. thanks, -- terry -- -- ------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>> Terry Bernstein <<terry@hq.af.mil<<< >"Who is John Galt?"> << The Pentagon <<< --------------------------------------------------------------------
jabusch@osiris.cso.uiuc.edu (John Jabusch) (07/31/90)
>We manage the Air Force LAN in the pentagon. It consists of a >broadband running throughout the building, with numerious ethernet >segments bridged off of it. >We currently have 1 office (office A) running Banyon vines. They have >2 offices, each with their own ethernet, connected together over the >broadband. To the vines system, it just looks like 1 big ethernet. >Now another office (office B) wants to do the same thing -- use the >broadband to expand their local vines network to another office. The >problem is that we don't want this office to use office A's servers >(routing servers ??). >As I understand it, when turned on, the PC sends out a request for a >routing server. Whichever server answers first is it. We would like >it so that only the servers from that PCs office answer. Is there a >way to do this in Banyon Vines????/ >If not, the only alternative would be to filter addresses at the >ethernet level -- only allowing a particular office's PC get to its >server (or vice versa), but this would be a pain to manage. >thanks, >-- terry -- >-- >------------------------------------------------------------------ >>>>>>>>>>>>>>>>>>>>>> Terry Bernstein <<terry@hq.af.mil<<< >>"Who is John Galt?"> << The Pentagon <<< >-------------------------------------------------------------------- I work on some very large Banyan networks (over 30 servers at this site alone) and we aren't even concerned about "routing" servers on the net. We have a very large Ethernet, using a thick backbone, lots of thin repeaters and even a couple of bridges. Our routing servers tend to be the fastest machines on the network. The way the routing server is selected is actually fine. The workstation boots, transmits a broadcast message via Banyan's broadcast packet format, trying to find a server on the network. The first server to respond becomes the routing server for that station. In order to be the first responding server, the server is usually the fastest (highest clock speed, etc.) or the least busy. Either case is usually okay, since the servers which are loaded down with heavy work don't usually respond quickly enough. You have the other problem of not having any segmentation on your Ethernet, as you said, one big, logical Ethernet. When this happens, you've dedicated a 10Mbps channel of your broadband to your Ethernet, and that's a given at each subnet. If the gateway box you're using (Chipcom?) doesn't have any filtering features, then everything is going through the broadband anyway, regardless of which server is "routing". The only concern for the network, then, is failure of the broadband. If it goes down, a person whose routing server is located on some other baseband subnet will end up having to reboot his/her computer, at which time the local server will definitely be the new routing server for that workstation. Being a routing server on a Banyan network is not a CPU-intensive task, because it's mainly a hand-off of resource addresses. If the workstation tries to link to a particular service, the routing server hands the appropriate address for that service off to the pc, which in turn then directly communicates with the service. You can subnet the Banyans, by placing two Ethernet boards in each server. Use the server to bridge to the Backbone via one Ethernet board, and the second board handles the local pcs on a separate logical Ethernet segment. This works very well and requires no other configuration parameters on the part of the Banyan - their software handles this automagically. Everyone in each office will have access to all resources on the network they would normally have access to. However, there is an overhead penalty to pay. Take the situation: ---------backbone---------- | | serverA serverB | subnets | ------------ ----------------- | | user1 user2 Banyan uses a separate suite of protocols, or rather, packetization handling, to work across a backbone. When user1 tries to access a file on serverA, for instance, their "local" server-client communications is used. However, if user2 tries to access the same file, his request at serverB is reassembled, then packetized in a different fashion for network routing, and passed on to serverA. The nice thing about this is that no matter how many Banyan servers you put in a network, and no matter the configuration of the logical network, cabling scheme, etc., every workstation can reach every server automatically. The performance penalty comes into play due to the reassembly and repacketization of network messages going on within serverB. I can give you some specific test examples, using an older version of the Banyan software. We ran a series of tests on performance degradation on a Banyan network in May of 1987. We have never had occassion or reason to run these over. The configuration was: ---------------- ============ A B 2 C D 4 --------------- ----------------- 1 3 - is Ethernet = is Arcnet The letters above represent Banyan servers A through D. The numbers represent workstations, all 386/16s. Each pc was the same, Compaq 386 model 70 (70 MB disk), with 3Com 3C501 boards, except number 4, which had an Arcnet board. Each server had a 3C501 board, B and C had an additional 3C501, and D had an Arcnet board. The servers were all Compaq 386 model 130 pcs, with 4MB RAM. The network was in a quiescent state - up and running for several hours, no activity, Saturday afternoon with no one else around. A 10 MB (Megabyte) file was created on server A. Then, the file was copied to each pc, one at a time, and the times recorded. We averaged the results and got: pc time to copy 10MB file 1 3.0 min. 2 6.0 min. 3 6.1 min. 4 9.1 min. The times reflect: 1. 3.0 minutes was the fastest - local link from server A to the pc 2. server A was using the routing packetization, which B then reformatted to the local link style for the pc and doubling processing time as a result 3. server A was using routing, server C handling the trans- lation to local. difference in time from #2 is due to server B in the middle just passing packets on through 4. server A, B, and C routing, but D is translating to local and to Arcnet packets. Interesting notes: - The translation from routing to local style packetization is a fixed overhead, or appears to be, roughly equal the local-only transmission time. Remember that the server handling the translation also handles local transmission to the pc. - local transmission is fastest - routing is only a slight overhead on the server, almost unnoticeable - translations between different cable types is very fast Calls to Banyan engineers confirmed that we were on track with our results. We have tried different versions of these tests, always with the same results, on more hops, more cable types, etc. The effect we were testing was always just basic transmission rate levels. Since that time, Banyan has released versions 3.0 and now 4.0 of their software, each having a major performance increases and better protocol handling. While we haven't tested this again in recent past, our servers are all faster hardware and software platforms, and I would expect to find a vast increase in the overall performance. For a small network, less than 50 or stations, I would not subnet the Banyans out. I would prefer to leave them on the same network. We don't use subnetting on our pc networks unless they get very big. As I said before, we've got 30 servers, with over 450 pcs, on one large Ethernet. We subnetted our Unix workstations because NFS generates a lot of traffic. However, we average about 15% utilization on our Banyan Ethernet in-house, and seldom peak above 40%, only for a few seconds. Feel free to e-mail or call me if you'd like to discuss this further. -- John W. Jabusch INTERNET: jabusch@cerl.cecer.army.mil MILNET: jabusch@osiris.arpa US Mail: USA CERL, PO Box 4005 Newmark Drive, Champaign, Il 61824-4005 Voice/Phone: Commercial (217) 352-6511