|
> 1) purpose of the bridges #A & #B is to get a backup link between segments 1
> & 2 in case of a failure of one of the switches. Does the topology
> automatically imply that one of bridges # A or B will be in blocking mode,
> or is there anything to configure specifically.
If you only have 2 to 4 ethernets on each switch, why not use one of
the remaining ones for the backup links? You don't need separate
bridges. Run a connection from segment 1 to Switch 3 and one from
segement 2 to Switch 1 and you have each segment connected to 2
switches.
If you don't have the ports, what sort of bridge did you have in mind
for this [hint: don't say 'DECbridge 90']?
> 2) use of connections like segment 3 on both switches #1 and #2: I suppose
> in this situation one of the switches port will be blocking: can I decide ?
> Furthermore, is it allowed to put two DECswitches 900 EF "in parallel" with
> - DAS connections on the same FDDI ring.
> - all Ethernet connections in parallel on the same 6 segments.
> In this case, in normal operating mode (both DECswitches are on) may I split
> the blocking ports (e.g. 3 on each) thus making overall performance even
> better.
Yes - 802.1d support means that you may have them in parallel.
It is possible for you to control the spanning tree to some extent.
You can set the spanning tree priority (dot1dStpPriority) to select
which switch will become the root (On our LAN, I set the priority of
one switch to '0' so that I know it will be the root, and another to
'1' so that I know which one will take over if it fails), and you can
set the cost of each port (dot1dStpPortPathCost). The path with the
lower cost to the root will be the active connection.
However, you shouldn't really need to; since the switches forward on
all ethernets at line rate none of them will become a bottleneck even
if all the traffic goes through one switch. The default costs will
ensure that the FDDI link is preferred over an Ethernet.
|
| Thanks for helping and a few further questions.
> If you only have 2 to 4 ethernets on each switch, why not use one of
> the remaining ones for the backup links? You don't need separate
1) The customer was asking what happened in a case where a DECswitch comes down.
So I did investigate solutions with external backup.
2) At the beginning there should be free ports but after, remaining ports
would be used for dedicated connections of servers.
> If you don't have the ports, what sort of bridge did you have in mind
> for this [hint: don't say 'DECbridge 90']?
I was considering LANbridges (150 or 200, i.e. 802.1d) that are already
in place and would provide that "external backup" at no extra cost.
Does your question mean that there is a possible limitation where external
simple Ethernet bridges would not understand such a spanning tree config.
> Yes - 802.1d support means that you may have them in parallel.
> It is possible for you to control the spanning tree to some extent....
If I understand you well, FDDI should be the root path. And in case
of two parallel DECswitches, I can set one of them to be primary.
One more question about spanning tree:
Let's assume a typical configuration as drawn in .0, where there would be
some segments shared between two switches (as segment 3 on the drawing in .0)
If one of the DECswitches comes down, I understand that all active ports on
the failed DECswitch would be backuped by corresponding ports on the
remaining one.
|
|
My question about what other bridges you were planning to use was just
to make sure that they were not DB90's - they can't be used that way
because of the address limit on the workgroup port.
Any 802.1d bridge should correctly participate in a configuration like
yours; that's what 802.1d is all about.
Yes - unless you do something wierd the FDDI will be used in preference
to an Ethernet right out of the box.
If you want to control which switch/bridge is the spanning tree root,
set the bridge priority of that one to a low number ('0' is the lowest
it can go, and works fine - the default on our bridges is 128). You
can do that in the Spanning Tree Information panel of the Bridge
Summary screen in HUBwatch, or by setting the dot1dStpPriority if you
have a generic mib tool.
I'm not sure that I understand your redundancy question; to take a
simple case:
segment X
------------+----------------------+---------------------
| |
| |
| |
#====|=====# #====|=====#
[ ] [ ]
[ Bridge1 ] [ Bridge2 ]
[ ] [ ]
#==|===|===# #===|===|==#
| | | |
| | | |
------------+ +-------------------+ +------------------
segment A segment B segment C
If segment X fails: segments A, B, and C are connected.
If segment B fails: segments A, C, and X are connected.
If Bridge1 fails: segments B, C, and X are connected, A is isolated.
If Bridge2 fails: segments A, B, and X are connected, C is isolated.
Nodes on a segment that is connected to only one bridge will be
isolated from nodes on all other segments if that bridge fails.
|