none
DHCP in mehreren Standorten in dem selben L2 Netz mit mehreren Internet-Breakouts

    Frage

  • Hi,

    meine Anfrage ist mehr oder weniger schon so konkret, wie das Setup ist: Wir haben einen Kunden mit einem LAN-Link (Layer2 Verbindung zwischen zwei Standorten)

    Zur Einfachheit und Ausfallsicherheit würden wir gerne in jedem Standort einen (oder mehrere) Server stellen, die den DHCP-Dienst bereitsstellen. Soweit kein Problem, da die DHCP clustern könnten, klar. Die Netze sollen in beiden Standorten gleich sein, da wir Einheiten haben, die in beiden Standorten vertreten sind und diese auf IPsec Tunnel zugreifen müssen. Somit könnten wir durch das Setup die Komplexität des Source NAT umgehen und hätten mit den wenigen Servern trotzdem maximale Ausfallsicherheit, bereits auf Layer 2.

    Nun wollen wir aber auch die Vorteile der zwei Standorte, nämlich eine Internetverbindung pro Standort, verwenden. Das hieße, dass wir pro Standort die Default Gateway-Option ändern müssten, damit der Internetverkehr an dem jeweils eigenen Gateway ausgebrochen wird.

    Wir dachten zuerst daran, die zeitliche Verzögerung zu nutzen und einfach die DHCP in den Standorten ungeclustert laufen zu lassen. Wenn der Discover kommt, würde der Client sich somit für den lokalen DHCP entscheiden, weil er einfach schneller sein sollte. Problem ist bloß, dass ja keine zwei DHCP-Server im selben Netz sein dürfen.

    Gibt es Erfahrung für so einen Fall? Wie ist hier die Best-Practice? Gibt es eventuell die Möglichkeit die DHCP-Optionen nach anderen Parametern (Pattern in Hostname) zu verteilen? Müsste man sowas vielleicht sogar per GPO verteilen und beim DHCP garkein Gateway mitgeben?

    Das Default Gateway ist zwar ausschlaggebender aber gleiches wäre dann nochmal bei beim DNS Thema. Und da wiederum das Problem: Wenn ich keinen DNS per DHCP verteile, kann ich dann überhaupt eine Domänenanmeldung machen, um per GPO dann wieder einen DNS-Server einzutragen?

    Sorry, wenn die Anfrage etwas fremd klingt aber ich bin eher aus der Netzwerkschiene ;)

    Danke schonmal für die Mühen.

    Viele Grüße

    Freitag, 9. Februar 2018 09:58

Alle Antworten

  • Moin,

    erstens dürfen selbstverständlich zwei DHCP-Server im selben Netz sein. Und das, was Du beschrieben hast, mit Verzögerung, ist die Grundlage der Aktiv-Aktiv-Scope-Partnerschaften in 2012 und höher. Und früher hat man das auch schon so nachgebaut.

    In Deinem Fall würde ich schauen, ob ich mir nicht mit der Reihenfolge der IP-Helper auf den Swtchen behelfen kann. Das sollte deutlich zuverlässiger sein als eine reine Verzögerung bei der Lease-Ausgabe. Allerdings ist es vom Switch abhängig, ob er bei mehreren eingetragenen Helpern den Request parallel an alle (würde Dir nicht helfen) oder gemäß der Reihenfolge der Eintragung (bringt Dich ans Ziel) schickt.

    Oder Du trägst immer nur einen Helper ein, und der zeigt auf den DHCP im eigenen Standort.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Freitag, 9. Februar 2018 20:32
  • Hi Evgenjj,

    Ich habe schon mehrere Artikel gelesen, demnach Windows Server "Probleme bekommen können", wenn sie einen anderen DHCP sehen.

    Ich hatte es jetzt so versucht:

    DHCP Standort 1 geteilter Bereich mit DHCP Standort 2

    Interessanterweise antwortet aber immer nur DHCP Standort 1, auch, wenn der Client in Standort 2 anfragt (Direkt am Core nahe dem Server). Ich sehe keine Offers vom DHCP Standort 2 raus gehen, außer ich nehme den LAN-Link vollkommen außer Betrieb. Aber selbst, wenn er dann eine IP vom Standort 2 hat, geht er trotzdem über das Default Gateway von Standort 1 raus, obwohl es in der Liste der Default Gateways weiter unten steht. Außerdem hat sich mir noch die Frage gestellt, wo man die geteilten Bereiche nachträglich verwalten kann? Klar ich sehe die Scopes und ausnahmen der Verteilung. Aber wenn ich die Lösche und neu anlegen will, sagt er, dass es bereits eine Beziehung gibt. Aber ich finde nicht, wo ich die auch wieder lösen könnte.

    Die Infrastruktur ist Cisco Meraki. Von daher gibt es auch keine Helper direkt auf dem Switch, soweit ich weiß.

    Ich dachte auch an 802.1X. Wäre eine gute Möglichkeit mehr zentrale Verwaltbarkeit durch Gruppen zu implementieren. Und ich wusste, dass es dort den Punkt Einstellungen --> IP-Einstellungen gibt. Leider finde ich dazu keine Dokumentation und gefühlt machen alle Punkte dort genau dasselbe: Standort 1 beantwortet die Anfrage. Ich dachte, dass ich durch die Netzwerkrichtlinie in der Lage wäre die Zuweisung der IP auf einen bestimmten Server zu lenken.

    Ansonsten dachte ich mir via GPO irgendwie einfach eine Priorisierung der Gateways einzurichten. Allerdings kann ich mittels route nur ein default Gateway angeben. Das andere springt immer raus. Außerdem finde ich die Variante definitiv nicht schön.

    Ich komme hier irgendwie echt nicht weiter. Alle Wege sind nur Sackgassen. Liefert dir vielleicht einer der Ansätze noch einen Gedankenblitz?

    Viele Grüße,

    Mattes

    Freitag, 23. Februar 2018 11:50
  • Die Infrastruktur ist Cisco Meraki. Von daher gibt es auch keine Helper direkt auf dem Switch, soweit ich weiß.

    Moin,

    erstens gibt es auf dem MS natürlich auch Helper: https://documentation.meraki.com/MS/Layer_3_Switching/Configuring_DHCP_Services_on_the_MX_and_MS

    Zweitens helpen Dir die Helper in dem Falle wohl doch nicht, denn, wenn ich mir richtig vorstelle, wie Dein Netz gebaut ist, hast Du ja mit Meraki logisch nur einen Switch und nur ein VLAN. Sprich: Du hast quasi gar keine Verortungsmöglichkeit für das verbundene Endgerät. Somit werden auch die DHCP-Requests so verschickt wie von Dir beobachtet.

    Hast Du schon darüber nachgedacht, den Standort mit weniger Servern umzubauen, ihm ein separates VLAN, einen separaten IP-Bereich zu geben und dazwischen zu routen? Da die Switche das Routing übernehmen würden, wäre die Performance ja nicht schlechter als jetzt, und Du hättest eine saubere Verortung.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Freitag, 23. Februar 2018 19:37
  • Hi Evgenij,

    Nein es gibt VLANs. Sogar mehrere. Aber das hilft mir nicht weiter. Dann bräuchte jeder Switch in absolut jedem VLAN ein L3 Interface. Und ob er dann schneller ist, ist auch nicht garantiert.

    Aber Vielleicht nochmal zu dem Setup. Wir haben zwei Standorte, die direkt mit einem Layer3 Link verbunden sind und somit nur ein VLAN bilden. Das ist auch so gewollt, da wir ansonsten viele Tunnel umbauen müssten und wir so auch einen schönen Redundanzfall haben.

    Was ich probiert habe, ist, wie gesagt 802.1X, zu benutzen und die Adressanforderung auf dem Authenifizierenden Server verarbeiten zu lassen. Leider antwortet immer der primäre DHCP obwohl der sekundäre DC die Authentifizierung durchführt. Ich habe daraufhin mal das Scope auf dem primären DC volllaufen lassen, sodass nur der sekundäre DC antworten kann und es dauert 4 Discovers bis er selbst ein Offer raus schickt. Leider finde ich keine Dokumentation zu der Adressvergabe bei 802.1X. Wie gesagt, alle Punkte scheinen das gleiche zu tun. Aber bei einem Intervall von mehreren Sekunden ist die Latenz von wenigen Millisekunden, die hier anliegt zu gering, alsdass ich mit einer Verzögerung sicher gegensteuern könnte.

    Desweiteren habe ich immernoch das Problem, dass das Gateway in Standort 1 immer priorisiert wird. Auch wenn da Gateway 1 bei der Verteilung von Standort 2 niedriger priorisiert ist. Die DHCP Leases zeigen es auch korrekt.

    Ethernet-Adapter Ethernet:

       Verbindungsspezifisches DNS-Suffix: hello.local
       Verbindungslokale IPv6-Adresse  . : fe80::fc09:357c:6790:676a%7
       IPv4-Adresse  . . . . . . . . . . : 10.10.10.100
       Subnetzmaske  . . . . . . . . . . : 255.255.255.0
       Standardgateway . . . . . . . . . : 10.10.10.2
                                           10.10.10.1

    IPv4-Routentabelle
    ===========================================================================
    Aktive Routen:
         Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
              0.0.0.0          0.0.0.0       10.10.10.2     10.10.10.100     25
              0.0.0.0          0.0.0.0       10.10.10.1     10.10.10.100     25

    Routenverfolgung zu 8.8.8.8 über maximal 30 Hops

      1     1 ms     1 ms     1 ms  10.10.10.1

    Wenn zwei Routen sich in keiner Weise unterscheiden, scheint er einfach nach der Gateway IP zu gehen. Finde ich ein bisschen einen Designfehler. Wenn ich Gateways priorisieren kann, sollte es auch über die Metrik gesteuert sein.

    Wenn es hilft, kann ich das ganze auch gerne einmal in Visio zeichnen, damit die Basis vielleicht doch nochmal klarer ist.

    Viele Grüße,

    Mattes

    Dienstag, 27. Februar 2018 08:58
  • Wir haben zwei Standorte, die direkt mit einem Layer3 Link verbunden sind und somit nur ein VLAN bilden. Das ist auch so gewollt, da wir ansonsten viele Tunnel umbauen müssten und wir so auch einen schönen Redundanzfall haben.

    Also, wie ich oben schon sagte: EIN VLAN. ;-) Auch wenn es noch weitere gibt. Du hast alles erdenkliche getan, um die Geographie aus Deinem Netz zu verbannen, und jetzt fehlt sie Dir.

    Wenn die Maschinen nicht ständig zwischen den Standorten hin- und herwandern, kannst Du einen Failover-Scope bauen und für alle Geräte mit Reservierungen arbeiten.

    Stell die Frage vielleicht im Meraki-Forum, da tummeln sich mitunter ein paar fähige Leute.

    Wenn zwei Routen sich in keiner Weise unterscheiden, scheint er einfach nach der Gateway IP zu gehen. Finde ich ein bisschen einen Designfehler. Wenn ich Gateways priorisieren kann, sollte es auch über die Metrik gesteuert sein.

    Dann würden sich die Routen ja unterscheiden, denn die Metrik ist ein fester Bestandteil der Route ;-) Also merkst Du selbst: Default Gateway kannst Du eben nicht priorisieren - Default ist Default, und das Eintragen von mehreren ist ohnehin Mist und wird sich irgendwann rächen.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 27. Februar 2018 20:06