|
DD9QP > XNET 13.01.05 20:05z 124 Lines 3714 Bytes #999 (360) @ DL
BID : D1FDB0RES043
Read: GUEST
Subj: Re: Problem DB0II
Path: SR1BSZ<DB0TEM<DB0GR<DB0ERF<DB0FBB<DB0GOS<DB0ACC<DB0EA<DB0RES
Sent: 050113/1612z @:DB0RES.#NRW.DEU.EU [Rees JO31ES OP:DD9QP] obcm1.06b47 LT:3
From: DD9QP @ DB0RES.#NRW.DEU.EU (Egbert)
To: XNET @ DL
X-Info: Sent with login password
>From: DG8YGZ @ DB0EEO.#NRW.DEU.EU (Olaf)
>To: XNET @ DL
>Reply-To: DG8YGZ @ DB0BI.#NRW.DEU.EU
> ...
>Knoten wie DB0RHB, DB0BM,DB0SYS,DB0PKE sind nun
>über eine leider wacklige INP-Strecke gerouted.
>
>routing KEV:DB0PKE v PI1VRZ
>> DB0PKE PI1VRZ 176/6 22.15s 6 hops
>=>
>*** route: DB0EEO PI1VRZ PI1NOS PI1EHV DB0II* PI1EHV PI1NOS PI1VRZ DB0EEO
> ...
>Könnte bitte jemand so nett sein und das irgendwie unterbinden ?? von EEO
>gehts via DB0ME sicher schneller zu DB0BM.
Hallo Olaf,
Sebastian DD4JY und ich habe es unabhaengig voneinander heute morgen/mittag
untersucht. Folgendes hat DD4JY festgestellt:
"Stimmt ... das kann vorkommen, heute mittag siehts dagegen so aus:
routing KEV:DB0PKE v DB0RES
> DB0PKE DB0RES 122/6 40.25s 22 hops
=>
routing RHB:DB0RHB v DB0RES
> DB0RHB DB0RES 145/6 32.19s 19 hops
DB0RHB PI1VRZ 100/6 49.07s 14 hops
=>
*** route: DB0EEO DB0RES DB0RES-10 LX0IST-14 ON6DP VE3MCH-8 ? VE3MCH-8*
VE3MCH-3 DG2SBV-10 DB0RES-10 DB0RES DB0EEO
=>n db0sys
Node 'db0sys' unknown.
=>n db0bm
routing JULICH:DB0BM v DB0RES
> DB0BM DB0RES 139/6 34.24s 20 hops
=>
Super oder ? ... Jetzt kommt allerdings die Intelligenz von XNET zu tragen,
denn die Ziele werden ALLE via flexnet connectet:
=>c db0pke
link setup (5)...
>>> *** connected to DB0PKE
RMNC/FlexNet V3.3g Digipeater Kevelaer - JO31DO -
...
wie du siehst, gibt es keinerlei Probleme damit."
Ich kann das derzeit bestaetigen, auch wenn die scheinbaren Routen durchs
INP-Netz immer mal etwas variieren. Ich erziele mit einem simplen "C DIGINAME"
immer einen Flexnet-Connect:
DD9QP de DB0RES (17:04:44 MEZ) =>no db0ovn
routing OVN:DB0OVN v DB0RES-10
> DB0OVN DB0RES-10 110/6 44.97s 28 hops
DD9QP de DB0RES (17:04:54 MEZ) =>
*** route: DB0RES DB0RES-10 DO7VLR-4 LX0IST-14 ON6DP VE2PKT-3 VE3MCH-12
VE2RXY-8 VE8JL-3 ? ? N8DA-3* VE3MCH-3 VE3MCH-8 ON0PIH LX0IST-14 DB0RES-10
DB0RES
Sieht grausam aus! Aber:
DD9QP de DB0RES (17:04:54 MEZ) => c db0ovn
link setup (3)...
*** connected to DB0OVN
Digi Neuss JO31IF 438.525 MHz (-7.6 MHz) 9k6/14k4 DAMA-Duplex
m Mailbox i Informationen (20.12.00)
dlc DL-Convers ne Neuigkeiten (07.12.03)
wwc WW-Convers betr Betriebshinweise (20.12.00)
clx DX-Cluster tcpip Hinweise zu TCP/IP (05.08.02)
spend Spendenliste
Connected am 13.01.05 um 16:06:07 UTC via Port: Link db0ii
16:06:07 =>u
p user via lst srv lst p to
8:DB0OVN-5 DB0OVN <-> flx <-> 4:DB0II-1
8:DB0OVN-6 DB0OVN <-> flx <-> 4:DB0FHK-6
8:DB0OVN-6 DB0OVN <-> flx <-> 4:DB0GOS-6
8:DB0OVN-12 DB0OVN <-> flx <-> 4:DB0PRA-13
0:DJ5BH WAK con <-> 4:DB0GV
4:DB0LJ-9 DB0II <-> flx <-> 7:DB0OVN-8
7:DB0OVN-9 DB0OVN <-> flx <-> 4:DB0II
7:DB0OVN-10 DB0OVN <-> flx <-> 4:DB0II
0:DB5EB <-> flx DBS 7:DB0OVN-8
7:DB0OVN-8 DB0OVN <-> flx <-> 4:DB0II
4:DD9QP DB0RES <-> con
13.01.05 16:06:16 =>
Wie man sieht, ein Flexnet-Connect ueber den korrekten Weg (leider alles 9k6):
DD9QP de DB0RES (17:08:26 MEZ) =>d db0ovn
*** DB0OVN (0-15) T=48
DD9QP de DB0RES (17:08:45 MEZ) =>
*** route: DB0RES DB0PKE DB0II DB0OVN
Ich habe dieses Verhalten zur Zeit reproduzierbar getestet via EEO, RES und
EA.
Dennoch: Unproblematisch ist die ganze Geschichte nicht. Sei gewiss, dass wir
das hier auch staendig beobachten. Aber solange es funktioniert, gewinnen wir
Zeit und die brauchen wir, um mal in Ruhe an die Wurzel heranzugehen und eine
vernuenftige Loesung zu finden.
73s de Egbert DD9QP
Read previous mail | Read next mail
| |