| 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,
We are currently working on a project in Australia on behalf of
Brisbane Airport and the Civil Aviation Authority.
The solution calls for a low-budget, redundant dechub 90 configuration.
As the system will be running Air Traffic control for both
International and Domestic flights, obviously availability and fault
tolerance are key considerations.
Our intial specification consisted of the following :
_____
| | - Decstation 5000/133
| | radar display
----- terminal
|
---
|***| - Cabletron TPT-D4
--- fault tolerant
| | UTP MAU.
| |
| | - Dual homed Shielded UTP
| |
| -------------------------------
| |
_|___________ _______|_______
| Dechub 90 | | Dechub 90 |
| 90T |=============| 90T |
| 90FL bridge | thinwire | 90FL bridge |
------------- ---------------
# #
# #
# <- 2 core multimode fibre -> #
# #
# #
___#_________ _______#_______
| Dechub 90 | | Dechub 90 |
| 90T |=============| 90T |
| 90FL bridge | thinwire | 90FL bridge |
------------- ---------------
| |
| |
--------------- --------------
| |
---
|***| - Cabletron TPT-D4
--- fault tolerant
| UTP MAU.
|
_____
| | - NIU radar tracking
| | interface unit
-----
Purpose :
The idea of the config is to provide dual homed and dual pathed
connections between each station on the network. Redundancy is assured
by duplicating hub chassis, modules and cable paths.
Problem :
Unfortunately, in the advent of a hub failure, fibre link failure or
bridge module failure, the spanning tree algorithm is taking >45 secs
to activate the secondary stand-by link. During this timeframe, the
Decstations are unable to access the NIUs for radar tracking info. The
customer has requested a switching delay of less than 10 secs.
Possible solutions (comments? suggestions?)
A. Receive a tailored version of firmware if possible for the
Decbridge 90FLs. Modified listen and learn timers for the spanning
tree?
B. Replace the 90FLs with Decrepeater 90FS in each hub as per the
following :
_|___________ _______|_______
| Dechub 90 | | Dechub 90 |
| 90T | | 90T |
| 90FS rptr | | 90FS rptr |
------------- ---------------
# # # #
# # # #
# # # # -- 2 core multimode fibre runs
# ## #
# # # #
___#_________ # # _______#_______
| Dechub 90 | | Dechub 90 |
| 90T |=============| 90T |
| 90FS rptr | thinwire | 90FS rptr |
------------- ---------------
Questions with this config are :
1. Will the 90FS repeaters switch correctly to prevent network loops?
2. Repeater counts will be excessive. However, they may work under
IEEE model 2... fibre length = 80m (max), UTP length = 40m (max)
--------------------------------------------------------------------
We need an answer on this **URGENTLY** as the system is scheduled to go
live in a couple of days.
If there are any other ideas or remedies, please let me know. However,
bear in mind the need for MODULE and CHASSIS redundancy. The
specification states that no more than TWO network stations may fail at
any given time.
REGARDS,
JASON CALEY
Components and Peripherals Group.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1423.1 | LEVERS::DRAGON | Wed Sep 14 1994 09:51 | 11 | ||
Jason,
The Thinwire between DEChub 90s doesn't look right too me. Perhaps
I'm missing something.
Also, the links from the 90FSs which cross over to the opposite
DEChub 90 doesn't look right. Are these setup as redundant pairs?
If so, shouldn't they run in parallel to the same DEChub 90?
Bob
| |||||
| 1423.2 | LEVERS::SLAWRENCE | Thu Sep 15 1994 13:45 | 14 | ||
DO NOT USE DECBRIDGE 90 FOR THIS.
This usage is not a supported configuration for them (see the owners
manual). Even if it were, a bridge cannot provide nearly the switching
times you require without setting the bridge timers so low that you
will cause other problems.
The fiber repeater solution may work - I will ask one of the repeater
folks to take a look at it.
I cannot overemphasize the first line above - if you do this, don't
take a plane anywhere in that system.
| |||||
| 1423.3 | Updated scenario | SNOC02::CALEYJASON | An ex-customer of the worst kind... | Thu Sep 15 1994 19:31 | 56 |
Ok Guys thanks for your help and understood.
Here is another idea.
________
| | Decstation
| |
--------
|
___
| | Cabletron xceiver
---
| |
| | Dual homed Shielded UTP
| |
| --------------------------------
__|_________ ______|______
| Dechub 90 | | Dechub 90 |
| 90T | | 90T | Spanning Tree disabled
| 90FS | | DEWGF x 2 | on bridges. Used as
------------ ------------- non-responder ports
# # # #
# # # #
# P S # # S P #
# # #
# # # #
# # # #
__#_________ ________#____
| Dechub 90 | | Dechub 90 |
| 90T |================ | 90T |
| 90FS | thinwire | 90FS |
------------ -------------
Rationale :
If each 90FS can be configured to have a primary and backup fibre link,
then it is possible that the config can use the paths as specified.
bridges are used in the top right hub to prevent the repeater counts
blowing out. The thinwire between the two bottom hubs is used to form a
logical 16 slot hub and avoid interepeater links.
Ideally, the 90FS units will provide the switching capability and
prevent networking loops, whilst the bridges serve as non-responder
ports purely for segmentation purposes.
Please advise.
By the way, I know the configuration is obscure to say the least and we
have tried to get the customer onto FDDI or a token based or switched
network but they have chosen Ethernet, hence all the problems.
Many thanks for your replies, once again.
| |||||
| 1423.4 | I don't think this will "fly" either. | MSDOA::REED | John Reed @CBO, DTN:367-6463, KB4FFE, SouthEast | Fri Sep 16 1994 10:04 | 47 |
I would quickly convince this customer to purchase FDDI connections for
this scenario. The redundancy and failover speeds of FDDI are
incredible.
I have several DEChub900's with FDDI connections between them, and I
love to show the customer how fail-over works. I just have him pull
out any ANSI MIC connector while his users are logged in, and we watch
the LED's on the FDDI modules just patch around it. It happens in
shorter than a second, and the end users and Hosts CPU's never lose a
beat.
This is the type of scenario that FDDI's inherent fault tolerance was
designed for. You are trying to build a fault-tolerant network using
Ethernet techology that has redundancy "bolted on as an after-thought",
and is not part of the architecture.
The Spanning Tree (which you are trying to disable) is a wonderful
thing for Ethernet, but as you discovered, it REQUIRES at least 45
seconds to determine that a link has dropped and patch around it. I
don't beleive that you will like the results if you disable the
spanning tree on two bridges in the same hub, connected to each other
using repeaters. I understand that the secondary paths of these
repeaters are both connected to the bridges, and therefore should never
see any traffic, but the bridges themselves will be shutting down the
port that they can't use. Your Bridges will go into LEARNING mode when
the repeater enables itself, and LEARNING mode will take about 15 seconds,
and PREFORWARDING will take another ten seconds, so you will not have
the system operating as you wish in this configuration.
If this is an air traffic controller, than it is a MISSION CRITICAL
application, and should be designed using a mission critical redundancy
architecture like FDDI. It's not cheap. You can't do what you want
using Ethernet repeaters and bridges. I would not fly out of this
airport either, if the planners were looking for "cheap" networks....
Just my opinion. I hope you find something that works for you and
your customer. I would use DECbridge900MX's and FDDI Concentrators.
You have the fiber already. I would install Digital FDDI controllers
in the DECstations, (much faster throughput) and you are now state of
the art. (this gets rid of the cabletron xceiver too). All you need
now is money...
Good Luck
JR
| |||||
| 1423.5 | Flying High | SNOC02::CALEYJASON | An ex-customer of the worst kind... | Sun Sep 18 1994 23:51 | 25 |
Thanks John.
I know all of that. And yes, we've tried getting the customer to go
FDDI with the 900 series stuff and even with the older gear. No
success. See the problem is that the customer is building down to a
price and not up to a solution.
The initial specification (provided by the customer) called for a
thickwire backbone with point to point AUI cabling to each device. Hows
that for a mission critical network?!
Anyway, if you ever come over to Australia..fly into Melbourne Airport
instead.
In the meantime, I will probably be forced to move the NIU unit
connections directly to the first floor. This will consolidate the OPS
display terminals and NIUs onto a common dual hub backplane. The ground
floor connections will be used for non-critical technical display
terminals but not the flight control process itself.
Thanking you,
Jason.
| |||||