SUMMARY OF RESPONSES TO BRIDGES.VS.ROUTERS POST From: Jim Burks Organization: The Promus Companies, Inc. If you're using the link for LAN-type stuff, you'll find that performace suffers, while total utilization on the satellite link is low. The problem is that LAN activity (file sharing, MS Mail, etc.) sends a request for a relatively small packet to be returned (~1kb), and waits for a response before sending the next request. This is the opposite of a streaming protocol (such as TCP/IP FTP) that streams data without waiting for an acknoledgement until a specified window is reached. Depending on the configuration of the bridges, and software and network use of them, they can be more efficient on a point-to-point link, but may pass more broadcast packets between the networks than necessary. From: sdaggett@netrix.com (Steve Daggett) Organization: NETRIX Corporation Actually this is not a "simple network". Depending on the protocol running on the LAN & WAN segments, the type of data, and the total usage of each segment of the network things could get pretty strange. > ( ---- ) > host bridge---sat.---/\ /\ ---sat.---bridge bridge--DSU > | | modem modem | | | > ------------ ---------- | > *Segment #1* *Segment #2* | > T1 | > | > host bridge---DSU > | | > ------------- > *Segment #3* > You didn't include the speeds for each of the WAN segments but I'll assume that the big bottleneck is the satellite hop. You will pick up about 750 ms delay for every hop over a satellite shot. The delay does nasty things to protocols like X.25 & TCP that are expecting a acknowledgment from the far end that the data was transmitted without error. You may also have exceeded the capacity of your WAN segments to carry data. When you exceed the capacity of the WAN your data will begin to buffer up and increase the delay in the network. You can also experience a condition called "thrash" were your data buffering up causes retransmit timers to pop. The datagrams caught up in the congestions are retransmitted causing even more congestion in the network. There are techniques for setting timers, frame sizes, and window size to combat the delay and increase throughput on the WAN. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >> EDITOR's COMMENT: >> The following paragraph is incorrect, bridges do filtering, so not all >> datagrams are passed. When the entire network was being bridged all datagrams on all segments were transmitted to every segment in the network. Therefore heavy usage between workstations on segment #3 could cause network congestion between segment #1 and #2. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! When you reconfigured to a routed network only those datagrams that are addressed to a workstation on another segment are actually passed on the WAN segments. Your traffic is now probably within the capacity of the WAN segments to carry data and therefore you don't experience the buffer or network delay. > I was under the impression that bridges were more efficient because > of lower overhead, less complexity, etc. and therefore would offer > the better performance. In some cases bridges offer better performance. Sometimes they are murder on the network. If segment #1 was an engineering office running high power workstations and passing gigabytes of data between stations then a bridged configuration won't work. If the entire network is an IPX network with light traffic between users and NOVELL mail servers then a bridged configuration might work. As with most things in communications today the official answer is " well, maybe yes ... maybe no ...". > Does anyone have thoughts on the matter? My personal opinion is that bridging in a WAN environment is probally a bad idea. It's better to go with the routed configuration. I be out of the office next week so I won't be able to respond to any follow up posts. I hope this helps to clear things up a little. From: leo@elmail.co.uk (E.J.Leoni-Smith) Organization: ElectricMail News Service In general bridge for performance and route for security. Routing enforces pre-deetermined segmntation. Bridging tends to adapt to the traffic. Routing also restricts broadcasts, so it tends to keep inter segment traffic to a minimum Bridging is easier to make work at very high throughputs: there is less computation per packet I think. From: cwg@urbino.mcc.com (Chris Garrigues) Organization: Microelectronics and Computer Technology Corporation (MCC) E.J.Leoni-Smith wrote in article : EJLS> EJLS>In general bridge for performance and route for security. EJLS> EJLS>routing enforces pre-deetermined segmntation. Bridging tends to EJLS>adapt to the traffic. EJLS> EJLS> EJLS>Routing also restricts broadcasts, so it tends to keep inter segment EJLS>traffic to a minimum If the network is sufficiently large, on a well engineered network you can get better performance out of a routed network than a bridged network because there's better control over what packets are sent where. (Give your doom players their own segment.) The problem is that a lot of sites don't have the talent available to engineer the network well, or the physical geography limits the ability to properly segment traffic. From: David Devereaux-Weber Organization: TELECOM Digest It depends on what protocols the network is carying. Routers can improve performance on several protocols by reducing unnecessary broadcast traffic -- for example, in an IPX network, if there are many servers, the servers periodically advertise their resources to the network in broadcast messages. Routers can suppress redundant messages like that and then regenerate them on the other end of a link. Furthermore, plain old IPX (without packet burst) sends a packet at a time and then waits for an acknowledgement that the packet arrived at the far end. A satellite circuit has a significant delay, which severely limits throughput. Routers can "spoof" the IPX protocol by sending an acknowledgement (an electronic white lie) from the local router before the packet is recieved by the far end. The far router blocks the acknowledgement, because it knows the near router has already simulated it. Because of the magnitude of the delay of the satellite link, several packets can be in the pipeline during the time required to send just one and wait for the ack. If your network is IP, much of the broadcast traffic (like ARP packets) can be kept off narrow bandwidth long delay circuits like the satellite link. So, in a purely local, wide bandwidth network, a bridge has less latency than a router, but in a narrow, long delay network like one with a satellite link, a router can reduce broadcast traffic and improve performance on many protocols. From: lars@Eskimo.CPH.RNS.COM (Lars Poulsen) Organization: Rockwell Network Systems, Copenhagen DENMARK > I have a puzzling (at least to me) situation. We have a simple > network with a satellite link included. Orginally, we bridged three > ethernet segments ... ... ... ... ... ... and got poorer that expected > results. We decided to replace the bridges with routers, one per > segment. The throughput was tripled! > I was under the impression that bridges were more efficient because of > lower overhead, less complexity, etc. and therefore would offer the > better performance. The most likely reason for your poor performance, is that one of the sites in question is a LARGE network (maybe several hundred stations or more ?) and the amount of broadcast/multicast traffic floating around in the network is eating up all the bandwidth of the DS-1 link. When connecting multiple LANs into one extended network, the connection can be implemented with different logical models. Bridging is the lowest level model; it takes to similar networks (such as two Ethernets or two Token-Rings) and joins them intpo one logical network. A bridge device on each end of the link: - goes into promiscuous mode (snooping on all traffic) - keeps track of which devices (identified by their Ethernet addresses) are on each end, and - forwards traffic for any device not know to be on the same LAN as the sender, as well as all broadcast/multicast messages across the link. Because this is done at Media Attachment Control (MAC) level, it is protocol independent, and requires very little setup. The downside is that all broadcast/multicast traffic is forwarded, as well as traffic from protocols that are entirely unsuited for wide area traffic. The larger the combined network, the larger the amount of background "slosh" og broadcasts, even as a percentage of total traffic. (For instance, every ARP request will be sent everywhere, theough almost all of them are for stations local to the sender.) When you have a couple hundred workstations, you are likely to have about 32 Kbps worth of "slosh". (Meaning you need a T1 to get any WORK done.) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >> EDITOR's COMMENT >> Some bridges can and do filter on protocol type, and can filter all >> broadcasts. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! To overcome the deficiencies of bridging, you need a router. Routers must understand each protocol and must be configured appropriately for each protocol. This means that somewhere in the organization there has to be a person who understands each protocol that is being routed, and who can set up an addressing plan and troubleshoot when problems arise. For a good textbook in this area, I recommend Radia Perlman's book "Interconnections: Bridges and Routers". Addison-Wesley, 1992. ISBN 0-201-56332-0. I think I paid $53.26 (incl CA tax).