| |
DMA284 > PRNETZ 04.06.23 13:02l 27 Lines 1184 Bytes #999 (0) @ DEU
BID : 13070-MD2BBS
Read: GAST DHT201
Subj: RE^2: Unerreichbare Nodes, wer ist schuld?
Path: DBO595<DBX320<MD2BBS
Sent: 230603/2146Z @:MD2BBS.#SAW.SAA.DEU.EU #:13070 [Salzwedel] $:13070-MD2BBS
From: DMA284@MD2BBS.#SAW.SAA.DEU.EU
To : PRNETZ@DEU
Moin Manuel!
Nein DIG233 ist nicht zwangslaeufig schuld. Es ist nur der Node der einen
Loop detektiert. Es sollte eigentlich nicht lange dauern, nachdem ein INP3
Node aus dem Netz verschwindet, das die Routen zu ihm geloescht werden. Denn
wenn dein Node merkt, ein Node ist nicht mehr da, sendet er weiter das der
nicht mehr erreichbar ist. Genau dafür hat man INP3 ja erfunden.
Und wie ich gerade festgestellt habe, macht TNN es auch richtig und vermischt
nicht Quality Domain mit Time Domain based Routing via INP3. Jedenfalls
sendet dein TNN im Broadcast nur NETROM Only Nodes aus und keine via INP3
gelernte Nodes. Genauso wie XRouter welches ich genutzt habe.
Ich kann mir also nur vorstellen das irgendein X-Net Node dafür verantwortlich
ist der selber mit einem NETROM Only Node verbunden ist. Denn der rechnet
Qualität in INP3 Laufzeiten um und umgekehrt. Nur dadurch kann es Echos
geben, die sich so lange halten. Wenn dann noch auf NETROM only Nodes lange
Broadcast Intervalle auf schlechte OBSINIT und OBSMIN Parameter trifft ist
das Chaos vorprogrammiert.
Das war aber auch vor 20 Jahren schon so.
55 & 73
Lese vorherige Mail | Lese naechste Mail
| |