| |
DD9QP > XNET 11.01.05 20:03z 78 Lines 3275 Bytes #999 (999) @ DL
BID : B1FDB0RES07G
Read: GUEST
Subj: Re^3: re. INP-Problem
Path: SR1BSZ<ON0RET<DB0RES
Sent: 050111/1912z @:DB0RES.#NRW.DEU.EU [Rees JO31ES OP:DD9QP] obcm1.06b47 LT:9
From: DD9QP @ DB0RES.#NRW.DEU.EU (Egbert)
To: XNET @ DL
X-Info: Sent with login password
>From: DD4JY @ DB0EEO.#NRW.DEU.EU (Sebastian)
>To: XNET @ DL
>Hallo zusammen,
> ...
>- Die TNN-Programmierer bitten, den mist mit dem Routen vermischen
>rauszunehmen.
Zugegebenerweise hat mich TNN nie so recht interessiert. Ich war natuerlich
davon ausgegangen, dass man das Gaten von Flexnetknoten nach NetRom in der
Konfiguration an oder abschalten kann. Wenn das wirklich nicht einstellbar ist,
wieso kann man dann in den Nodeslisten eines TNN-Knoten fuer FlexNetDigis ein
passendes ALIAS finden? Z.B. KEV:DB0PKE ? Der TNN kann doch von selbst nicht
wissen, dass KEV fuer Kevelaer steht?!
>- Im XNET eine Gleichstellung der Protokolle Flexnet und INP3 programmieren.
hmm... TNN oder XNet - egal - die lieben Programmierer werden begeistert sein
und sich noch heute Nacht in die Arbeit stuerzen hi.
>...
>Problem bleibt natürlich das im TNN-Land dann keine Flexnetziele mehr sind.
>Aber im Flexnetland gibt es auch keine TNN Ziele. Wenn man ins TNN Land will
>muss man
>auch erst nen übergangspunkt connecten, das ist schon seit Jahren so. Warum
>also sollte es umgegekehrt anders sein ?!
Da koennte ich mit leben.
> ...
>Aber TNN Sysops von XNET zu überzeugen ist ein schweres Unterfangen, ich habe
>das hier in der Gegend schon des öftern versucht. Leider erfolglos...
>
>Oder hat jemand bessere Vorschläge ?!
Ja - bitte alle XNET-INP3 wieder einschalten und die Uebergaenge zu TNN-Knoten
nicht im INP3 routen sondern nur im Flexnet. Alles hatte zuvor hervorragend
funktioniert. Allerdings darf nicht ein einziger XNet Knoten in der Kette sein
INP3 ausschalten, dann geht es nicht mehr. Das ist offenbar gestern so gewesen
als zuerst DB0EA abgeschaltet hat. Prompt bekam DB0NOS Probleme, weil alles
"hinten herum" lief. Dann hat NOS auch weggeschaltet. Jetzt haben alle anderen
Probleme. Das wird in Kuerze besser werden, weil es dann ein Backup-Routing
fuer INP3 geben wird, das nicht ueber diesen langen Weg durchs Internet laeuft.
Der jetzige Zustand ist fuer die User unertraeglich. Ein simpler Connect ins
Ruhrgebiet ging vorher rasend schnell. Jetzt sieht das z.B. von DB0EEO aus so
aus:
=>no db0gos
routing Essen:DB0GOS v DB0RES
> DB0GOS DB0RES 201/6 14.65s 17 hops
=>
*** route: DB0EEO DB0RES DB0RES-10 ON0RET-10 ON6DP-1 ON6DP VE2PKT-3 VE3MCH-12
VE3MCH-3 VE3MCH-8 ? ? VE2HAR-6 VE3MCH-3* DG2SBV-10 DB0RES-10 DB0RES DB0EEO
=>
Ein C DB0GOS fuehrt jetzt ueber diesen unsinnigen Weg - und bleibt prompt
haengen! Gleiches z.B. fuer DB0FBB, DB0WAL, DB0HSK usw usw. Es geht fast KEIN
Connect mehr!
Abschalten des INP3-Routings hier bei DB0RES-10 nutzt garnix (hab es trotzdem
gestestet;), denn dann kommen die Nodes ueber DB0LJ rein, oder ueber PI1VRZ. Es
wird seit neuestem dann alles "hinten herum" via DB0ERF-13 ins INP3 Netz
gegated... und wenn die wegschalten wuerden, kommt es wieder woanders her.
Das Ausschalten bei EA und NOS hat also nicht den erhofften "alten Zustand"
wieder hergestellt, weil die Linksituation sich in der Zwischenzeit veraendert
hat.
So wie es jetzt ist, ist es das unertraeglich. Jetzt koennen die User hier noch
nicht einmal den kurzen Weg ins Ruhrgebiet oder nach Osten connecten (und
umgekehrt!).
73 de Egbert DD9QP
Read previous mail | Read next mail
| |