Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!topaz!root
From: root@topaz.RUTGERS.EDU (Charles Hedrick)
Newsgroups: comp.dcom.lans
Subject: Re: Tradeoff between LAN repeaters and routing gateways?
Message-ID: <8238@topaz.RUTGERS.EDU>
Date: Wed, 7-Jan-87 00:19:37 EST
Article-I.D.: topaz.8238
Posted: Wed Jan  7 00:19:37 1987
Date-Received: Wed, 7-Jan-87 02:58:58 EST
References: <476@savax.UUCP>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 157
To: dove@savax.UUCP


I'm responding to your message in public as well as by mail because
I've found recently that a number of people don't understand the
dangers to using bridges, which you refer to as filtering repeaters.
Bridges include the DEC LANbridge, Vitalink, Applitek broadband and
fiber bridges, and point to point selective repeaters from companies
such as Ungermann-Bass.  Routers for IP are primarily from Bridge,
Cisco, Proteon, and, Ungermann-Bass.  Of course the main conceptual
difference is that they operate at a different level in the OSI level
hierarchy, and thus use different classes of address.  The bridges
decide whether to forward a packet based on its Ethernet address,
while the routers use the protocol address (normally the IP address,
but there are routers for other protocols, and some that will handle
multiple protocol types).

The bridge has the obvious advantage that it will work with any
protocol or combination of protocols.  Because it is based on only the
Ethernet address, in theory it can handle any network services capable
of passing over Ethernet.  This can be a big advantage for
organizations that use many protocols, or that are not sure what they
may be using in the future.  In addition, because the bridges don't
know anything about the protocols, the software in them is less likely
to need continual upgrades as protocols and needs change.  You can
think of a bridge as a piece of hardware.  You should think of a
router as routing software that happens to run on a particular kind of
box.  You are going to be conscious of that software.  You are likely
to need new features as time goes on, and changes will likely be
needed as protocols and your needs evolve.  You may even run into bugs
and crashes.  In theory, once a bridge works there would be no need to
update it.  (One suspects that in practice there will be new releases
of software with them as well, particularly the more sophisticated
ones.  At Rutgers we actually have more crashes from our bridges than
our routers, but I think that is because we have unusually unreliable
bridges.)

The advantages of routers include the following.  More detailed
explanations will follow:
  - better isolation from misbehaviors on the other Ethernets
  - a slight increase in security
  - more routing flexibility
  - the ability to handle busy networks
  - network monitoring

ISOLATION

Most of the new bridges work in roughly the same way: They watch all
packets on the local Ethernet, and make a list of every Ethernet
address that has appeared.  When they see a packet addressed to an
address not on the list, they know it is intended for another
Ethernet, and forward it.  The problem is, what should they do about
broadcasts and multicasts.  For various good reasons, it turns out
that they have to forward them.  The problem is that certain kinds of
configuration errors can result in "broadcast storms".  We have seen
such things several times on Ethernets that contain diskless Suns.
(They were a result of development work.  Properly configured Suns
don't just suddenly decide to start a broadcast storm.) During such a
storm, the rate of broadcasts is large enough to bring every machine
on the network to its knees.  By its nature, a broadcast must be
processed by every machine that sees it.  It takes a certain amount of
CPU time to look at the packet and figure out whether it is for you.
If the packet rate is high enough, this can take over your machine.
In practice this seems to happen before the Ethernet is physically
saturated.  With bridges, these broadcasts will be passed on to all of
the other Ethernets.  It's not clear how serious this problem would be
in practice.  It is possible in principle to put various safety
features in the bridge to prevent complete disaster on all of the
Ethernets.  But I'm not at all sure whether actual bridges use these
safety measures.  I'm also not sure how often a broadcast storm would
happen to other sites.  It happened to us because of changes we were
making to the Sun network handling.  But I am nervous about a design
where one misbehaving workstation can bring down the entire campus.

SECURITY

No Ethernet is very secure, if you have people who can run their own
software on a machine attached to the Ethernet.  However routers do
provide some help.  Normally when a router is in use, each Ethernet is
a separate subnet.  No matter what a user does with his machine, he
can't pretend to be a machine on a different subnet.  With bridges, in
theory a student could program his PC to look like any other machine
on campus, and then take advantage of any .rhost files to break into
files on other machines.  A network constructed with bridges is
logically a single large Ethernet.  If he does this on a network built
with routers, he can only imitate other machines on his own Ethernet.

ROUTING

It is very hard to construct complex networks using bridges.  Some
implementations are better than others.  With the simplest kinds, it
is not feasible to use redundant connections to get faster throughput
or insurance against failure.  DEC's technology (which I believe is
also licensed by Vitalink) seems to be the most sophisticated.  They
can handle configurations with redundancy, but they can't use the
redundant lines.  That is, when they detect a loop, they put a link
into standby mode.  Should a failure occur, that link can be brought
into play.  This helps reliability, but still can be a limit on
configuration.  Suppose you have a large network

		A ---- B ----- C ----- D ------ E

A and E find that they talk to each other a lot, and want to install a
direct line.  That line would cause a loop.  With most vendors,
turning on a line from A to E would get the system into a loop and
cause trouble.  With the DEC LANbridge, it's OK, but the line wouldn't
be used unless one of the others fails.

Note by the way that there is a routing standard for IP.  There is
some hope that you can build a network with both Proteon and Cisco
routers, because they both (I think) will support RIP routing.
There is no such standard for bridges, so you will want to construct
networks from just one vendor's product.


BUSY NETWORKS

Note that bridges must look at every packet on the network.  This is
because the machines that use them don't know they are there.  The
bridge must be prepared to forward a packet addressed to any Ethernet
address on the other end.  With existing technology, the only way to
do that is to run its Ethernet interface in "promiscuous mode", and
examine every packet.  This means that one could saturate a bridge by
attaching it to a busy network, even though little if any traffic
actually passes through the bridge.  Again, how serious this problem
is depends upon the vendor.  Based on vendor specs, at least some
bridges would have problems coping with out networks.  However boxes
built with special-purpose high-speed hardware (as the LANbridge is
reputed to be) may be able to cope with fairly high packet rates.  A
router only needs to look at the packets that actually go through it.


NETWORK MONITORING

Again, this depends upon the vendor.  A simple selective repeater may
cause you trouble with network diagnosis.  There is no easy way to
tell whether it is working.  We have a program that periodically
issues pings (echo requests) to all of our routers.  If a router is
down, it will stop answering pings.  But a repeater has no address of
its own.  There is no way to ping it.  You have to ping a bunch of
hosts, and deduce that if you suddenly can't reach any host on network
X, probably the bridge going to that network is down.  However the
more sophisticated bridges have their own network management software.


GENERAL COMMENTS

If you do decide to use bridges (because of cost, simplicity, or
because you need to support protocols that you can't find routers
for), I'd be very careful how they are used.  For a network of any
size, I'd pick a system that can do some routing and that has network
monitoring capabilities.  The DEC technology comes to mind here,
though we haven't actually used it.  I'd also put at least some
routers in the system at points where you think you need isolation.
You have to be insane to use bridges between different companies or
universities.  You also probably want to isolate student from
administrative portions of the network.  You will also want to use
enough routers to allow you to put in redundant connections where you
want them.  But my personal preference would be to use routers
exclusively.