Vor 4 Stunden
Moin!
Ich muss hier mal wieder mein Frust von der Seele schreiben. Trotz AXIP Internet Links scheint es kaum möglich mal sauber mit einem Connect Befehl von einem Node zu einem entfernten Node zu Connecten.
Man träumt in Romanen von dem perfekten Netz und fürchtet eine Intelligenz welche den Sysop überflüssig macht, aber davon sind wir sehr weit entfernt.
Ich glaube es ist einfach das Unwissen vieler Sysops was NETROM ist und wie es funktioniert. NETROM ist quasi Stein alt und wurde in den 1980er Jahren entwickelt. Die Idee war, das jeder Node eine Node- und Routing-Liste pflegt, damit ein User sehen kann welche (erreichbaren) Nodes es gibt und diesen mit einem einfachen Connect Befehl erreichen kann. Den Weg zum Ziel kannte das NETROM.
Vorher gabs es nur das Digipeating und ein User musste den Pfad zu einer entfernten Station kennen um sich dorthin zu verbinden. Zudem war es nicht effizient, weil die AX.25 Pakete immer über die gesamte Strecke bestätigt werden musste. Dadurch ergab sich bei Störungen auf einer Teilstrecke, das die Pakete wieder vom Anfang der beiden Link Enden wiederholt werden mussten. Effizienz sieht anders aus.
Bei NETROM wurde ein virtueller Link zwischen zwei Nodes aufgebaut und Pakete wurden an jedem Node Hop zwischen gespeichert und das AX.25 Protokoll wurde nur zwischen den beteiligen Nodes abgewickelt. Ebenso konnte ein Paket, falls ein Node ausfiel und es einen anderen Weg zum Ziel gab, dieses um geroutet werden. Soweit die Theorie.
Das Problem war jedoch die Art wie das Netz die Informationen zum Netz übertragen hat. Jeder Node strahlt sich selbst und ihm bekannte Nodes in einem Broadcast aus. Dieser wurde von anderen Empfangen und bei sich selbst eingetragen. Dieser sendete diese wieder aus, und so weiter.
Damit eine Routing Entscheidung gefällt werden kann, muss es eine Metrik geben die sagt welche Route gut und welche nicht so gut ist. Man hat das bei NETROM über ein fiktiven Wert mit Namen "Qualität" abgebildet. Ein Wert von 0-255. Je höher der Wert desto besser. Mit jedem Hop über einen weiteren Node verringerte sich dieser Wert. Dieser Qualitätswert ist aber an gar nichts fest gemacht, sondern kann frei definiert werden. Er spiegelt rein gar nichts wieder. Weder Durchsatz noch Latenz einer Funkstrecke.
Deswegen und auch weil die Übertragung der Nodes Information ungesichert erfolgte, hat man INP3 entwickelt für NETROM. Hiermit werden die Nodes Informationen in einer gesicherten AX.25 Verbindung übermittelt und gleichzeitig wird die Latenz zwischen den Teilstrecken des Netzes gemessen. Außerdem werden nicht erreichbare Nodes sofort als unerreichbar dem restlichen Netz gemeldet. Was eindeutig besser ist als das alte Verfahren.
Was jetzt das fatale ist, das es ein System NETROM gibt mit zwei Möglichkeiten wie Routing Infos zum NETROM übermittelt werden. Altes NETROM mit Broadcast und Qualität, und INP3 mit Laufzeitmessung.
Kommen wir zu dem was mir halt auffällt im jetzigen Netz.
Gemischter Betrieb von NETROM alter Art und INP3 auf AXIP Links. Das macht keinen Sinn! Es gibt keine aktuelle Node Software die nicht INP3 spricht. BPQ kann das, TNN kann das, Xrouter kann das und auch XNet. Zu letzterem komme ich noch. Also bitte, prüft eure AXIP Links und verwendet dort nur INP3!
Kommen wir zu XNet, diese Software hat den Fehler gemacht das sie beide Routing Metriken, Laufzeit und Qualität mischt und auch umrechnet. Dabei sollte klar sein das man Qualitäten nicht in Laufzeiten und Laufzeiten nicht in Qualitäten umrechnen kann. TNN, BPQ und Xrouter trennen diese beiden Systeme, wobei auch hier wieder Unterschiede sind. Während TNN und Xrouter INP3 Informationen bevorzugen bei Routing Entscheidungen, bevorzugt BPQ die alten NETROM Qualitäten. In Verbindung mit XNet ist das jetzt fatal.
Kurz gesagt, es kommt zu Schleifen im Netz. Pakete machten die große Runde im NETROM AXIP Netz und kommen letztendlich nie am Ziel an.
Deswegen meine Bitte, macht kein altes NETROM Quality Routing auf AXIP Links, wenn der Nachbar auch INP3 kann. Wer manuell das so konfiguriert, gehört einfach nicht mehr angebunden. XNet sollte auf keinen Fall irgendwo das alte NETROM Quality Protokoll fahren.
Des weiteren war ich immer ein Freund von geographischen Routing. Sprich ich verbinde mich wenn möglich maximal im eigenen Bundesland untereinander und vielleicht noch mit dem nächst gelegenen Nachbar Bundesland. Aber auch da wenns geht sinnvoll. Muss eine Node in Norddeutschland einen Link nach Österreich haben. Ich glaube nicht. Weniger ist mehr und kommt auch dem Routing zum tragen. Mit den kurzen Latenzen via Internet hat nämlich auch INP3 so seine Schwierigkeiten. Lieber nur 2-4 Nodes anbinden und es dabei belassen. So ne Linkwüste mit duzenden Verbindungen ist nicht gut fürs Netz. Das gilt auch für alle Anderen die sogar am selben Standort mehrere Nodes betreiben und die sowohl per AXIP intern im LAN als auch noch über Funk verbinden. Tut das Not?
So, ich bin auf die hoffentlich startende Diskussion hier sehr gespannt.
55 & 73 Marc-Andre
Ich muss hier mal wieder mein Frust von der Seele schreiben. Trotz AXIP Internet Links scheint es kaum möglich mal sauber mit einem Connect Befehl von einem Node zu einem entfernten Node zu Connecten.
Man träumt in Romanen von dem perfekten Netz und fürchtet eine Intelligenz welche den Sysop überflüssig macht, aber davon sind wir sehr weit entfernt.
Ich glaube es ist einfach das Unwissen vieler Sysops was NETROM ist und wie es funktioniert. NETROM ist quasi Stein alt und wurde in den 1980er Jahren entwickelt. Die Idee war, das jeder Node eine Node- und Routing-Liste pflegt, damit ein User sehen kann welche (erreichbaren) Nodes es gibt und diesen mit einem einfachen Connect Befehl erreichen kann. Den Weg zum Ziel kannte das NETROM.
Vorher gabs es nur das Digipeating und ein User musste den Pfad zu einer entfernten Station kennen um sich dorthin zu verbinden. Zudem war es nicht effizient, weil die AX.25 Pakete immer über die gesamte Strecke bestätigt werden musste. Dadurch ergab sich bei Störungen auf einer Teilstrecke, das die Pakete wieder vom Anfang der beiden Link Enden wiederholt werden mussten. Effizienz sieht anders aus.
Bei NETROM wurde ein virtueller Link zwischen zwei Nodes aufgebaut und Pakete wurden an jedem Node Hop zwischen gespeichert und das AX.25 Protokoll wurde nur zwischen den beteiligen Nodes abgewickelt. Ebenso konnte ein Paket, falls ein Node ausfiel und es einen anderen Weg zum Ziel gab, dieses um geroutet werden. Soweit die Theorie.
Das Problem war jedoch die Art wie das Netz die Informationen zum Netz übertragen hat. Jeder Node strahlt sich selbst und ihm bekannte Nodes in einem Broadcast aus. Dieser wurde von anderen Empfangen und bei sich selbst eingetragen. Dieser sendete diese wieder aus, und so weiter.
Damit eine Routing Entscheidung gefällt werden kann, muss es eine Metrik geben die sagt welche Route gut und welche nicht so gut ist. Man hat das bei NETROM über ein fiktiven Wert mit Namen "Qualität" abgebildet. Ein Wert von 0-255. Je höher der Wert desto besser. Mit jedem Hop über einen weiteren Node verringerte sich dieser Wert. Dieser Qualitätswert ist aber an gar nichts fest gemacht, sondern kann frei definiert werden. Er spiegelt rein gar nichts wieder. Weder Durchsatz noch Latenz einer Funkstrecke.
Deswegen und auch weil die Übertragung der Nodes Information ungesichert erfolgte, hat man INP3 entwickelt für NETROM. Hiermit werden die Nodes Informationen in einer gesicherten AX.25 Verbindung übermittelt und gleichzeitig wird die Latenz zwischen den Teilstrecken des Netzes gemessen. Außerdem werden nicht erreichbare Nodes sofort als unerreichbar dem restlichen Netz gemeldet. Was eindeutig besser ist als das alte Verfahren.
Was jetzt das fatale ist, das es ein System NETROM gibt mit zwei Möglichkeiten wie Routing Infos zum NETROM übermittelt werden. Altes NETROM mit Broadcast und Qualität, und INP3 mit Laufzeitmessung.
Kommen wir zu dem was mir halt auffällt im jetzigen Netz.
Gemischter Betrieb von NETROM alter Art und INP3 auf AXIP Links. Das macht keinen Sinn! Es gibt keine aktuelle Node Software die nicht INP3 spricht. BPQ kann das, TNN kann das, Xrouter kann das und auch XNet. Zu letzterem komme ich noch. Also bitte, prüft eure AXIP Links und verwendet dort nur INP3!
Kommen wir zu XNet, diese Software hat den Fehler gemacht das sie beide Routing Metriken, Laufzeit und Qualität mischt und auch umrechnet. Dabei sollte klar sein das man Qualitäten nicht in Laufzeiten und Laufzeiten nicht in Qualitäten umrechnen kann. TNN, BPQ und Xrouter trennen diese beiden Systeme, wobei auch hier wieder Unterschiede sind. Während TNN und Xrouter INP3 Informationen bevorzugen bei Routing Entscheidungen, bevorzugt BPQ die alten NETROM Qualitäten. In Verbindung mit XNet ist das jetzt fatal.
Kurz gesagt, es kommt zu Schleifen im Netz. Pakete machten die große Runde im NETROM AXIP Netz und kommen letztendlich nie am Ziel an.
Deswegen meine Bitte, macht kein altes NETROM Quality Routing auf AXIP Links, wenn der Nachbar auch INP3 kann. Wer manuell das so konfiguriert, gehört einfach nicht mehr angebunden. XNet sollte auf keinen Fall irgendwo das alte NETROM Quality Protokoll fahren.
Des weiteren war ich immer ein Freund von geographischen Routing. Sprich ich verbinde mich wenn möglich maximal im eigenen Bundesland untereinander und vielleicht noch mit dem nächst gelegenen Nachbar Bundesland. Aber auch da wenns geht sinnvoll. Muss eine Node in Norddeutschland einen Link nach Österreich haben. Ich glaube nicht. Weniger ist mehr und kommt auch dem Routing zum tragen. Mit den kurzen Latenzen via Internet hat nämlich auch INP3 so seine Schwierigkeiten. Lieber nur 2-4 Nodes anbinden und es dabei belassen. So ne Linkwüste mit duzenden Verbindungen ist nicht gut fürs Netz. Das gilt auch für alle Anderen die sogar am selben Standort mehrere Nodes betreiben und die sowohl per AXIP intern im LAN als auch noch über Funk verbinden. Tut das Not?
So, ich bin auf die hoffentlich startende Diskussion hier sehr gespannt.
55 & 73 Marc-Andre