Switch immer DHCP? oder immer NAT?

[mkScheller]

Moin Leude,

vor kurzem führte ich ne Diskussion mit nem Kollegen, in der ich behauptete, dass ein Switch immer DHCP kann. Anscheinend irrte ich mich. Allerdings ist mir das nicht schlüssig, denn zuhause haben wir auch einen Switch mit 8 Ports, aber wenn der kein DHCP kann, wie funktioniert denn NAT ??

Gelegentlich kommen drei Leute gleichzeitig über den Switch ins Netz, manchmal gibt es aber "Keine oder unzureichende Verbindung". Also gibts doch nen Adress- oder vielmehr Port-Konflikt ??

Gruss

[axxis]

Ein Switch kann auch einen DHCP-Server integriert haben, in größeren Layer3-Switchen ist das mittlerweile keine Seltenheit. Aber das ein Switch immer einen DHCP-Server an Board hat ist schlicht und einfach falsch!

Ein Switch macht auch kein NAT, dass macht ein Router. Ich denke du verwechselst hier etwas.

P.S.: "Port-Konflikt" stell ich mir lustig vor, drei Leute stehen mit ihren Netzwerk-Kabeln vorm Switch und kloppen sich um nen freien Port :cool:

Bearbeitet 16. August 2011 von axxis

[DocInfra]

Zeig mit bitte einen Switch (kein Kombi-DSL-Router-Switch-TK-Anlagen-Teil), der einen DHCP integriert hat. Ich kenne keinen. In der Regel können Switches mit Layer 3/4 Funktionalitäten als DHCP Relay agieren, aber nicht als DHCP.

Ein Switch kann i.d.R. weder DHCP, noch NAT. Wenn du von einem Kombigerät, z.B. einer Fritz! Box, ausgehst, dann ist es der Router in dem Gerät, der als DHCP und Router fungiert. Und ein Router kann nun mal auch NAT.

[axxis]

fyi: XSM7224S

Gibt auch ältere Modelle, die DHCP-Server spielen können.

[DocInfra]

Interessant. Na ja, mit dem Kinderspielzeug von Netgear hab ich wenig zu tun. Zudem fällt mir kein Grund ein, warum ich einen Switch DHCP spielen lassen sollte.

[mkScheller]

Okay, das heisst also, dieser Switch macht nix weiter als das was ein Hub macht, oder?

[flashpixx]

Okay, das heisst also, dieser Switch macht nix weiter als das was ein Hub macht, oder?

Nein, ein Hub ist salopp gesagt ein elektrischer Verteiler, der das ankommende Signal entsprechend entgegen nimmt und auf allen anderen Port wieder raus schiebt. Ein Switch hat eine intelligente Logik drin und stellt dedizierte Verbindungen zwischen den Endpunkten her.

Hub (Netzwerk)

Switch (Computertechnik)

[mkScheller]

okay, NAT bedingt aber DHCP, nicht?

[flashpixx]

okay, NAT bedingt aber DHCP, nicht?

Du möchtest dringend lernen Wikipedia zu benutzen:

Dynamic Host Configuration Protocol

Network Address Translation

[axxis]

Zudem fällt mir kein Grund ein, warum ich einen Switch DHCP spielen lassen sollte.

Jedenfalls kein vernünftiger in der Theorie. In der Praxis habe ich mal mit dem Gedanken gespielt, um ein paar Firewall-Lizenzen einzusparen, das Setting wäre aber viel zu krank geworden, daher wars schnell wieder verworfen.

@TE: Bitte nehme flashpixx' Hinweis wahr! Danach ist man bei offenen Fragen auch gerne bereit zu helfen.

[dgr243]

fyi: XSM7224S

Gibt auch ältere Modelle, die DHCP-Server spielen können.

Das vond ir erwähnte Gerät kann zwar laut Datenblatt DHCP. ABER nur dann, wenn du per Zusatzlizenz die Layer Features freischaltest. Damit machst du den Switch aber zum Router (oder vermutlich eher Layer 3 Switch) und es ist eben kein Layer 2 Switch mehr.

Von daher bleibt die Aussage, dass kein Switch (klassisch == Layer 2 ONLY) DHCP können KANN, weil eben IP Zuordnung nicht Layer 2 ist.

Interessant. Na ja, mit dem Kinderspielzeug von Netgear hab ich wenig zu tun.

Kinderspielzeug würde ich nicht unbedingt sagen. Du solltest hier dringend zwischen der Consumer Linie und den Business Produkten unterscheiden. Du steckst ja auch Linksys und Cisco nicht in eine Kategorie

Zudem fällt mir kein Grund ein, warum ich einen Switch DHCP spielen lassen sollte.

Für einen Layer 3 Switch fallen mir diverse Gründe ein

@TE: Du solltest dich dringend mit den Grundlagen der Netzwerktechnik auseinandersetzen. Du würfelst hier diverse Themen die rein gar nichts miteinander zu tun haben zusammen. Das dabei Kauderwelsch rauskommt ist klar. Fang klein an und arbeite dich dann an komplexere Themen heran

[DocInfra]

Kinderspielzeug würde ich nicht unbedingt sagen. Du solltest hier dringend zwischen der Consumer Linie und den Business Produkten unterscheiden. Du steckst ja auch Linksys und Cisco nicht in eine Kategorie

Linksys ist nicht Ciscos Consumer Line. Und das Ding richtet sich auch nicht an Consumer.

Für einen Layer 3 Switch fallen mir diverse Gründe ein

Die wären? Klingt für mich eher nach einer hässlichen Bastelei. Routing ist ja okay, aber spätestens bei ACLs auf einem Layer-3 Switch sollte ich mir Gedanken über mein Netzdesign machen. Und aus Management- und Interoperabilitätsgründen würde ich einen DHCP NIE durch eine aktive Netzwerkkomponente (Switch, Router, Firewall etc.) machen lassen.

[dgr243]

Und was genau ist ein Server?

Auch nur eine Netzkomponente..

Ich weiß nicht, was für LANs du betreust, aber bei mir sind genügend reine Client Netze, an denen keine Server stehen, die eben ausser Standortanbindungsrouter bzw. Switch dahinter keine Systeme haben, die DHCP spielen können. DHCP Relay auf ein zentrales System mag toll sein, nützt dir aber nix, wenn die Leute dann nicht mal mehr lokal Drucken können, wenn die Standortanbindung ausfällt.

ACLs auf einem Layer 3 Gerät machen dir sorgen im Netzdesign? Why? Quellnahes filtering empfinde ich immer noch sinniger als unerwünschten traffic quer durchs Netz zu transportieren. In einem LAN mit nahezu unbegrenzter Bandbreite mag das keinerlei Impikationen aufwerfen, aber spätestens wenn du anfängst nationale Netze zu betrachetn (hallo: 802.1x mit voller nationaler User Mobility inkl. Mitnahme der lokalen VLAN Konfiguration) nützt dir das nix mehr, wenn du erstmal allen Traffic einer zentralen Entscheidungsinstanz zuführst. Da machts viel mehr Sinn das Ganze gleich quellnah zu blocken.

Ist hier aber auch gar nicht Thema

[Eleu]

Von daher bleibt die Aussage, dass kein Switch (klassisch == Layer 2 ONLY) DHCP können KANN, weil eben IP Zuordnung nicht Layer 2 ist.

Hallo,

IP ist zwar layer 3, ich habe aber immer gedacht, dass DHCP prinzipiell nur in einem Subnetz funktioniert.

Oder anders gesagt, der Server der DHCP liefert, kann nur Clients mit IP Adressen versorgen, die im gleichen Subnetz liegen.

Will man auch Clients in einem anderen Subnetz über den gleichen DHCP Server versorgen benötigt man doch ein DHCP Relay.

Das DHCP Relay wäre dann ein Stück Software auf einem Router zum anderen Subnetz.

Ohne DHCP Relay funktioniert es nur auf layer 2.

Oder habe ich da einen Denkfehler ?

Gruß

Eleu

[DocInfra]

Und was genau ist ein Server?

Auch nur eine Netzkomponente..

Na ich denke über die Definition brauchen wir nicht streiten. Ein Server ist keine aktive Netzwerkkomponente.

Ich weiß nicht, was für LANs du betreust, aber bei mir sind genügend reine Client Netze, an denen keine Server stehen, die eben ausser Standortanbindungsrouter bzw. Switch dahinter keine Systeme haben, die DHCP spielen können. DHCP Relay auf ein zentrales System mag toll sein, nützt dir aber nix, wenn die Leute dann nicht mal mehr lokal Drucken können, wenn die Standortanbindung ausfällt.

Standortverbindungen sind redundant oder es gibt Standortserver, die vor Ort Dienste wie lokales Spoolen, Domain-Controller, DNS und eben auch DHCP übernehmen.

ACLs auf einem Layer 3 Gerät machen dir sorgen im Netzdesign? Why? Quellnahes filtering empfinde ich immer noch sinniger als unerwünschten traffic quer durchs Netz zu transportieren. In einem LAN mit nahezu unbegrenzter Bandbreite mag das keinerlei Impikationen aufwerfen, aber spätestens wenn du anfängst nationale Netze zu betrachetn (hallo: 802.1x mit voller nationaler User Mobility inkl. Mitnahme der lokalen VLAN Konfiguration) nützt dir das nix mehr, wenn du erstmal allen Traffic einer zentralen Entscheidungsinstanz zuführst. Da machts viel mehr Sinn das Ganze gleich quellnah zu blocken.

Durchaus ein Punkt, gebe ich dir Recht. Aber es ist nun mal eine Sache des Netzwerkdesigns diesen Verkehr zu vermeiden. Und wenn User VLANs mitnehmen, sehe ich keinen Grund Verkehr zu filtern. Verkehr fange ich erst dann zu filtern, wenn ich Netze, z.B. VLANs über einen Router verbinde, die eigentlich nichts miteinander zu tun haben sollten. Da muss ich mich fragen: Muss das sein? Netze die keinen Kontakt zueinander haben sollten, sollten über Firewalls getrennt sein. Aber ich gebe dir Recht, dass solche Lösungen nicht immer möglich sind.

[Crash2001]

@eleu:

Naja, "im gleichen Subnetz liegen" ist leicht verwirrend, da die Clients ja erst vom DHCP-Server die entsprechende IP-Adresse bekommen. Sagen wir lieber Netzsegment.

Ansonsten ist es aber soweit richtig.

Dadurch dass ein Broadcast (der DHCP-Request) nicht in ein anderes Netzsegment springen kann, außer es sind IP Helper bzw ein DHCP-Relay vorhanden, ist das halt immer auf ein Subnetz limitiert.

Na ich denke über die Definition brauchen wir nicht streiten. Ein Server ist keine aktive Netzwerkkomponente.

Nicht? Sagt wer? Ein Server KANN durchaus eine aktive Netzwerkkomponente sein. Z.B. sobald er routet oder DNS spielt.

[Eleu]

Dadurch dass ein Broadcast (der DHCP-Request) nicht in ein anderes Netzsegment springen kann, außer es sind IP Helper bzw ein DHCP-Relay vorhanden, ist das halt immer auf ein Subnetz limitiert.

Stimmt es, dass es pro LAN Infrastruktur nur einen DHCP Server (Rechner) geben sollte ?

Andernfalls stell ich mir vor, dass vielleicht zufällig zwei host die gleiche IP bekommen könnten.

Wenn aber nur ein DHCP Server verwendet werden soll / darf, könnte es dann bei Routerausfall Probleme geben, weil das DHCP Relay dann nicht mehr funktioniert ?

Werden die IP Adressen vom DHCP Server zyklisch akualisiert, oder nur einmalig beim Client -Rechnerstart ?

Wenn zyklisch, könnten doch theoretisch IP Adressen mehrfach vergeben sein, wenn der Router wieder in Betrieb genommen wird.

[lilith2k3]

Moin Leude,

vor kurzem führte ich ne Diskussion mit nem Kollegen, in der ich behauptete, dass ein Switch immer DHCP kann. Anscheinend irrte ich mich. Allerdings ist mir das nicht schlüssig, denn zuhause haben wir auch einen Switch mit 8 Ports, aber wenn der kein DHCP kann, wie funktioniert denn NAT ??

Gelegentlich kommen drei Leute gleichzeitig über den Switch ins Netz, manchmal gibt es aber "Keine oder unzureichende Verbindung". Also gibts doch nen Adress- oder vielmehr Port-Konflikt ??

Gruss

Kompletter Käse!

Einleuchtend wird es, wenn Du Dir die OSI-Schichten vor Augen hälst, in denen sich die Funktionalitäten abspielen:

1) Hub := Physical Layer

2) Switch := Link Layer manchmal auch Link Layer und Network Layer

3) DHCP := Applictaion Layer Protokoll und setzt auf einem funktionierenden Netzwerk Stack auf

4) NAT := Network Layer

also 4 Sachen auf 4 Layern.

Bestimmt gibt es Kombi-Geräte, die einige Sachen aggregiert zur Verfügung stellen - Es ist aber unsinnig anzunehmen, dass alle Geräte das könnten.

Es ergibt überhaupt keinen Sinn eine Aussage zu formulieren wie "ein Switch kann DHCP".

Die DHCP-Funktion hat nichts mit der Switching-Funktion zu tun.

Es sei den man meint mit "Switch" das "Gerät".

Bearbeitet 17. August 2011 von lilith2k3

[axxis]

@Eleu:

Kommt auf den Anwendungsfall an, ich habe noch keine "größeren" LANs gesehen, vielleicht kann hier der ein oder andere mehr zu sagen, würde mich auch interessieren. Per Protokoll ist es so, dass du ein DHCP-Offer von dem Server erhältst, den du am "schnellsten" erreichst.

Wenn du mit DHCP-Relays arbeitest und der Router die Grätsche macht (und du keine Redundanz dahingehen hast), dann werden eben keine DHCP-Request mehr beantwortet, hier greift dann Zeroconf.

Wenn du dynamisch IPs vergibst, dann kommt bei jeder Zuweisung eine Lease-Time mit, die dir Auskunft darüber gibt, wie lange diese IP-Adresse für dich gültig ist. Wenn der DHCP-Server (oder Router mit Relay) ausfällt, ist die Lease-Time imho obsolet und der Client kann die Adresse einfach weiterverwenden.

Wie es dann aussieht, wenn der DHCP-Server wieder erreichbar ist, weiß ich auch nicht, vermutlich könnte es dann zu IP-Adress-Konflikten kommen.

[Eye-Q]

Stimmt es, dass es pro LAN Infrastruktur nur einen DHCP Server (Rechner) geben sollte ?

Andernfalls stell ich mir vor, dass vielleicht zufällig zwei host die gleiche IP bekommen könnten.

Man kann auch zwei DHCP-Server im selben Netz haben, die dürfen dann aber nicht die selben IP-Adressen verteilen (Beispiel: einer verteilt von der 192.168.0.50 bis zur .150, der zweite von der .151 bis zur .250). Wenn dann ein DHCP-Server ausfällt, ist das nicht so schlimm, da der zweite dann ja immer noch Adressen verteilt. Außerdem verwenden die Clients ihre IP-Adressen bis zum Ablauf der Leasezeit weiter, ohne dass der DHCP-Server zwingend eine Bestätigung senden muss.

Werden die IP Adressen vom DHCP Server zyklisch akualisiert, oder nur einmalig beim Client -Rechnerstart ?

Dynamic Host Configuration Protocol

[Crash2001]

Also in größeren Umgebungen hat man zwar meist mehrere DHCP-Server - jedoch nur EINEN davon aktiv (also nur dieser vergibt IP-Adressen). Der andere ist inaktiv und wird (entweder automatisch oder von Hand) aktiviert, wenn der andere ausfällt/abgeschaltet wird.

Leases verfallen nicht einfach so. Im Normalfall ist es so, dass die Leases ständig auch auf dem Backup-DHCP-Server repliziert werden.

Übernimmt dieser, kennt er also die Leases und handhabt sie genau wie der andere DHCP-Server auch weiter.

So wird z.B. nach der Hälfte (?) der Lease Time eine Refresh-Anfrage vom CLient an den Server geschickt, wodurch die Lease-Zeit wieder ihre normale Zeitspanne hat. Ansonsten würde ja die MAC-IP-Zuordnung nach Auslaufen der Lease-Zeit verfallen und die IP-Adresse würde wieder dem Pool freier IP-Adressen hinzugefügt - egal, ob das Gerät nun noch immer im Netzwerk ist, oder ob nicht.

Es gibt diverse dieser Mechanismen. Wenn du dir bei Wikipedia z.B. den Artikel über DHCP (und die direkt verlinkten Beiträge auch noch) anschaust, dann findest du dort einige Informationen darüber.

Alternativ zu einem aktiven und einem inaktiven Server kann man natürlich auch einfach mehrere Server im gleichen Segment haben, die IP-Adressen aus unterschiedlichen Ranges vergeben. Ob das Sinn macht, ist eine andere Sache...

[edit]

Oooh, da war wer schneller als ich.

[/edit]

[DocInfra]

Nicht? Sagt wer? Ein Server KANN durchaus eine aktive Netzwerkkomponente sein. Z.B. sobald er routet oder DNS spielt.

Jaaa, jetzt fällt mir der feine Herr auch noch in den Rücken. *rolleyes* Bei Routing bin ich bei dir, bei DNS aber nicht. Ab er gut, lassen wir das Thema hier. )

Wegen DHCP. Man kann auch mehrere haben, man kann z.B. den Scope teilen. DHCP Server lassen sich aber auch relativ problemlos clustern oder anderweitig hochverfügbar machen.

[Crash2001]

Sorry, aber das konnte ich nun mal nicht so stehen lassen.

Ein Rechner ist laut Definition eigentlich schon eine aktive Netzwerkkomponente, sobald er eine Netzwerk- oder ISDN-Karte drin hat.

[...]

Als passive Netzwerkkomponenten wird das Material bezeichnet, das ohne jegliche Stromversorgung auskommt. Dazu zählen insbesondere: Leitungen, Kabel und Patchkabel, Anschlussdosen, Stecker und Buchsen. Baugruppen, die lediglich passive Bauelemente enthalten (also Widerstände, Kondensatoren usw.) wie z. B. die DSL-Splitter, werden meistens auch dieser Gruppe hinzugerechnet.

Aktive Netzwerkkomponenten sind alle Geräte, die aktiv Signale verarbeiten bzw. verstärken können. Sie benötigen dazu eine Stromversorgung. Zu dieser Gruppe gehören Hubs und Switches, Router, Bridges und Hardware-Firewalls. Ein Bestandteil eines Computers kann ebenfalls eine Netzwerkkomponente sein, z. B. Netzwerkkarte und ISDN-Karte.

[...]

Quelle

[dgr243]

IP ist zwar layer 3, ich habe aber immer gedacht, dass DHCP prinzipiell nur in einem Subnetz funktioniert.

Oder anders gesagt, der Server der DHCP liefert, kann nur Clients mit IP Adressen versorgen, die im gleichen Subnetz liegen.

Subnetz ist dem Namen nach Layer 3. Was du meinst ist Broadcast Domäne und das ist Layer 2.

Das DHCP Relay wäre dann ein Stück Software auf einem Router zum anderen Subnetz.

Muss kein Router sein auf dem der Relay Agent läuft.

Technisch macht das Ding ja nix anderes als

- Warten auf DHCP Discover (Broadcast)

- DHCP Discover in einem Unicast an den konfigurierten DHCP Server schicken

- DHCP Offer Antwort vom DHCP an den anfragenden Client schicken

(Dazu natürlich noch ACKs und Co. die ich hier jetzt mal der Übersichtlichkeit halber ausgelassen hab)

Stimmt es, dass es pro LAN Infrastruktur nur einen DHCP Server (Rechner) geben sollte ?

Nein. es sollte aus Redundanzgründen immer n+1 DHCP Server geben. Dass das nicht immer umsetzbar ist ist dann wiederum meist eher eine finanzielle Problemstellung und keine technische.

Wenn aber nur ein DHCP Server verwendet werden soll / darf, könnte es dann bei Routerausfall Probleme geben, weil das DHCP Relay dann nicht mehr funktioniert ?

Wenn der Router (korrekter die Kiste wo der Relay Agent läuft) ausfällt funktioniert auch kein DHCP Relay mit n+1 DHCP Servern.

Wenn zyklisch, könnten doch theoretisch IP Adressen mehrfach vergeben sein, wenn der Router wieder in Betrieb genommen wird.

Dazu gibt es zum Beispiel Graceful Arp als Mechanik um zu vermeiden, dass ein Client eine vom DHCP offerierte IP verwendet, wenn diese bereits vergeben ist. Sollte in der Praxis aber bei sauber geplanten Netzen nur auftreten, wenn aus irgendwelchen Gründen die Lease Liste des DHCP Servers von den konkret am Client vorhandenen Leases abweicht.

Also in größeren Umgebungen hat man zwar meist mehrere DHCP-Server - jedoch nur EINEN davon aktiv (also nur dieser vergibt IP-Adressen). Der andere ist inaktiv und wird (entweder automatisch oder von Hand) aktiviert, wenn der andere ausfällt/abgeschaltet wird.

Das hängt wohl auch ein wenig von der Unternehmensphilosophie ab. Solang es rein um private IP Adressen gibt, halte ich Splitted Scopes für die bessere Variante, auch wenn man dadurch natürlich mehr IP adressen "verbrät" als man im Idealfall braucht. Ist bei privaten IPs ja aber kein Thema.

Im Normalfall ist es so, dass die Leases ständig auch auf dem Backup-DHCP-Server repliziert werden.

Nur bei einem clustered DHCP. Bei splitted Scopes weiss normal der eine nicht von dem anderen DHCP.

Alternativ zu einem aktiven und einem inaktiven Server kann man natürlich auch einfach mehrere Server im gleichen Segment haben, die IP-Adressen aus unterschiedlichen Ranges vergeben. Ob das Sinn macht, ist eine andere Sache...

Einfacher zu konfigurieren --> Weniger Konfig --> Weniger beteiligte Prozesse --> Geringeres Ausfallrisiko (eines einzelnen Nodes).

Solange IP changes kein Problem darstellen oder andere Gründe für den Einsatz eines Clustered DHCP sprechen, halte ich daher DHCP Server mit gesplitteten Scopes für die bessere Lösung.

[Crash2001]

Aktiv/Passiv ist ja nur, wenn der Backup-DHCP-Server den gleichen IP-Adress-Bereich bedient. Nur dann ist eine Replizierung der Leases auch sinnvoll.

Natürlich kann man in einem großen Netz in jedes Subnetz auch einen DHCP-Server stellen. Nur von der Administrierbarkeit ist das dann so eine Sache... x Maschinen, die konfiguriert und gewartet, sowie gesichert werden wollen gegenüber einem System, das nahezu ausfallsicher ist und man nur auf einer Instanz administrieren muss...

Klar fällt dann nur ein kleiner Teil aus, wenn einer dieser "Mini-DHCP-Server" ausfällt und nicht der gesamte Dienst. Dafür gibt es aber ja wiederum dann Redundancen oder Clustering, damit das nicht passiert.

Ich denke für beide Möglichkeiten gibt es Argumente und man muss halt jeweils abwägen, was man fährt.

Auch bedenken sollte man hierbei, dass DHCP- und DNS-Server oftmals in einem implementiert sind.

Geringeres Ausfallrisiko für das Gesamtnetz steht hier höherem administrativem Aufwand gegenüber.