| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2932.1 | 6 Segments | SCAS02::TERPENING | | Tue Oct 31 1995 18:53 | 4 |
| To the best of my knowledge you can only have 6 ethernet segments in
the DH 900. The hub can do more but todays modules cannot. I got caught
on this once and found it documented in the Hubwatch manual AFTER it
was shipped to the customer.
|
| 2932.2 | | STRWRS::KOCH_P | It never hurts to ask... | Tue Oct 31 1995 19:16 | 9 |
|
That is not the question. In order for us to go beyond the 6 Ethernet
limit, I want to connect directly to the AUI port via a DEFLM. So, by
pushing the TP ports to the backplane and using the AUIs directly on
the DS900EF, you can essentially get more usable Ethernets in the hub.
The question is whether a 90FS enabled as a master treats a connection
as two separate DS900EF AUI ports (with DEFLMs) the same way as if they
were connected to 900FP ports on two seperate DEChubs.
|
| 2932.3 | some thoughts | VAXRIO::ROLF | Vaporware Design Specialist | Wed Nov 01 1995 08:47 | 13 |
| Don't forget that whenever you use a front-panel connection on the
DS900EF (AUI or UTP), THAT port CANNOT at the same time be connected to
a backplane channel. Of course, you can "create" more than 6 Ethernets,
(8 in your example), but only 6 are available to the backplane. The two
AUI/DEFLM ports can talk to another 4 backplane-Ethernets, but only thru
the bridge. The remaining 2 backplane channels can be Ethernets but
CANNOT be connected to the same DS900EF.
So, INSIDE the hub you can have 7 Ethernets (6 flex-channels + the
Thinwire channel), but COMING OUT OF the hub you can have many more,
specially if you add more DS900EFs.
|
| 2932.4 | | STRWRS::KOCH_P | It never hurts to ask... | Wed Nov 01 1995 08:54 | 6 |
|
Yes, I'm aware of all the limitations.
I'm still looking for an answer to the base note .0
Can anyone answer the base note?
|
| 2932.5 | should work OK | VAXRIO::ROLF | Vaporware Design Specialist | Wed Nov 01 1995 13:36 | 22 |
| If I understand your scenario correctly, you want to connect two
DEChub900s to one 90FS, and instead of using a 900FP port in each hub, use
an AUI port of a DECswitch900EF, converted to fiber with a DEFLM.
If you use the 900FP to 90FS connection, you will have FULL fault
detection, because both the 900FP and the 90FS have the ability
to detect and signal back to the other end if they detect a broken
receive fiber. That is because both the 900FP and 90FS are "responder
ports".
All other 10baseFL devices are "non-responder ports", so that if you
connect a DEFLM to the 90FS, fault detection will only work in one
direction.
Other than that it should work.
Check the DECrepeater90FS Installation and Configuration manual
(EK-DEFMI-IN.A01) It contains a pretty good description of this
mechanism.
Rolf
Rolf
|
| 2932.6 | What's the difference? | PTOJJD::DANZAK | Pittsburgher � | Thu Nov 02 1995 08:05 | 15 |
| Er, what is the 'fault detection in one direction..." That doesn't
quite make sense to me.
If you have fiber into the AUIs of the 900EF back to a 90FS the FS acts
to master the failover between ports. If the FS fails - things die -
if the EF fails - things die - if one fiber fails however you failover
to the other port.
This would not change with a 90FS to 900FP would it? HOw would going to
a 900FP help? The same scenario would apply....if either module failed
it would die, but if a fiber failed it would failover.
So, what's the difference?
j
|
| 2932.7 | one-way connectivity | NETCAD::PAGLIARO | Rich Pagliaro, Networks BU, HPN | Fri Nov 03 1995 09:18 | 21 |
|
Re: .6
The 'fault detection in one direction" problem refers to one-way
connectivity faults. The 90FS (acting as redundant master) can only
detect link failures on its receive link. If its FO transmitter fails
or its tranmit fiber link gets cut when its receive fiber link is still
intact, the master FS would never know about it. It's the job of the
redundant responder, which would detect this fault on ITS receive link,
to signal this condition to the master.
A redundant master connected to a redundant responder can recover from
one-way connectivity faults. A redundant master connected to anything
else will not recover from one-way connectivity faults.
See notes 2085.* (especially 2085.8 and 2085.9) for a discussion about
connecting redundant repeater ports to switch ports.
-Rich
|
| 2932.8 | Glad I asked that..thanks | PTOJJD::DANZAK | Pittsburgher � | Mon Nov 06 1995 09:37 | 7 |
| Drat - then you still have to depend on one device as a single point of
failure.
Glad that I asked this because that is NOT what I've been telling
customers for the past year or so. AARUGH,
j
|
| 2932.9 | For future reference | NETCAD::PAGLIARO | Rich Pagliaro, Networks BU, HPN | Mon Nov 06 1995 10:43 | 15 |
| Jon,
I'm not clear on what you mean by depending on one device as a single
point of failure.
For future reference, section 3.5 of the DEChub Repeater Family
Functional Specification provides a fairly complete description of
repeater dual port redundancy, including full and partial fault
detection as well as complex and simple redundant links (sections 3.5.3
and 3.5.2, respectively).
Regards,
Rich
|
| 2932.10 | A pointer might prove useful :-) | NETCAD::BATTERSBY | | Mon Nov 06 1995 11:02 | 4 |
| Rich, can you provide a pointer to where this doc is for folks
like Jon to get it & read?
Bob
|
| 2932.11 | Better yet read Appendix A of PORTswitch 900FP I&C | NETCAD::BATTERSBY | | Mon Nov 06 1995 11:08 | 5 |
| Actually, the appendix A of the Portswitch 900FP Installation
and Configuration guide has a good description and discussion
of the Redundant-Link Configuration & fault detection.
Bob
|
| 2932.12 | Note 3.0 already provides a pointer. | NETCAD::PAGLIARO | Rich Pagliaro, Networks BU, HPN | Mon Nov 06 1995 12:48 | 15 |
| Bob,
Note 3.0 provides a pointer to find hub documentation. The particular
document I mentioned can be found at the following location.
nac::nipg:[hub.manuals]repspc11.doc
This document is in MS-Word format. In addition to providing a
detailed description of dual port redundancy it also provides a good
technical description of most repeater functionality for the entire
family of DEChub-based repeaters. This document is slightly out of date
as it was completed while the PORTswitch 900TP/900CP were still under
developement.
-Rich
|
| 2932.13 | REPSPEC...? what is it in README.TXT..? | PTOJJD::DANZAK | Pittsburgher � | Mon Nov 06 1995 13:49 | 36 |
| Folks....
Regarding the document:
Considering that the 0README.TXT file never references the REPSPC11
document - how would I ever KNOW that it was there, useful or did
anything for me without looking at the thing?
Question: How/What/Where are the specs for EVERYTHING and when will
they be CONSISTENTLY on-line and when will we publish it to da world?
Regarding "total reliability":
When I think of total reliability I think of physical destruction of a
component compromising the LAN integrity. Environments that require
this type of thinking are:
- Military - i.e. we just lost 1/2 of the building but need to keep
going...
- Banking - somebody lost the first floor com room of World Trade
center and we need to keep trading...
- Factor floor - a crane knocked out the datacomm room and the
caster is in the middle of pouring steel, the control computer
needs to talk with it NOW or we'll destroy a few miles of plant
You get the picture. Redundant means that if the device itself fails
the network will continue via another device. A good example of this
would be a DAS ringed DEChub 900 to another DEChub 900 with dual-homed
redundant servers etc. (The stuff that CompUserve does)
u c? Some folks really DO worry about the product getting destroyed by
other than me stepping on it...
Regards,
j
|
| 2932.14 | Re: Total reliability | NETCAD::PAGLIARO | Rich Pagliaro, Networks BU, HPN | Mon Nov 06 1995 17:12 | 119 |
| Jon,
RE: "total reliability"
After we spoke off-line I re-read this string. The confusion I had
with your posting in .8 (which I expressed in .9) was with how the
clarification of full/partion fault detection affected the notion of
total reliability. Full fault detection allows detection and recovery
from cable plant failures. The shortcomings you expressed in .13 were
more a function of module failures not cable plant failures.
I believe some of the catastrophic physical destruction faults you
described would likely cause multiple system faults where much
equipment is co-located. Neither Digital's nor our competitor's
products would recover from such faults if they are designed to protect
against only a single failure. Competitors such as Chipcom still
require some amount of equipment co-location. I'll elaborate later.
It is absolutely true that the dual port redundancy feature of
DEChub-based repeaters do not provide "total reliability" against
physical destruction to the lowest granularity of protection. They're
not designed to do so. However, useful redundancy in Ethernet links
can be provided at various granularity levels, depending upon the needs
of the user (especially quick-failover).
Unlike FDDI, Ethernet's CSMA/CD protocol obviously does not provide any
inherent, low-level, standards-based mechanisms for fault-tolerant
connections (spanning tree doesn't count). This is a selling point for
FDDI. It is more robust (but also, in some ways, more complex and
costly) than Ethernet. In designing the redundancy algorithm for the
DEChub-based repeater family of products, the task at hand was to
devise a proprietary mechanism to provide fault tolerance at various
granularity levels on top of an inherently non-fault-tolerant protocol.
The solution had to be able to be implemented in a timely manner and
not unduly burden the cost of a very price sensitive product. The
following description of the various redundancy granularities offered
is mainly copied from the DEChub Repeater Family Functional Spec.
As you know, the configuration constraints of dual-port redundancy is
that redundant master ports must reside in the same module. Responder
ports can be on different modules in different hubs. They just have to
be connected to the same LAN.
The simple redundant link pictured below provides fault tolerance for
only the cable plant. Here the redundant responder ports live on the
same module. Obviously, if either the master or responder fail,
communications between stations connected to either module will be
eliminated.
MASTER RESPONDER
+-----+ +-----+ Simple Redundant Link
| | Primary | | ---------------------
| Tx []-----\ /-------[] Tx | - Protects against faults in the cable
| 1| X | | plant only. No recovery from faults
| Rx []-----/ \-------[] Rx | in either module.
| | | |
| | | | - Responder allows fault detection &
| Tx []-----\ /-------[] Tx | recovery in the Master's transmit
| 2| X | | and receive links.
| Rx []-----/ \-------[] Rx |
| | Secondary | | - Replacing responder with a non-
+-----+ +-----+ responder allows fault detection &
recovery in only the Master's receive
links.
The complex redundant link pictured below provides fault tolerance for
failures in the cable plant as well as failures in either one of the
responders. Consider the example of the two responder modules
configured as the hub of a star-wired fiber Ethernet backbone. The
connection of the master module to the two responder modules in the
figure below represents just one spoke which may be replicated several
times. Let the cable plant plus the two responders constitute the
entire backbone. This configuration provides backbone fault-tolerance.
If a fault occurs in the cable plant or one of the responders, all
stations connected to all masters can still communicate. If one master
fails then all stations connected to that single master will not be
able to communicate, but stations connected to all other masters will
not be affected. Yes, this is a single point of failure for those
stations connected to the failed master module, but the failure is
localized and does not take down the entire network.
MASTER RESPONDER
+-----+ +-----+ Complex Redundant Link
| | Primary | | ----------------------
| Tx []-----\ /-------[] Tx | - Protects against faults in the cable
| 1| X | []-+ plant and the responder modules. No
| Rx []-----/ \-------[] Rx | | recovery from faults in master module.
| | | | |
| | +-----+ | - Responder allows fault detection &
| | +-----+ | recovery in the Master's transmit
| | | | | and receive links.
| Tx []-----\ /-------[] Tx | |
| 2| X | []-+ - Replacing responder with a non-
| Rx []-----/ \-------[] Rx | responder allows fault detection &
| | Secondary | | recovery in only the Master's receive
+-----+ +-----+ links.
RESPONDER
The next level of granularity would be if the two repeater ports
comprising the master end of a redundant link could reside in separate
modules. Here we would also be able to recover from failures in one of
the master modules. Unfortunately, DEChub repeater redundancy
implementations do not support this. Some of our competitors, such as
Chipcom, do. In Chipcom's case, while the master ports can be on
different modules I believe they still have to be in the same hub. This
could still be a problem in the case of one of your catastrophic
physical destruction faults.
Digital also does not build a redundant MAU which works with our
redundancy algorithm. This would provide an even finer level of
fault-tolerance granularity, allowing a fault tolerant connection to a
single end node. Some competitors also offer this.
The moral of the story is that no, our repeater fault-tolerance is not
perfect and it might not be appropriate for all applications. But is
does recover from a great range of faults reliably and QUICKLY (~10ms).
|
| 2932.15 | http://npbwww.hpn.lkg.dec.com | NETCAD::PAGLIARO | Rich Pagliaro, Networks BU, HPN | Tue Nov 07 1995 10:14 | 18 |
| Re .13
Regarding documentation:
The Network Product Businenss World Wide Web home page
(http://npbwww.hpn.lkg.dec.com) provides access to much technical data,
including firmware, drivers, manuals, tech tips, MIBs, etc.. Once in
the home page, select "Products & Technology" and then "Technical
Data".
The repspec11.doc document mentioned in previous notes is not available
on the Web page because it is intended to be an internal use only
document and the Web page is publically accessible.
Please direct any comment/suggestions about how this information is
distributed to the field to the appropriate training personell.
|