| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 59.1 | | KONING::KONING | NI1D @FN42eq | Thu May 03 1990 12:19 | 16 |
| That's basically correct.
In this sort of configuration, when both connections are healthy, the
connection to the B port will become active, and the connection to the
A port will be inactive and "standby". Both concentrator A and
concentrator C know that the connection is in "standby" and therefore do
not insert the connection into the ring. In other words, no data flows
over that connection at all.
If the connection on the B port (the one between B and C) fails, then
the standby connection is changed to active, and is inserted into the ring.
Later, if the connection on the B port is repaired, the connection on
the A port goes back to standy (disconnecting it from the ring) while the
connection on the B port goes to active.
paul
|
| 59.2 | Where are the configuration rules? | CSOA1::SEITZ | LOST-IN-SPACE | Fri May 04 1990 13:18 | 6 |
| Would it be possible to get a copy of that paper or, is there another
document which contains the complete configuration rules and guideline
for DEC's FDDI products?
Thanks,
Mike
|
| 59.3 | DFON docu | SKYWAY::ZINNIKER | Dieter Zinniker @THR | Tue May 08 1990 11:35 | 8 |
| The paper I mentioned in .0 is called "FDDI Introduction" and doesn't give
you any configuration rules. If you want a hardcopy of it send me a mail.
But see note 26.1.
As far as I know in Europe these documents are not yet available.
Dieter
|
| 59.4 | Is this legal? | CSOA1::SEITZ | LOST-IN-SPACE | Fri May 18 1990 12:28 | 25 |
| Per the comments made in 59.0 and 59.1, would the following be a legal
configuration? I expect that the connections on port A on
concentrators 3 and 4 would be in back-up mode until a failure
occured making port B inoperative?
+---------+ +--------+ Dual Ring
------+ CON1 +----+ CON2 +--------
------+---++--+++----+---++---+-------
||M ||M ||M
|| || ||
|| |+-------+ ||
B|| +-------+|A||B
+----++--+ +++-++---+
| CON3 +----+ | CON4 |
+---++---+---+| +++------+
||M A |+--+|M
|| +----+
||
B||
+---++---+
| CON5 |
+--------+
Thanks,
Mike
|
| 59.5 | | KONING::KONING | NI1D @FN42eq | Fri May 18 1990 18:13 | 5 |
| Yes, that's legal. To keep your wiring hierarchy clean, it would be
better to run the backup link into Con3 from Con2 rather than Con4, but
either way is functionally valid.
paul
|
| 59.6 | "Automatic" failover? | ZPOV03::HWCHOY | FE110000 | Mon Jul 16 1990 15:36 | 25 |
|
re .1
�In this sort of configuration, when both connections are healthy, the
�connection to the B port will become active, and the connection to the
�A port will be inactive and "standby". Both concentrator A and
�concentrator C know that the connection is in "standby" and therefore do
�not insert the connection into the ring. In other words, no data flows
�over that connection at all.
how exactly does conc A and C "knows" that the connection is in
standby? Does it work only with DECconc 500 or is it a standard?
�If the connection on the B port (the one between B and C) fails, then
�the standby connection is changed to active, and is inserted into the ring.
�Later, if the connection on the B port is repaired, the connection on
�the A port goes back to standy (disconnecting it from the ring) while the
�connection on the B port goes to active.
I presume all these "switchings" are automatic (and reasonably quickly)
and any lost packets are to be recovered by higher-level protocols?
Thanx,
Heng-Wah
|
| 59.7 | | KONING::KONING | NI1D @FN42eq | Wed Jul 18 1990 09:25 | 5 |
| This switching is all automatic. Knowing whether to insert a connection
or to leave it in standby is part of the standard. It is NOT specific
to DEC products.
paul
|
| 59.8 | MANDATORY? | ZPOV01::HWCHOY | FE110000 | Wed Jul 18 1990 10:08 | 15 |
|
re.7
Hi Paul,
�This switching is all automatic. Knowing whether to insert a connection
�or to leave it in standby is part of the standard. It is NOT specific
�to DEC products.
the next logical question would be: Is this capability Mandatory in ALL
DAS implementations (SAS obviously wouldn't be able to), and that
multivendor concentrators will be able to mix and match in such configs?
thanx,
hw
|
| 59.9 | Redundant backup FDDI ring? | ZPOV01::HWCHOY | FE110000 | Thu Jul 26 1990 01:19 | 28 |
|
Hi,
Is this a legal configuration?
o---o o---o
/ \ Ring 1 / \ Ring 2
o o o o
\ / \ /
o---o o---o
\ /
\ /
+------------+ +------------+
\ /
\ /
Port A \ / Port B
o concentrator X
.... SAS devices
Is it possible to have the concentrator X switch from Ring 2 to Ring 1
when, say, Ring 2 is completely obliterated by an air-strike? The 2
Rings are presumably very far apart and that Conc X is attached by
SMF?
thanx,
Heng-Wah
|
| 59.10 | Not without more peices... | AUNTB::REED | John Reed @CBO - DTN:367-6463 - NWSS | Thu Jul 26 1990 10:31 | 6 |
| Heng-Wah,
It sounds like you are looking for a 100/100 single-mode F.D.D.I.
bridge, not a Wiring concentrator...
JR
|
| 59.11 | | KONING::KONING | NI1D @FN42eq | Thu Jul 26 1990 12:16 | 11 |
| Actually, what you showed can in theory be viewed as "dual homing". I'm
not sure that is appropriate. You've shown two "rings". That's not what
dual homing is for. Instead, it is used when you meant to build a single
ring, but want redundant connections to the higher levels of the wiring
hierarchy.
So my answer would be: "perhaps, depending on what you meant". But it seems
to me that you are confusing physical wiring hierarchy with logical
organization.
paul
|
| 59.12 | I hope this is much clearer! | ZPOV03::HWCHOY | FE110000 | Thu Jul 26 1990 15:29 | 24 |
| I am quite definitely NOT looking for a 100/100 SMF Bridge (though I'd
be able to use that too!).
I understand 'dual-homing' to be a mechanism whereby a SAS-WC can gain
access to a ring even if the DAS it is attached to fails, by attaching
to 2 DAS! And you say it is in the specs.
What I'm asking is, can I have a SAS-WC attached to 2 DAS (just as in
'dual-homing') but the DAS are on *different* rings. Reason being:
I have 2 physically separated rings, devices are attached to SAS-WC
which is in turn attached to ONE DAS on EACH ring (making sure that ALL
SAS-WCs' Port Bs are attached to one ring and Port As' attached to the
other). If one of the ring, along with its DASes are wiped out. The
SAS-WCs will switch to the other connection (say from Port B to A), so
the entire ring and the devices should continue (perhaps with some ring
inits) operation. IE a redundant, disaster tolerant FDDI. Assuming of
course, that the 2 rings and the SAS-WCs are sufficiently far apart.
And if I have a 100/100 SMF Bridge I'd bridge the 2 rings together so
I'd survive a partial switch (where some SAS-WCs switch over to ring 2
while others stay on ring 1)? Don't you all agree it's nifty? ;-)
hw
|
| 59.13 | | ZPOV03::HWCHOY | FE110000 | Thu Jul 26 1990 15:34 | 4 |
| BTW, who should I talk to regarding Single Mode solutions?
Thanx much,
hw
|
| 59.14 | See 95.* | XDELTA::HOFFMAN | Steve VOX::HOFFMAN, 223-7186 | Thu Jul 26 1990 20:13 | 3 |
| > <<< Note 59.13 by ZPOV03::HWCHOY "FE110000" >>>
>
> BTW, who should I talk to regarding Single Mode solutions?
|
| 59.15 | thanx! | ZPOV01::HWCHOY | FE110000 | Thu Jul 26 1990 23:44 | 1 |
|
|
| 59.16 | | KONING::KONING | NI1D @FN42eq | Fri Jul 27 1990 13:02 | 7 |
| When you talk about connecting in "dual homing" fashion to DIFFERENT
rings, the best answer is "don't do that". Some of the time it will do
something that may be what you wanted, but in general it will NOT have
the right properties. Instead, use two separate attachments. For example,
two FDDI adapters, one per ring.
paul
|
| 59.17 | too bad :( | ZPOV01::HWCHOY | FE110000 | Fri Jul 27 1990 22:07 | 10 |
| Thanx for the confirm. I was only hoping anyway, but it would've been
nice to be able to do so. In particular, SAS wouldn't be able to
fail-over to the second ring without some software/human intervention.
BTW, if I want to find out more about this "dual-homed switching"
mechanism (the customer's bound to ask), where is a good place? the
PMD perhaps?
rgds,
hw
|
| 59.18 | | KONING::KONING | NI1D @FN42eq | Mon Jul 30 1990 11:07 | 5 |
| You mean the ANSI PMD spec? No, that's definitely not the place.
Our marketing people undoubtedly have some suitable material. Ask them...
paul
|
| 59.19 | Dual Rings with CON | HBAHBA::HAAS | Big Smile at the Drivethrough | Tue Jan 22 1991 15:58 | 23 |
| Maybe a bit of this topic but is the following a supported configuration
and if so, what are the gotchas, if any.
The general idea is to have
dual ring-concentrator<->concentrator-dual ring
maybe like:
--------- ---------
--------| CON |---------------| CON |------- Dual Ring
--------| A1 |---------------| A2 |------- A
--------- ---------
| | | |
| | | |
| | | |
--------- ---------
--------| CON |---------------| CON |------- Dual Ring
--------| B1 |---------------| B2 |------- B
--------- ---------
Thanks,
Tom
|
| 59.20 | Disallowed by ANSI standard rules | KONING::KONING | NI1D @FN42eq | Tue Jan 22 1991 16:42 | 14 |
| No. No way.
If you follow the connection rules in the manuals ("A to B is ok, A to A isn't",
and all those like it) you will discover that there is no way you can connect
together what you've drawn. This becomes more obvious once you start putting
port type labels (A, B, M, etc.) on the endpoints of the various connections.
The reason what you've drawn isn't allowed is that you would not end up with
a single primary and single secondary ring, but rather with a whole bunch of
disjoint rings. As a result, what appears to be a single LAN would actually
be a number of disconnected LANs. This isn't what you had meant to do, I'm
sure!
paul
|