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 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! }
@rice.edu:JACOBSON@LSUVAX.LSU.EDU ("Michael_Jacobson, Networks Manager, L.S.U.") (06/06/89)
Finally a problem simple enough that i know the answer.
The problem appears in DEC bridges that have v2.0 of the rom software. There is
a new set of roms that fix the problem. Unfortunately the FCO for this rom
change is still not out so your field service rep will have to special order the
ROMs. We have 19 brdiges here and our filed service rep can only order 3 sets of
ROMS at a time. It is taking a while to get them replaced. If you have RBMS I
can send you a com file I got at DECUS that will go out and check to see what
bridges have the problem and then send you a mail message and/or send the
commands to clear the bridges (you set a flag in the comfile as to the action
you want taken.)
Hope this helps,
Mike Jacobson
Jacobson%lsuvax.bitnet@cunyvm.cuny.edugary@SALT.ACC.COM (Gary Krall) (06/09/89)
>Date: 31 May 89 22:43:45 GMT >From: robert@g.ms.uky.edu (Robert Lee) >Organization: U of Kentucky, Communications Services, Networking. >Subject: Re: bridges & address filtering >To: tcp-ip@sri-nic.arpa >Status: R Robert, >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. ACC's ACS 4110 (remote ethernet bridge) product implements SNMP management in an effort to provide some of the tools necessary to manage bridges. Currently, SNMP commands are entered locally through a RS232 console port mounted on the rear of the unit. Through that port commands can be issued to the local unit or to any currently accessible remote unit. Management stations which support SNMP (and those ACC enterprise specific variables) could also access the units. >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. The SNMP implementation on the ACS 4110 unit supports the ability to disconnect or connect from a ethernet in two ways. The first is to disable the physical port, or alternatively the spanning tree port (802.1) may be disabled. In either case when the port is enabled packet forwarding may resume. >2) Be able to tell the bridge to forward all the packets it sees. In a local environment this might make sense, but in a remote environment where bandwitdh is at a premium this is not suggested. However, the ACS 4110 can certainly be configured to disable "learning mode" and effectively forward all packets it sees. >3) Programmable filters that don't degrade packet forwarding >to any high degree. The ACS 4110 supports filters based on the 802.1 specification; in general the specification of arbitrary filters is not without it's cost. It all comes down to implementation and capabilities of the unit. >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. SNMP management supports basic data collection and control. Some statistics are available to the user such as number of packets passing through an interface. Rather then having the unit itself calculate statistics, a SNMP based management station could calculate more complex statistics such as packets/sec based on collected data and so on. >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. I mention this above, but in addition to priority forwarding on protocol type the ACS 4110 can also discard by protocol. >Anyway, that's what I would like for a bridge. Hope that helped. >Robert Lee >SYSBOB@UKCC >University of Kentucky Gary.