Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!decwrl!hplabs!hpda!hpcupt1!hprnd!reb
From: reb@hprnd.HP.COM (Ralph Bean)
Newsgroups: comp.dcom.lans
Subject: Re: bridges & address filtering
Message-ID: <2230005@hprnd.HP.COM>
Date: 2 Jun 89 23:54:37 GMT
References: <3407@ursa-major.SPDCC.COM>
Organization: HP Roseville Networks Division
Lines: 54

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