Bridges vs. Routers

  

Date: Thu, 28 Jul 1994 15:48:59 GMT 

From: sthomas@mitchell.hac.com (Scott D. Thomas) 

Subject: Summary: Bridges vs. Routers 

Organization: Hughes Aircraft Company 

 

I want to thank everybody who responded to my post about the performance 

differences of bridges vs. routers.  Special thanks to Mike Drollman 

of Networks Northwest and Greg Pflaum of Software, Tool & Die. 

 

To summarize: The performance problem with bridges is the unnecessary 

broadcast traffic that is forwarded across the WAN.  Bridges CAN do 

filtering, some support filtering on specific protocols.  However, 

routers enable the network engineer greater flexibility for filtering, 

and other technics, such as "spoofing", as suggested by David 

Devereaux-Weber. 

 

Thanks again to all those who responded. 

 

        -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-== 

 

SUMMARY OF RESPONSES TO BRIDGES.VS.ROUTERS POST 

 

 From: Jim Burks <jburks@promus.com> 

 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 <CtBM89.wM@elmail.co.uk> : 

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 <weberdd@clover.macc.wisc.edu> 

 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).