[comp.dcom.lans] bridges & address filtering

eli@spdcc.COM (Steve Elias) (05/31/89)

i'd like to get people's opinions, theories, and war stories on the
subject of bridging and address filtering.  some bridges do address
filtering with hardware, others use software (hash tables, lookup tables).

what sort of advantages and disadvantages do you expect with each 
technique?  we'd be interested to hear from you whether you are a
bridge designer or a bridge user...

thanks...

steve elias
chipcom corp.


-- 
 ...... Steve Elias (eli@spdcc.com);(6178906844:days); {}
 { Apple: keep your lawyers off of our computers! }

robert@ms.uky.edu (Robert Lee) (06/01/89)

We've had some experience with bridges at UK.  For the most part we use
them to isolate the various ethernets on campus from the broadband backbone.
Currently we use the UB-DLB and LAN-100 bridge, the latter had a bug.
if someone used a destination address of all 1's FFFFFFFF the routing table
would get trashed.  It turned out the LAN-100 was using FFFFFFFF as the
terminating entry for the routing table...  We also use the 
UB DLB(Data link bridge) with no problems.  We have a limited set of
management capability for these bridges and would like to have much more.

With the UB DLB we can program filters bi-directionally but not 
uni-directionally.  It would be nice if we could do this with a bridge
also it would be *very* nice if there was a extensive set of tools that
would work with bridges at the network management level. 

For example here are some things I would like to be able to do with
a bridge.

1) Be able to tell the bridge to disconnect from a ethernet for a time
   or until I tell it to turn its packet forwarding back on.
2) Be able to tell the bridge to forward all the packets it sees.
3) Programmable filters that don't degrade packet forwarding to any high 
   degree.
4) A extensive set of statistical variables.  Like # packets/sec. Collision
   etc etc.  Also it would be nice if these results could be put into
   a file that can be processed with statistical programs like SAS or SPSS.
5) Bridges usually only look at the ethernet address header and
   not what type of packet it is.  It would be nice if there was a facility
   that allow the bridge to forward based on packet types.  I can do
   this to some extent with filters now.

Anyway, that's what I would like for a bridge.   

Robert Lee
SYSBOB@UKCC
University of Kentucky

ron@ron.rutgers.edu (Ron Natalie) (06/01/89)

The LANBridge learning of the broadcast address is a bug.  It
showed up in later releases and hopefully has been fixed by now.

You are certainly learning all the instances where a router
would be much handier for you than a bridge.  You might call
up Cisco and Proteon and get them to do a song and dance for
you.

-Ron

ggm@brolga.cc.uq.oz (George Michaelson) (06/02/89)

On a parallel note, what is the effect of address and <other> filtering
on throughput? My personal measure based on light loadings of some
2Mbit ethernet bridges is that ANY address filtering makes throughput 
appreciably slow. -Of course large packet protocols are less affected 
but per-character packet activity is a bummer. I was surprised how visible 
this could be given 10Mbit one side, 2Mbit the other.

	-George

-- 
ACSnet: ggm@brolga.cc.uq.oz                    Phone: +61 7 377 4079
Postal: George Michaelson, Prentice Computer Centre
          Queensland University, St Lucia, QLD 4067 

reb@hprnd.HP.COM (Ralph Bean) (06/03/89)

> 
> For example here are some things I would like to be able to do with
> a bridge.
> 
> 1) Be able to tell the bridge to disconnect from a ethernet for a time
>    or until I tell it to turn its packet forwarding back on.

HP's 28647B (ethernet to StarLAN) and 28648B (ethernet to ethernet) bridges 
can be instructed, via network management, to "not forward".

> 2) Be able to tell the bridge to forward all the packets it sees.

HP's bridges can do this, too.

> 3) Programmable filters that don't degrade packet forwarding to any high 
>    degree.

HP's bridges can filter out multicast packets, and can filter packets based
on MAC address.  There is little, if any, performance degradation, even if
many addresses are specified.

> 4) A extensive set of statistical variables.  Like # packets/sec. Collision
>    etc etc.  

Approximately 50 statistics are maintained by the HP bridges.  They can be 
inspected or cleared via network management.  These stats can be logged to a 
disk file.  Additionally, alarms can be set on many of the statistics.  The 
user can specify the alarm level and sampling interval (e.g. 1000 pkts in 2 
seconds).  When an alarm goes off, the user sees the bridge icon go red on 
the network management station.  The alarm is also recorded in an event log 
in a disk file.

>    Also it would be nice if these results could be put into
>    a file that can be processed with statistical programs like SAS or SPSS.

Both the stats and alarms are stored in an ASCII format, for ease of access.

> 5) Bridges usually only look at the ethernet address header and
>    not what type of packet it is.  It would be nice if there was a facility
>    that allow the bridge to forward based on packet types.  I can do
>    this to some extent with filters now.

Sorry. We don't do this.

> 
> Anyway, that's what I would like for a bridge.   
> 
> Robert Lee
> SYSBOB@UKCC
> University of Kentucky
> ----------

Ralph Bean
Hewlett-Packard

eli@spdcc.COM (Steve Elias) (06/06/89)

In article <326@brolga.cc.uq.oz> ggm@brolga.cc.uq.oz (George Michaelson) writes:
>
>On a parallel note, what is the effect of address and <other> filtering
>on throughput? My personal measure based on light loadings of some
>2Mbit ethernet bridges is that ANY address filtering makes throughput 
>appreciably slow. 

	some bridges really do support "full ethernet throughput".
	(define that term if you can!).  shall i plug our product?
	performance analysis of bridges is nontrivial -- but it is quite
	possible to get nearly 10 Mbps throughput through a lanbridge.

-Of course large packet protocols are less affected 
>but per-character packet activity is a bummer. I was surprised how visible 
>this could be given 10Mbit one side, 2Mbit the other.
	
	if you are interested in long distance ethernet extension,
	please give me an email.  also, if you have any ideas about
	how (why) to use a 20 Mile logical ethernet to connect Internet
	sites, drop me another email!  technically, two of our (Chipcom's)
	Marathon Bridges could run much further than 26.2 miles, if 
	anyone builds a broadband plant that long...  volunteers?


steve elias, chipcom corporation

..................
-- 
 ...... Steve Elias (eli@spdcc.com);(6178591389); {}
 { Apple: keep your lawyers off of our computers! }