Conference 7.286::fddi

Hello all,

I've come across an interesting configuration which, although it works, is not
valid and has left me with some questions I can't answer properly. All comments
welcome....

The config;

	Vax 6320 VMS 5.4-3
	--------
	DEBNI	to ethernet \
	DEMFA   to fddi      > all connected together (with cons and bridge)
	DEMFA   to fddi     /

The customer started decnet (phase IV) on all 3 interfaces and sure enough
decnet started to complain.

The circuit was switched off on the debni and the 2 demfa circuits came up.

>That surprises me.  In any event, I trust you realize that this configuration
>is illegal, even though it came up.
>
>The reason it's surprising is that we just saw a description of how a check
>is made for duplicate addresses when the address is set.  Perhaps the FDDI
>chip suppresses reception of any frame that has a matching DA?  Don't
>remember...
>
>By the way, is there a bridge between these two DEMFAs, or are they on the
>same FDDI?

Q1. I believe the circuit come up as the decnet hellos from one interface are
stripped at the other interface (same source address) so decnet doesn't "see"
the loop. I think the controllers are NOT aware of any problem (loop) as each
strips the others hello off the ring (ie every time one talks the other will
also be sending the same packet and each will strip the 'wrong' packet -
confusing explaination I know :-).  Is this reasonable ? What should happen if
a controller transmits and never receives that packet to strip (does it care) ?

>No, that is absolutely NOT how it works.  If our adapters actually did that,
>your ring would be very unstable.  DEC FDDI adapters always use the hardware
>address (from ROM) as their MLA ("My Long Address").  Frames carrying that
>address in SA are indeed stripped based on the SA match.
>
>Any other individual addresses, such as the DECnet Phase IV address, are
>supported as "alias" addresses.  For those, the FDDI MAC chip uses the
>stripping method that was originally developed for bridges.  This does NOT
>involve a source address match.  Instead, it uses a count plus a marker
>frame.  As a result, even though two adapters are sending with the same (alias)
>SA, each will strip the frames IT sent and leave untouched the frames sent
>by the other.
>
>Is this a router or an endnode?  If it's a router, I don't know why it's
>ignoring the hellos that come in from one adapter to the other.  Perhaps
>it's a DECnet rule to ignore those (if so, I've forgotten).  If it's an
>endnode, then it's simple: endnodes don't listen to endnode hellos at all.
>
>While it's not directly relevant to the situation, on your last question:
>a controller doesn't care if it never receives the packet it sent.  If it
>was stripping by MLA, it doesn't even know (it doesn't keep track of what
>it sent and certanly doesn't wait for it).  If it was stripping bridge-fashion
>(so-called "Frame Content Independent Stripping") then it keeps a count of
>what it sent, which means it needs some recovery mechanism in case not
>everything comes back.  That recovery mechanism is the marker frame (Void
>frame) which follows the sequence of data packets.  Receipt of that void
>frame also stops stripping, independent of the count.

Q2. When another station transmits to the 6320, the first demfa on the ring
will copy the frame AND set the A and C flags in the status field. The second
demfa will then also copy the frams BUT the status flags are set (so it will
repeat them as received). Doesn't this cause any confusion (fddi level) or any
counters to be logged at the second demfa to say that a unicast for me has also
been copied by someone else ?

>Your analysis is correct but this does not cause any confusion.  The adapter
>doesn't care.  The driver could check if it wanted to, but it doesn't want
>to.  No counters are defined for this; it didn't seem worth the trouble.

Q3. I believe decnet is showing nothing because receiving duplicates is no real
problem for decnet and the only 'system' level impact will be performace
(processing twice as many decnet packets as it needs to). Correct ?

>Sounds right to me.

>	paul

>That surprises me.  In any event, I trust you realize that this configuration
>is illegal, even though it came up.

Yes and we've persuaded the customer it's a non-starter. He was a bit confused
because the 5.4-3 release notes discuss 2 controller BUT it's for clusters and 
not decnet.

>The reason it's surprising is that we just saw a description of how a check
>is made for duplicate addresses when the address is set.  Perhaps the FDDI
>chip suppresses reception of any frame that has a matching DA?  Don't
>remember...

Is it possible the duplicate address test uses the MLA rather than the decnet 
address ?

>By the way, is there a bridge between these two DEMFAs, or are they on the
>same FDDI?

Same ring, the only bridge was to connect the debni into the ring

Q1. Thanks for the info here.

>Is this a router or an endnode?  If it's a router, I don't know why it's
>ignoring the hellos that come in from one adapter to the other.  Perhaps
>it's a DECnet rule to ignore those (if so, I've forgotten).  If it's an
>endnode, then it's simple: endnodes don't listen to endnode hellos at all.


Life's not that easy :-) it is a router (level 1). What I'd expect to happen if
it is hearing it's own hellos over more than one circuit is exactly what was 
happening when the debni was on, the node brings up an adjacency to itself, then
hears a hello on a different port and takes down the first adjacency and brings 
up a new one (also to itself). Result - decnet bounces like a yo-yo. This 
definitely doesn't happen with the 2 demfa circuits and seeing you've destroyed
the stripping theory/guess I don't understand it either (yet!).

>  Receipt of that void
>frame also stops stripping, independent of the count.

I'm happy that this works but would consider it a problem on the ring if all 
stripping operations of this type were terminated by the void frame rather than
the count. Is there any way to 'see' that this is happening and wouldn't that be
a good idea (as it implies that packets are getting 'lost' all the time).

Q2 and Q3, thanks I'm happy with this.

Thanks for your info so far,

Steve

Re void terminating the strip: we don't count that case.  I suppose the
theory is that you'd have plenty of other evidence that frames are being
lost in the scenario you mentioned.

There is a counter "FCI Strip Errors" but that counts something different.
There's one more reason for FCI strip to stop, which is receipt of a token.
Occasionally that will happen if a frame and the void is lost and a token
comes right after it, but that's quite improbable.  The more interesting
case that will make this counter increment is a duplicate token.  Frequent
occurrence of FCI strip error (I don't remember the details of the treshold)
is taken as evidence that there may be a duplicate token.  In that case, the
ring is reinitialized (claim) to clean things up.

	paul

    Well,.. folks,.. you've found the bug.
    
    It appears that we have a problem with the DAT on the DEMFA.
    What *I think* is happening is that the DEMFA is not recognizing
    the LOOPBACK with the DA for the DECnet address. The DEMFA probably
    has adhered to the architectural guideline that MOP/LOOPBACK
    is only valid for the MLA (MLA == FDDI terminology for the Hardware
    Address). The LOPBACK packet we are sending is destined for the
    DECnet address (AA-00-04...) and so the DEMFA is ignoring it. 
    
    The support for aliasing presents a problem in itself. To really
    be a valid check, the DEMFA or its device driver needs to respond
    to a LOPPBACK (or 802 TEST) message addressed to any valid MLA or
    alias address active on that controller. What I believe is happening
    is that:
    
    	1) The DEMFA is only responding to the MLA
    
    	2) The DEMFA is not recognizing MOP LOOPBACK messages for any other
    	    address other than the MLA.
    
    	So,.. even though the DEMFA has an alias active (AA-00-04...)
    for the DA in the LOOPBACK packet, it doesn't reply to it,.. and
    it doesn't pass it up to the driver because there is no filtering
    match for DA and PTY.
    
    	This problem is under investigation. The important thing to
    remember is that the DAT we are doing is not "guaranteed" to
    100% prevent a duplicate address problem from occuring. People
    need to still follow the guidelines for unique addressing, which
    also applies to aliases. The DAT we do is an attempt to spot a problem
    before it gets created. Clever network types can easily fake out
    the DAT.
    
    	And just to be complete, remember:
    
    	Having two nodes/controllers with the same Physical address active
    on a single extended LAN is not supported and does not work. Starting
    DECnet Phase IV on two Ethernet/FDDI controllers in the same machine,
    where the segments those controllers are attached to are connected
    or bridged together, is a violation of the guidelines.
    
    								/Bill

I should have caught this sooner.

It's really a design problem in your DAT.  It depends on an assumption
that is not valid for ANY implementation that conforms to any of the LAN
architectures (Ethernet as well as FDDI).  Reason: each port gets to specify,
separately, its destination address(es) and protocol type(s).  Only matching
packets are looked at.  So, by the architecture, a Loop message sent to some
alias address will not generate a response, since that message doesn't match
any of the active address/protocol filters.  This applies to FDDI, and also
to any Ethernet implementation that implements the alias support specified
by the CSMA/CD architecture.

	paul

    Paul,
    
    		We should probably take it off line, but the question now
    	becomes how to design a DAT that will work in "all" cases. Is it
    	even possible?
    
    								/Bill
    

    I like your subject Bill.
    
    Just to interject some of the problems of a 100% functional DAT, I
    will add the following:
    
    1) Not all nodes respond to 90-00 loopback request even though this
       is in the Ethernet Specification.
    2) Not all nodes respond to XID or TEST 802 commands.
    3) You need to detect duplicate addresses when two separate extended
       LANs are joined.
    4) Some nodes will have multiple unique physical addresses.
    5) Bridges can discard packets that are destined for the address
       you are trying to test; yet they may forward packets to your
       multicast addresses.  The combination of these means that you
       may think you have a unique address when you actually don't and
       the multicast addresses being forwarded will cause problems.
    6) At any moment, another node (PC, ULTRIX, etc), may start using
       the address that you have already determined to be unique.  They
       can do this because they don't have a DAT.
    
    If you cannot solve all of these problems (and there are probably
    more, then you don't have a 100% working DAT.

It sounds like my little decnet confusion is nothing compared to the headaches
you're going to have with DAT ;-)

I've one last question - does anyone have an idea why decnet ISN'T bouncing
with the 2 demfa circiuts up at the same time ? I'd have expected the 'adjacency
to itself' to keep changing circuits, just like it does when the debni is on.

Ideas?

Steve

    Its not an "adjacency to itself" unless its routing.
    
    						/Bill
    

re -.2, -.1, the system in question is a router. The DAT doesn't prevent both
circuits coming up for the reasons discussed in previous notes, BUT both 
circuits come up and stay up with no visible problem (no events or counters
showing problems). This is part of my original problem/question. When the 
system also turns on a debni (connected into the ring via a bridge) decnet
bounces like I'd expect, but decnet on the 2 demfa works which leaves
me wondering how...

Steve

    Sorry, I missed that. Well,.. you've got me wondering too now.
    
    						/Bill