Das 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 (in diesem Pool ist die Besonderheit das Ausschließen aller IP-Adressen des Pools (excluded IP address = pool)) sowie Pools zur Vergabe von IP-Adressen für reale Netzwerke (hier ist die Besonderheit, dass Policies eingerichtet werden – in denen die DHCP Relay Circuit ID gefiltert wird und diese DHCP Relay Circuit ID den VNI für das Netzwerk enthält, d. h. für einen anderen Pool wird diese DHCP Relay Circuit ID etwas anders sein).
Um DHCP auf dem Windows-Server zu konfigurieren.
1. Erstellen Sie einen SuperScope. Innerhalb des SuperScopes erstellen Sie 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' als den gesamten Adressbereich an (so dass der angebotene Adressbereich nicht aus diesem Scope stammen darf).
3. Für jedes Segment Scope Si legen Sie eine Richtlinie fest, die mit der Agent Circuit ID mit dem Wert '0108000600XXXXXX' übereinstimmt, wobei '0108000600' ein fester Wert für alle Segmente ist; die 6 Ziffern "XXXXXX" sind der Segment-ID-Wert in hexadezimal. Stellen Sie außerdem sicher, dass das Kontrollkästchen für Wildcard (*) aktiviert ist.
4. Setzen Sie den Richtlinienadressbereich auf den gesamten Bereich des Scopes.Dieser Artikel enthält Antworten auf die folgenden Fragen:
Inhalt
- ( & )
Einführung
In diesem Abschnitt sind alle Ausgangsdaten kurz aufgeführt: Anleitungen zur Konfiguration der Netzwerkgeräte, RFC, die in DHCP-Paketen in eVPN-Fabriken verwendet werden, sowie eine Übersicht über die Entwicklung der DHCP-Serverkonfiguration in der Dokumentation von Cisco für Microsoft Windows Server 2012. Außerdem finden Sie kurze Informationen zu Superscope und Richtlinie im DHCP-Dienst auf Microsoft Windows Server.
Wie wird DHCP Relay auf der VXLAN BGP EVPN-Fabrik, DFA, eingerichtet?
Die Einrichtung von DHCP Relay auf der VXLAN BGP EVPN-Fabrik ist nicht das Hauptthema dieses Artikels, da sie ziemlich einfach ist. Ich werde auf die Dokumentation verweisen und eine spoilerartige Übersicht der Einstellungen auf den Netzwerkgeräten geben.
Beispiel für die Einrichtung von DHCP Relay auf Nexus 9000V v9.2(3)
Dienst dhcp
ip dhcp relay
ip dhcp relay Informationen Option
ip dhcp relay Informationen Option vpn
Schnittstelle loopback10
vrf Mitglied VRF1
ip Adresse 10.120.0.1/32 tag 1234567
Schnittstelle Vlan12
kein Shutdown
vrf Mitglied VRF1
keine ip Umleitungen
ip Adresse 10.120.251.1/24 tag 1234567
keine ipv6 Umleitungen
Fabric Weiterleitung Modus anycast-gateway
ip dhcp relay Adresse 10.0.0.5
ip dhcp relay Quellschnittstelle loopback10
RFCs, die im DHCP Relay-Dienst in VXLAN BGP EVPN Fabriken implementiert sind
RFC#6607: Sub-option 151(0x97) — Virtuelle Subnetz-Auswahl
• Sub-option 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-Multi-Tenants-Umgebung zu übermitteln.Der Name des VRF, in dem sich der Client befindet, wird übermittelt.
RFC#5107: Sub-option 11(0xb) — Server-ID-Überschreibung
• Sub-option 11(0xb) - Server-ID-Überschreibung (Definiert in RFC#5107.)
Die Server-ID-Überschreibungs-Sub-Option ermöglicht es dem DHCP-Relay-Agenten, einen neuen Wert für die Server-ID-Option anzugeben, der vom DHCP-Server im Antwortpaket eingefügt wird. Diese Sub-Option lässt den DHCP-Relay-Agenten wie den tatsächlichen DHCP-Server agieren, sodass die Erneuerungsanfragen an den Relay-Agenten und nicht direkt an den DHCP-Server gesendet werden. Die Server-ID-Überschreibungs-Sub-Option enthält die IP-Adresse der Eingangs-Schnittstelle, die die IP-Adresse des Relay-Agenten ist, auf die der Client zugreifen kann. Mithilfe dieser Informationen sendet der DHCP-Client alle Erneuerungs- und Freigabeanforderungspakete an den Relay-Agenten. Der Relay-Agent fügt alle entsprechenden Sub-Optionen hinzu und leitet dann die Erneuerungs- und Freigabeanforderungspakete an den ursprünglichen DHCP-Server weiter. Für diese Funktion ist Ciscon’s proprietäre Implementierung die Sub-Option 152(0x98). Sie können den Befehl ip dhcp relay Sub-optionstyp cisco verwenden, um die Funktion zu verwalten.Diese Option wird verwendet, damit der Kunde eine Anfrage zur Verlängerung der Mietdauer der IP-Adresse an die in dieser Option verwendete IP-Adresse sendet. (Im Cisco VXLAN BGP EVPN handelt es sich hierbei um die Anycast-Adresse des Standard-Gateways für den Kunden.)
RFC#3527: Sub-Option 5(0x5) — Link-Auswahl
Sub-Option 5(0x5) - Link-Auswahl (Definiert in RFC#3527.)
Die Sub-Option zur Link-Auswahl 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-Agenten durch den DHCP-Server verwendet werden kann. Der Relay-Agent setzt die Sub-Option auf das richtige Abonnenten-Subnetz, und der DHCP-Server verwendet diesen Wert, um eine IP-Adresse zuzuweisen, anstatt den Wert für giaddr zu verwenden. Der Relay-Agent setzt giaddr auf seine eigene IP-Adresse, damit DHCP-Nachrichten über das Netzwerk weitergeleitet werden können. Für diese Funktion ist die proprietäre Implementierung von Cisco die Sub-Option 150(0x96). Sie können den Befehl "ip dhcp relay sub-option type cisco" verwenden, um die Funktion zu verwalten.Das Netzwerk, aus dem der Kunde eine IP-Adresse benötigt.
Die Entwicklung der Dokumentation von Cisco zur Konfiguration von DHCP auf Microsoft Windows Server 2012
Ich habe diesen Abschnitt aufgenommen, da ein positiver Trend seitens des Anbieters erkennbar ist:
In der Dokumentation wird lediglich die Konfiguration des DHCP Relay auf Netzwerkgeräten behandelt.
Für die Konfiguration von DHCP auf Windows Server 2012 wurde ein anderer Artikel verwendet:
In diesem Artikel wird angegeben, dass für jedes Netzwerk/VNI ein eigenes SuperScope und ein eigener Satz von Loopback-Adressen erforderlich sind:
Wenn für mehrere Subnetze mehrere DHCP-Bereiche erforderlich sind, müssen Sie pro Subnetz/VLAN auf allen LEAFS ein LoopbackX erstellen und einen Superscope mit einem LoopbackX-Bereichsbereich und dem tatsächlichen Client-IP-Subnetzbereich 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 stellt die Grenze des Rechenzentrums dar:
Erstellen Sie einen Superscope für alle Bereiche, die Sie für auf Option 82 basierende Richtlinien verwenden möchten.
Hinweis
Der Superscope sollte alle Bereiche kombinieren und als administrative Grenze fungieren.
Es wird alles sehr prägnant dargestellt:
Nehmen wir an, der Switch verwendet die Adresse aus Subnetz B (es kann das Backbone-Subnetz, das Verwaltungs-Subnetz oder ein beliebiges vom Kunden zugewiesenes 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 Superscope. Innerhalb des Superscope erstellen Sie den Bereich B, S1, S2, S3, …, Sn für das Subnetz B und die Subnetze für jedes Segment.
2. Geben Sie im Bereich B den 'Ausschlussbereich' als den gesamten Adressbereich an (so dass der angebotene Adressbereich nicht aus diesem Bereich stammen darf).
3. Für jeden Segmentbereich Si geben Sie eine Richtlinie an, die mit der Agent Circuit ID übereinstimmt, mit dem Wert '0108000600XXXXXX', wobei '0108000600' ein fester Wert für alle Segmente ist, und die 6 Zahlen "XXXXXX" den Segment-ID-Wert in hexadezimaler Form darstellen. Stellen Sie außerdem sicher, dass das Kontrollkästchen Wildcard (*) anfügen aktiviert ist.
4. Setzen Sie den Richtlinienadressbereich auf den gesamten Bereich des Bereichs.
DHCP in Microsoft Windows Server (Superscope & Richtlinien)
Ein Superscope ist eine administrative Funktion eines DHCP-Servers, die es ermöglicht, mehrere Scopes als eine einzige administrative Einheit zu gruppieren. Ein Superscope erlaubt es einem DHCP-Server, Adressvergaben aus mehr als einem Scope an Clients in einem einzigen physischen Netzwerk bereitzustellen. Scopes, die zu einem Superscope hinzugefügt werden, werden Mitgliedsscop genannt. Was ist ein Superscope – es handelt sich um eine Funktion, die es ermöglicht, mehrere IP-Adresspools in einer administrativen Einheit zusammenzufassen. Damit können IP-Adressen aus mehreren Pools Nutzern in einem einzigen physischen Netzwerk (in einem VLAN) zugewiesen werden. Wenn die Anfrage an einem Pool von Adressen innerhalb des Superscope eingeht, kann die Adresse aus einem anderen Scope, das zu diesem Superscope gehört, zugewiesen werden.
Die Rolle des DHCP-Servers in Windows Server 2012 führt eine neue Funktion ein, mit der Sie IPv4-Richtlinien erstellen können, die benutzerdefinierte IP-Adressen und Optionen für DHCP-Clients basierend auf einer Reihe von Bedingungen festlegen.
Die funktionalitätsbasierte Zuweisung (PBA) ermöglicht es Ihnen, DHCP-Clients nach spezifischen Attributen zu gruppieren, die in den Feldern des DHCP-Client-Anforderungsbereichs enthalten sind. PBA ermöglicht eine gezielte Verwaltung und eine größere Kontrolle über die Konfigurationsparameter, die Netzwerkgeräten mit DHCP bereitgestellt werden. Richtlinien – ermöglichen die Zuweisung von IP-Adressen an Nutzer abhängig vom Benutzertyp oder Parameter. Cisco-Ingenieure nutzen Richtlinien in Windows Server 2012 zur Filterung nach VNI (Virtual Network Identifier).
Hauptteil
In diesem Abschnitt werden die Forschungsergebnisse dargestellt, warum es nicht unterstützt wird, wie es funktioniert (Logik), was neu ist und wie uns diese Neuerung 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 (Option 82) nicht und senden das Rückpaket ohne Option 82.
- Die Anfrage vom Client wird als Broadcast (DHCP Discover) gesendet.
- Die Hardware (Nexus) sendet das Paket an den DHCP-Server (DHCP Discover + Option 82).
- Der DHCP-Server empfängt das Paket, verarbeitet es und sendet es zurück, aber ohne Option 82. (DHCP Offer – ohne Option 82)
- Die Hardware (Nexus) empfängt das Paket vom DHCP-Server. (DHCP Offer) Es wird jedoch nicht an den Endbenutzer weitergeleitet.
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 die Antwort an die Netzwerkausrüstung. (Option 82 fehlt in der Optionsliste im Paket)
Anfrage vom Client – DHCP Discover ist vorhanden und DHCP Offer fehlt
Statistiken zur Netzwerkausrüstung:
NEXUS-9000V-SW-1# zeige ip dhcp relay statistiken
----------------------------------------------------------------------
Nachrichtentyp Empfang Sendung Verworfen
----------------------------------------------------------------------
Entdeckung 8 8 0
Angebot 8 8 0
Anfrage(*) 0 0 0
Bestätigung 0 0 0
Freigabe(*) 0 0 0
Ablehnung 0 0 0
Information(*) 0 0 0
Nack 0 0 0
----------------------------------------------------------------------
Gesamt 16 16 0
----------------------------------------------------------------------
DHCP L3 FWD:
Gesamt empfangene Pakete : 0
Gesamt weitergeleitete Pakete : 0
Gesamt verworfene Pakete : 0
Nicht DHCP:
Gesamt empfangene Pakete : 0
Gesamt weitergeleitete Pakete : 0
Gesamt verworfene Pakete : 0
VERWORFEN:
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
Unbekannter vrf oder Schnittstelle für Server : 0
Maximale Hops überschritten : 0
Option 82 Validierung fehlgeschlagen : 0
Paket fehlerhaft : 0
Relay vertrusteter Port nicht konfiguriert : 0
DHCP-Anfrage auf MCT verworfen : 0
* - Diese Zähler zeigen korrekte Werte an, wenn der Switch
DHCP-Anforderungspaket mit 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) – Linkauswahl) noch nicht unterstützt.
Der Funktionsumfang von Policy ist jedoch bereits implementiert.
So funktioniert es:
- Microsoft Windows Server 2012 verfügt über einen Super-Pool (SuperScope), der Loopback-Adressen sowie Pools für reale Netzwerke umfasst.
- Die Auswahl des Pools zur Vergabe von IP-Adressen fällt in den SuperScope, da die Antwort von einem DHCP-Relay mit der Quelladresse Loopback kam, die in den SuperScope gehört.
- Mit Hilfe von Policy wählt die Anfrage aus dem Superscope den Member-Scope aus, dessen VNI in Option 82 Suboption 1 Agent Circuit ID enthalten ist. ("0108000600" + 24 Bit VNI + 24 Bit von Werten, die mir nicht bekannt sind, wobei der Sniffer 0 in diesem Feld anzeigt.)
Wie wird die Einrichtung in Microsoft Windows Server 2016/2019 vereinfacht?
In Microsoft Windows Server 2016 wurde die Funktionalität von RFC#3527 implementiert. Das bedeutet, dass Windows Server 2016 in der Lage ist, das richtige Netzwerk anhand des Attributs Option 82 Suboption 5(0x5) – Linkauswahl zu erkennen.
Es ergeben sich sofort drei Fragen:
- Können wir auf den Superscope verzichten?
- Können wir auf Policy und die Umwandlung von VNI in eine hexadezimale Darstellung verzichten?
- Können wir auf den Scope für Loopback-Adressen von DHCP-Quellen verzichten?
Q. Können wir auf den Superscope verzichten?
A. Ja, Scopes können direkt im Bereich der IPv4-Adressen erstellt werden.
Q. Können wir auf Policy und die Umwandlung von VNI in eine hexadezimale Darstellung verzichten?
A. Ja, die Auswahl des Netzwerks erfolgt basierend auf Option 82 Suboption 0x5.
Q. Können wir auf den Scope für Loopback-Adressen von DHCP-Quellen verzichten?
A. Nein, das können wir nicht. In Microsoft Windows Server 2016/2019 gibt es einen Schutz gegen böswillige DHCP-Anfragen. Das heißt, alle Anfragen von Adressen, die nicht im DHCP-Server-Pool enthalten sind, werden als böswillig betrachtet.
Hinweis
Alle IP-Adressen des Relay-Agenten (GIADDR) müssen Teil eines aktiven DHCP-Bereichs sein. Jede GIADDR außerhalb der IP-Adressbereiche des DHCP-Scopes wird als unerwünschter Relay angesehen, und der Windows-DHCP-Server wird keine DHCP-Clientanfragen von diesen Relay-Agenten anerkennen.
Ein spezieller Bereich kann erstellt werden, um Relay-Agenten zu "autorisieren". Erstellen Sie einen Bereich mit der GIADDR (oder mehreren, wenn die GIADDR aufeinanderfolgende IP-Adressen sind), schließen Sie die GIADDR-Adressen von der Verteilung aus und aktivieren Sie dann den Bereich. Dadurch werden die Relay-Agenten autorisiert, während verhindert wird, dass die GIADDR-Adressen zugewiesen werden.Das heißt, um einen DHCP-Pool für eine VXLAN BGP EVPN-Fabrik auf Microsoft Windows Server 2016/2019 einzurichten, sind nur folgende Schritte erforderlich:
- Erstellen Sie einen Pool für die Quelladressen des Relay.
- Erstellen Sie einen Pool für die Clientnetzwerke.
Was nicht erforderlich ist (aber konfiguriert werden kann und funktioniert, ohne die Funktionalität zu beeinträchtigen):
- Policies erstellen
- SuperScope erstellen
BeispielBeispiel für die Konfiguration eines DHCP-Servers (es sind 2 reale DHCP-Clients vorhanden — 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 Policies — zum Nachweis, dass die Policies nicht für das ordnungsgemäße Funktionieren des Pools verwendet wurden):
Beispiel für die Konfiguration eines Pools für die Source-Adressen des DHCP Relays (der Adressbereich zur Vergabe entspricht vollständig den Ausnahmen des Adresspools):
Einrichtung 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.
Wir fügen Ausnahmen hinzu. Der Bereich der Ausnahmen muss vollständig mit dem Bereich des Pools übereinstimmen.
Leasingdauer. „Weiter >“
Frage: Möchten Sie jetzt die DHCP-Optionen konfigurieren (DNS, WINS, Gateway, Domain) oder später? Es ist schneller, nein zu antworten und den Pool später manuell zu aktivieren. Oder Sie können einfach bis zum Ende gehen, ohne Informationen auszufüllen, und am Ende des Assistenten den Pool aktivieren.
Wir bestätigen, dass die Optionen nicht konfiguriert sind, der Pool nicht aktiviert ist. „Fertig“
Wir aktivieren den Pool manuell. — Wählen Sie Scope und im Kontextmenü — wählen Sie „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.
Wir fügen Ausnahmen hinzu. (Standardmäßig sind keine Ausnahmen erforderlich) „Weiter >“
Leasingdauer. „Weiter >“
Frage: Möchten Sie jetzt die DHCP-Optionen konfigurieren (DNS, WINS, Gateway, Domain) oder später? Ja, wir konfigurieren 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 des Scopes.
Pool ist konfiguriert. „Fertig“
Fazit
Die Verwendung von Windows Server 2016/2019 vereinfacht die Konfiguration des DHCP-Servers für die VXLAN-Fabrik (oder jede andere Fabrik). (Es ist kein spezielles IT-Fachwissen erforderlich: Network/Agent Circuit ID für die Filterkonfiguration.)
Wird die Konfiguration für Windows Server 2012 auf den neuen Servern 2016/2019 funktionieren? – ja, sie wird funktionieren.
In diesem Dokument sind Links zu 2 Versionen enthalten: 7.X und 9.3. Dies liegt daran, dass Version 7.0(3)I7(7) — Cisco empfohlene Version ist, während Version 9.3 die innovativste ist (einschließlich Unterstützung für Multicast über VXLAN Multisite).
Quellenverzeichnis
Quelle: habr.com
