| Title: | FDDI - The Next Generation |
| Moderator: | NETCAD::STEFANI |
| Created: | Thu Apr 27 1989 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2259 |
| Total number of notes: | 8590 |
An FDDI ring with 3 DECconcentrators is having one reboot
as a result of an unsollicited reset. This network has 10
Sun workstations, Sparc 2' and IPX's, running 4.1.2. Is there
any way to determine via mgt software which address is sending
the unsollictied reset ?
I reviewed note 902.* so upgrading the sun sw and segementing
the Ring in three has been suggested. But short of a trace
or segementation is there any way of finding the offending
station ? The resets occur every other day or so.
Note all other counters LOOK ok. The counters are from the
OBM port on the concentrators.
Larry
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1037.1 | What we did.... | CTOAVX::BEAULIEU | Tue Jul 27 1993 15:29 | 20 | |
We have with DECMCC, unsolicited resets monitored, this is how we
caught the problem the first time (note 902) By doing a trace we
caught the offending workstations. I know of no other way to find the
address of the offending SUN station in a large network. You only have
ten nodes, so if you could disconnect a node for 48 hours, or
reconnect the node thru enet, you could start guessing. We found the
offending nodes to be several machines.
Be careful with SUN, I have found problems with SUN FDDI controllers
and their software. SUN 4.1.2 has a bug in it that if you are on a
directly connected FDDI SUN workstation with a SUN FDDI SBUS
controller, TCP/IP will only work with other SUN nodes in the network,
the DEC nodes and the IBM nodes couldn't communicate to the SUN node.
We never saw the problem with unsolicited resets with SUNOS 4.1.2, but
we did with SUNOS 4.1.3 as stated in note 902. SUN has patches for
both problems.
Mike Beaulieu
| |||||
| 1037.2 | Patch Numbers? | SANFAN::ROBAK_RI | Born to be obnoxious | Wed Jul 28 1993 14:37 | 5 |
Do you happen to know what the patch numbers are?
Thanks,
Richard Robak
| |||||
| 1037.3 | Who got that patch? | SAHQ::TROTTER | Fri Jul 30 1993 14:20 | 3 | |
I also have a site that is experiencing this kind of unsolicited reset
and they Sun systems in the network. I would like to know more about
the patch as well.
| |||||
| 1037.4 | sun patch ID | CROWES::HULLEY | Mon Aug 09 1993 11:22 | 5 | |
The SUN patch ID is # 100706-04
Synopsis: Problems with FDDI on Sun4c and Sun4m with 4.1.3
Date may 93
Tom H
| |||||
| 1037.5 | Didn't cure it. | PFSVAX::MCELWEE | Opponent of Oppression | Thu Sep 30 1993 23:39 | 15 |
We're seeing Unsolicited Resets on DEFCNs V3.1 and 620 bridges V1.2
adjacent/connected to a SUN W/S with the patch mentioned in .4
installed.
DEFCN V3.3 and 620 V1.3 will be installed this weekend. Line
counters show Ring Inits. Recvd., nothing else. Having problems looking
at the PHYPORT counters on the DEFCN because MSU/ELMS cannot access
other than the A & B primary ring ports, and the OBM port isn't
working...
What is the best way to approach this problem should the updates
not resolve it i.e. what analyzer would be best? DA30?
Phil
| |||||
| 1037.6 | One item solved. | PFSVAX::MCELWEE | Opponent of Oppression | Mon Oct 04 1993 11:21 | 11 |
Re: .5 (mine):
> Having problems looking
>at the PHYPORT counters on the DEFCN because MSU/ELMS cannot access
>other than the A & B primary ring ports...
This was fixed after V3.3 was installed on the DEFCN. Waiting to
see if the Unsolicited Resets problem is also resolved.
Phil
| |||||
| 1037.7 | Resolution. | 35405::MCELWEE | Opponent of Oppression | Thu Dec 02 1993 01:18 | 6 |
A defective SUN FDDI adapter was the problem. It was isolated after
tracing Beacon frames at several points on the ring. FWIW I used a HP
Network Advisor (only analyzer available) and found it sorely lacking
in features for this type of fault isolation.
Phil
| |||||