glen@aecom.YU.EDU (Glen M. Marianko) (04/06/88)
We are planning a campus-wide ethernet here and are running into some hair-pulling questions, specifically about mac-layer bridges. We have about 6 buildings that will be wired with either a thick or thin riser cable (any arguments about preference for one or the other are welcome). One building will be the "center" or hub of the network with the other buildings connecting to the hub in a star fashion using ethernet fiber optic repeaters (multiport at the hub). We thought it would be a good idea to incorporate mac-layer bridges in the design with, at bare minimun, a learning ethernet-ethernet bridge at every building (between the riser and fiber repeater to the hub). We came to this conclusion for two reasons: first, maximizing throuput by deleting packets that would propagate where they are not needed; second, so that we won't exceed the number of repeaters in the network. In reading a recent issue of LAN Magazine, it became apparrent that different bridges have different filtering/passalong speeds. DEC's was rated the fastest, but it uses a VAX for network management; Retix was the cheapest but no management I could find; Bridge IB/3 seems like a nice compromise using a standalone manegement station with backup links, and so on. Big question is, are we shooting our network in the foot by putting in bridges - in other words will the bridge become the bottleneck before the ethernet does? I've heard all the comments about typical ethernet usage being about T-1 speed, but what about the times it bursts - the network could still theoreticaly service more when that happens? What would be the sense of having fiber between bridges if the bridge would reduce us to 1-2 megabits/sec.? Anyone have any bridge preferences? IB/3 seems like the best, but doesn't come cheap. It also seems like it could support 2 fiber links between other IB/3s in a ring fashion providing better network reliability at the hub (now just a fiber patch panel). -- Glen Marianko glen@aecom.yu.edu
sung@mcnc.org (Wayne Sung) (04/07/88)
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).
ron@topaz.rutgers.edu (Ron Natalie) (04/08/88)
Well, I think you are shooting yourself in the foot using bridges not because of their bandwidth, but because I don't think joining all the segments together at the MAC level is the right place. We manage a large multiethernet network spanning six campuses here. Even the learning bridges don't provide enough isolation between the segments. For example, broadcast messages are obligated to go everywhere, but these very packets can melt down diskless nodes, and cause other bugs normally unnoticed in a small network to leap up and strangle the net. For a good lesson read Len Bosack and Charles Hedricks paper in the recent IEEE Network Magazine. What we use are protocol specific routers which allow us a much tighter level of control. The two major vendors Proteon and Cisco both make good products and each supports multiple protocols (if you must, I'm an IP bigot). -Ron "Bridges freeze before routers" Natalie
ron@topaz.rutgers.edu (Ron Natalie) (04/08/88)
Also, rather than using fiber optic repeaters, consider using one of the ethernet over fiber products (we like FiberCom). This provides multiple drops from the same fiber backbone and makes life a little more convenient. -Ron