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 |
I have a customer who is experiencing an unusual problem with his DEChub 90's. At the end of a thinwire segment they have a DEChub90 housing a fibre repeater and a couple of DS90TL's. The repeater has three fibre connections each to a fibre bridge in one of three other DEChub90's. The diagram below shows one such fibre link. +-------+ | 3100 | +---+---+ +--------+-+ | +-+--------+ | | | | |H|Fibre +-------------+ Fibre |H| +-+-------+------------|U|Repeater| | Bridge |U| | |B| | | |B| Bridge | | | +--------+ | to |A+--------| |DS90TL |B| main | |DS90TL | +--------+ | network +-+--------+ |DS90TL | | +--------+-+ Each hub has two or more DECserver 90TL's in it and all users access a service offered by the 3100 on the local segment. All works well under normal conditions. However, if the bridge link to the main network (a Translan) fails, (either because the bridge ethernet port is unplugged, the NTU is unplugged or the bridge powered off) then some users accessing the 3100 are affected; HUB A users are not affected, but users on the other hubs are kicked off the system. Replacing the fibre bridges with fibre repeaters (90F's) cures this problem. Does the DEChub90 fibre bridge have any known problems that would explain this. Any help appreciated. Dave 62870
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
261.1 | Answer is a piece of cake. | CGOS01::DMARLOWE | dsk dsk dsk (tsk tsk tsk) | Fri Jun 11 1993 13:00 | 25 |
First, the users on Hub A are not affected as they are directly, (no bridge) connected to the same segment as the 3100. As per the "bridged" part of the network, the Vitalink bridge is the root bridge and every DEWGF in the 3 hubs knows it. If the Vitalink bridge goes away then the DEWGF's must select another root bridge and this is where your problem starts. It takes 10's of seconds (up to about 30) for spanning tree to select another root bridge. While this is happening no traffic flows. DECNET can withstand this outage as the timers are long enough. LAT is another story. LAT has a fixed 1 second retransmit timer. There is also a retransmit limit count usually set at 8. You could try uping this number until the sessions usually survive a spanning tree reconfig. By replacing the bridges with repeaters, there is no spanning tree reconfig if the Vitalink bridge goes away and thus no LAT sessions are lost. How often does the Vitalink bridge go away? If it unnecessarily high maybe something could be done to correct that problem and thus prevent excessive lost LAT sessions. By the way, all terminal servers work this way so third party servers will be no better. dave |