The Hacker's Encyclopedia 1998/hackers_encyclopedia.iso/phreak/sysinfo/br_vs_rt.txt

Text File | 2003-06-11 | 10.3 KB | 227 lines

SUMMARY OF RESPONSES TO BRIDGES.VS.ROUTERS POST

 From: Jim Burks <[e-mail]>
 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: [e-mail] (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: [e-mail] (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: [e-mail] (Chris Garrigues)
 Organization: Microelectronics and Computer Technology Corporation (MCC)

     E.J.Leoni-Smith wrote in article <[e-mail]> :
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 <[e-mail]>
 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: [e-mail] (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).