Zwei Router hintereinander schalten

[tschloss]

+++ fullquoting entfernt +++
DIESER BEITRAG WURDE VON EINEM MODERATOR AUS DEM ZUSAMMENHANG GERISSEN - ER BEZIEHT SICH AUF DEN POST VON LOFGUARD 2 POSTS OBEN DRÜBER

Die .255 ist die sog. Broadcastadresse bei einem normalen C-Netz, das heißt ein Paket geht an alle Hosts in diesem Netz.

Thomas

 

[magheinz]

+++ fullquoting entfernt +++
+++ der zitierte Beitrag steht doch unmittelbar darüber +++
+++ http://learn.to/quote +++

Dank dem Entfernen des Zitats ist es leider etwas unklar worauf du geantwortet hast.

Nur der Vollständigkeit halber:
Heutzutage wird classless geroutet, das bedeutet dass es kein Class-C-Netz mehr gibt. Das Subnet wird nur noch durch die Netzwerk-ID, oder die Netzadresse und die Subnetmask beschrieben.
Bleistift:
Netzwerk-ID=10.43.8.67/28
Netzmaske=255.255.255.240
Adressbereich= 10.43.8.64–10.43.8.79
Somit sind 10.43.8.64 die Netzwerkadresse und 10.43.8.79 die Broadcastadresse. Es muss also nicht immer die 255 sein.
(Beispiel ist von Wikipedia geklaut)

 

[magheinz]

@magheinz
Da stelle ich ja prinzipiell gar nicht in Abrede. DHCP wurde aber ursprünglich nicht für solche Zwecke entwickelt und ist dafür nicht optimiert; das merkt man dem Protokoll eben an. "Früher" waren Clients halt einfach nur Clients und brauchten keine festen IP Adressen zu haben.

Eigentlich ist das genau das wofür es DHCP gibt. Die Automagische Verteilung der Netzwerkonfig. Das in meinem Beispiel halt eben nur 99% automatisch verteilt werden ist doch egal, oder? Ich meine, DNS, WINS, Gateway, ntp usw können ja immer noch per DHCP verteilt werden. Im Prinzip kann man auch noch die IP so verteilen. Bringt man dem DHCP-Server dann eine Tabelle MAC-Adresse<->IP bei, dann hat man sogar vollautomatische feste IPs. Genau dafür ist DHCP meines Wissens nach entwickelt worden, zur automatischen Verteilung der Netzwerkkonfig. Es war nie Pflicht ALLE möglichen Parameter per DHCP zu verteilen. Zumindest kann ich dass weder in rfc1531 noch in rfc1541 finden.

 

[maceis]

...
Bringt man dem DHCP-Server dann eine Tabelle MAC-Adresse<->IP bei, dann hat man sogar vollautomatische feste IPs.
...

Genau das war nach meinem Kenntnisstand lange Zeit eben nicht vorgesehen.

 

[sir.hacks.alot]

Aber inzwischen kann es doch jede halbwegs anständige DHCP Serverlösung.

 

[maceis]

Ich sag ja auch nicht, dass es grundsätzlich nicht geht. Ich sag nur, dass es nachträglich ins Protokoll eingebaut wurde und erfahrungsgemäß manchmal Probleme bereitet.

 

[magheinz]

Ich sag ja auch nicht, dass es grundsätzlich nicht geht. Ich sag nur, dass es nachträglich ins Protokoll eingebaut wurde und erfahrungsgemäß manchmal Probleme bereitet.

Das ist halt falsch. In das Protokoll musste dafür nichts eingebaut werden.
Das ging schon immer. Schliesslich ist es dem Protokoll egal was der client draus macht. Ich hab dir die RFCs genannt. Da steht nix von "client MUSS alle angebotenen Daten übernehmen".
Eigentlich dürfte das auch nirgends Probleme verursachen.
Das RFC schreibt folgenden Ablauf vor:
Client schickt an broadcast: "hilfe ich brauch ne netzkonfig"
server schickt an client "hier, nimm die"
client testet per arprequest ob ip schon vergeben. wenn nein dann gibts ein "ok, alles toll", wenn ja, dann gibts ein "misst das war wohl nix" an den server.
Du siehst, der Schutz vor doppelten IP-Adressen wird auf dem client geregelt. Dadurch kann man auch zwei DHCP parallel mit dem selben ip-Addressbereich fahren ohn edass es zu konflikten kommt. Wenn die natürlich unterschiedliche nameserver rund gateways und ntpserber usw verteilen dann sollte man dafür sorgen dass es auch die jeweiligen Maschinen gibt. Das ist aber kein Problem von DHCP, sondern nur eins von schlechter Administration.

 

[maceis]

Ja, ist genau genommen schon richtig, ass es nicht direkt ins Netzwerkprotokoll eingebaut wurde. Da habe ich mich nicht ganz sauber ausgedrückt.
Allerdings wird - wenn man schon so genau ist - der Schutz vor doppelten IP Adressen auch nicht auf dem Client allein geregelt sondern auf der Sicherungsschicht des Netzwerks mit dem (wie Du ja auch schreibst) ARP Protokoll. Ich hatte übrigens weiter oben schon geschrieben, dass zwei DHCP Server in einem netz an sich unproblematisch sind.

Was aber erst relativ spät eingeführt wurde (und zwar bei den Serverinmplementationen des DHCP), ist die von Dir erwähnte MAC <-> IP Zuordnungstabelle. Im engsten Sinne hat das nichts mit dem Protokoll an sich zu tun sondern ist eine Erweiterung desselben.

Früher war die Argumentation einfach die: "Ein Client hat keine Dienste bereitzustellen und braucht daher keine statische IP. Punkt". In Zeiten von Remote Management etc. hat sich das in vielen Umgebungen natürlich geändert.

 

[magheinz]

Ja, ist genau genommen schon richtig, ass es nicht direkt ins Netzwerkprotokoll eingebaut wurde. Da habe ich mich nicht ganz sauber ausgedrückt.
Allerdings wird - wenn man schon so genau ist - der Schutz vor doppelten IP Adressen auch nicht auf dem Client allein geregelt sondern auf der Sicherungsschicht des Netzwerks mit dem (wie Du ja auch schreibst) ARP Protokoll.

Ja und nein. Es wird natürlich durch ARP geregelt. Das diese Anfrage gemacht wird ist aber nunmal Bestandteil des DHCP-Verfahrens. Das DHCP-Protokoll sieht erst wenn diese Überprüfung erfolgreich war vor, das der Client sein ok gibt.

Ich hatte übrigens weiter oben schon geschrieben, dass zwei DHCP Server in einem netz an sich unproblematisch sind.

stimmt.

Was aber erst relativ spät eingeführt wurde (und zwar bei den Serverinmplementationen des DHCP), ist die von Dir erwähnte MAC <-> IP Zuordnungstabelle. Im engsten Sinne hat das nichts mit dem Protokoll an sich zu tun sondern ist eine Erweiterung desselben.

Ja, vor der Serverimplementierung gab es kein funktionierendes DHCP
In welcher Version die Tabelle jetzt dazu kam müsste ich auch nachschauen.

Früher war die Argumentation einfach die: "Ein Client hat keine Dienste bereitzustellen und braucht daher keine statische IP. Punkt". In Zeiten von Remote Management etc. hat sich das in vielen Umgebungen natürlich geändert.

full ACK

 

[magheinz]

hmm, hab grad noch mal nachgedacht (ja, manchmal tue ich das)

DHCP ist ja sowas wie ein Aufsatz auf bootp.
Die bootp-Server konnte aber eigentlich schon immer MAC-Adressen IPs feste zuordnen. Daraus sollte eigentlich folgen das diese Funktion schon von Anfang an in den DHCP-Server eingebaut war.

q.e.d.

 

[maceis]

...
Ja und nein. Es wird natürlich durch ARP geregelt. Das diese Anfrage gemacht wird ist aber nunmal Bestandteil des DHCP-Verfahrens. Das DHCP-Protokoll sieht erst wenn diese Überprüfung erfolgreich war vor, das der Client sein ok gibt.
...

Auch ja und nein (aber ganz klar mehr nein ). Die ARP Abfrage ist Bestandteil einer jeglichen IP Zuweisung. Wenn Du ganz ohne DHCP eine IP Adresse in den Netzwerkeinstellungen vergibst, wird die auch durchgeführt. Wenn die entsprechende IP Adresse im Netzwerk schon vergeben ist, erhältst Du unter Mac OS X z.B. eine entsprechende Warnmeldung und die Schnittstelle wird deaktiviert.

Das ist ARP - Sicherungsschicht, Layer 2. DHCP setzt höher auf und verlässt sich (wie alle anderen Protokolle) auf die Dienste der unteren Schichten ohne in diese einzugreifen. Das ist das Prinzip des ISO/OSI Modells.

Wenn wir wieder ganz genau sind, ist die ARP Geschichte gar nicht "Bestandteil des DHCP-Verfahrens".

 

[maceis]

...
DHCP ist ja sowas wie ein Aufsatz auf bootp.
Die bootp-Server konnte aber eigentlich schon immer MAC-Adressen IPs feste zuordnen. Daraus sollte eigentlich folgen das diese Funktion schon von Anfang an in den DHCP-Server eingebaut war.

q.e.d.

Nicht wirklich. Die fehlende Möglichkeit der dynamische Adress Allokation in BOOTP war mit einer der Gründe, die zur Entwicklung von DHCP geführt hatte. Es war den Netzwerkverwaltern zu dieser Zeit nämlich einfach zu mühsam in wechselnden Umgebung auf die Korrektheit der Gerätezuordnungstabellen zu achten. Dies fällt in die Zeit, als Computer langsam kleiner wurden und deshalb öfter von einem in ein anderes logisches Netz verbracht wurde. Häufig hieß das damals: Änderung von zwei BOOTP Server Konfigurationen". Die statische Adresszuordnung war ein Ärgernis. Nicht zuletzt deswegen wurde das D in dem Namen des neuen Protokolls aufgenomme.

Deswegen ist es ja aus meiner Sicht ein wenig widersprüchlich, dass man nun in DHCP etwas implementiert hat, was man eigentlich mal loswerden wollte. Ist aber natürlich historisch bedingt . Aber mit einer Sache hast Du trotzdem recht behalten. Das statische Mapping war bei DHCP von Anfang an möglich - wurde nur kaum verwendet, weil man ja gerade davon wegkommen wollte.