🚀 go-pugleaf

In article <1992Dec8.214231.12692@berlioz.nsc.com> macomber@thoreau.nsc.com (
Robert Macomber) writes:
>In article <1078@rsp.UUCP>, tom@rsp.UUCP (Thomas Ruf) writes:
>> my@dunkin.nsc.com (Mike Yip) writes:
>> >If a station is inserted in the ring already, and if it starts
>> >to beacon forever (eg software die), the whole ring will be down
>> >forever, right?  SMT 6.2 and 7.2 does not have a timer to check
>> >if RMT is in DETECT forever. 
>> > May be we should change that for SMT-2.
>> 
>> That's how I understand it also, and in my opinion SMT would be
>> more robust if ALL stations that are in DETECT initated a trace
>> once they have been in this state long enough (e.g., 2*T_Stuck).
>> 
>
>It seems to me that this argument assumes that the ailing station
>is still capable of responding intelligently to a trace signal.
>I'm convinced that there will always be some way to bring down
>the ring.  For example, even if the neighbor(s) to this evil station
>forced it to go through PCM again, the stuck beacon condition could
>persist (e.g., PCM on PHY, SMT split across multiple processors).

You can also add the case where Path_Test does not detect the error
so the station returns.

The cases Robert cites are real. I think I have run across the 
multiprocessor problem once though my efforts were not directed at 
finding why the ring was down, but to get it running again.

If someone wants to enhance RMT to cover the beaconning, insane, single 
processor station, I favor all stations performing Path_Test without 
firing off a trace. The key for the insane station is to break the 
connections to it, assuming that the connection will not be 
reestablished. I have not performed enough analysis to recommend 
this approach, but it doesn't scare me as much as ALL stations 
firing off trace.

Any enhancement that does this must include a mecanism to limit 
this non-trace Path_Test getting into a cycle (i.e., only do it once).
No matter how smart the automatic protocol, there will be a case 
where they fail. A stable ring is very helpful for the centralized 
fault isolation below. More automatic protocols for isolation 
decrease the probability of leaving the ring in a stable state 
for the "manual fault isolation" which is necessary for some 
set of problems anyway.
>
>I believe that the 7.2 draft standard provides the ability to disable
>and enable specific ports, so that a human or intelligent agent could
>handle this error. [Bob Grow, do I have this right?]
>
Yes, we added actions to Disable_A port, Disable_B port and Disable_M 
ports. For example, a manager could transmit immediate Disable_M to the 
broadcast address. If the trunk ring is healthy, then start adding 
trees until the problem reappears. If it doesn't fix the problem, 
transmit immediate Disable_B (again broadcast), then grow the 
network one trunk ring station at a time. (The Disable A and B 
actions only apply to peer mode connections so only DASs on the 
trunk ring are affected.)

--Bob Grow
bob@xlnt.com