bolug bonner linux user group
news about wissen files archive hilfe suchen  

 

archive :: SchAN-User

druckfassung

SchAN-User

Re: [Schan-user] IP-Adressvergabe über 2 Netzwerkkarten an Arktur nach d

To: Schulen ans Netz - Anwender <schan-user@xxxxxxxxxxxxxxxxx>
Subject: Re: [Schan-user] IP-Adressvergabe über 2 Netzwerkkarten an Arktur nach dem Zufallfprinzip?
From: Martin Hülsmann <huelsmann@xxxxxxxxxxxxx>
Date: Wed, 23 May 2012 16:58:50 +0200
Hallo Helmut und Jürgen,

wenn es aber nun Probleme mit der Adressvergabe gibt und das Argument mit dem Datendurchsatz nur am Rande interessant ist, kann ich auch die 3er-Karte stilllegen und alle Adressen aus dem 192.168.16.0/20-er Netz nehmen. Für die fest installierten Rechner zwacke ich davon einfach einen Adressbereich ab.

Es kommen ohnehin noch eine Reihe netzwerkfähiger Geräte im Automatisierungslabor hinzu, die auch alle über eine eigene Adresse angesprochen werden wollen (ca. 70 Automatisierungsgeräte), und da wird mir der 3er Bereich dann doch zu eng.

Das mit den 2 Netzwerkkarten scheint mir doch eher bei physikalisch getrennten Netzen sinnvoll zu sein (was bei mir ja nicht der Fall ist, es läuft alles "über den gleichen Draht").

Es stellt sich jetzt noch die Frage, ob es (aus Vereinfachungsgründen) ausreicht, meine dhcp-MAC-Vergabe-Liste einfach anzupassen und anschließend aus der 3er-Karte den Stecker herauszuziehen. (dann brauche ich die Karte nicht zu deinstallieren, meine Fernwartung über 192.168.3.1 würde auch funktionieren, weil capella ja so herrlich routet).

Dann müssten die dhcp-Anfragen doch ausschließlich über die 16er Karte laufen?

Und der Aufwand für mich wäre halbwegs überschaubar, ich bräuchte nur 2-3 Dateien anzupassen (/etc/dnsmasq.d/dhcp.conf und die Dateien für die squid-Anmeldung, soweit sie über die IP-Adresse geregelt sind).

Am 23.05.2012 16:42, schrieb Helmut Hullen:
Hallo, Juergen,

Du meintest am 22.05.12:


             -192.168.3.1/24--
Capella----|                 |------LAN mit allen Rechnern
             -192.168.16.1/20-

d. h. die beiden "Subnetze" sind nicht physikalisch getrennt. Ich
wollte nur die Netzlast auf 2 Karten verteilen, die 3er-Karte
versorgt den Bestand an fest verkabelten Rechnern, die 16er Karte
eine Vielzahl an mobilen Geräten, etliche davon privat.
Der DHCP-Request des Client erreicht als Broadcast definitiv beide
Netzwerkkarten.


diese Konstruktion macht Dir möglicherweise mehr Ärger als Freude.

Das Bild ist etwas ungenau; das LAN besteht aus 2 Teilnetzen.

Hast Du messbare Indikatoren, die Dich davon abhalten, den
Datenverkehr über eine Netzwerkkarte abzuwickeln?

Datendurchsatz. Auch bei einer Gigabit-Karte ist der Durchsatz begrenzt;
über 2 Karten geht nun mal mehr als über eine.

Hinzu kam: das Netz 192.168.3.0/24 war schon fast voll mit den
schuleigenen Rechnern, "irgendwie" musste sowieso ein weiterer
Adressbereich freigeschaufelt werden. Und wenn an einer Berufsschule
auch private Smartphones sich einloggen dürfen, dann reicht ein weiterer
  x.y.z.0/24-Bereich nicht lange.

Erhoffter Zusatznutzen: einfache Steuerung z.B. von Berechtigungen, je
nach IP-Adresse. Aber da hakt es ja noch irgendwo.

und da sind ja noch andere Mechanismen im Spiel, z. B. die squid-Anmeldung und damit die Notwendigkeit, über einen Nutzeraccount zu verfügen.

Und da ich jetzt über eine professionelle W-LAN-Umgebung verfüge (deren Möglichkeiten ich noch gar nicht ganz durchschaue), ist meine frühere Idee, mit RADIUS zu arbeiten, auch noch nicht im Papierkorb gelandet. Ist nichts dringendes, möchte ich aber weiterverfolgen.

Viele Gruesse!
Helmut

_______________________________________________
schan-user mailing list
schan-user@xxxxxxxxxxxxxxxxx
http://www.heise.de/bin/newsletter/listinfo/schan-user

--
Viele Gruesse,

Martin Huelsmann

_______________________________________________
schan-user mailing list
schan-user@xxxxxxxxxxxxxxxxx
http://www.heise.de/bin/newsletter/listinfo/schan-user

 « Vorige im Thread  Dieser Thread  Nächste im Thread » 

 

seitenanfang


 

news about wissen files archive hilfe suchen  
kontakt letzte änderung: 23.05.2012