Conference 7.286::fddi

FDX switching should take maybe a second or two to make its decision,
and should interrupt service for no more than a few milliseconds.

The TTRT display on the Gigaswitch side is somewhat strange, but you
should ignore it: TTRT has no meaning and no effect when in full
duplex mode.

	paul

    
    Thanks Paul for the quick reply. That explains at least the TTRT-value.
    But still I have no explanation for the 20 seconds delay my customer is
    seeing, which is his primary problem.
    
    Does anybody have some ideas to the still unanswered questions in the 
    base-note?
    
    Bart

    re: .2
    
    [Just a guess] If the port is just coming up to the GIGAswitch, there
    may be a little delay for the link to come available and for the packet
    forwarding to take place.
    
       /l

    
    Re .3
    
    I am not sure I understand what you mean. I think what you are saying
    is " Why dont you put everything directly to the gigaswitch?" Answer
    is simple: The customer wants it this way! He wants FDX-nodes on his
    gigaswitch directly, he wants his ring connected to the Gigaswitch
    and he wants those 2 things interoperating without 20 sec. delay.
    
    Thanks for the reply!
    
    Bart.

    
    	How often is this reproducable? Is this always or when you first 
      come up? Are there any specific applications or just generic LAT
      and DECnet?
    
    							Rene'
    

    Re .4
    
    >>I am not sure I understand what you mean. I think what you are saying
    >>is " Why dont you put everything directly to the gigaswitch?" Answer
    
    No, I'm not saying that at all.  What I AM saying is that there is an
    inherent delay to bring the link up whenever you connect two FDDI
    devices together for the first time.  On top of that, there may also be
    a delay in packet forwarding while the GIGAswitch learns that(those)
    address(es) on its port.  How long that delay is I don't know.  You
    should check with someone in GIGAswitch engineering to be sure.
    
    >>is simple: The customer wants it this way! He wants FDX-nodes on his
    >>gigaswitch directly, he wants his ring connected to the Gigaswitch
    >>and he wants those 2 things interoperating without 20 sec. delay.
    
    Just so there's no confusion.  FDX only works in point-point
    connections or when attached directly to the GIGAswitch.  By its very
    nature, concentrators do NOT support FDX and any nodes attached to a
    concentrator which is in turn attached to the GIGAswitch will NOT be
    running under FDX.                                                
     
    Here's an illustration:
    
        DEFTA----GIGAswitch---concentrator---DEFTA    <--- FDX is NOT possible
        ^                              |
        |                              +-----DEFTA    <--- FDX is NOT possible
        |
        FDX is possible
    
    Do you see why FDX can work on the leftmost DEFTA, but not on the right?
    
       - Larry

A bit about the startup delay:

1. From the time you plug an FDDI cable in to the time it becomes useable
   for traffic is about 1 second (assuming no faults).

2. From the time a bridge port is plugged in to the time it starts to
   forward traffic is set by a parameter, which by default is 30 seconds.

So, it depends on what you mean by "20 seconds delay".  If you mean delay
from the time you plugged in the connection or turned on the adapter,
that's normal (but you can reduce it by changing a parameter in the
bridge/Gigaswitch).  If you mean that you get 20 second delays in traffic
long AFTER the connections have been made, then there is something severely
broken.

	paul

    
    An update:
    
    Re .5 The problem is SOLID reproduceable. As to the question about only
    	  first time delay or constant: I didn't specifically ask, but from
    	  my mind it is always, and not only the first time after
    	  connecting. Customer was talking on the phone to me while trying
    	  things.
    Re .6 Sorry about the confusion, my understanding of FDX vs ansi FDDI
    	  is the same as yours. The only question I have in this area is
    	  If you have 2 FXD nodes on Gigaswitch you can FDX amongst the 2
    	  (no problem). But if you then add a ring to the Gigaswitch also
    	  you now also want to talk to whoever is on the ring from the 2
    	  FDX nodes. Of course you're then talking ansi and not FDX. But
    	  then those FDX-nodes have to switch between FDX and ANSI, and
    	  that is the area of my questions.
    Re .7 I am not talking about delay after "plugging in", the delay is
    	  simply observed bij doing
    
    		$ SET HOST XXXXXX
    
    		........20 seconds.......
    
    		Username: 
    
    	  and this is reproduceable at will.
    
    Update:
    
    	Since my last entry the customer has added 1 more AXP3600, and a
    	V4090, both connected to the Gigaswitch. Guess what: the second
    	AXP is giving exactly the same strange behaviour, the V4090 (also
    	equipped with a DEFTA) is working WITHOUT any delay problems.
    	And this goes for BOTH talking to the outside world on the ring
    	and talking to each other in the switch. (V4090-AXP3600 is slow,
    	even on the switch. V4090 to the ring is FINE)
    
    	So the problem is now narrowing down to AXP3600 combined DETFA
    	combined GIGASWITCH combined AXP VMS 1.5. Our next step will be
    	to put an AXP3600 on the ring and see what happens. We might be
    	able to exclude GIGASWITCH from the list, and state that we have
    	a "AXP3600/DEFTA/VMS 1.5" problem.
    
    	Somebody else has taken over this problem from me, since I'll be
    	going on holiday in a day or so.
    
    Thanks chaps for sharing knowledge and thinking with me!
    
    	Bart Rietkerk.

        It isn't clear to me from your diagram: are you running
    Phase IV DECnet, bridging between the ethernet and FDDI LANs, and
    presenting the same address (AA-00-04-xx-xx-xx) on both interfaces?  If
    so, the GIGAswitch (and other bridges) are probably pretty confused
    about the forwarding database.

Re .8: I think you're a bit confused about the scope of full duplex.

As with any other bridge, each Gigaswitch port is a SEPARATE LAN connection.
The configuration or state on one LAN does not affect that of any other.
Full Duplex is an FDDI LAN state.  It is available ON A PARTICULAR PORT when
that port is connected to a single other station, and not (on that port)
otherwise.  The state of other ports is irrelevant.

Therefore, if you have two stations, each one separately plugged in by
itself to a switch port, then each is running FDX on that port.  But it
is not correct or meaningful to say that they are "FDX amongst the 2".

Once the packets arrive at a Gigaswitch port, they are just packets that are
forwarded to other ports.  The rules for when such packets can actually
be transmitted change when you go from FDX to normal ANSI mode, but that
is transparent to the sender (except for possibly a difference in 
throughput/latency).  It very definitely is NOT the case that the sender
has to do anything different depending on whether the outbound port is
running regular or FDX mode, as you suggested.  There is no such thing
as "having to switch between FDX and ANSI".

Mike Lyons's suggestion sounds plausible...

	paul

    re. 9  <your right>
    
    The customer did do the following.
    The AXP systems are part of a cluster, they boot via ethernet, default was
    decnet setup for ethernet. after the system was running they changed
    decnet from ethernet to FDDI. Then the delay occurs.
    (samee address for both interfaces $ana/system sho lan)
    The customer changed his configuration used now FDDI for decnet worked
    oke now.
    
    The VAX 4090 mentioned in this note was a stand alone system wich
    worked oke.
    
    
    thanks for all your help.
    
    Gerard v Wee  (take the problem over from Bart)
    
    
    

    
    re .10
    
    Thanks Paul for the explanation about how Gigaswitch does the
    Full-Duplex. This cleared my mind, and made me understand better.
    
    Re .9,.10,.11
    
    The Customer first reported this problem as a "GIGASWITCH" problem,
    and directed me to the FDX-area. The solution was quite simple (that
    is, once you know what it is) and had nothing to do whatsoever with
    gigaswitch or FDX.
    
    Since I was the only one around who had seen a Gigaswitch before at the
    time the customer reported his problem I was assigned to it, and after
    some hours on the phone with the customer I was completely out in the
    dark. Sorry about some confusion, but this gave me a chance to learn
    something from you guys.
    
    	Thanks for all contributions!
    
    	Bart (Back from the this-summer-warm-water-lakes in Switzerland)