cck@cucca.UUCP (Charlie C. Kim) (05/25/86)
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 <uwvax!uwmacc!dorl@seismo.UUCP> 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
dougm@ico.UUCP (Doug McCallum) (05/26/86)
> 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). Hmmm. I don't have my 802.3 management spec handy, but I do know that 802 specific protocols don't use the type field as a type but as a length of the data segment. 0x8038 is not a valid length for 802.3. The management protocol was not published as part of the 802.3 standard. I haven't seen a published 802 management standard, but have seen a draft. It uses the 802.2 Logical Link Control protocol. I would be interested in what you find out. Another vendor with the same product is Vitalink. I think that the DEC and Vitalink boxes are the same product. Doug McCallum Interactive Systems {cbosgd, nbires, hao}!ico!dougm
phil@amdcad.UUCP (Phil Ngai) (05/26/86)
In article <264@cucca.UUCP> cck@cucca.UUCP (Charlie C. Kim) writes: >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. Ask your salesman for the current "Networks and Communications Buyer's Guide", they come out frequently and the Jan edition is out of date. >Basically, I should mention that the LAN Bridge-100 can be aptly >described as a "selective, adaptive repeater" between exactly two >ethernet segments. I think your use of the word "repeater" here is unfortunate as there is a specific meaning as to what an "Ethernet Repeater" is and the LANBridge 100 is not an "Ethernet Repeater". It is a bridge. >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." No, it's IEEE 802.1 management protocol, not IEEE 802.3. >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? I talked to engineers at Digital who confirmed my understanding of the above paragraph. Because the LANBridge 100 operates in a store and forward mode, each pass through one adds delay. The recommendation is that your network be designed such that any path only accumulates up to seven of these delays. A particular Ethernet can span 2800 meters, 2800 times 8 = 22,400. If delay is not important you can string an arbitrary number in series, subject to the 8K node limit. >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. Could you describe this 3 level DELNI setup? I thought you couldn't cascade DELNIs, that is, attach a DELNI to a DELNI? >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 The Vitalink box is much slower. DEC says the LANBridge 100 runs at full Ethernet speed. Vitalink is limited to something like 224Kb per SIO with a four SIO max. >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 DEC's (and many other people's) terminology, Bridges are by definition protocol independent. Perhaps you mean a router? -- Vote Yes on Proposition 51! Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
phil@amdcad.UUCP (Phil Ngai) (05/26/86)
In article <109@ico.UUCP> dougm@ico.UUCP (Doug McCallum) writes: >Another vendor with the same product is Vitalink. I think that the >DEC and Vitalink boxes are the same product. No they are not. The Vitalink box is based on Bridge Communications Corp hardware. The DEC box is their own design. I have seen both and they look quite different. -- Vote Yes on Proposition 51! Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
chris@umcp-cs.UUCP (Chris Torek) (05/27/86)
Incidentally, while I cannot confirm this, I believe that the Vitalink boxes use Xerox NS protocols to handle routing information between themselves. They broadcast this over the Ethernet looking for more Vitalinks. This is all well and good until you put a Xerox Inter-Network Router (INR) onto your cable. The Xerox box crashes unless all directly reachable XNS routers all claim to have the same network number. At this point you have to either convince the Vitalink to use your Xerox-assigned network number, change your network number to match the Vitalink's and hope that everything still works, or separate the cables. All we know for certain is that our own Xerox boxes running INR software were crashing because someone was claiming to be on network 1. We simply stopped running INR service, as there were no other networks for the Xerox machines to connect anyway, but this could be a problem for others. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu