Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!bloom-beacon!gatech!mcnc!sung
From: sung@mcnc.org (Wayne Sung)
Newsgroups: comp.dcom.lans
Subject: Re: Ethernet-Ethernet Bridges
Message-ID: <2979@alvin.mcnc.org>
Date: 7 Apr 88 11:33:09 GMT
References: <1716@aecom.YU.EDU>
Organization: Microelectronics Center of NC; RTP, NC
Lines: 41
Keywords: Ethernet Mac Layer Bridge
Summary: info about bridges


First, some specifics concerning the units mentioned. IB/3's are normally
equipped for serial line driving up to T1 line speeds. I am not aware of
a fiber optic version. It also does not allow a true ring topology (as is
true of almost all bridges, this sidesteps the loop question). It's thruput
is very good but setup is much more difficult than IB/1 or IB/2. In fact,
the IB/2 is the Enet/Enet version and can use fiber optic transceivers.
Retix now does offer net management using MAP protocols. Control is done
using a remote station. IB's have a serial port or can use a remote station.
LanBridge 100's indeed are normally controlled with their RBMS software.

In our system, which now includes around 40 bridges of all kinds, the thing
we see the most need of is not the local/remote filtering that all bridges
normally do, but rather specific filters to control errant behavior. For
example, the problem of subnet rwho's triggering large numbers of arps. In
this respect, no one yet beats Bridge for easily controllable filters. They
essentially allow an arbitrary string specifying the point in a packet and
the value to check. Vitalink allows fill-in tables which is not as good,
although in their latest release they also claim arbitrary filters (we don't
hae this release, don't know how it works). Retix and LanBridge are ok at
filtering multicasts, but not arbitrary packets. (The Retix guy says to me,
our throughput is high and we can't afford to put in too many filters because
the throughput will be reduced).

One of the earlier considerations of bridged nets is the amount of traffic
which can demonstrably be segregated. That is to say, if you know less than
10 percent of one department's traffic needs to leave it then bridging is a
good solution. If large amounts of traffic need to cross then bridging is bad.
It only introduces delay and possibly congestion. I have been handed some
ridiculous forwarding rates for bridges and soon we will have the capability
to verify these. Nonetheless, if you expect to need thousands of packets a
second forwarded you don't need a bridge, you need a repeater.

Since fiber optic is a possibility, consider something like the Fibercom
Whisperlan setup. It behaves like a non-filtering bridge, in that all
packets go everywhere but the distance can be much larger. This will give
the initial arrangement the global connectivity. The speed on the fiber
side is presently 40 Mbits/s so there is no congestion or delay problem.
They are working on FDDI drivers and so you're not locked in (I believe there
is a plan to trade FDDI units for Whisperlan units). Later on, if there
seems to be problems, bridges can be added as needed. Get a decent lanscope
first thing (or as we've found out, design your own).