T.R | Title | User | Personal Name | Date | Lines |
---|
1423.1 | | LEVERS::DRAGON | | Wed Sep 14 1994 10: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 14: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 20: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 11: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... | Mon Sep 19 1994 00: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.
|