Re: ISDND: Aufzucht und Hege

On Fri, Oct 15, 1999 at 08:33:23AM +0200, Marc Santhoff wrote:
> Bernd Walter wrote:
> >
> > On Thu, Oct 14, 1999 at 05:45:06AM +0200, Marc Santhoff wrote:
> > > Bernd Walter wrote:
> [...]
> > > Ich will den isdnd nur zeitweise laufen haben. Nach etwas rumspielen
> > > und Dokulesen gehts mit dem ersten Befehl des up-skriptes und dem
> > > expliziten löschen der route. Welcher dämon sollte das denn sonst tun?
> > >
> > Die Route brauchst du nicht loeschen, da durch das Interface sowieso nichts
> > durchgeht wenns auf down ist.
> > Den isdnd solltest du laufen lassen.
> >
>
> 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:

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
        inet 10.17.0.2 --> 10.17.0.1 netmask 0xfffffffc
isp2: flags=2815<UP,DEBUG,POINTOPOINT,SIMPLEX,LINK1> mtu 1500
        inet 10.17.0.9 --> 10.17.0.10 netmask 0xfffffffc
isp3: flags=2815<UP,DEBUG,POINTOPOINT,SIMPLEX,LINK1> mtu 1500
        inet 10.17.0.13 --> 10.17.0.14 netmask 0xfffffffc
isp4: flags=2815<UP,DEBUG,POINTOPOINT,SIMPLEX,LINK1> mtu 1500
        inet 10.17.0.25 --> 10.17.0.26 netmask 0xfffffffc

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 194.231.9.129 UGc 2 118556 isp0
10.1.1/24 link#1 UC 0 0 de0
10.1.1.8 0:0:92:a7:13:40 UHLW 7 1668797 lo0
10.1.1.255 ff:ff:ff:ff:ff:ff UHLWb 0 1 de0
10.1.2/24 link#2 UC 0 0 de1
10.1.2.8 0:0:92:a7:13:41 UHLW 0 1 lo0
10.1.2.10 0:0:92:9b:76:1e UHLW 1 15116373 de1 593
10.1.2.255 ff:ff:ff:ff:ff:ff UHLWb 0 1 de1
10.1.3/24 link#5 UC 0 0 de4
10.1.3.3 0:0:c0:33:94:9f UHLW 0 104 de4 621
10.1.3.8 0:0:92:a7:12:88 UHLW 0 1 lo0
10.1.3.255 ff:ff:ff:ff:ff:ff UHLWb 0 1 de4
10.1.4/24 link#7 UC 0 0 de6
10.1.4.6 0:0:c0:27:94:9f UHLW 0 14573 de6 149
10.1.4.8 0:0:92:a7:12:8a UHLW 0 1 lo0
10.1.4.255 ff:ff:ff:ff:ff:ff UHLWb 0 1 de6
10.1.5/24 link#4 UC 0 0 de3
10.1.5.7 0:0:92:9b:20:e7 UHLW 1 11596364 de3 307
10.1.5.8 0:0:92:a7:13:43 UHLW 0 11 lo0
10.1.5.255 ff:ff:ff:ff:ff:ff UHLWb 0 1 de3
10.1.6/24 link#3 UC 0 0 de2
10.1.6.8 0:0:92:a7:13:42 UHLW 0 1 lo0
10.1.6.9 0:0:92:9b:31:51 UHLW 6 28455892 de2 45
10.1.6.255 ff:ff:ff:ff:ff:ff UHLWb 0 1 de2
10.1.7/24 link#6 UC 0 0 de5
10.1.7.8 0:0:92:a7:12:89 UHLW 0 1 lo0
10.1.7.11 0:0:d1:19:de:1f UHLW 1 34898 de5 1001
10.1.7.255 ff:ff:ff:ff:ff:ff UHLWb 0 1 de5
10.1.16/24 link#8 UC 0 0 de7
10.1.16.8 0:0:92:a7:12:8b UHLW 0 1 lo0
10.1.16.255 ff:ff:ff:ff:ff:ff UHLWb 0 1 de7
10.1.128/24 10.1.5.7 UGc 0 1790 de3
10.1.129/24 10.1.6.9 UGc 0 2 de2
10.2/16 10.17.0.26 UGc 0 0 isp4
10.5/16 10.17.0.14 UGc 0 0 isp3
10.17.0.1 10.17.0.2 UH 1 0 isp1
10.17.0.2 127.0.0.1 UGH 0 0 lo0
10.17.0.9 127.0.0.1 UGH 0 0 lo0
10.17.0.10 10.17.0.9 UH 0 0 isp2
10.17.0.13 127.0.0.1 UGH 0 0 lo0
10.17.0.14 10.17.0.13 UH 1 0 isp3
10.17.0.25 127.0.0.1 UGH 0 0 lo0
10.17.0.26 10.17.0.25 UH 1 0 isp4
127 127.0.0.1 URc 0 0 lo0
127.0.0.1 127.0.0.1 UH 7 208 lo0
194.231.9.129 194.231.9.142 UH 2 0 isp0
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.

-- 
B.Walter                  COSMO-Project              http://www.cosmo-project.de
ticso(at)cicely.de             Usergroup                info(at)cosmo-project.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message