[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

1398.0. "dual home to different rings?" by COMICS::REYNOLDS (Mad Dogs and Englishmen) Wed Jul 13 1994 06:43

    
    Can someone confirm whether this is feasable:
    
    a customer wants to have a resiliant FDDI config with two
    separate rings -  the plan is to attach DAS devices such as 
    DECbridge620 with A port to one ring and B port to another.
    This would in effect be a dual home configuration with the B
    port 'live', but into different rings.
    
    I believe this should work since dual homing works only at
    PHY level and performs only LCT on the backup link, so 
    if the live link failed, we would get a new upsteam neighbour
    and probably go through claim.
    
    John.
T.RTitleUserPersonal
Name
DateLines
1398.1I wouldn't recommend it...koning.lkg.dec.com::koningPaul Koning, B-16504Wed Jul 13 1994 14:1922
Such a configuration is technically invalid.  The rules require that the
two ports are connected to the SAME LAN.

However, in spite of that it MAY work.  Or it may not.  That depends on
the higher layer protocols used.

In effect what happens on a failover is that you move to a different LAN.
Consider IP, for example.  If that different LAN is a different subnet, you
have moved your interface to the wrong subnet.  That doesn't work.  If it's
the same subnet, it means you have two LANs in the same subnet -- unless they
are bridged that's a partitioned subnet, which also doens't work.

Other protocols may not care as much; for example DECnet would not, although
even there you would probably see an interruption while the routers and
adjacent endnodes adjust their knowledge of you.

Conversely, if you build it as intended -- same ring for both ports -- then
the failover is completely transparent to all higher layer protocols, and
the interruption experienced is just that of the failover itself (and should
be much less than 1 second).

	paul