Conference npss::gigaswitch

992.0. "Decnis'es in parallel to Gigaswitch/FDDI ?" by COPCLU::EBC () Fri May 30 1997 09:58

Can somebody find a logicaL explanation to the behaviour explained below,
or should we be looking for a bug in either the Decnis or the Gigaswitch
software ?

This customer had two Decnis 600's connected in parallel between two FDDI
rings, and everything has apparently been working well since it was setup
over a year ago.

Now they've replaced the area 5 FDDI ring with two gigaswitches connected
by a 3-link hunt group (two more gigaswitches are waiting to take over for
the area 2 FDDI ring). No changes were made to the Decnis configurations.

In the new configuration, SLNIS2 will operate only on one of the FDDI
interfaces. If the area 2 interface is connected first, it seems to operate
normally on this one (OSI, Rip, etc. broadcasts look normal). When the
area 5 interface is then connected, a single OSI hello and a single set of
Rip updates are sent on this interface , and then it shuts up completely (well,
that was monitored on the other side of the Gigaswitches, but there nothing was
seen from it). If the area 2 interface is disconnected, it then after appr. 60
seconds starts operating normally on the area 5 interface.

I have wanted to try and disconnect SLNIS1 to see whether SLNIS2 would
then resume normal routing between the two interfaces, but have not so far
been allowed to do so.

I understand that since the Decnis'es are Decnet IV enabled, multiple
learning domains would be needed if the Gigaswitches would see traffic
with � Decnis data link address on multiple interfaces, but that is not
the case as far as I can see (one of the dual homing links are in "backup",
and I have tried connecting SLNIS2 with only a single link to area 5, and it
made no difference). 

regards,
Erik

OLD WORKING CONFIGURATION:
	---------------------------------------------------------
	!		   DECNET IV/OSI AREA 2			!
	!							!
	!	192.66.35.47			192.66.35.48	!
	!	---------     L1 RV, L2 LS	---------	!
	--------!SLNIS1	!-----------------------!SLNIS2	!--------
		! 2.4	!			! 2.2	!
	--------!	!-----------------------!	!--------
	!	!	!	L2 ONLY		!	!	!
	!	---------			---------	!
	!	172.30.2.83			172.30.2.84	!
	!							!
	!			OSI AREA 5			!
	---------------------------------------------------------
DECNET + IP ROUTING, RIP, LAT BRIDGING.
Decnis V3.1-6, Gigaswitch V3.1


NEW NOT WORKING CONFIGURATION:
	---------------------------------------------------------
	!		   DECNET IV/OSI AREA 2			!
	!							!
	!	192.66.35.47			192.66.35.48	!
	!	---------     L1 RV, L2 LS	---------	!
	--------!SLNIS1	!-----------------------!SLNIS2	!--------
		! 2.4	!			! 2.2	!
		!	!			!	!
		---------			---------	
		 !DUAL !			 !DUAL !
		 !HOME !			 !HOME !
		 !     !			 !     !
		---------	HUNT GROUP	---------
		!GIGASW.!-----------------------!GIGASW.!
		!	!-----------------------!	!
		!	!-----------------------!	!
		---------			---------
		 !  !  !			 !  !  !
		 !  !  !			 !  !  !
			OSI AREA 5 HOSTS, ROUTERS, SWITCHES
			SOME DUAL HOMED.

        I am not sure exactly what you are trying to accomplish, but it
    appears to me that you have created a spanning tree loop which is being
    resolved by putting the ports into the spanning tree blocking state.
    
        Since you say "LAT bridging", I assume that all of your ports are
    running IEEE802.1d spanning tree.
    
    MDL

You are right of course, Mike, STP is blocking the link, I can see that now.
The Nis'es in parallel are there for redundancy, and in order to maintain that
redundancy for the routed protocols I guess we could disable bridging on one of
the Nis'es. Do you see any better solution ?

Erik

        I am not certain what you are trying to do with that topology, and
    what the constraints are.
    
        What services do the DECnis systems provide?  I don't understand
    exactly what your diagram is telling me.
    
        If SLNIS1 and SLNIS2 are physically colocated with the two
    GIGAswitch/FDDI systems, I'd start by dual homing the two DECnis
    systems to different GIGAswitch/FDDI systems, instead of dual homing
    each to the same GIGAswitch/FDDI system.
    
        Allowing bridging to work on all the interfaces is going to result
    in spanning tree blocking all but one connection as you have found out.
    As far as I can see, your options are:
    
    1) Live with spanning tree failover time (as you have now)
    2) Disable the redundant bridging connections
    3) If the Area 2 network is FDDI, connect it directly to the
    GIGAswitch/FDDI system - I assume it isn't, otherwise there's no point
    to the DECnis systems
    4) Separate out the routing/bridging, either with additional
    interfaces, or additional devices.
    
    MDL