| |
DG8YGZ > XNET 11.01.05 14:12z 30 Lines 1406 Bytes #999 (0) @ DL
BID : B1FDB0BI_00X
Read: GUEST
Subj: re. INP-Problem
Path: SR1BSZ<ON0RET<DB0RES<DB0EA<DB0NOS<DB0BI
Sent: 050111/1358z @:DB0BI.#NRW.DEU.EU [Bielefeld JO42FA] obcm1.06b47
From: DG8YGZ @ DB0BI.#NRW.DEU.EU (Olaf)
To: XNET @ DL
X-Info: Sent with login password
Hallo Egbert,Markus und co
sobald ich aber bei DB0NOS das INP Richtung DB0EAM wieder anmache, werden
dort die "eingemappten" Ziele herkommen. Flexnet-Übergänge ala
DB0EAM- DB0BID/DB0NHM (beide z.Zt offline)
DB0EAM- DB0AX (aktiv)
DB0GOE- DB0SMG (relativ langsam, da grauts mir vor)
DB0HAN- DB0ABZ (gute Strecke; war lange Zeit das Tor nach draussen)
(in der TNN-Insel)
werden IMMER genau dieses Phänomen im Routing erzeugen, weil TNN nicht
zwischen Flexnet und INP unterscheidet und beides zusammenwirft. Es
gibt auch TNN-Digis die NICHT am Flexnet-Netz hängen, dorthin aber
trotzdem noch Routen möchten (z.B. DB0LIP/DB0VFK/DB0HOL/DB0NDH), dafür
macht TNN diesen Krams. Sobald ein Ziel einmal mit einem Alias im INP
bekannt geworden ist, hällt ihn TNN durch dieses Gateway "am Leben".
Ein Konfigurationsproblem bei TNN ist das also nicht. It's not a bug,
it's a feature ;))
Es bleibt nur Momentan die Möglichkeit TNN im INP zu isolieren, was aber
auch nicht die Feine Art ist. Alternativ könnten natürlich alle TNNs ihre
Flexnetgateways abschalten und damit mind. 30% der Ziele nicht erreichen,
bzw. sind dann im Flexnet-Land auch nicht bekannt. Ergo unakzeptabel.
Für Lösungsvorschläge bin ich durchaus Dankbar.
tüsskes und bye bye de Olaf dg8ygz@db0bi.#nrw.deu.eu
Read previous mail | Read next mail
| |