| It's my understanding that the BAYswitch 28115 has a spanning
tree algorithm called "Lattispan" (spelling may not be exact).
It is a modified version of IEEE 802.1d, and defaults to this
algorithm. Along with the use and implementation of this modified
version of 802.1d in the 28115, comes some other "baggage" in the
form of other configuration rule restrictions. Other than this
information, I have no other familiarity with their configuration rules.
Your customer should probably read the BAYswitch 28115 documentation
shipped with the product to get more familiar with the configuration
restrictions. There may be a way of setting the 28115 to the real
IEEE 802.1d spanning tree rather then the BAYswitch default.
Now why there should be a difference in behavior when the 900EF is
configured with router code, I cannot answer, other than guessing
that maybe when using CLI to enable bridging, you didn't restart the
router, thus the router still didn't really have bridging enable, and
this could explain why the router (configured) 900EF "appeared" to work.
One thing I do know is that both the 900EF switching firmware and
the router firmware use the IEEE 802.1d spanning tree algorithm.
Bob
|
| Bob is exactly right......LattisSpan is causing the problem. You must
add two address filters to the DECswitch 900 EF to filter the
LattisSpan packets. The two addresses are: 010081000200 and
010081000201. The Bay documentation does mention this limitation
of the Bay 28115. Because the 28115 does not support the standard
IEEE 802.1d spanning tree, you must place these address filters
in any other internetworking device that connects two 28115
switches. This way, each 28115 in your configuration will
consider itself to be in it's own LattisSpan community
and won't cause other 28115s to go into configuring mode.
Chris
|