|
Its possible in the abstract, but very hard in practice. Its not
like a bus where all activity is visible. In the ring, any station
that thinks it should win the claim will block the frames of a losing
station, and source its own frames. If your analyzer is in the right
spot you might see the claims from the guy who started the init. If
the analyzer is downstream from a station that thinks it should be the
claim winner, you'll only see claim frames from that station. If yet
another station is th real claim winner, you'll then see that stations
claims too.
If the ring is all DEC equipment, you might be able to check all
of the stations and see which one's "ring inits initiated" counter has
ticked. If one of them has this counter incrementing, and the others
have the "ring inits received" counter ticking, you'll quickly
find the station that started the inits. But, this relies on all
of the counters working perfectly in all stations on the ring, and
I can't remember if that was true for all incarnations of products.
This might also work if the station initing the ring is a DEC station.
Try it and see.....
|
| Hi,
I have now started the "hunt" for the one, who is initialize,ing the ring.
This a trace, of a normal reboot of the OSF/1 machine, every morning.
I'm surpriced about the great number of claim frames.
Does the claim goes on for a time, or a number of frames ?
Can I deduct from this, trace, that it was the OSF/1 that whent down, an
3,5 min later, came back up. ?
If I place the analyzer some where else, could I figure out, what started this?
Are my remarks correct ? ( Do I understand what happends :v) )
The setup. ( upstream/ downstream neighb. )
v
PE switch 900
v
Alpha OSF/1
v
NT ( in trace as :DEC------A1-89-57 )
v
NT ( in trace as :Oracle )
v
HP network advisor/analyzer
v
DECconcentrator 900 ( in trace as : con1 )
v
DECbridge 900 MX
v
( going to next hub.)
v
DECbridge 900 MX
v
DECswitch 900 EF
v
DECconcentrator 900
v
( back to the top )
With the analyser, I only collect claim frames, ( and bad crc's)
During the morning, the OSF/1 is doing a reboot.
First it go'es down.
1 45:49.981 Oracle Oracle FDDI
2 45:49.981 DEC------A1-89-57 DEC------A1-89-57 FDDI
3 45:49.981 DEC------A1-89-57 DEC------A1-89-57 FDDI
4 45:49.981 DEC------A1-89-57 DEC------A1-89-57 FDDI
5 45:49.981 DEC------A1-89-57 DEC------A1-89-57 FDDI
6 45:49.981 DEC------A1-89-57 DEC------A1-89-57 FDDI
7 45:49.981 DEC------A1-89-57 DEC------A1-89-57 FDDI
8 45:49.981 DEC------A1-89-57 DEC------A1-89-57 FDDI
9 45:49.981 DEC------A1-89-57 DEC------A1-89-57 FDDI
10 45:49.981 DEC------A1-89-57 DEC------A1-89-57 FDDI
In frame 1 "Oracle" is sending it's own claim frame.
In frame 2, it appears, that the other NT, has a better bid.
This frame is be'ing forwarded by every one.
This go'es on several times. ( but only 3 msec's )
1050 45:49.984 DEC------A1-89-57 DEC------A1-89-57 FDDI
1051 45:49.984 DEC------A1-89-57 DEC------A1-89-57 FDDI
1052 45:49.984 DEC------A1-89-57 DEC------A1-89-57 FDDI
1053 45:49.984 DEC------A1-89-57 DEC------A1-89-57 FDDI
1054 45:49.984 DEC------A1-89-57 DEC------A1-89-57 FDDI
1055 45:49.984 DEC------A1-89-57 DEC------A1-89-57 FDDI
1056 45:49.984 DEC------A1-89-57 DEC------A1-89-57 FDDI
1057 45:49.984 DEC------A1-89-57 DEC------A1-89-57 FDDI
1058 45:49.984 Con1 Con1 FDDI
1059 45:49.984 Con1 Con1 FDDI
1060 45:49.984 Con1 Con1 FDDI
1061 45:49.984 Con1 Con1 FDDI
1062 45:49.984 Con1 Con1 FDDI
1063 45:49.984 Con1 Con1 FDDI
1064 45:49.984 Con1 Con1 FDDI
1065 45:49.984 Con1 Con1 FDDI
1066 45:49.984 Con1 Con1 FDDI
1067 45:49.984 Con1 Con1 FDDI
Finaly, the claim contension is wun by Con1.
There is a pause for approx 3 min.
Then the OSF/1 machine comes back up.
1068 49:04.631 Oracle Oracle FDDI
1069 49:04.631 DEC------A1-89-57 DEC------A1-89-57 FDDI
1070 49:04.631 DEC------A1-89-57 DEC------A1-89-57 FDDI
1071 49:04.631 DEC------A1-89-57 DEC------A1-89-57 FDDI
1072 49:04.631 DEC------A1-89-57 DEC------A1-89-57 FDDI
1073 49:04.631 DEC------A1-89-57 DEC------A1-89-57 FDDI
1074 49:04.631 DEC------A1-89-57 DEC------A1-89-57 FDDI
1075 49:04.631 DEC------A1-89-57 DEC------A1-89-57 FDDI
.
.
2119 49:04.633 DEC------A1-89-57 DEC------A1-89-57 FDDI
2120 49:04.633 DEC------A1-89-57 DEC------A1-89-57 FDDI
2121 49:04.633 DEC------A1-89-57 DEC------A1-89-57 FDDI
2122 49:04.633 DEC------A1-89-57 DEC------A1-89-57 FDDI
2123 49:04.633 DEC------A1-89-57 DEC------A1-89-57 FDDI
2124 49:04.633 Con1 Con1 FDDI
2125 49:04.633 Con1 Con1 FDDI
2126 49:04.633 Con1 Con1 FDDI
2127 49:04.633 Con1 Con1 FDDI
2128 49:04.633 Con1 Con1 FDDI
2129 49:04.633 Con1 Con1 FDDI
2130 49:04.633 Con1 Con1 FDDI
2131 49:04.633 Con1 Con1 FDDI
2132 49:04.633 Con1 Con1 FDDI
2133 49:04.633 Con1 Con1 FDDI
2134 49:04.633 Con1 Con1 FDDI
Finaly, the claim contest is wun by Con1, as before.
The con1 will issue then real token.
3 of the frames in detail:
___________________________________________________________________________
1 45:49.981 Oracle Oracle FDDI
Frame: 1 Time: Sep 07@21:45:49.9819596 Length: 21
***** DETAILED FORMAT *****
FDDI
Protocol note -> Preamble >= 255 symbol pairs
Frame Control C3 (Hex)
Class bit 1...-.... Synchronous
Address Length bit .1..-.... 48 bit address
Format bits ..00-.... MAC frame
Control bits ....-0011 Claim frame
Destination Address Oracle Individual, universal
Source Address Oracle Individual, universal
Target Rotation Time 7.98720 ms.
Frame Status:
Error Detected Reset No errors detected
Address Recognized Reset Address not recognized
Frame Copied Reset Frame not copied
Frame check sequence E8-70-69-11
> Preamble symbol pairs 255
> Control Indicators 3
Frame dat
___________________________________________________________________________
2 45:49.981 DEC------A1-89-57 DEC------A1-89-57 FDDI
Frame: 2 Time: Sep 07@21:45:49.9819621 Length: 21
***** DETAILED FORMAT *****
FDDI
Frame Control C3 (Hex)
Class bit 1...-.... Synchronous
Address Length bit .1..-.... 48 bit address
Format bits ..00-.... MAC frame
Control bits ....-0011 Claim frame
Destination Address DEC------A1-89-57 Individual, universal
Source Address DEC------A1-89-57 Individual, universal
Target Rotation Time 7.98720 ms.
Frame Status:
Error Detected Reset No errors detected
Address Recognized Reset Address not recognized
Frame Copied Reset Frame not copied
Frame check sequence B2-D8-49-75
> Preamble symbol pairs 8
> Control Indicators 3
___________________________________________________________________________
2134 49:04.633 Con1 Con1 FDDI
Frame: 2134 Time: Sep 07@21:49:04.6337339 Length: 21
***** DETAILED FORMAT *****
FDDI
Frame Control C3 (Hex)
Class bit 1...-.... Synchronous
Address Length bit .1..-.... 48 bit address
Format bits ..00-.... MAC frame
Control bits ....-0011 Claim frame
Destination Address Con1 Individual, universal
Source Address Con1 Individual, universal
Target Rotation Time 7.98720 ms.
Frame Status:
Error Detected Reset No errors detected
Address Recognized Reset Address not recognized
Frame Copied Reset Frame not copied
Frame check sequence F8-2E-24-29
> Preamble symbol pairs 8
> Control Indicators 3
Jan.
|
|
What you are seeing looks normal to me. The claim frames go on
until the claim winner (con 1) is the only one sending frames, then
a token is issued. Claiming goes on for at least enough time for the
winner's frames to go all the way around the ring, and get back to
the claim winner. It isn't just 1 or 2 frames.
If the OSF/1 machine is rebooting, that is the reason for the claims
occurring. When the OSF/1 machine reboots, its FDDI adapter leaves the
ring. This causes the first claim sequence. When the OSF/1 machine
finishes the reboot, and reenters the ring, that causes the second
claim sequence.
Unless I misunderstand your question, the claims are a normal
result of the daily reboot of the OSF/1 system. The trace is
consistent with what I would expect to see from an analyzer at
that location in the ring.
|
| Hi,
The ring has now run well for 8 day's. So I decided to add an extra NT
server ( Alpha )
The next night, there was 10 RING INITS ( they apeared 2 and 2 )
I changed the TP-FDDI cable, and the concentrator port to the newly
added NT server.
Then after about 2 hours, I saw this on the analyser.
Claim contests, but NOT 1000, of a frames durations, but only 12 & 13 ?
claim's long.
Why are there "long and short claim contests ?
here is the trace.
***************************************************************************
***** *****
***** HEWLETT PACKARD NETWORK ADVISOR *****
***** *****
***** Measurement: FDDI Stack Decode *****
***** Print Type: Frames 1 to 25 *****
***** Open Views: Summary *****
***** Display Mode: Viewing All Frames *****
***** Print Date: 09/15/95 *****
***** Print Time: 13:1:10 *****
***** *****
***************************************************************************
1 40:35.317 Con1 Con1 FDDI
2 40:35.317 Con1 Con1 FDDI
3 40:35.317 Con1 Con1 FDDI
4 40:35.317 Con1 Con1 FDDI
5 40:35.317 Con1 Con1 FDDI
6 40:35.317 Con1 Con1 FDDI
7 40:35.317 Con1 Con1 FDDI
8 40:35.317 Con1 Con1 FDDI
9 40:35.317 Con1 Con1 FDDI
10 40:35.317 Con1 Con1 FDDI
11 40:35.317 Con1 Con1 FDDI
12 40:35.317 Con1 Con1 FDDI
13 40:36.739 Oracle Oracle FDDI
14 40:36.739 Con1 Con1 FDDI
15 40:36.739 Con1 Con1 FDDI
16 40:36.739 Con1 Con1 FDDI
17 40:36.739 Con1 Con1 FDDI
18 40:36.739 Con1 Con1 FDDI
19 40:36.739 Con1 Con1 FDDI
20 40:36.739 Con1 Con1 FDDI
21 40:36.739 Con1 Con1 FDDI
22 40:36.739 Con1 Con1 FDDI
23 40:36.739 Con1 Con1 FDDI
24 40:36.739 Con1 Con1 FDDI
25 40:36.739 Con1 Con1 FDDI
Jan.
|