Re: ISDND: Aufzucht und Hege

Bernd Walter wrote:
>
[...]
> >
> > Da muß ich zwei Fälle unterscheiden:
> > 1. Einrichtung des Zugriffs normaler User auf's große Netz.
> > Ist in Vorbereitung, aber momentan in der Warteschlange, bis ich
> > alles im Griff habe.
> > 2. Abholen von Daten 1x täglich von verschiedenen Meßstationen,
> > der Verbindungsaufbau kommt von hier. Daran sitze ich grade, und
> > da wirklich nur einmal am Tag gepollt wird, braucht der daemon nicht
> > ständig präsent zu sein. Am liebsten würde ich ihn via inetd starten.
> > Es kann allerdings sein, daß zu weit entfernten Stationen die Verbindung
> > über Provideranwahl durch eine Art VPN nötig wird.
> > Im ersten Fall hast Du natürlich recht, im zweiten nicht unbedingt.
>
> Mir ist immer noch nicht klar warum der isdnd nicht durchlaufen darf/soll.
>
> Warum willst du defaultrouten zu den Messstationen haben?
> Wenn die nur die Transfer-IP oder nur wenige andere haben dann route doch nur
> diese. Wenn es hier Kollisionen gibt ist das Design schlecht.
> Wir haben im Cosmo-Project selber ein kleines Internes Netz mit Waehlverbindungen
> laufen, das laeuft Problemlos und ohne irgendwelche Daemons abzuschiessen
> Interfaces runterzufahren oder irgendwelche Routen zu veraendern:
>

Der Hintergrund für diese Idee ist, das es sich sozusagen um Wander-
baustellen handelt. Das sind kleine Datenlogger, die für eine bestimmte Zeit
(bisher zwischen einer Woche und drei Monaten) aktiv sind und dann abgebaut
werden. Jeder Einsatzort hat eine eigene Telefonnummer. Und da ich es einfach
mag, wollte ich möglichst ein Setup für alle auftretenden Fälle haben, aber
hier sind statische Routen natürlich auch möglich und wahrscheinlich sinnvoller.

Ein zweiter Grund ist, das in der Probierphase, nachdem eine Verbindung
bereits beendet ist, ab und zu ohne erkennbaren Grund die Leitung aufgemacht
wird (Netscape Mailfenster, sonst nichts, Mailanfragen sind natürlich aus).
Das soll nicht unkontrolliert passieren.

> isp0: flags=2815<UP,DEBUG,POINTOPOINT,SIMPLEX,LINK1> mtu 1500
> inet 194.231.9.142 --> 194.231.9.129 netmask 0xffffffe0
> isp1: flags=2815<UP,DEBUG,POINTOPOINT,SIMPLEX,LINK1> mtu 1500
[...]
> 194.231.9.142 127.0.0.1 UGH 0 0 lo0
> 194.231.145.208/28 10.17.0.1 UGc 0 9027 isp1
> 224.0.0.5 127.0.0.1 UH 1 498836 lo0
> 224.0.0.6 127.0.0.1 UH 1 2 lo0
>
> Innerhalb des Cosmo-Prjects gibt es noch mehrere derartig aufgesetze
> Standorte.
> DNS laeuft vollstaendig intern obwohl wir alle intern andere Zonen benutzen.
> Bei Aufbau der Waehlverbindung, aus welchem Grund auch immer, wird sofort
> zwischen den Beteiligten System E-Mail ausgetauscht.
> Automatische Anwahl von nicht bidirektional angebundenen Systemen per
> Voicecall
> Und wie schon erwaeht laeuft das ganze ohne das jemand staendig hinterher-
> schaut.
> Das einzige wo es manchmal mangelt sind freie B-Kanaele :)
>
> >
> > Es geht mir logischerweise darum festzustellen, welcher Nutzer wieviele
> > Einheiten auf sein Konto bekommt, bei den Meßdaten ist das wurscht.
> > Komisch, das I4B solche Möglichkeit nicht bietet. Wie benutzt Du tcpdump denn
> > konkret?
>
> Ich benutze den DNS - aber der tcpdump waere von den Informationen aehnlich.
> Wenn bei mir das System irgendwohin eine Verbindung aufbaut und ich der Ansicht
> bin das haette jetzt absolut nicht passieren duerfen schaue ich halt im Log nach.
> Und bislang bin ich eigendlich in fast allen Faellen aleine durch das DNS-Log
> dahintergekommen.
> Du koenntest natuerlich die Client-IP fuer eine DNS-Anfrage auswerten und versuchen
> diese den Einheiten zeitlich zuzuordnen - wird aber wohl etwas Aufwand bedeuten.
>

Ich habe es grade wieder beobachtet, irgendein lokaler Prozeß wählt raus, d.h.
ich werde jetzt erstmal Bekanntschaft mit tcpdump machen, wenn ich den los bin
ist das Problem entschärft und der isdnd darf laufen, so lange er will.

Bis später,
Marc

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 16 Oct 1999 - 05:17:50 CEST