SUMMARY: Problems with SunLink FDDI/S 3.0

From: Juergen Peus (
Date: Wed Mar 08 1995 - 16:15:20 CST

Hi !!

Sorry for the late summary, but i took some time to test your suggestions...;-)

What was my problem ?? :

>>>>>>>>>>>>>>>>>>>> Original Question <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>From: Juergen Peus <>
Subject: Problems with SunLink FDDI/S 3.0
Date: Sat, 11 Feb 1995 15:03:51 +0100

Hi !!

We use the SunLink FDDI/S 3.0 Interface in a SS1000 with Solaris 2.4 11/94
(patches: patch-cluster from the cdrom + recommended):

grobi@wiwianka[~]>>uname -a
SunOS wiwianka 5.4 Generic_101945-13 sun4d sparc

Patches for FDDI/S 3.0: 101766-04

The problem is, that the FDDI interface produces a very large number of

grobi@wiwianka[~]>>netstat -i
Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
lo0 8232 loopback localhost 65185 0 65185 0 0 0
le0 1500 wiwianka-mb 2084337 1 1678505 0 8789 0
le1 1500 wiwianka 236089 193 208769 0 1937 0
le3 1500 wiwianka-sn2 165149 0 240127 0 335 0
nf0 4352 wiwianka-fb 753859 13905 338713 109 0 0
>>>>>>>>>>>>>>>>>>>> Original Question <<<<<<<<<<<<<<<<<<<<<<<<<<<<<

I got some answers about what to do if the system cannot boot right after the

There must be an entry in /etc/system and reboot the system.

        set kmem_align=64

Now you can install fddi 3.0 but do not reboot the system. Install the
Patch 101766-05 or later and then reboot the system.

Other suggestions were to modify the mtu values for the FDDI interface, but the
(hopefully) final solution was the new revision of the FDDI patch:


Since installing it last week there have been nearly no errors on the
interface !!

This patch is available e.g. at anonymous ftp

------- start of digest (2 messages) (RFC 934 encapsulation) -------
From: (Wolfgang Wetz R1045.P24 75425)
Subject: Re: Problems with SunLink FDDI/S 3.0
Date: Mon, 13 Feb 95 09:43:42 +0100
Message-Id: <9502130843.AA06316@wirz.chbs>


I forgot to mention the following setting in /etc/init.d/inetinit:

ndd -set /dev/ip ip_path_mtu_discovery 0

which disables the MTU path discovery feature; we did that in order
to allow us keeping the MTU of 4352 octets.

Another way would have been to adjust the MTU in /etc/system by
adding the line:

set nf:nf_mtu=1500

We did start with setting nf_mtu to 1500 (the size of ordinary
ethernet) and then we went on with setting mtu_discovery to "0"

hope this helps

Wolfgang (

From: (Greg Myers)
Subject: FDDI stuff
Date: Thu, 2 Mar 95 14:50:26 CST
Message-Id: <>

  Followup on the FDDI problem:

  My posting caused a tech support guy from NPI(Network Perphirals)
to call. If you don't know, NPI makes the Sbus FDDI card for SUN.
He explained that certain manufacturers bridges causes bad fragments to
be left on the ring. These fragments are causing the high error rates.
He mentioned two bridging cards that left fragments on the ring:
    UB(Ungermann-Bass) (Model #5361)
UB has supplied us with all of our bridges and ethernet/fddi
concentrators. He said that the problem with UB brigdes was a recent

  On Wednesday a conference call with SUN,NPI, and a few interested
origanizations here at TI took place. It looks like we finally may
be getting somewhere. NPI and UB are looking to resolve this problem
together. NPI suggested and seemed willing to help us locate a vendor
who produces FDDI cards that have the ability to "purge" bad fragments
from the ring. This ability is referred to as a "Ring Purger". DEC
started using this on their cards and others have followed. This would
be only a temporary patch until UB and NPI have a fix.


 Hope this helps. My FDDI knowledge is still in its early stages.
Greg Myers Email:
Texas Instruments
PO Box 655303 M/S 8316 Phone: 214-997-5780
Dallas, TX 75265 Fax: 214-997-5763
------- end -------


Juergen Peus (
<A HREF="">Click here</A>

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:18 CDT