Conference 7.286::fddi

That's fine.  You need an NFS server with an FDDI interface, of course...

If you think of a concentrator as the FDDI equivalent of a DELNI or DEMPR,
you won't go far wrong.  (Just remember NOT to apply the same configuration
rules!)

	paul

re. .1

Paul, I was mainly concerned about the flooding of all the Ethernet's, even
those that have not the destination node attached. Think about the happy
LAVC getting quite nervous ! And it happens, I have seen it !

Walter.

Clearly when someone uses up a big piece of the FDDI and most of that traffic
goes across the bridge, you have a problem.  That's really no different from
having two Ethernets, bridged to a third, each feeding vast amounts of
traffic into the third Ethernet.  Either way it's possible to exceed the
capacity of one or more of the LAN segments.  (True, it's easier to do that
now that FDDI is around!)

With NFS you'll see an occasional broadcast, of course, from ARP.  Apart from
that, it should behave itself, and the traffic will go over the LANs it
belongs on and not over others.  Note that our bridges will do the learning
at the top speed of the FDDI, so there isn't any possibility (with DEC
bridges) of failing to learn due to overload.  It's possible for non-DEC
bridges to do this wrong, though.

	paul

    The only time you have a problem with the bridges not knowing where the
    destination system is and therefore forwarding the packets onto all the
    ethernets is when the destination system never sends anything back.  
    
    NFS does require the destination system (ie the client) to send some
    sort of acknowlegments back to the server, right?  So there is no
    problem.

Hi Kelly
    
>>    NFS does require the destination system (ie the client) to send some
>>    sort of acknowlegments back to the server, right?  So there is no
>>    problem.

That's the real issue ! As far as I know, NFS makes use of UDP (CLTP), sending
datagrams without any ack's.

So the NFS server on FDDI ARP's first, to get the MAC address of the client on
the Ethernet. All bridges see the ARP response and update the database.

Everything works fine for the bridge doing the actual forwarding to Ethernet.
However all the other bridges will timeout the forwarding entry and therefore 
send start to flood the NFS traffic to the E-net.

So the cure of the problem would be to setup the lifetime of the forwarding
db to much higher value.

Walter.

Wait a minute.

The question isn't whether a protocol has ACK messages.  The issue with
bridge databases is only whether the protocol is exclusively one-way or not.

NFS is very clearly a two-way protocol: client sends requests, server
sends responses.  "Bystander" bridges will see those responses (not just
the ARP response, but also NFS read-data responses etc.) and will create
or refresh their table entries from these.

	paul

>>The question isn't whether a protocol has ACK messages.  The issue with
>>bridge databases is only whether the protocol is exclusively one-way or not.

>>NFS is very clearly a two-way protocol: client sends requests, server
>>sends responses.  "Bystander" bridges will see those responses (not just
>>the ARP response, but also NFS read-data responses etc.) and will create
>>or refresh their table entries from these.

Paul, completely agree. Let's make one thing clear. I am refering to the brick 
demo which showed the problems I mention in .0. 

Fact Nr. 1, If you run brick demo with TCP, no problem

Fact Nr. 2 If you run Brick demo with UDP, big trouble ! And please explain 
	   me WHY ?

You are right, that I am probably wrong assuming that the brick demo uses NFS ?
But you could have the situation, that a NFS server response takes more time 
than the default lifetime of the forwarding enty in the bridge.

	Walter.

Bricks is not NFS.  Both use UDP, but that's all they have in common.

UDP just sends what it is told to, and doesn't do anything with ACKs.
Bricks just sends blindly, it doesn't receive anything.  NFS both sends
and receives.

Yes, if an NFS server takes longer than the timeout period before it
responds, then the entry would have timed out.  No problem.  The timeout
is many seconds.  An NFS server that takes that long to respond is broken,
so it doesn't matter if its responses are flooded.

	paul

    Indeed, Bricks does not use NFS.  
    
    When a Bricks sender is in TCP mode, the connection-oriented TCP 
    generates ack's from receiver back to sender.  Same for DECnet.
    
    When in UDP mode, the receiver does not send any messages back to
    the sender (neither the receiver application, nor the protocol).
    The sending program is dedicated to sending datagrams as fast as
    possible and does not want to be bothered with receiving any messages.
    
    Because of this, the forwarding problem occurs.
    
    The 'pinger' shell script, included in the Bricks kit, is used to 
    generate a low level of traffic in the reverse direction, preventing
    the occurrence of the problem.
    
    Rich
    [Who looked at the Bricks comm code once :-)]
    

	Some additional information on Bridges:

	The default normal Aging Time for an address in the bridge is 
    	2 minutes. If that address is not seen as a source for 2 minutes, 
        then that address is considered 'Aged Out'. The result is flooding 
	of packets destined to that address. If the Spanning Tree algorithm 
 	detects a 'topology change' somewhere in the extended LAN, all 
	bridges are informed of this event and start using the 'Short 
	Aging Time' for addresses. The default for this timer is 30 seconds. 

	My information about the Bricks demo problem (and I was very close
	to it, as I am a bridge developer) was that the problem was caused
	by the Short Aging Timer being used due to a topology change in
	the network. It was my understanding that there was enough 2 
        way conversations to keep the the address active in the bridge 
	database using the 2 minute aging timer. If this is not true,
        please let me know.

	There are several ways to prevent this from happening. One is to
	increase the Forwarding Database Normal Age Timer, but as I 
	mentioned above, that is not the problem. So you must also increase
	the Short Age Timer. Increasing these two parameters is not at
	all desirable because they affect the entire extended LAN. All
	bridges use the same timer value that the Root Bridge has in its
	database. A second fix (for the bricks demo) is to 'lock' down
	the addresses to the FDDI side of bridge, that are involved
	in this extended 1 way conversation. This means that these
	addresses will not be subjected to aging or learning. Their 'learned'
	information is set by management and therefore fixed in the bridge's
        database.
                                   
    	The 'Fix' you talked about which sends occasional replies, can you
    	tell me the frequency of those replies? They must be less than 30
    	seconds to correct the problem.

    	Chris