[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::fddi

Title:FDDI - The Next Generation
Moderator:NETCAD::STEFANI
Created:Thu Apr 27 1989
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2259
Total number of notes:8590

1039.0. "Dual-Homing question" by LARVAE::HARVEY (Baldly going into the unknown...) Tue Jul 27 1993 12:19

   Can someone help confirm or deny whether the following will work or not ?
 
   Essentially, we're attempting to provide a fault-tolerant connection for an 
   ethernet connected VAX into 2 FDDI networks via a dual-homed bridge.
 
   So, using a DAS bridge 520 variant, the A port goes to an M port of a CON500 
   on one FDDI LAN while the B port goes to the M port of another CON500 on a 
   separate FDDI LAN. So both A and B ports connect as SAS links.
 
   My understanding is that the B port of the DAS bridge (connected as a SAS) 
   will take precedence over the A port and thus this line will become the 
   "live" link while the A port goes into "standby" mode. Is this true ?
 
   Does it matter that the CONs are on separate networks ? I don't think it 
   does (will stand corrected) and can't think of anything obvious as to why it 
   won't work. Looking through the FDDI Primer and System Level Description 
   docs, I can only find * an example * of dual-homing which shows a cascaded 
   CON using dual-homing to (DAC) CONs on the same ring.....
 
   Providing this is "legal" and (hopefully) supported, we'd like to document 
   the fact. Is there any text we can use to include into documentation which 
   describes what we're doing ?
 
   What is it that causes the Bridge to "failover" - just a loss of signal to 
   the B (?) port ?
 
 
   For anyone interested further the scenario is an FDDI VAX cluster.
 
   � 2 x VAXes each with 2 x DEMFAs
 
   � each VAX system located in separate computer room
 
   � 2 x CON500s provide 2 separate FDDI "LANs" between the VAXes. 
     ie. 2 x 100 Mbps bandwidth to aid file copying/shadowing performance etc.
 
   � 1 x DAS bridge 520 dual-homed between the 2 CON500s to provide the Quorum 
     VAX "voting member". Provides continued availability in the event of a 
     cluster "lobe" failure or partial FDDI network outage.
 
   A picture ....
 
 
 
   -------					 	   	        -------
 � !     !DEMFA-----------------------------------CON500-----------DEMFA!     !
   ! VAX !					    *	          	! VAX !
   !     !DEMFA------------------CON500----------------------------DEMFA!     !
   -------                         +		    *	   		-------
                                   +		    *
                                   +		    *
                                   +		    *
                                  ---------------------
                                  !   DAS BRIDGE 520  !
                                  --------------------- 
                               Port 'A'    E       Port 'B'
                               Standby     E       Live
                                           E
                                           E
                                     QUORUM VAX
 
 
   Hope that's clear(ish)............
 
   Rog
T.RTitleUserPersonal
Name		DateLines
1039.1KONING::KONINGPaul Koning, A-13683Tue Jul 27 1993 15:0214
That configuration is legal according to the topology rules.

On the other hand, I'd say that you should use it with caution.  The "usual"
configurations all have the property that a failover still leaves you as part
of the same LAN as before.  In the setup you've shown, a failover will move
you to another LAN.  Depending on what other protocols you run, what other
LANs your friends are connected to, and how (if at all) those LANs are 
interconnected, the results might not be what you want.

However, so long as you understand this, analyzed the consequences, and
convinced yourself that such failovers will still leave you with a topology
that has the right nodes reachable, go ahead.

	paul
1039.2From the man himself..LARVAE::HARVEYBaldly going into the unknown...Tue Jul 27 1993 15:5934
 
   Thanks Paul, that's what I needed to hear.   ;^)
 
   In this context the FDDI "LANs" are purely to be used for cluster traffic 
   between the two cluster lobes - hence only SCS (or is it SCA ?) protocol 
   will be in use. This protocol can be run over multiple adapters with no (?) 
   problem.
 
   From what I know, I believe DECnet will be in use on the "user" side of the 
   network and thus be well away from these FDDI adapters.
 
   I believe that cluster software is clever enough to "load balance/share" 
   over multiple adapters as well, so this should make good use of the 
   additional bandwidth.
 
   The only questions I have is in terms of failure scenarios.....
 
   - If the live link of the bridge fails, then it swops over to the other PHY 
     and connects to the second CON channel. 
        How long does this take ? 
        Will it have any effect(s) on the bridge's node tables ?
        If only SCS/SCA protocol is in use what will the bridges learn about ?
 
   I need a basic handle of the above and how it may interact with a failure in 
   a node, where we're going to see a cluster state transition too.
 
   At the end of the day the customer is getting a relatively high-performance, 
   segregated cluster on the cheap and I think it is our job to carify that 
   this system only goes so far in the resilience stakes. If he wants more, 
   he's going to have to dig deeper into his pockets...
 
   Thanks again for your input.
 
   Rog
1039.3the MTBF of your single point-of-failureASDS::LEVYWed Jul 28 1993 12:425
    Don't know if this is an option, but...
    
    Have you considered a DC500 instead of the DB520? The DC500's MTBF is
    roughly twice as good as the DB5xx/6xx. They're both in the multi-year
    range, but the DC500 is a more reliable device.
1039.4KONING::KONINGPaul Koning, A-13683Wed Jul 28 1993 13:306
I know SCA can handle multiple adapters and multiple LANs.  But that's not the
same as saying that it deals readily with stations moving from one LAN to
another, which is what happens here.  You should confirm with a cluster
protocol expert that this is in fact ok; I have no idea.

	paul
1039.5A parallel activity...LARVAE::HARVEYBaldly going into the unknown...Thu Jul 29 1993 10:0510
   -1.  Paul - I hope this is being looked at by the clusters man on the job, 
   but I'd best check it out anyway.
 
   -2.  John - Granted the CON is the more reliable, still need a bridge in 
   there though. So the customer sees it as additional expense (I did say he is 
   doing this on the cheap !)
 
   thanx
 
   Rog
1039.6VMScluster software should handle thisSTAR::PARRISThe SLED is dead, long live RAIDFri Aug 06 1993 09:5018
As long as the adapters all use unique LAN addresses, the VMScluster software
should have no problem handling the failover.  PEDRIVER sends out multicasts
from each adapter about every 3 seconds -- the receipt of these multicasts is
what causes channels to be formed and what keeps them alive in the absence of
other cluster traffic.

In the case of a failover of the bridge to the other LAN in your configuration,
it appears that PEDRIVER will just start seeing the multicasts from the quorum
VAX now being received on a different adapter than before, set up a channel for
that, and eventually time out the old channel that it had set up for traffic
through the old adapter.  The virtual circuit should see no interruption as
long as the failover takes less than 8-9 seconds; failing that, the cluster
should survive as long as the failover takes less than RECXNINTERVAL plus 8-9
seconds. 

If you try to take advantage of the fact that you have separate LANs and run
DECnet Phase IV (or LAT with /DECnet specified) on both adapters, so they have
the same LAN address, then all bets are off.