alan@cunixc.columbia.edu (Alan Crosswell) (01/06/88)
[Please no "I told you so's" and "you should have bought gateways" from the
peanut gallery. I am aware of the arguments pro and con. Irrespective of
those arguments, we have a number of LAN Bridges as I'm sure many readers
have and this article is addressed to them.]
We just got our first VMS system (condolences gratefully accepted:-)
partially to run RBMS. After running RBMS for about an hour now, I
can make the following observations:
+ The manual and program aren't all so bad as a recent posting to this
group indicated. If you are already used to dealing with DEC
software like NCP for DECNET then the commands will soon roll right
off your finger tips.
+ You can group all your bridges together and do neat commands like:
USE KNOWN BRIDGES
SHOW COUNTERS TO "filename" EVERY 5 MINUTES
This will poll all your bridges every 5 minutes and dump their counters
to a file. (You can poll every second if you like.)
- You have to know the addresses of all your lanbridges before you can
start querying them. Seems to me that, since they all talk to each
other with this wonderful multicast protocol in order to establish
the spanning tree for the network, RBMS should be able to listen for
a few minutes and figure out what bridges are out there. I know --
I should have written down the bridge addresses when I installed
them (ha!). Fix: use netwatch on a PC and get the bridge addresses.
(Figuring out which bridge is which after you find their addresses
is left as an exercise for the reader.)
- RBMS (or more specifically, the lanbridge) uses a unique method of
network management security: a combination of an unpublished
management protocol and financial disincentives. (How many bad guys
are going to spend the money to license RBMS just to turn off
someone else's lanbridge across campus?). Clearly, they assume that
the so-called "extended LAN" is in the "typical" corporate data
center environment and not in a decentralized university environment
where j-random departments could run RBMS and do all kinds of damage
to every bridge put theire owne (purely unintentionally -- it is
easy to apply the same command to the set of all known bridges).
- So you say, what about DIP switches 3 & 4 (enable/disable RBMS
access via port A/B)? Well, picture the typical backbone hierarchy
where some central support organization runs a backbone which
departments are connected to:
===+=====================+=== campus backbone
| |
+-----+ +-----+ (RBMS enabled on port A)
| X | | Y |
+-----+ +-----+
| | (RBMS disabled on port B)
===+=== ===+===
Dept. X LAN Dept. Y LAN
In this scenario, Dept. X can't clobber lanbridge X because RBMS access
to bridge X's B port is disabled. However, Dept. X can clobber bridge Y
since his packets arrive at bridge Y's A port!
Possible workaround (not yet tried): configure each bridge to drop
packets destined for the set of all other bridges. This won't break
anything since the only time a bridge's physical ethernet address is
used is for the management protocol. At all other times, it looks
transparent and assumes the address of the original packet's sender.
The RBMS command is something like:
SET FORWARDING PHYSICAL ADDRESS 12-34-56-78-9A-BC DESTINATION NONE
This leads to my next item:
? How come I get an error message back when I make a change to the forwarding
table as in the above example which says the change was made (and it has
indeed taken effect) but could not be saved in non-volatile RAM? Is this
some sort of old revision level problem that I should call field service
about? The bridges all show firmware version 1.0 (and they are all under
service contracts).
Comments, corrections, and Ultrix, 4BSD, or PC implementations of the protocol
gratefully accepted. We would even pay for it.
Alan Crosswell
User Services, Center for Computing Activities
Columbia University