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, |