Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!ptsfa!amdahl!amdcad!phil From: phil@amdcad.UUCP (Phil Ngai) Newsgroups: comp.dcom.lans Subject: Re: Tradeoff between LAN repeaters and routing gateways? Message-ID: <14236@amdcad.UUCP> Date: Wed, 7-Jan-87 23:27:03 EST Article-I.D.: amdcad.14236 Posted: Wed Jan 7 23:27:03 1987 Date-Received: Thu, 8-Jan-87 02:40:08 EST References: <476@savax.UUCP> <8238@topaz.RUTGERS.EDU> Reply-To: phil@amdcad.UUCP (Phil Ngai) Organization: Advanced Micro Devices, Sunnyvale, California Lines: 126 Having some experience with the DEC LANBridge 100, aka DEBET, I wanted to talk about how DEC has addressed some of the problems with bridges mentioned by Charles Hedrick. Note that the DEBET is not applicable to the original poster's application as it can not use leased lines. It can operate over fiber optic cable but there is a 2000 meter length limit. >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 A router can also provide slightly better communications efficiency because it need only send the level 3 packet, not the level 2 (MAC) packet. That is, a bridge has to send the Ethernet physical source and destination address and the Ethernet type number. A router does not. >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. This may not be possible, but could a cracker imitate a router? First, he could try to wipe out the real router and take its place. Most routers have some kind of network management virtual terminal port and it may be possible to get in this way to take it down. Second, if this approach failed, could he come up as a new router advertising via RIP packets a shorter way to a host he wished to imitate? The original point still stands, that it is easier to do evil on a bridge type network. However, if people use telnet or ftp, it's already pretty easy to grab passwords as they login and this is independent of the bridge/router issue. >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. Agreed, but I don't see how the "routing" standard would be a problem. The routing technique shouldn't vary. If you get a packet with a destination address you know is on the other side, forward it. If you get a packet with a destination address you know is on the same side, ignore it. If you haven't seen the address, forward it. Seems simple enough to me. > 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. The DEBET is claimed to be able to handle full Ethernet speed. DEC has done some clever things to make this possible. See the DEBET technical manual for more details. Other people's bridges do have bandwidth limitations. I won't name names in public. >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. A "repeater" does not have a network address. A bridge need not. The DEBET does have a network management address. In addition, it broadcasts "I am here" type messages periodically. A network of DEBETs configured in a redundant topology (a good one is a ring, as you get N+1 redundancy. That is, if you need 7 DEBETs and put 8 in a ring, any one of the 8 can fail without taking down the network. Much better than the usual "one spare for each unit in service".) automatically reconfigures when one DEBET does down. A minimum distance spanning tree topology is always maintained. >The DEC technology comes to mind here, >though we haven't actually used it. We used one for several months and had good results. Throughput and delay looked good. We only had one so we didn't get to try the redundancy but I have no reason to believe it doesn't work. We did not buy any due to budget constraints. They are about $8,000 or so. The DEBET is excellent for an "extended" Ethernet type application. That is, if you've run out of repeater allowances or collision propagation time limit, the DEBET allows you to "start over", in effect. If you are using thinwire Ethernet, for example, you start getting lots of repeaters all of a sudden. The DEBET is also good for isolating a segment with heavy local traffic, say between a file server and its diskless workstations. A router would work also but the network administration is more involved and the bandwidth through a router will probably be less. One of the important issues with bridges vs routers which has been much discussed in other forums but not here as far as I know is the issue of routing. The bridges make everything look like one big Ethernet. If it is not, if you have skinny wires(serial lines, say 9,600 or even 56,000) between sites, then you may want to take into account the bandwidth of the hops you are considering routing over. With a bridge, this is impossible. With a router, it is possible in theory although I don't believe any versions of TCP/IP are that sophisticated. But at least with a router, the infrastructure exists. Usage of redundant communications lines has already been covered by Charles but I want to reiterate that for us, redundancy is vital and waste is frowned upon. Systems that do not provide redundancy are unacceptable. Systems that fail to use the backup resources during normal operation to provide higher throughput seem badly designed. -- Butter and salt can make almost anything taste good. Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com