Ziel dieses Artikels ist es, die Konfiguration des DHCP-Dienstes für die VXLAN BGP EVPN und DFA Fabrik mit Microsoft Windows Server 2016/2019 zu vereinfachen.
In der offiziellen Dokumentation wird der DHCP-Dienst auf Basis von Microsoft Windows Server 2012 für die Fabrik als SuperScope konfiguriert, das einen Loopback-Pool enthält (der besondere Punkt hierbei ist, dass alle IP-Adressen aus dem Pool ausgeschlossen sind (excluded IP address = pool)) und Pools zur Vergabe von IP-Adressen für reale Netzwerke (hier ist der interessante Punkt, dass Policies konfiguriert werden – in denen der DHCP Relay Circuit ID gefiltert wird und dieser DHCP Relay Circuit ID den VNI für das Netzwerk enthält, d. h. für einen anderen Pool wird dieser DHCP Relay Circuit ID etwas anders sein).
Um DHCP auf einem Windows-Server zu konfigurieren.
1. Erstellen Sie einen SuperScope. Innerhalb des SuperScopes erstellen Sie den Scope B, S1, S2, S3, …, Sn für das Subnetz B und die Subnetze für jedes Segment.
2. Geben Sie im Scope B den 'Ausschlussbereich' an, der den gesamten Adressbereich umfasst (damit der angebotene Adressbereich nicht aus diesem Scope stammen kann).
3. Für jeden Segment-Scope Si geben Sie eine Policy an, die übereinstimmt mit dem Agent Circuit ID mit dem Wert '0108000600XXXXXX', wobei '0108000600' ein fester Wert für alle Segmente ist und die 6 Zahlen "XXXXXX" der Segment-ID-Wert in hexadezimaler Form sind. Stellen Sie außerdem sicher, dass das Kontrollkästchen für das Anhängen von Wildcards (*) angekreuzt ist.
4. Setzen Sie den Adressbereich der Policy auf den gesamten Bereich des Scopes.Dieser Artikel beantwortet folgende Fragen:
Inhalt
- ( & )
Einführung
In diesem Abschnitt sind alle Ausgangsdaten kurz aufgelistet: Anleitungen zur Konfiguration von Netzwerkausrüstung, RFCs, die in DHCP-Paketen in eVPN-Fabriken verwendet werden, sowie eine Übersicht über die Evolution der Einstellungen des DHCP-Servers auf Microsoft Windows Server 2012 in der Dokumentation von Cisco. Außerdem sind kurze Informationen über Superscope und Policies im DHCP-Dienst auf Microsoft Windows Servern enthalten.
Wie wird der DHCP Relay in der VXLAN BGP EVPN, DFA Fabrik konfiguriert?
Die Konfiguration des DHCP Relay in der VXLAN BGP EVPN Fabrik ist nicht das Hauptthema dieses Artikels, da sie recht einfach ist. Ich gebe Links zur Dokumentation und einen Spoiler zu den Einstellungen für die Netzwerkausrüstung an.
Beispiel zur Konfiguration des DHCP Relay auf Nexus 9000V v9.2(3)
Service DHCP
IP DHCP-Relay
IP DHCP-Relay-Information Option
IP DHCP-Relay-Information Option VPN
Schnittstelle Loopback10
VRF-Mitglied VRF1
IP-Adresse 10.120.0.1/32 Tag 1234567
Schnittstelle Vlan12
Kein Shutdown
VRF-Mitglied VRF1
Kein IP-Redirects
IP-Adresse 10.120.251.1/24 Tag 1234567
Kein IPv6-Redirects
Fabric Forwarding-Modus Anycast-Gateway
IP DHCP-Relay-Adresse 10.0.0.5
IP DHCP-Relay-Source-Interface Loopback10
RFC, die in der Implementierung des DHCP-Relay-Dienstes in VXLAN BGP EVPN-Fabriken realisiert sind
RFC#6607: Suboption 151(0x97) — Virtuelle Subnetz-Auswahl
• Suboption 151(0x97) - Virtuelle Subnetz-Auswahl (Definiert in RFC#6607)
Verwendet, um VRF-bezogene Informationen an den DHCP-Server in einer MPLS-VPN- und VXLAN-EVPN-Multimandantenumgebung zu übermitteln.Der "Name" des VRF, in dem sich der Client befindet, wird übermittelt.
RFC#5107: Suboption 11(0xb) — Server-ID-Überschreibung
• Suboption 11(0xb) - Server-ID-Überschreibung (Definiert in RFC#5107.)
Die Server-ID-Überschreibungs-Suboption ermöglicht es dem DHCP-Relay-Agent, einen neuen Wert für die Server-ID-Option anzugeben, der vom DHCP-Server im Antwortpaket eingefügt wird. Diese Suboption ermöglicht es dem DHCP-Relay-Agent, als tatsächlicher DHCP-Server zu fungieren, sodass die Erneuerungsanfragen an den Relay-Agent und nicht direkt an den DHCP-Server gesendet werden. Die Server-ID-Überschreibung-Suboption enthält die IP-Adresse der eingehenden Schnittstelle, die die IP-Adresse des Relay-Agents ist und vom Client aus zugänglich ist. Mit diesen Informationen sendet der DHCP-Client alle Renew- und Release-Anfragepakete an den Relay-Agent. Der Relay-Agent fügt alle entsprechenden Suboptionen hinzu und leitet dann die Renew- und Release-Anfragepakete an den ursprünglichen DHCP-Server weiter. Für diese Funktion ist die proprietäre Implementierung von Cisco die Suboption 152(0x98). Sie können den Befehl ip dhcp relay sub-option type cisco verwenden, um die Funktion zu verwalten.Die Option wird verwendet, damit der Client eine Anfrage zur Verlängerung der Mietdauer an die IP-Adresse sends, die in dieser Option verwendet wird. (Im Cisco VXLAN BGP EVPN ist dies die Anycast-Adresse des Standardgateways für den Client.)
RFC#3527: Suboption 5(0x5) — Linkauswahl
Suboption 5(0x5) - Linkauswahl (Definiert in RFC#3527.)
Die Linkauswahl-Suboption bietet einen Mechanismus, um das Subnetz/den Link, auf dem sich der DHCP-Client befindet, von der Gateway-Adresse (giaddr) zu trennen, die zur Kommunikation mit dem Relay-Agent vom DHCP-Server verwendet werden kann. Der Relay-Agent wird die Suboption auf das richtige Abonnenten-Subnetz setzen, und der DHCP-Server wird diesen Wert verwenden, um eine IP-Adresse anstatt des giaddr-Wertes zuzuweisen. Der Relay-Agent wird die giaddr auf seine eigene IP-Adresse setzen, sodass DHCP-Nachrichten über das Netzwerk weitergeleitet werden können. Für diese Funktion ist die proprietäre Implementierung von Cisco die Suboption 150(0x96). Sie können den Befehl ip dhcp relay sub-option type cisco verwenden, um die Funktion zu verwalten.Die Netzwerkadresse, aus der der Client eine IP-Adresse benötigt.
Die Evolution der Dokumentation von Cisco zur DHCP-Konfiguration auf Microsoft Windows Server 2012.
Ich habe diesen Abschnitt aufgenommen, da eine positive Tendenz seitens des Anbieters erkennbar ist:
Die Dokumentation enthält nur die Konfiguration von DHCP Relay auf Netzwerkgeräten.
Für die Einrichtung von DHCP auf Windows Server 2012 wurde ein anderer Artikel verwendet:
In diesem Artikel wird angegeben, dass für jedes Netzwerk/VNI eine eigene SuperScope-Bindung und ein eigener Satz von Loopback-Adressen erforderlich sind:
Wenn mehrere DHCP-Scopes für mehrere Subnetze erforderlich sind, müssen Sie pro Subnetz/VLAN einen LoopbackX auf allen LEAFS erstellen und einen Superscope mit einem LoopbackX-Bereichsscope und einem tatsächlichen IP-Subnetzscope pro VLAN erstellen.
Die Einstellungen für Windows 2012 Server wurden in die Dokumentation zur Konfiguration von Netzwerkgeräten aufgenommen. Für alle verwendeten Adresspools ist ein SuperScope im Rechenzentrum erforderlich, und dieser SuperScope bildet die Grenze des Rechenzentrums:
Erstellen Sie einen Superscope für alle Scopes, die Sie für optionale 82-basierte Richtlinien verwenden möchten.
Hinweis
Der Superscope sollte alle Scopes kombinieren und als administrative Grenze fungieren.
Es wird alles sehr prägnant erklärt:
Nehmen wir an, der Switch verwendet die Adresse aus Subnetz B (es kann das Backbone-Subnetz, das Verwaltungs-Subnetz oder ein beliebiges vom Kunden festgelegtes Subnetz für diesen Zweck sein), um mit dem Windows DHCP-Server zu kommunizieren. In DFA haben wir Subnetze S1, S2, S3, …, Sn für die Segmente s1, s2, s3, …, sn.
Um DHCP auf dem Windows Server zu konfigurieren.
1. Erstellen Sie einen Super Scope. Innerhalb des Super Scope erstellen Sie Scope B, S1, S2, S3, …, Sn für das Subnetz B und die Subnetze für jedes Segment.
2. Geben Sie in Scope B den 'Ausschlussbereich' als den gesamten Adressbereich an (so dass der angebotene Adressbereich nicht aus diesem Scope stammen darf).
3. Für jeden Segment-Scope Si geben Sie eine Richtlinie an, die auf die Agent Circuit ID mit dem Wert '0108000600XXXXXX' übereinstimmt, wobei '0108000600' ein fester Wert für alle Segmente ist, die 6 Zahlen "XXXXXX" den Segment-ID-Wert in hexadezimaler Schreibweise darstellen. Stellen Sie außerdem sicher, dass das Kästchen für das Anfügen des Wildcards (*) aktiviert ist.
4. Setzen Sie den Richtlinienadressbereich auf den gesamten Bereich des Scopes.
DHCP in Microsoft Windows Server (Superscope & Richtlinie)
Der Superscope ist ein administratives Merkmal eines DHCP-Servers, das verwendet werden kann, um mehrere Scopes als eine einzige Verwaltungseinheit zu gruppieren. Der Superscope ermöglicht es einem DHCP-Server, von mehr als einem Scope an Clients in einem einzigen physischen Netzwerk Leasing zu vergeben. Scopes, die einem Superscope hinzugefügt werden, werden als Mitglieds-Scopes bezeichnet. Was ist ein SuperScope – es ist eine Funktion, die es ermöglicht, mehrere IP-Adresspools in eine verwaltungstechnische Einheit zusammenzufassen. Um IP-Adressen aus mehreren Pools Benutzern in einem physischen Netzwerk (in einem VLAN) anzubieten. Wenn eine Anfrage an einen Adresspool innerhalb eines SuperScope gestellt wird, kann die Adresse an den Client aus einem anderen Scope innerhalb dieses SuperScope vergeben werden.
Die DHCP-Serverrolle in Windows Server 2012 führt eine neue Funktion ein, die es Ihnen ermöglicht, IPv4-Richtlinien zu erstellen, die benutzerdefinierte IP-Adressen und Optionszuweisungen für DHCP-Clients basierend auf einer Reihe von Bedingungen festlegen.
Die richtlinienbasierte Zuweisungsfunktion (PBA) ermöglicht es Ihnen, DHCP-Clients nach bestimmten Attributen basierend auf Feldern zu gruppieren, die im DHCP-Client-Anforderungs-Paket enthalten sind. PBA ermöglicht zielgerichtete Administration und größere Kontrolle über die Konfigurationsparameter, die an Netzwerkgeräte mit DHCP geliefert werden. Richtlinien – ermöglichen es, Benutzern IP-Adressen abhängig vom Benutzertyp oder -parameter zuzuweisen. Cisco-Ingenieure verwenden Richtlinien in Windows Server 2012 zur Filterung nach VNI (Virtual Network Identifier).
Hauptteil
In diesem Abschnitt werden die Ergebnisse von Forschungen dargestellt, warum Unterstützung fehlt, wie es funktioniert (Logik), was neu ist und wie uns das Neue helfen kann.
Warum werden Microsoft Windows Server 2000/2003/2008 nicht unterstützt?
Microsoft Windows Server 2008 und frühere Versionen verarbeiten die Option 82 nicht und senden das Rückpaket ohne Option 82.
- Die Anfrage des Clients wird als Broadcast (DHCP Discover) gesendet.
- Die Hardware (Nexus) sendet ein Paket an den DHCP-Server (DHCP Discover + Option 82).
- Der DHCP-Server empfängt das Paket, verarbeitet es und sendet eine Antwort zurück, jedoch ohne Option 82. (DHCP Offer – ohne Option 82)
- Die Hardware (Nexus) empfängt das Paket vom DHCP-Server. (DHCP Offer) Sendet dieses Paket jedoch nicht an den Endbenutzer weiter.
Daten des Sniffers – auf Windows Server 2008 und auf dem DHCP-ClientWindows Server 2008 erhält die Anfrage von der Netzwerkausrüstung. (Option 82 ist in der Liste vorhanden)
Windows Server 2008 sendet eine Antwort an die Netzwerkausrüstung. (Option 82 fehlt in der Optionenliste im Paket)
Anfrage des Clients – DHCP Discover ist vorhanden und DHCP Offer fehlt
Statistiken auf der Netzwerkausrüstung:
NEXUS-9000V-SW-1# show ip dhcp relay statistics
----------------------------------------------------------------------
Nachrichtentyp Rx Tx Drops
----------------------------------------------------------------------
Discover 8 8 0
Offer 8 8 0
Request(*) 0 0 0
Ack 0 0 0
Release(*) 0 0 0
Decline 0 0 0
Inform(*) 0 0 0
Nack 0 0 0
----------------------------------------------------------------------
Total 16 16 0
----------------------------------------------------------------------
DHCP L3 FWD:
Gesamtzahl empfangener Pakete : 0
Gesamtzahl weitergeleiteter Pakete : 0
Gesamtzahl verworfener Pakete : 0
Nicht-DHCP:
Gesamtzahl empfangener Pakete : 0
Gesamtzahl weitergeleiteter Pakete : 0
Gesamtzahl verworfener Pakete : 0
DROP:
DHCP Relay nicht aktiviert : 0
Ungültiger DHCP-Nachrichtentyp : 0
Schnittstellenfehler : 0
Tx-Fehler zum Server : 0
Tx-Fehler zum Client : 0
Unbekannte Ausgabeschnittstelle : 0
Unbekannte VRF oder Schnittstelle für Server : 0
Maximale Hops überschritten : 0
Option 82-Validierung fehlgeschlagen : 0
Paket fehlerhaft : 0
Relay-Vertrauensport nicht konfiguriert : 0
DHCP-Anfrage in MCT verworfen : 0
* - Diese Zähler zeigen den korrekten Wert, wenn der Switch
einen DHCP-Anfragepacket mit der Ziel-IP als Broadcast-Adresse empfängt. Wenn die Anfrage unicast ist, wird sie HW-geschaltet
NEXUS-9000V-SW-1#
Warum ist die Konfiguration in Microsoft Windows Server 2012 so kompliziert?
In Microsoft Windows Server 2012 wird RFC#3527 (Option 82 Suboption 5(0x5) – Link Auswahl) noch nicht unterstützt.
Aber die Funktionalität Policy ist bereits implementiert.
Wie es funktioniert:
- Microsoft Windows Server 2012 hat einen Super-Pool (SuperScope), in dem Loopback-Adressen und Pools für reale Netzwerke vorhanden sind.
- Die Auswahl des Pools zur Vergabe einer IP-Adresse fällt in den SuperScope, da die Antwort von einem DHCP Relay mit der Quelladresse Loopback, die im SuperScope enthalten ist, kam.
- Durch die Verwendung von Policy wählt die Anfrage aus dem Superscope den Mitgliedsbereich aus, dessen VNI in der Option 82 Suboption 1 Agent Circuit ID enthalten ist. ("0108000600" + 24 Bit VNI + 24 Bit unbekannter Werte, aber der Sniffer zeigt 0 in diesem Feld an.)
Wie wird die Konfiguration in Microsoft Windows Server 2016/2019 vereinfacht?
In Microsoft Windows Server 2016 ist die Funktionalität RFC#3527 implementiert. Das heißt, Windows Server 2016 kann das richtige Netzwerk aus dem Attribut Option 82 Suboption 5(0x5) – Link Auswahl erkennen.
Es stellen sich sofort 3 Fragen:
- Können wir ohne Superscope auskommen?
- Können wir ohne Policy und die Umwandlung von VNI in hexadezimale Form auskommen?
- Können wir ohne Scope für Loopback-Adressen von DHCP Source auskommen?
Q. Können wir ohne Superscope auskommen?
A. Ja, Scope kann direkt im Bereich der IPv4 Adressen erstellt werden.
Q. Können wir ohne Policy und die Umwandlung von VNI in hexadezimale Form auskommen?
A. Ja, die Auswahl des Netzwerks erfolgt auf der Grundlage von Option 82 Suboption 0x5.
Q. Können wir ohne Scope für Loopback-Adressen von DHCP Source auskommen?
A. Nein, das können wir nicht. Da in Microsoft Windows Server 2016/2019 ein Schutz gegen böswillige DHCP-Anfragen besteht. Das heißt, alle Anfragen von Adressen, die nicht im Pool des DHCP-Servers vorhanden sind, werden als böswillig angesehen.
Hinweis
Alle IP-Adressen des Relay-Agenten (GIADDR) müssen Teil eines aktiven IP-Adressbereichs des DHCP-Scope sein. Jeder GIADDR, der außerhalb der IP-Adressbereiche des DHCP-Scope liegt, wird als rogue relay betrachtet und der Windows DHCP-Server wird DHCP-Client-Anfragen von diesen Relay-Agenten nicht anerkennen.
Es kann ein spezieller Scope erstellt werden, um Relay-Agenten zu "autorisieren". Erstellen Sie einen Scope mit der GIADDR (oder mehreren, wenn die GIADDRs aufeinanderfolgende IP-Adressen sind), schließen Sie die GIADDR-Adressen von der Verteilung aus und aktivieren Sie dann den Scope. Dies autorisiert die Relay-Agenten und verhindert gleichzeitig, dass die GIADDR-Adressen zugewiesen werden.Das heißt, um einen DHCP-Pool für die VXLAN BGP EVPN Fabrik auf Microsoft Windows Server 2016/2019 einzurichten, benötigt man nur:
- Einen Pool für die Source-Adressen von Relay zu erstellen.
- Einen Pool für die Client-Netze zu erstellen.
Was nicht notwendig ist (aber eingerichtet werden kann und funktionieren wird, ohne den Betrieb zu stören):
- Policy zu erstellen.
- SuperScope zu erstellen.
BeispielBeispiel für die Konfiguration des DHCP-Servers (vorhandene 2 reale DHCP-Clients – die Clients sind mit der VXLAN-Fabrik verbunden).
Beispiel für die Konfiguration eines benutzerdefinierten Pools:
Beispiel für die Konfiguration eines benutzerdefinierten Pools (ausgewählte Politiken – um zu beweisen, dass Politiken nicht für die korrekte Funktionsweise des Pools verwendet wurden):
Beispiel für die Konfiguration eines Pools für die Source-Adressen von DHCP Relay (der Adressbereich zur Vergabe entspricht vollständig der Ausschlussliste aus dem Adresspool):
Konfiguration des DHCP-Dienstes auf Microsoft Windows Server 2019.
Konfiguration des Pools für Loopback-Adressen (Source) für DHCP Relay.
Wir erstellen einen neuen Pool (Scope) im IPv4-Bereich.
Assistent zur Erstellung des Pools. „Weiter >“
Wir konfigurieren den Namen des Pools und die Beschreibung (Description) des Pools.
Wir legen den IP-Adressbereich für Loopback und die Maske für den Pool fest.
Fügen Sie Ausnahmen hinzu. Der Bereich der Ausnahmen muss mit dem Bereich des Pools vollständig übereinstimmen.
Lease-Dauer. „Weiter >“
Anfrage: Möchten Sie die DHCP-Optionen jetzt konfigurieren (DNS, WINS, Gateway, Domain) oder später? Es ist schneller, mit Nein zu antworten und den Pool manuell zu aktivieren. Alternativ können Sie den Assistenten bis zum Ende durchlaufen, ohne Informationen auszufüllen und den Pool am Ende zu aktivieren.
Wir bestätigen, dass die Optionen nicht konfiguriert sind und der Pool nicht aktiviert ist. „Fertig“
Aktivierung des Pools manuell. — Wählen Sie den Scope aus und wählen Sie im Kontextmenü „Aktivieren“.
Wir erstellen einen Pool für Benutzer/Server.
Wir erstellen einen neuen Pool.
Assistent zur Erstellung des Pools. „Weiter >“
Wir konfigurieren den Namen des Pools und die Beschreibung (Description) des Pools.
Wir legen den IP-Adressbereich für Loopback und die Maske für den Pool fest.
Fügen Sie Ausnahmen hinzu. (Standardmäßig sind keine Ausnahmen erforderlich) „Weiter >“
Lease-Dauer. „Weiter >“
Anfrage: Möchten Sie die DHCP-Optionen jetzt konfigurieren (DNS, WINS, Gateway, Domain) oder später? Ja, wir konfigurieren sie jetzt.
Wir konfigurieren die Standard-Gateway-Adresse.
Wir konfigurieren die Domain und die Adressen der DNS-Server.
Wir konfigurieren die IP-Adressen der WINS-Server.
Aktivierung von Scope.
Der Pool ist konfiguriert. „Fertig“
Fazit
Die Verwendung von Windows Server 2016/2019 vereinfacht die Konfiguration des DHCP-Servers für VXLAN-Fabriken (oder jede andere Fabrik). (Es ist nicht erforderlich, den IT-Spezialisten spezielle Bündel: Network/Agent Circuit ID zur Eingabe von Filtern zu übergeben.)
Wird die Konfiguration für Windows Server 2012 auf den neuen Servern 2016/2019 funktionieren – ja, es wird funktionieren.
In diesem Dokument sind Links zu 2 Versionen angegeben: 7.X und 9.3. Dies liegt daran, dass Version 7.0(3)I7(7) die von Cisco empfohlene Version ist und Version 9.3 die innovativste ist (einschließlich der Unterstützung von Multicast über VXLAN Multisite).
Literaturverzeichnis
Quelle: habr.com
