Redesign Netzwerk +DHCP +RODC +DNS ....

[zahni 554]

https://www.netmanias.com/en/post/techdocs/6000/dhcp-network-protocol/understanding-dhcp-relay-agents

 

DHCP  Relay-Pakete  können geroutet werden. Daher  muss der  Agent  einen DHCP-Server  kennen.

[Admini2017 0]

das ist mir schon klar. Also müsste es mit einem DHCP Relay Server an Standort B funktionieren. Die Clients würden ein DHCP-Discover per Broadcast starten und den Relay-Agent an Standort B finden. Dieser schickt die Anfrage per Unicast weiter an den DHCP Standort A. Die dazwischen liegenden Switche routen zwischen den Netzen, wodurch die Unicast Anfrage ohne Probleme geroutet werden sollte.

 

So würde ich mir das vorstellen:

 

 

bearbeitet 27. Februar 2018 von Admini2017

[magheinz 110]

vor 1 Stunde schrieb zahni:

https://www.netmanias.com/en/post/techdocs/6000/dhcp-network-protocol/understanding-dhcp-relay-agents

 

DHCP  Relay-Pakete  können geroutet werden. Daher  muss der  Agent  einen DHCP-Server  kennen.

jetzt wo du das schreibst. sie sind ja unicast.

 

Aber wozu sollte man dafür extra einen Server aufsetzen wenn das der Router auch kann?

Der MPLS-Router ist Relay-Agent für Standort A?

 

Deswegen nimmt man den router dafür. Für cisco ist das eine Zeile pro Subnetz.

bearbeitet 27. Februar 2018 von magheinz

[zahni 554]

vor einer Stunde schrieb Admini2017:

das ist mir schon klar. Also müsste es mit einem DHCP Relay Server an Standort B funktionieren. Die Clients würden ein DHCP-Discover per Broadcast starten und den Relay-Agent an Standort B finden. Dieser schickt die Anfrage per Unicast weiter an den DHCP Standort A. Die dazwischen liegenden Switche routen zwischen den Netzen, wodurch die Unicast Anfrage ohne Probleme geroutet werden sollte.

 

Nein, Standort A schickt Broadcasts an Relay Agent Standort A. Der Agent geht dann über  die Datenleitung.

Wer Relay-Agent macht? Fragen Sie Ihren Router. Früher konnte man einen Relay-Agenten auch auf einem Windows-Desktop laufen lassen.

Hat MS aber wohl wegrationalisiert, weil es niemand brauchte.

bearbeitet 27. Februar 2018 von zahni

[Admini2017 0]

Ich glaube die Zeichnung ist noch nicht deutlich genug :(. An Standort A steht der Einzige DHCP Server mit Bereichen für Subnetz A und B. Clients an Standort A benötigen doch keine Relay!? Die finden ihren DHCP doch direkt per Broadcast, steht schließlich im selben Netz. Clients an Standort B benötigen einen Relay, in diesem Falle entweder einen Server oder Router.

[zahni 554]

Sorry, jetzt habe ich was verwechselt. Standort B hat den Client und seinen Relay-Agenten. 

Alles gut und richtig.

[Admini2017 0]

Kein Problem, bin auch schon verwirrt. Aber bei meiner Konstellation wäre es doch so, dass ich die Router nicht anpacken müsste. Der Relay von Standort B schickt ja die Anfragen per unicast weiter. Oder irre ich mich?

 

PS: an den Außenstandorten steht immer mindestens ein Server. Somit wäre ich nicht von der Telekom abhängig, was den Relay betrifft. Falls mein Gedankenspiel funktioniert :)

bearbeitet 27. Februar 2018 von Admini2017

[zahni 554]

Und wer macht jetzt den Relay-Agent? Der Server?

[Admini2017 0]

Genau, ein Server an Standort B soll Relay für die Clients an Standort B werden. Meine Frage ist, ob die DHCP Anfragen (unicast) dann ohne weiteres durch mpls durchgeroutet werden. 

 

 

PS: der Server an Standort B soll keine IPs verteilen! Er ist NUR Relay

 

bearbeitet 27. Februar 2018 von Admini2017

[zahni 554]

Wenn ich das richtig lese: Port 67 und 68 UDP  https://www.juniper.net/documentation/en_US/junos/topics/concept/dhcp-extended-firewall-filter-overview.html

 

[MurdocX 950]

vor 16 Minuten schrieb Admini2017:

PS: der Server an Standort B soll keine IPs verteilen! Er ist NUR Relay

Ok und wo siehst du dann den Vorteil gegenüber vorher? Der Server wird dadurch nicht aufgelöst, laut deiner Beschreibung. Es kommt anscheinend auch noch einer hinzu. Der wegfallende Server wäre für mich der Benefit der Aktion dann gewesen. Aber so könnte er auch gleich die DHCP-Rolle behalten. So wird der administrative Aufwand auch noch erhöht. 

[Admini2017 0]

Bisher gibt es gar keinen DHCP, alle Adressen werden statisch vergeben. Und um den administrativen Aufwand gering zu halten, möchte ich nur einen DHCP und nicht einen an jedem Standort. 

 

Alternativ wäre es eine Überlegung die Server an den Außenliegenschaften als Standby DHCP Server zu betreiben falls MPLS wegfällt oder der Haupt DHCP Probleme hat.

bearbeitet 27. Februar 2018 von Admini2017

[MurdocX 950]

vor 1 Minute schrieb Admini2017:

Bisher gibt es gar keinen DHCP, alle Adressen werden statisch vergeben. Und um den administrativen Aufwand gering zu halten, möchte ich nur einen DHCP und nicht einen an jedem Standort.

Der administrative Aufwand eine DHCP-Servers kann m. M. n. vernachlässigt werden. Bei 2 statisch vergebenen IP-Adressen hast du den Aufwand wieder drin. Oder was wird in deinem Fall großes anfallen? Vielleicht können wir dort ansetzen.

[Admini2017 0]

Was wäre denn ihrer Meinung nach die beste Idee? Wir sprechen von 10 Standorten die alle per MPLS verbunden sind. Bisher werden IPs statisch vergeben, was wohl nicht zeitgemäß ist. In meiner Überlegung gibt es einen DHCP am Hauptstandort und Relays an den Außenliegenschaften. Ob man jetzt noch Failover Lösungen braucht ist erstmal kein Thema. Was ist an der Idee so verwerflich :(. Bin etwas verwirrt xD

[MurdocX 950]

vor 2 Minuten schrieb Admini2017:

Was ist an der Idee so verwerflich :(. Bin etwas verwirrt xD

An der Idee an sich ist nichts verwerflich. Du möchtest so professionell wie möglich machen, das verstehe ich. Wenn wir den lokalen DHCP und den DHCP-Relay gegenüberstellen und deine Anforderungen mit einspielen lassen, dann würde ich die lokale Variante wählen. Es spricht ja nichts diese in einer MMC zu verwalten, oder?