| Title: | DEChub/HUBwatch/PROBEwatch CONFERENCE |
| Notice: | Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7 |
| Moderator: | NETCAD::COLELLA DT |
| Created: | Wed Nov 13 1991 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4455 |
| Total number of notes: | 16761 |
Hi,
How can we explain this.
1. Customer configuration
BACKBONE
[]------+-------------------+---------------+--------[]
| | |
STE's +------+| |
STE's |DEMPR2|| +---+--+
| +------+| |DEMPR3|
+-+----+ | | +-+-+--+
|DEMPR1| | | | |
+----+-+ | | | STE's
| | | |
STE STE STE | | | |
| | | | | |Backup |
+-2---3---4---5---6---7-+ |
+--| DECbridge900MX 1 |--+ |
| A| |B | |Loop
| +-----------------------+ | |
| |FDDI |
| | |
| B+-----------------------+A | |
+--| DECbridge900MX 2 |--+ |
| Root | |
+-2---3---4---5---6---7-+ |
| | | | |
VAX VAX VAX +-------------+
STEs = Cluster's Satelite
2. The questions
By mistake the customer made a loop between the 2 bridges through
a DEMPR.
Until there no problem, line 7 of bridge 1 is in backup.
All the Cluster statelites on the Bridges and on the DEMPR's (Cluster)
are running fine.
Now they' removed the connector of bridge 1 port 7. From this moment
ALL the stations of the clusters lost their connections (Cluster state
transition) (SYSGEN; RECNXINTERVAL = 20 sec)
I can undertsand that VAXes on the Backbone and on DEMPR3 can't access
the server during the the pre-forwarding and listening phase of the
bridge port (longer than 20 secs), but WHY ALL OTHERS VAXES connected
on the bridge 1 also were loosing the connection.
The only way possible for me is that a Topology change on ONE port of
a Bridge causes a complete spanning tree configuration.
Is this possible or normal?
What I need to understand is how to see (calculate) the spanning tree
algorithm with a Multi-port Bridge, i.e, should I see such a bridge;
as separate 7 bridges connected to a virtual segment or 7 separate
bridges connected together (some white paper or doc available?).
Thanks in advance,
Robert
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1744.1 | NETCAD::SLAWRENCE | Thu Dec 01 1994 13:46 | 16 | ||
The algorithm doesn't change with the number of ports.
If the link that you disconnected was Blocking (was the backup link),
then you shouldn't have seen any break in connectivity. If, however,
you have the root wrong then what was disconnected was the designated
port for that LAN, and you would experience the delay waiting for the
backup port to take over.
As for why the cluster members all saw a problem, you should check
with Cluster gurus; is it not true that all nodes maintain the state of
connections to all other nodes in the cluster?
You can see the spanning tree configuration with HUBwatch, or any SNMP
manager using RFC1493 - the Bridge MIB.
| |||||
| 1744.2 | I was not dreaming | KETJE::VANDENBERG_R | Fri Dec 02 1994 03:26 | 6 | |
Scott, OK, I 'checked with Cluster guru and I may be possible that other nodes of the cluster are reseting if there is a group inconsistancy. Thanks, | |||||