| |
DG8NGN > XNET 13.01.05 18:57z 281 Lines 14625 Bytes #999 (0) @ DL
BID : D1FDB0FHN03V
Read: GUEST SP6FIG
Subj: Re: TNN/Flex/Xnet
Path: SR1BSZ<DB0TEM<DB0BLO<DB0GR<DB0ERF<DB0MRW<DB0FHN
Sent: 050113/1335z @:DB0FHN.#BAY.DEU.EU [JN59NK Nuernberg] obcm1.06b47
From: DG8NGN @ DB0FHN.#BAY.DEU.EU (Jann)
To: XNET @ DL
X-Info: No login password
Hallo Zusammen,
Olaf wrote:
> DB0NDS spricht Flexnet (via SWM) und INP! Ruf einfach mal bei DB0AGI
> einen beliebigen Flexnetknoten deiner Wahl auf (z.B. BRO-1). Er wird
> nicht über das IGATE geroutet, sondern via NDS.
Ja stimmt. Wenn ich D DB0BRO-1 macht, kommt gar nichts. Wenn ich aber
N DB0BRO-1 mache, dann kommt was :) Aber ein N DB0FHN brachte das:
>DG8NGN de DB0AGI (09:23:28)>n db0fhn
>
>can't route #tmp:DB0FHN
Schade, denn mit Flexnet wäre das nicht passiert :)
> Nur leider kann TNN max. 1 Routingeintrag zum direkten Partner. Wir
> haben das beim Übergang DB0EAM(tnn)- DB0AX-DB0BQ (beide Xnet) so gelößt,
> das EAM als direkten Partner einen Flexlink zu AX einträgt und einen
> INP-Link zu BQ via AX.
Klingt gut. Andersrum wirds wohl nicht gehen. Also den INP3-Link so lassen
und den Flex über den INP3-Link einzutragen :)
Für DB0NDS gäbe es mehrere Möglichkeiten. Halten wir fest:
DB0NDS hat bereits einen Flexlink zu DB0SWM (RMNC im großen Flexnetz).
DB0NDS hat 2 INP3-Links zu DB0AGM und DF0HMB (Xnet in der Flexnetinsel).
Außerdem:
DG8NGN de DB0AGM (09:20:40)>d df0hmb
*** DF0HMB (0-15) T=5
DG8NGN de DB0AGM (09:20:45)>
*** route: DB0AGM DB0AGI DF0HMB
Und auf DB0AGI:
2:DB0AGM 143 I 3 2/2 0129d 19h 3.8G 2.7G 100/100 0.3 1633
2:DB0AGM 3 F 3 2/3 1129d 19h 3.8G 2.7G 100/100 0.3 1633
3:DF0HMB 14 F 2 2/1 0 10d 09h 53M 80M 99/98 0.6 1191
3:DF0HMB 312 I 3 2/2 0 10d 09h 53M 80M 99/98 0.6 1191
Sind also wirklich stabile Links.
Man könnte also ein Szenario wie bei EAM-AX-BQ machen oder einfach einen der
beiden Links auf Flexnet umstellen und fertig. Noch einfacher wäre es, wenn
DB0NDS ein Xnet wäre. Oder TNN wie schon mehrmals gesagt eben Flexnet und
INP3 parallel könnte.
Die harte Variante wäre natürlich einfach als DB0AGM und DF0HMB Flexnet
einzuschalten und INP3 auszuschalten. Dann wäre allerdings DB0NDS ganz ohne
INP3-Links und das Nachbarschaftsverhältnis wäre dann sicherlich auch
gestört :( Wenn das L2-Digipeating aktiviert ist, könnte ja auch DB0SWM via
DB0NDS nach DB0AGI oder DF0HMB sprechen :) Wäre fast mal witzig das auszu-
probieren. Bei unserer IGATE-Entwicklung müssen wir auch den ein oder
anderen Workaround bauen :)
Also ich denke mit den OMs von DB0NDS lässt sich doch sicher reden, so dass
man dort bestimmt auch zu einer Lösung kommen wird.
Übrigens ähnliche Situation bei DB0HRO. DB0HRO (TNN) hat einen Flexlink nach
DB0MAR und einen INP3-Link nach DB0RMV. Das INP3-Netz dort ist aber schon
ziemlich klein (DB0HRO, DB0RMV, DB0HST). DB0RMV und DB0HST sprechen auch
Flexnet, so dass dort auch eine Mini-Flexnetinsel entstanden ist (via IGATE
angebunden). Daher kann ich dort nur Empfehlen DB0HRO <-> DB0RMV ebenfalls
auf Flexnet umzustellen. Dann ist die kleine Insel an die große Insel
angebunden HI.
> Warum Flexnet-Ziele im TNN bekannt sind, aber nicht umgekehrt?
Da hattest du mich falsch verstanden. Ich meinte, dass TNN eben auch seine
Nodestabelle nach Flexnet propagieren könnte. Aufgrund der verschiedenen
Layer halte ich das aber für sehr bedenklich und nicht empfehlenswert. Die
paralle Routingvariante gefällt da schon viel besser.
> Ist eigendlich geplant, das die IGATE-Übergänge auch INP Routen ?
> Dann wirds spannend, zumindest bei DB0AGI und DB0CL. Dort gibts
> TNN Nachbarn mit Flexnet-Ziele (db0nds/db0pdf/db0whv)...hihi
Wie schon in der letzte Mail geschrieben, halte ich INP3 als nettes
Experimentierfeld. Die Erreichbarkeit von PR-Knoten ist aber mit dem
einfachen Flexnetprotokoll bestens gewährleistet und genau Diese soll IGATE
erhalten.
Zu den zwei Vorteilen von INP3 noch ein paar Worte:
1. Automatisches Umrouten:
Ist die Infrastruktur (Alternativrouten) zur Nutzung vorhanden?
Wie oft brechen Links, die umgerouted werden könnten?
Ich finde es durchaus praktischer, wenn ich als User sehe, wenn Links
brechen. Bei INP3 wartet man unter Umständen einige Minuten, bis das Netz
merkt, dass es keine Alternativrouten gibt. Im Convers wundert man sich
vielleicht nur, wo die Antwort bleibt :)
2. TCP/IP im INP3:
Habe ich mir angeschaut. Auch eine nette Sache zum experimentieren. Die
meisten Knoten müssen dafür aber sauber konfiguriert sein. Leider sind bei
vielen die IP-Routen festgeklopft, so dass die INP3-Routen gar nicht
greifen. Sogar mit IPR gesetzte Routen werden gelernten Hostrouten
vorgezogen.
Prinzipiell spricht ja auch gar nichts gegen den Einsatz von INP3. Ich
glaube auch nicht, dass es zu Problemen führt, wenn man ein paar Dinge
beachtet.
Mit dem Aufbau von DB0FHN habe ich schon einige Experimente mit INP3-
Routing gemacht. Zunächst hatte ich DB0FHN im Wormholenetz mit angebunden
und auf Funk alles mit Flexnet gemacht. Später irgendwann habe ich mich
aus dem Wormholenetz mit INP3 verabschiedet und die NordDL-INP3-Netze
über Internet ein bischen zur Kommunikation verholfen (DB0HST, DB0FHN,
DB0AGI, DB0DIM, DB0CL). Letztendlich bin ich mit der Fertigstellung
von IGATE dazu übergegangen nur noch direkte RF-Partner per INP3 zu
verlinken (die nicht irgendwie ins Wormholenetz gelinkt sind). Unser Netz
schaut im Moment so aus:
=>n
JN59RM:DA5UF JN59ML:DB0ANF JN59GG:DB0ANU JN59NK:DB0FHN
JN59MK:DB0VOX
Den Alias mit den Loctor zu belegen fand ich auch recht passend :)
Experimente mit TCP/IP im INP3 werden sicherlich noch folgen, wenn es die
Zeit erlaubt.
Dann noch zum Thema Wormholenetz und INP3. Da wir uns bei der Abkopplung
vom Wormholenetz (Flexnetprotokoll) bereits intensiv damit beschäftigt
haben, können wir auch die Punkte ansprechen, die sich auf INP3 auswirken.
Das Wormholenetz hat eine viel zu gute RTT zwischen den Linkpartnern und
außerdem viel zu viele Querconnections. D.h. jeder linkt mit jedem :) Es sind
also eigentlich alle Knoten mit weniger als 4 Hops zu erreichen, was im
Funknetz absolut unmöglich wäre. Durch diese Struktur dauert es aber eine
halbe Ewigkeit, bis ein abgeschaltener Knoten wirklich im Netz expired. Bei
Flexnet konnte das fast einen halben Tag dauern. Wenn nun ein RF-Link am
Wormholenetz plötzlich einiges schlechter wurde, war er schon nicht mehr
erreichbar, da die niedrigere RTT noch im Wormholenetz zirkulierte :((
Eine Verlinkung von RF und Wormholenetz ohne klarer Trennung (egal welches
Protokoll) halte ich für wenig sinnvoll. Der weltweite INP3-Routingtraffic
lastet einen 1k2-Link fast zur Hälfte aus.
Thema SSIDs und INP3-Erreichbarkeit:
Recht bescheiden finde ich, dass man im INP3 keine "SSID-Ranges" mitgeben
kann. Für DB0FHN bräuchte ich 12 Einträge im INP3-Routing, um alle Dienste
im Netz verfügbar zu machen (und jedesmal einen hübschen Alias). Daher bleibt
nur der Grundknoten über INP3 erreichbar :) Übrigens ein Trick für User, die
wegen INP3-Falschrouting nicht zu ihr Ziel kommen: Einfach mit SSID connecten,
die nicht im INP3-Routing eingetragen ist. Dann gehts über Flexnet zum
Beispiel zu DB0FBB-1 :)
Manche TNN-Hosts gehen auch etwas unpfeglich mit der Kapazitätsgrenze von 600
Flexnetknoten im Flexnetnetz um. Letztens war DB0II noch mit 5 eigenen
Routingeinträgen unterwegs. Scheinbar kann man dies auch umstellen, da jetzt
DB0II 0-10 announced wird ;) Wenn das bei DB0II geht, könnte es ja auch bei
DB0KOE gehen:
=>d db0ko
DB0KOE 0-0 69 DB0KOE 4-4 89 DB0KOE 5-5 89 DB0KOE 6-6 89
DB0KOE 7-7 89 DB0KOE 10-10 88 DB0KOE 12-12 88 DB0KOE 14-14 88
Die Faustregel: Für jeden Knoten eine SSID-Range vergeben. Hat man mehrere
Knoten mit gleichem Call, sollten sich die SSID-Ranges nicht überlappen.
Ansonsten am Besten immer 0-15 :) Schaut man ins Wormholenetz hinein, merkt
man, dass dort viele OPs nicht aufgeklärt sind. Im Xnet geht das in der
AUTOEXEC.NET mit "ro fl pa ssid 15".
Was ich noch recht bedenklich finde, ist die Nutzung von INP3-Links via
L2-Hops über Flexnetknoten. Das funktioniert zwar, aber das Kosten/Nutzen-
Verhältnis passt glaube ich nicht so ganz. Erst recht nicht, wenn das
Wormholenetz über die Flexdigis übertragen wird.
Letztens hab ich noch ein schönes Beispiel entdeckt:
=>u db0lbg
p user via lst srv lst p to
23:DB0LBG-7 DB0AMB <-> flx <-> 6:DB0KH
=>d db0lbg-7
*** DB0LBG (0-15) T=99
=>
*** route: DB0VOX db0amb-5 DB0AMB DB0HBG DB0GAP DB0LAI DB0HER DB0SAO DB0LEL
DB0BAC DB0LX DB0LBG-7
=>d db0kh
*** DB0KH (0-0) T=87
=>
*** route: DB0VOX DB0THA DB0INS DB0ERF DB0BRO-1 DB0HSK DB0HUN DB0GIS DB0MDX
DB0KH
Will heißen, dass man nicht wirklich über solch einen Pfad INP3-Routing machen
will ?? Achja, das Call LBG wird auch ins Flexnetnetz announced. Ok, ich darf
nicht meckern, wir machen das mit IGATE ja auch HI. Man könnte ja jetzt in die
Versuchung kommen, den INP3-Link via IGATE zu machen :)) Naja, warum auch
nicht.
DB0VOX hat übrigens endlich wieder alle Links aktiv. Zu DB0THA muss zwar noch
etwas geschraubt werden, aber das schaut schon gut aus:
Link to dst Q/T rtt tx connect tx rx txq/rxq rr+% bit/s
1:DB0ANU 1 I 3 4/1 0 3d 07h 2.2M 592K 100/100 2.4 80
18:DB0FHN 3 I 1 1/0 0 10d 21h 9.0M 2.7M 100/100 0.4 101
1:DB0ANU 1 F 4 1/6 0 3d 07h 2.2M 592K 100/100 2.4 80
4:DB0ZB 152 F 2 2/2 0 3d 07h 1.3M 8.7M 100/100 0.8 281
6:DB0THA 305 F 9 12/5 0 23h 03m 494K 725K 38/100 40.3 118
18:DB0FHN 6 F 1 0/1 0 10d 21h 9.0M 2.7M 100/100 0.4 101
19:DB0FOR 21 F 1 1/1 0 10d 21h 5.7M 31M 100/100 0.4 319
23:DB0AMB 93 F 5 5/4 0 23h 18m 604K 1.1M 100/100 0.3 167
DB0THA ist ein RMNC, der mit DB0THA-6 per KISS verbunden ist. Da könnte ich
mir auch vorstellen, DB0THA-6 per INP3 via DB0THA zu verbinden. Allerdings
macht DB0THA-6 noch INP3-Wormhole via DB0INS nach DB0ERF. Wozu ?
Wenn ich gerade schon bei so einer langen Mail bin, kann ich gleich noch Thema
DB0HP ansprechen. Ich denke das "Lastrouting" bei DB0HP (siehe "L" auf DB0HP)
und die erhoffte Wirkunsweise (Leute sollen Links bauen), ist nicht mehr
angebracht. Solche Methoden sind einfach nicht mehr angebracht, da viel eher
Internetlinks geschalten werden, als dann RF-Links gebaut werden. Vielleicht
kann man da nochmal drüber nachdenken oder meinetwegen die Hardcorevariante
mit Flexlinks via DB0HP wählen. Die Linkparameter "!" bei DB0SPC sind mir
auch nicht ganz klar?
Ihr seht also schon, dass neben den ganzen Internetlinks auch viele Probleme
hausgemacht sind (Meinungsverschiedenheiten usw.). Das fängt beim Routing-
protokoll an und geht bis zu Linkparameter auf RF-Links (wobei die eher zu
Internetpartnern angesagt wären).
Dann hab ich noch gelesen, dass international INP3 weiter verbreitet sei als
Flexnet. Ich hab da mal recherchiert HI:
Wir haben weltweit wohl etwa 900 Nodes und etwa 1200 Destinations. Von den
900 Nodes kannst du nochmal eine ganze Menge abziehen, da für jeden Service
ein weitere Node gebroadcasted wird. Bei Flexnet gibts das zwar auch, aber
viel weniger. Klar, international magst du Recht haben (G, M, PY, VE, VK, W,
ZL), aber hast du mal die Funklinks gezählt ???
Ich kann nur weiterhin behaupten, dass volles Routing zwischen Internet und
Funknetzen die Aktivität/Interesse sinken lässt. Ich beschränke mich
allerdings mit meinen Aktivitäten auf Flexnet (IGATE) und werde sicherlich
keine Zeit investieren im INP3-Sektor auch noch eine Trennung zu bekommen.
Ich denke mit IGATE haben wir bzgl. Attraktivität einen neuen RF-Link zu bauen
sehr gute Karten. Internet kann genutzt werden, aber ein neuer RF-Link
(auch wenn es nur 1k2 ist) kann das Netz verbessern. Der Sysop sieht das
Ergebnis seiner Arbeit anhand der Connections auf dem Link. Wer baut schon
einen Funklink, wenn keine Connects drüber laufen??? Für den Sysop ist es doch
genau das Erfolgserlebnis, wenn Nutzdaten über einen Link fließen. Wenn ich am
Wormholenetz mit 1k2 anlinke, dann macht das (abgesehen von der Belastung
durch das Routingprotokoll) weit weniger Spaß, als wenn ich z.B. in OE wieder
zwei Subnetze (zwar via IGATE verbunden, aber nicht mit vollem Routing) wieder
miteinander verbinde.
Oft höre ich auch, dass Sysops wegen Verhalten/Äusserungen von Usern keine
Lust mehr haben, was zu tun. Wir bauen die Netze aus, weil wir daran Spaß
haben. Es ist ein gewisser Reiz die Linkzeiten in der Destinationtable über
Funk sinken zu lassen. Es ist nett auch viel Nutzdaten über Funk zu sehen
oder auch mal das ein oder andere Kompliment von Usern zu bekommen. Viele
fragen sich, was PR heute neben dem Internet noch bietet. Ich glaube die
mobile Verfügbarkeit von Convers, Chat, Email, BBS, ICQ usw. macht es doch
noch zu einem Erlebnis. Diese kleinen Anwendungen, die nicht wirklich Band-
breite braucht, macht es auch für den User weiter interessant. Wer braucht
schon die Bandbreite, um eine E-Mail zu lesen? Problematisch ist wohl bzgl.
meinem Knoten DB0FHN die Dokumentation. Alle Informationen sind lediglich als
plain Text verfügbar und nicht als "Klicki-Bunti". Mangels Zeit wird sich das
so schnell auch nicht ändern (außer es finden sich Leute, die das machen).
Aber zu behaupten PR wäre wegen Internet uninteressant geworden kann ich
nicht bestätigen. Viele User von DB0FHN sicher auch nicht. Es fehlt nur die
richtige Werbung für das heutige Schnell-Klick-Zeitalter :))
Da fällt mit gerade noch ein, dass letztens mal wieder ein Posting zum
Amateurfunk als Notfunk kam. Auch das ist noch interessant behaupten zu
können, dass das Netz ohne Internet funktioniert.
Würden wir alles einfach quer über das Internet vernetzen wäre im Krisenfall
wohl die Stabilität nicht gewährleistet, da wir gar nicht wüßten was alles
durch Inet-Links zusammengehalten wird und welche Inseln entstehen würden.
An manchen Stellen ist PR sogar schneller als das Internet :) Da jetzt endlich
der Umbau an DB0VOX fertig ist (siehe Links weiter oben) und auch die Links
an DB0FHN alle OK sind, können wir weiterbauen, um das Breitbandbackbone
weiter auszubauen. Der Link DB0VOX (FMT Nürnberg) <-> DB0AMB (FMT Nennslingen)
funktioniert schon mit 5 Mbit/s. Jetzt folgen Tests das ganze unter Linux
laufen zu lassen.
Dann wird ein FMT nähe Augsburg angebunden und von dort geht es weiter
zum Olympiaturm nach München. Ebenso der Link von DB0VOX nach DB0ZB
(95km) oder nach DB0THA (150km) könnte auf 5 MBit/s umgestellt werden.
Nahezu alle der genannten Standorte haben AUCH Internet parallel zur
Verfügung, aber trotzdem ist es einfach genial solch ein Netz unabhängig zu
bauen. Wir hoffen auch bald IRLP oder Echolink auf den RF-links laufen lassen
zu können ;)
Soweit meine Monstermail :)
73
Jann
Read previous mail | Read next mail
| |