🚀 go-pugleaf

iscyeoak@nuscc.nus.sg (YEO ANN KIAN) writes:
>>Can NFS over FDDI work properly?  Certainly.

>Perhaps it should have been 
>"Can NFS over FDDI-Ethernet work properly thru a bridge?"

>>
>>The most obviously distinctive thing about NFS traffic is that it
>>usually contains many 4 or 8KByte UDP/IP datagrams.   These packets are
>>divided into about 4K Byte** or 1500 Byte IP fragments (for FDDI or
>>ethernet respectively), and commonly come from their source "back to
>>back."
>>
>>You might use 1500 Byte IP fragments on FDDI if you're stupid or you're
>>working around stupid FDDI-ethernet bridges or routers that can't
>>fragment at all or cannot fragment at full speed.  There are such
>>bridges and routers.  Since the problem is intermittent, it cannot be
>>caused by a bridge or router that cannot fragment at all.  Perhaps the
>>bridge cannot fragment at full speed, like many PC ethernet boards
>>cannot receive the back-to-back 1500 byte IP fragments of NFS traffic.
>>
>>If this is the problem, you might expect such observations with
>>etherfind on the ethernet side of the bridge.
>>
>>If this is the problem, reducing the NFS block sizes on the clients to
>>something less than or equal to 1400 should make it go away, although
>>that will make NFS a lot slower.

>Experiment (I):
>                      FDDI                         Ether
>DEC500 NFS server <--------> 3com NetBuilder II <-------> Sun ELC NFS Client

>We have tried that on our Sun machines by setting rsize and wsize to
>1400, the problem didn't go away unfortunately.
>When we run nfsstat on the Sun, 
>it shows that there are a lot of RPC timeout and badcalls
>on the client statistics.
>When we run nfsstat on the NFS server (DEC 5000), the server statistics
>is clean, ie no RPC timeout and badcalls.

>We tried another experiment as follows:

>Experiment(II):
>                     Ether                 FDDI 
>DEC5000 NFS server <--------> 3com NB II <--------> IBM R6000/560 NFS Client

>We connect the DEC5000 NFS server now to the bridge via the Ethernet port.
>We use a IBM R6000 connected to the bridge via a FDDI to run as a NFS client.
>We encounter intermittent NFS problem too.

>We then change the FDDI MTU of the IBM R6000/560 from 4352 to 1500, and
>everything works! (It seems to me that if we change the FDDI MTU of
>the DEC5000, experiment (I) should work fine too! -- Refer to VJS's remark.
>Unfortunately, we don't know how to change the MTU value yet in Ultrix)

>It certainly looks like the 3com bridge is dropping packets
>and it is very likely that, as vjs@sgi.com has pointed out,
>the bridge is not fast enough to fragment IP packets:
>ie to break a 4325-byte fragment to several 1500-byte fragments.

>Just wonder what we can do now? Any suggestion pls?

>--
>Ann-Kian Yeo
>yeoak@iscs.nus.sg

You are correct in that you need to lower the MTU on the DEC5000. The
NETBuilder II will drop packets that are to be **BRIDGED** from FDDI
to Etherenet if that packet exceeds the ethernet 1500 byte MTU.

The NETBuilder II has ample capacity to perform fragmentation when
it is routing (FYI: see Scott Bradners FDDI-ethernet-FDDI router test for
exact performance numbers), however in a bridging mode the NETBuilder II
does not currently support fragmentation.

-brad-

--
v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v
Brad Turner | 5400 Bayfront Plaza  | Marketing Engineer   | (408) 764-5261
3Com Corp.  | Santa Clara CA, 95052| mbt@NSD.3Com.Com     | (408) 764-5002 fax