| see note 34.1 or ETHERNET_V2 703.
I have extracted some parts below. The bottom line is keep is less
than 200 nodes and both bridges MUST go back to a single "backbone"
or common point such that the backbone CANNOT be broken between
the bridges (AUI, thinwire or fiber). Backbone to backbone traffic
must never go into one DB90, thru the hub and out the other DB90.
See point "C" below.
But remember in the DEChub 90 only slots 7 and 8 have the extra
power for the DECbridge 90/90 FL, DECagent 90 or the DECrepeater
90 FA (when using the AUI port).
I don't see a situation that you would put 2 bridges in each hub
and then daisy chaining the hubs together. With 4 bridges it would
be easy to make a mistake and not have all bridges connecting to
just one backbone. Go with 2 bridges in one hub or one bridge in
each hub and then daisy chain the hubs together.
dave
<<< MOUSE::USER$:[NOTES$LIBRARY]ETHERNET.NOTE;1 >>>
-< Ethernet V2 >-
================================================================================
Note 703.3 questions for smarthub 3 of 9
PRNSYS::LOMICKAJ "Jeffrey A. Lomicka" 162 lines 8-APR-1991 10:59
-< More answers than you need >-
--------------------------------------------------------------------------------
> 2. What is the reason that a normal bridge (eg LB200) cannot be
> placed between two DECbridge 90 ? What is the meaning of 'end-node
> bridge' ? Is that implied the DECbridge 90 is not spanning tree
> compliance or only subnet of spanning tree has been implemented in
> it ? Does it support spanning tree, 802.1d or both ? If only
> 802.1d, does it imply we cannot use it in a spanning tree network
> (eg. network with LB100) ?
You have to be careful how you quantify "between".
By "end node bridge" we mean "no bridges connected to the work group
side". You can connect anything you want to the backbone side. The
reason for this is beacuse of the 200 node limit (I'll get into this).
The spanning tree in the DECbridge 90 is a full Epoch 2 algorithm. (Both
DNA and 802.1d.) You can use it with both LANbridge 100 and with IEEE
bridges, no problem.
The preferred configuration is:
(backbone A, over 200) +---------+ (backbone B, over 200)
--------+-------+ LB200 +-----+-----------+--------
| +---------+ | |
+---+---+ +---+---+ +---+---+
| '90 A | | '90 B | | '90 B |
+---+---+ +---+---+ +---+---+
|(Work group A) | | (Work group C)
--------+------ --------+--- ----+------------
(work group B)
The problem is that you cannot set up a condition where there is a ANY
POSSIBILITY that you may route traffic between two backbones through the
work group. Don't be tempted to redundantly feed one work group from two
backbones like this:
Really bad thing to do:
(backbone A, over 200) +---------+ (backbone B, over 200)
--------+-------+ LB200 +-----+--------
| +---------+ |
+---+---+ +---+---+
| '90 A | | '90 B |
+---+---+ +---+---+
|(Work group, under 200)|
--------+-----------------------+---------
Initially, the spanning tree will select one of '90A or '90B to go into
backup mode, and it will work fine. Then one day somebody trips over the
power cord to the LB200, and suddenly you find both DECbridge 90 units are
forwarding, and both have over 200 nodes in their work group!
Party line:
You may not connect any bridges to the work group. Redundant
bridging is not supported. This prevents anyone from configuring
the above scenario, accidently or otherwise.
Real truth:
A: If there are fewer than 200 nodes TOTAL in the ENTIRE extended
LAN, you can do whatever you want with DECbridge 90 units, just as
if they were full bridges.
B: You can put all the bridges you want in the work group, so
long as the total count of stations (counting bridges as two) does
not exceed 200 nodes, and none of these bridges attach to anything
outside the work group. The work group MUST be a CLOSED AREA, for
which the only way in is via one DEcbridge 90.
C: There is one "almost safe" redundant bridge situation.
However, the only thing redundant bridge situation protects you
against is the loss of power or failure of the WGB itself. It
REQUIRES that both bridges are fed from taps on the SAME backbone
cable.
(backbone A, over 200)
--------+-----------+-------- Both bridges attached to the SAME
| | CABLE!!! No equipment of ANY KIND
+---+---+ +---+---+ between them. No repeaters, no
| '90 A | | '90 B | bridges, nothing. SAME CABLE.
+---+---+ +---+---+
| |
--------+-----------+--------
(work group A, under 200)
This is based on the idea that there is no possible failure mode
where both bridges would be forwarding at the same time.
Remember, although these configurations will work, there is danger that
if they are later re-configured so that a path exists out of the work
group other than one DECbridge 90, a network failure that reconfigures the
spanning tree through the work group will blow away the 200 node limit,
and the network will become unusable. You are best advised to play by the
rules, using DECbridge 90 only when no bridges are required in the work
group, and using the LANbridge 150 or 200 for all other cases.
> 3. How can we set up a redundant path for the workgroup LAN ? For
> the normal Lan bridge family, we can do so by simply adding an
> additional bridge in parallel with the primary bridge. How can
> we do that for DECbridge 90 ?
See "C" above. Note that you MUST allow the backbone wire to be a single
failure point. You cannot do FULL REDUNDANT networking with '90s. You
can, in an unsupported way, protect against independent power failure of
the '90's or of the '90 itself.
|
| > C: There is one "almost safe" redundant bridge situation.
> However, the only thing redundant bridge situation protects you
> against is the loss of power or failure of the WGB itself. It
> REQUIRES that both bridges are fed from taps on the SAME backbone
> cable.
>
> (backbone A, over 200)
> --------+-----------+-------- Both bridges attached to the SAME
> | | CABLE!!! No equipment of ANY KIND
> +---+---+ +---+---+ between them. No repeaters, no
> | '90 A | | '90 B | bridges, nothing. SAME CABLE.
> +---+---+ +---+---+
> | |
> --------+-----------+--------
> (work group A, under 200)
>
> This is based on the idea that there is no possible failure mode
> where both bridges would be forwarding at the same time.
If you have any proof that there is no possible failure mode I would
greatly appreciate it. I am in a situation now where the customer
maintains that there is an infinitessimal, but still greater than 0
chance of a loop and therefore will not accept this kind of solution.
If I could prove that it cannot happen (multiple failures required) It
would make my life simpler.
Thanks,
Joel
|