Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!seismo!columbia!cucca!cck From: cck@cucca.UUCP (Charlie C. Kim) Newsgroups: net.dcom,net.lan Subject: Digital LANBridge-100 survey results Message-ID: <264@cucca.UUCP> Date: Sun, 25-May-86 16:58:19 EDT Article-I.D.: cucca.264 Posted: Sun May 25 16:58:19 1986 Date-Received: Tue, 27-May-86 06:29:02 EDT Organization: Columbia University Center for Computing Activities Lines: 195 Keywords: ethernet Xref: watmath net.dcom:1944 net.lan:1517 Following is a brief description of the LANBridge-100, some comments, and the responses that I received to the original posting. Since I posted the original message, we received a LAN Bridge-100 and installed it for testing; I include some information below. If you need information on what the LAN Bridge-100 is and what it can do, see the "Networks and Communications Buyer's Guide, 1986 January Edition" from Digital, pp. 2.55-2.61. Basically, I should mention that the LAN Bridge-100 can be aptly described as a "selective, adaptive repeater" between exactly two ethernet segments. It is selective in that it only forwards remote traffic - local traffic stays local (remote traffic includes broadcasts and multi-casts). It is adaptive in that it decides what ethernet address are on which segment by monitoring the traffic. It's protocol independent and runs in the data link layer - which means that it has access only to the ethernet source and destination addresses and the protocol type. No loops are allow between LAN Bridges. You cannot use multiple Bridges, of any sort, to relieve flow congestion, but configuring in two LAN Bridge-100s doesn't hurt - one acts as a standby. You don't have to download software. IEEE 802.3 or Ethernet spec compliant. The bridge is store-and-forward. This means that adding a bridge to two segments does not add any distance constraints to either. Finally, you can get a fibre optic version which runs to either a remote repeater (dec's derep-rc) or another fibre optic bridge with fibre lengths of 1000m and 2000m respectively. You can also get Remote Bridge Management Software which allows a VMS or microVMS system to gain some control over the Bridge. You can: diable selected Bridge, black traffic, and look at statistics. "RBMS uses the IEEE 802.3 managment protocol for use in both DECnet and non-DECnet environments." It also lets you do some manual routing and testing. I'm not 100% clear on the number of segments you can connect. DEC says "When planning an extended LAN, Digital recommends configuring a maximum of seven Bridges in a series. This figure insures the performance of time critical protocols. There is no restriction on the number of Bridges when time critical protocols are not an issue. An extended LAN consisting of 8,000 node addresses and spanning up to 22,400 meters can be constructed by using the Bridge." Well, the confusing part to me is the last sentence. The 8000 node limit is understandable - this is the memory in the LANBridge for node addresses. The confusing part is 22,400 meter part - exactly what do they mean by this? That this is the maximum? If so, why? Something to ask DEC about someday. --- In the meantime, what we've found out about the bridge is that it has a number of little dip switches that allow you enable/disable writing to non-volatile ram and enable or disable RBMS (802.3 bridge management probably) access on a port A, port B basis. We've beening running DECNET, TCP/IP, and LAT protocols across the Bridge without any problems for about 2 weeks now. It seems to do what it is advertised to do (can't speak for the RBMS software though - we don't have any VMS machines). Controllers on both sides include: DEUNA, DEQNA, KNI (DEC-20), Ungermann-Bass NIC, Interlan (Unibus), and various Intel based controllers (including Kinetics FastPath box, DEC PRO DECNAs, etc.) with DELNIs, H4000 taps, and TCL taps. One cable on the Bridge goes to a H4000 tap and the other goes to a DELNI (which happens to be tiered to 3 levels e.g. three DELNIs in the path). If you get one - take a look at the LEDs in the back - two of them are used to indicate traffic on each of ports. I wonder what happens when the Bridge sees the same ethernet address on both segments? This would be an interesting experiment. Approximately every second or so the box spits out a type 0x8038 packet of length 60 to the multicast address 0x09-00-2B-01-00-01. I suppose this is some keepalive counter related to the 802.3 management protocol. (I'm guessing this because DEC specific protocols tends to use type 0x600X packets, but maybe they were assigned the 0x8038 protocol type). I'm trying to get information about exactly what this packet is and what the "802.3 management protocol is". (I couldn't find anything in the copy of the 802.3 spec lying around, but I didn't look as carefully as I might have). The disadvantages? Indiscriminate broadcasts or multicasts will now affect a potentially larger community. Less control over what can go over the Bridges (e.g. may not be able to restrict various hosts from going through the bridge); what's on the extended lan is essentially on your LAN (with the important difference that you still maintain security on your segment from "netwatch" programs running on other segments). You must have a VMS system to get any discrimination on what the Bridge does - this is something that shouldn't be too hard to get around if the management protocol is publicly available. I'm sure that other people will come up with others. Finally, the cost - the box runs $8,000 list ($8,500 for the remote version) - is rather substantial. Following are the responses from various people, most simply state that they have one or more bridges and that they work fine. Several people also wrote to note that they were planning on buying a number of these. I'm still interested in hearing about realistic alternatives to the LANBridge-100. (The only thing that comes close that I've heard of is the Vitalink box, but that's really meant more for long-haul connections and about double the price (I think)). Other things I've heard some people asking for is a comparable box with more than two taps, a little more control over the packet types that go through (this may be there - I don't know anything about what RBMS allows you to do), etc. David Post at Siemens points out something that people should be careful about. He warns that running another kind of Bridge in parallel causes problems. I assume he means some protocol dependent bridge since I don't know of a comparable product to DEC's. In any case, this will definitely cause problems! This ends up being equivalent to putting a very short loop in the ethernet topology. Moral: don't put any other kind of packet forwarding device (except a standby LAN Bridge-100) between two ethernet segments connected by a LAN Bridge-100. From: hedrick@topaz.UUCP (Charles Hedrick) To: cck@cucca Subject: Re: DEC LANBridge-100s I have no actual experience, however I have a general comment on protocol-independent gateways. Normally they pass broadcast packets. This means that certain kinds of network problems can take down not just your own Ethernet, but any Ethernet connected to it by one of these Bridges. E.g. at the moment we have two sets of Suns, one which know about subnets and another which do not. They must be used on separate Ethernets. If a broadcast from one is ever seen by the other, we have big problems. I conjecture that if our Ethernets were connected by a protocol- independent gateway instead of our IP gateways, the whole system would become non-operational whenever any of our Suns tried to boot. We have also seen systems fail in a mode that floods the network with broadcasts. For us, this kills only the one Ethernet they are on. So I would look very carefully at what the LANbridge 100 does with broadcasts. [ Yes, this is something people should be aware of, but I think the advantages will generally outweigh the disadvantanges in most cases. This sort of thing is something the vendor (e.g. Sun) should fix if they already haven't. - cck] ---------- From: harvard!talcott!sob@seismo.UUCP Subject: Re: DEC LANBridge-100s we have one here on test and it works just like it should. it has been quite important since we used it to isolate a sick vms site from the rest of our ethernet. scott bradner harvard university --------- From: Michael Dorl Subject: Re: DEC LANBridge-100s Organization: UWisconsin-Madison Academic Comp Center We bought three LAN 100s and are using them to bridge between a backbone broadband Ethernet using ChipCom transceivers and two baseband Ethernets using H4000 transceivers. The third LAN 100 is intended to bridge between the east and west portions of the braodband network which is now longer than spec's allow. The LAN 100s seem to work just fine. We have not put a lot of load on the system. I just took the things out of the box and plugged them in and everything worked. The plan is to add lots more LAN 100s as $ become available. The network uses TCP/IP. --------- Date: Tue, 20 May 86 13:35:41 edt From: dep@siemens.uucp (David E Post) Message-Id: <8605201735.AA06100@siemens.uucp> To: seismo!columbia!cck Subject: Lan Bridge-100 We at SIEMENS RTL in Princeton N.J. have had a LANBridge-100 working in our Ethernet network for over two months. I has worked without any problems at all, as long as we connected it correctly. We found that you could not put the LANBridge-100 in parallel with any other make of bridge. The only symtom we got was our Micro VAX's crashed. We have SUN's, 11/780's and uVAX's on our network and only the uVAX's had the above problem. The LANBridge-100 does not appear to propogate brodcast packets that have bad CRC's. ********* END OF RESPONSES ********* Charlie C. Kim User Services Columbia University