| |
DMA284 > PRNETZ 15.10.23 18:05l 274 Lines 14046 Bytes #999 (0) @ DEU
BID : 18208-MD2BBS
Read: GAST
Subj: Kaputtes Node Netz - XNet Problem
Path: DBO595<DBX320<MD2BBS
Sent: 231015/1651Z @:MD2BBS.#SAW.SAA.DEU.EU #:18208 [Salzwedel] $:18208-MD2BBS
From: DMA284@MD2BBS.#SAW.SAA.DEU.EU
To : PRNETZ@DEU
Moin!
Seit einigen Wochen experimentiere ich wieder mit Packet Radio und leider
muss man sagen, das man das Netz voellig vergessen kann und das trotz AXUDP
Verbindungen zwischen den Nodes.
Faellt denn Niemanden ausser mir auf das NETROM nicht wirklich funktioniert?
Ja, es gibt ein tolle Nodeliste, aber wenn man versucht vor allem entferntere
Nodes zu erreichen dann funktioniert das nicht. Der Grund ist auch voellig
klar. Es liegt daran das immer noch viel zu haeufig die Software XNet
verwendet wird.
XNet ist an sich gar nicht mal schlecht aber es hat einen grossen Makel. Es
mixt die beiden Routing Grundlagen naemlich die des Time Dependent Routing
(TDR) via INP3 und dem Qualitaets basierten Routingshema.
Das Qualitaets basierte Routing Schema ist das urspruengliche Verfahren wie
eine Route zu einem Nachbar NETROM Node berechnet wird. Der Sysop gibt den
einzelnen Ports seines Nodes eine "Qualitaet" fest vor. Jede Software die
NETROM kann muss also einem Port eine Qualitaet zuweisen. In der
Vergangenheit war das oft der Wert 192 fuer einen 1200 Baud Funkport im CB.
Ein NETROM Node schickt in regelmaessigen Abstaenden ein NODES Broadcast als
AX.25 UI Frame an das Call NODES aus. Damit identifiziert er sich bei anderen
Nodes als NETROM Node und gleichzeitig schickt er damit eine Liste mit NETROM
Nodes mit die er selber kennt. Ein Node Broadcast sieht so aus:
10:09:38T DNO284>NODES Port=1 <UI C> NODES broadcast from WITBPQ
WITPBX:DBO284 via DNO284 qlty=192
WITCNV:DNO284-4 via DNO284 qlty=192
Empfaengt ein NETROM Node so einen Broadcast, traegt er den sendenden Node
bei sich in der Nodeliste mit der Port Qualitaet 192 ein. Weitere Nodes in
der Liste ebenfalls, aber reduziert in der Qualitaet basierend auf der Port
Qualitaet und der Qualitaet die der sendene Node diese Nodes selber bei sich
eingetragen hat.
Zur Veranschaulichung:
Wir haben 3 Nodes. NODE01 <> NODE02 <> NODE03.
Alle Nodes haben eine Port Qualitaet von 192 eingetragen. NODE01 und NODE03
sehen sich nicht direkt.
NODE02 sendet an NODE03 das er NODE01 mit Qualitaet 192 empfaengt. NODE03
berechnet nun die Qualitaet von NODE01 so:
192/256 * 192/256 = 0,75 * 0,75 = 0,5625 * 256 = 144
Wuerde es jetzt noch einen NODE04 geben der NODE03 hoert wuerde NODE01 bei
ihm mit Qualitaet 108 eingetragen werden.
144/256 * 192/256 = 0,5625 * 0,75 = 0,421875 * 256 = 108
Und so geht das immer weiter wenn noch mehr Nodes in diesem Netz hinzukommen.
Die Qualitaet kann den Wert 0-255 annehmen. Und wie man in den Berechnungen
sieht kommt bei 192/256 der Wert 0,75 bei raus. Damit wollte man abbilden wie
zuverlaessig ein Funkverbindung zwischen zwei Nodes fuer gewoehnlich ist. Man
koennte auch schreiben 75% der AX.25 Pakete zwischen zwei via Funk
verbundenen Nodes kommen an. Dieser Wert kann erreicht werden, wenn zwei
Nodes die Frequenz ganz fuer sich alleine haben, aber nicht wenn auf diesem
Kanal noch weitere Stationen sind. Tummeln sich jetzt mehrere Nodes und ggf.
noch User auf einer Frequenz wie es bei CB-PR ueblich war, war 192 auch schon
immer zu hoch gesetzt. Wenn man Glueck hatte kamen vielleicht gerade mal 50%
der AX.25 Pakete an oder noch weniger. Dementsprechend muesste man die
Qualitaet entsprechend anpassen bei 50% waere 128 ein guten Wert. Die
meisten Nodes haben Port Statistiken gefuehrt, anhand diesen haette man
ermitteln koennen wie gut ein Port performt.
Obiges war jetzt die Beschreibung fuer Funk Links. Im heutigen CB-PR kommen
vor allem AXUDP Links via Internet vor, welche die Nodes miteinander
vernetzen. Das ist im Grunde nicht schlimm da wir, anders als im AFU, keine
exklusiven Frequenzen fuer eine Backbone Vernetzung zwischen Nodes haben.
Haeufig wir hier dann gerne die Port Qualitaet fuer solche AXIP/AXUDP Links
von 255 eingetragen. Das ist aber genauso falsch, weil Internet, welches auch
Paket basiert ist, nicht 100% Fehlerfrei ist. IP Pakete koennen und duerfen
verloren gehen. Nun ist unzweifelhaft das Links ueber Internet stabiler sind,
also kann man hier einen besseren Wert fuer die Qualitaet eintragen.
Die NADA (NorthEast Digital Association), eine in den 80er Jahren in den USA
gegruendete Organisation von Funkamateur Packet Radio Sysops hat fuer ihr
Netz Richtlinien herausgebracht. Dort wurde unter anderem festgelegt das
fuer AXIP/AXUDP Links die Port Qualitaet 203 betragen soll. Ich denke das ist
ein gute Wert. Er liegt hoeher als bei Funk Links und laesst die Moeglichkeit
zu das Internet Routen besser dastehen als reine Funk Links. Fuer lokale
Dienste wie z.B. die eigene Box oder der Convers kann der Wert 228 genutzt
werden. Dann resultiert daraus im Nodes Broadcast bei Nachbar Node eine
Qualitaet von 203 und ist somit genauso hoch wie der eigene Node.
Das oben genannte Routing mittels Qualitaeten hat schon in den Anfangstagen
so seine Probleme gehabt. Wie sich ja aus der von mir oben hoffentlich
einigermassen beschrieben kurzen Beschreibung ergibt, gibt die Qualitaet
ueberhaupt keinen Anhaltspunkt wie gut eine Node zu Node Verbindung
tatsaechlich ist. Sie ist ja nur angenommen und von den Sysops parametrisiert.
Jeder weiss, wenn sich Bedingungen aendern, muesste sich auch die Qualitaet am
besten Automatisch mit aendern. Das koennen verschiedene Dinge sein. Zum
Beispiel wenn ein Link oder eine Frequenz stark ausgelastet ist, sinkt der
Datendurchsatz. Ergo muesste die Qualitaet sich verschlechtern. Tut sie aber
nach dem alten NETROM verfahren nicht.
Ein weiterer Grund ist wie Nodes wieder aus der Nodes Tabelle verschwinden.
Das geschieht aus einer reinen Zeit Komponente heraus. Es gibt bei NETROM den
Parameter OBSINIT. Das ist der Startwert des Veraltenszaehlers. Wird ein Node
das erste mal in einem Node Broadcast empfangen bekommt dieser den
Zaehlerwert von OBSINIT. Sendet unser Node ebenfalls einen Node Broadcast
wird dieser Wert um 1 verringert. Ist dieser Wert auf 0, fliegt der Node aus
unserer eigenen Nodes Tabelle raus. Ein Zweiter Parameter ist der Wert
OBSMIN. Dieser gibt an wann ein Node unserer Nodes Tabelle nicht mehr weiter
gemeldet wird. OBSINIT und OBSMIN haengen also davon ab wie oft unser Node
seinen Node Broadcast sendet. Ein guter Wert sind meiner Meinung nach 10
bis 15 Minuten. Ich bin der Meinung wenn man einen Node seit einer Stunde
nicht mehr im Broadcast gelesen hat, sollte er aus der Liste fliegen. Also
setzt man OBSINIT bei 10 Minuten Broadcast Intervall auf 6. Bei 15 Minuten
auf 4. Alle Node in einem Netz sollten bei Node Broadcast Intervall und bei
OBSINIT und OBSMIN die selben Werte haben, ansonsten ist das Netz von vorn
herein zum scheitern verurteilt. Sysops die nicht angepasste Werte dort
stehen haben, sollte vom Netz ausgeschlossen werden.
Weil das alte NETROM Node Austausch verfahren so unzuverlaessig ist, hat man
sich INP3 fuer NETROM ausgedacht. Hier werden mehrere Dinge ueberprueft damit
ein Link und somit der Nachbar Node und dessen erreichbare Nodes in der
eigenen Nodesliste angezeigt wird und auch an andere Nodes weiter geleitet
wird.
* Es muss ein AX25 Link zwischen den Nodes dauerhaft bestehen.
Im alten Netrom Netz wurde mit den oben beschriebenen Nodes Broadcasts auf
sich aufmerksam gemacht. Nun konnte die Situation entstehen das er aussendene
Node den empfangenen Node garnicht hoeren kann. Der empfangene Node traegt den
sendenen Node aber in seine Nodetabelle ein und sendet auch die darueber
verbreiteten Nodes weiter aus. Kommt jetzt eine NETROM Paket an, kann dieses
nicht weitergeleitet werden zum sendenen Node. Sieht also ein INP3 NETROM
Node einen Nachbar Node via Node Broadcast, baut er einen AX.25 Connect zu
diesem auf. Und nur wenn das klappt, wir der Node erst in die Nodes Tabelle
bei ihm eingetragen.
* Laufzeitmessung
Zwischen INP3 Netrom Nodes werden Paketlaufzeiten ermittelt. Laufzeiten geben
einen Anhalt wie schnell ein Paket von Senden zum Empfaenger und zurueck
braucht. Das Ganze nennt sich abgeuerzt RTT (RoundTripTime). Da die Bandbreite
eines Links ja vorgeben ist, bedeutet eine kurze laufzeit das hohen Daten
durchsatz moeglich ist. Ist ein Link ausgelastet oder sogar von Stoerungen
betroffen, werden die Laufzeiten schlechter.
* Hopcount
INP3 weiss wie viele Nodes zwischen den Nodes sind.
* Gesicherte Uebermittlung von Routing Informationen
INP3 sendet zu den Nachbar Nodes keine Nodes Broadcast mehr aus. Sondern die
Informationen werden gesichert in der AX.25 Verbindung zwischen beides Nodes
uebertragen.
* Negative Routing Informationen
INP3 meldet nicht mehr verfuegbare Links und darueber gelernte Nodes sofort
als nicht mehr erreichbar zu seinen anderen Nachbar Nodes weiter. Anders als
beim Routing ueber Qualitaet wo erst ein Node aus der Tabelle fliegt wenn von
ihm nach einer bestimmten Zeit kein Nodes Broadcast mehr empfangen wird.
Was hat nun XNet mit dem ganzen zu tun?
Nun es ist eigentlich einfach. NETROM an sich ist erstmal nur ein Protokoll
was Verbindungen herstellt zwischen entfernten Nodes. Die Routing
Informationen werden aber wie oben beschrieben auf zwei verschiedene Arten
ermittelt. Qualitaet und INP3. Waehrend Routing nach Qualitaetsangaben sich
quasi nur auf die Einschaetzungen der Sysops baut, ermittelt INP3 Fakten
anhand von Laufzeitmessungen und ob ein Link tatsaechlich existiert, also
zwei Nodes auch wirklich eine Verbindung herstellen koennen.
Es ist auch gar kein Problem wenn diese zwei verschiedenen Verfahren in einem
Netz zusammen kommen. Es muss aber sichergestellt sein das jeder Node diese
Verfahren getrennt haelt. Ausser XNet macht das jede NETROM Node Software die
ich kenne.
XNet berechnet aus Laufzeiten Qualitaeten und aus Qualitaeten Laufzeiten. Aber
welche folgen hat das denn nun?
Schauen wir uns das noch mal an. Qualitaet = Von Sysop festgelegt und wenn
ein Nodes ueber ungesicherte Broadcasts weiter gemeldet wird, verringert sich
von Node zu Node die Qualitaet. Ueber einen auch vom Sysop einzurichtenen
Veraltenszaehler kann ein Node, wenn er nicht mehr in Broadcasts gehoert wird
auch wieder aus einer Nodes Liste verschwinden.
INP3 = Zeitbasiert mittels RTT ermittelte Laufzeiten, gesicherte Uebertragung
von Routing Infos via AX.25 Link und negative Rueckmeldungen. Nodes fliegen
bei AX.25 Abbruch zum Nachbarknoten direkt aus der Nodeliste und werden auch
sofort als nicht mehr erreichbar an andere Nachbar Nodes weitergemeldet.
Somit eine vertrauenswuerdige Routing Umgebung, mit gesicherten Informationen
zum Netzzustand.
Die Folge ist nun, dass ein Node, der nur in der nicht vertrauenswuerdigen
Qualitaets Umgebung existiert und in dieser Umgebung moeglicherweise
ausserhalb unseres Qualitaets Horizonts lag, nun in der vertrauenswuerdigeren
INP3 Umgebung auftaucht, wo er den NetRom veraltens Prozess umgehen kann. Die
Information koennte dann mit einer hoeheren "Qualitaet" in das Qualitaets
Netrom-Netz zurueckkehren, als wenn sie ueber eine direktere reine Netrom
Route empfangen worden waere.
Hier ein Beispiel wie das aussieht:
AP1DIG ==>n dnx284 +
routing WITXRO:DNX284 v AP0NOD
LOCAL Inp 3 rx: -.- (unreach) tx: -.-
DAB563-9 Inp 3 rx: 1.48 ( 9 hops) tx: -.-
> AP0NOD Inp 3 rx: 1.21 ( 6 hops) tx: -.-
CB0ESN Inp 3 rx: -.- (unreach) tx: 1.38
CB0GER Inp 3 rx: -.- (unreach) tx: -.-
AX25N0 Inp 3 rx: -.- (unreach) tx: 1.44
CT1NET Q BC Obs 0 RxQual 0
AP1NOD Q BC Obs 6 RxQual 0
NL5POP Q BC Obs 0 RxQual 0
Broadcasted 432s ago with quality 244
AP1DIG ==>
*** route: AP1DIG AP0NOD KS0NOD KS1NOD-2 AP0NOD* AP1DIG
DNX284 ist auch ein Test Node von mir. den ich jetzt seit mehrern Tagen
Offline genommen habe. Trotzdem ist er in Nodes isten weiterhin vorhanden
und wird von XNet Nodes wie hier zu sehen mit der Qualitaet von 244 weiter
gebroadcastet und natuerlich somit auch via INP3 mit einer fiktiven RTT
weiter gegeben.
Ein weiterer Grund den ich nicht verschweigen moechte ist das einige Node
die z.B. mit BPQ laufen den Parameter AUTOSAVE fuer die Nodes Liste
aktiviert haben. Dieser sollte immer ausgeschaltet werden. Denn damit
werden bei jedem Neustart von BPQ ggf. alte nicht mehr vorhandene Nodes
neu ins Netz eingespielt, obwohl die schon lange weg sind.
Deswegen ist XNet fuer das CB-PR und fuer alle sonstigen Netze die
schlechteste Software die man AX.25 NETROM Netzen antun kann. Im AFU Bereich
wo Packet auch nur noch von wenigen betrieben wird, ist die Software so gut
wie verschwunden. Ich finde man sollte dieses auch im CB-PR so handhaben. Im
Grunde bleiben einem nur drei NETROM Node Programme uebrig wenn man sich
umschaut.
BPQ: Aktive Weiterentwicklung inklusive Source-Code verfuegbar. Fuer Windows,
Linux und auch auf nem RasPi lauffaehig. Aeltere Versionen auch auf DOS.
Zahlreiche Schnittstellen vorhanden. INP3 faehig und rudimentaer sogar schon
IPv6 faehig.
Xrouter: Aktive Weiterentwicklung. Leider closed Source. Nur auf Linux und
RasPi verfuegbar. Aeltere Versionen auch fuer Windows und DOS. INP3 faehig.
TNN: Keine aktive Weiterentwicklung. Open Source Quellcode aber nicht fuer
aktuelle Compiler angepasst und Probleme wenn auf 64Bit System compiliert
wird. Angepasste CB Versionen verfuegbar. INP3 faehig.
Ich moechte jedem Sysop bitten sich mal die Alternativen anzusehen. Zum einen
erweitert man dadurch seinen Horizont und tut, wenn man sich entschliesst
XNet aufzugeben, auch was Gutes fuer das Netz.
Fuer Sysops die nicht wechseln koennen, weil sie XNet in einem TNC3 oder TNC4
laufen haben. Sollten nur Links zu Nodes aufbauen die keine NODES Broadcast
aussenden. Ebenso sollten sie selber mit dem Befehl "ro bc del nodes" das
Aussenden von Nodes Broadcast abschalten.
Link Partner zu XNet Nodes sollten nur INP3 erlauben. Nodes Broadcast zum
XNet Nodes ebenfalls abschalten und Nodes Broadcast von XNet Nodes
ignorieren oder die Port Qualitaet auf 0 oder 1 setzen.
Falls das alles nix hilft bleibt nur noch, das XNet Nodes von Sysops ohne
XNet vom Netz ausgeschlossen werden.
55 & 73 Marc-Andre DMA284
Lese vorherige Mail | Lese naechste Mail
| |