Syftet med denna artikel är att förenkla installationen av DHCP-tjänsten för VXLAN BGP EVPN och DFA-fabriken med hjälp av Microsoft Windows Server 2016/2019.
I den officiella dokumentationen konfigureras DHCP-tjänsten baserad på Microsoft Windows Server 2012 för fabriken som ett SuperScope, som innehåller en Loopback-pool (denna pool har det unika att alla IP-adresser från poolen exkluderas (excluded IP address = pool)) och IP-adressutdelningspooler för de verkliga nätverken (här är det unika att policyer ställs in – där DHCP Relay Circuit ID filtreras och detta DHCP relay Circuit ID innehåller VNI för nätverket, det vill säga för en annan pool kommer detta DHCP Relay Circuit ID att vara något annorlunda).
För att konfigurera DHCP på Windows-servern.
1. Skapa en super scope. Inom super scope, skapa scope B, S1, S2, S3, …, Sn för subnet B och subnät för varje segment.
2. I scope B, ange 'Exclusion Range' till att vara hela adressintervallet (så att det erbjudna adressintervallet inte får vara från denna scope).
3. För varje segment scope Si, ange en policy som matchar på Agent Circuit ID med värdet '0108000600XXXXXX', där '0108000600' är ett fast värde för alla segment, de 6 siffrorna "XXXXXX" är segment-ID-värdet i hexadecimalt format. Kontrollera även att kryssrutan för Append wildcard(*) är markerad.
4. Ställ in policyadressintervallet till hela intervallet för scope.Denna artikel innehåller svar på följande frågor:
Innehåll
- ( & )
Introduktion
I denna del listas alla ursprungliga data kortfattat: Instruktioner för konfiguration av nätverksutrustning, RFC som används i DHCP-paket i eVPN-fabriker, en översikt över utvecklingen av DHCP-serverinställningar på Microsoft Windows Server 2012 i Cisco-dokumentationen. Dessutom kort information om Superscope och Policy i DHCP-tjänsten på Microsoft Windows Server.
Hur konfigureras DHCP Relay på VXLAN BGP EVPN, DFA?
Konfiguration av DHCP Relay på VXLAN BGP EVPN-fabriken är inte huvudämnet för denna artikel, eftersom det är ganska enkelt. Jag ger länkar till dokumentation och en sammanfattning av inställningarna på nätverksutrustningen.
Exempel på konfiguration av DHCP Relay på Nexus 9000V v9.2(3)
tjänst dhcp
ip dhcp relay
ip dhcp relay information option
ip dhcp relay information option vpn
interface loopback10
vrf medlem VRF1
ip adress 10.120.0.1/32 tag 1234567
interface Vlan12
no shutdown
vrf medlem VRF1
no ip redirects
ip adress 10.120.251.1/24 tag 1234567
no ipv6 redirects
fabric forwarding mode anycast-gateway
ip dhcp relay adress 10.0.0.5
ip dhcp relay source-interface loopback10
RFC som implementeras i arbetet med DHCP Relay-tjänsten i VXLAN BGP EVPN-fabriker
RFC#6607: Sub-option 151(0x97) — Virtuell subnetval
• Sub-option 151(0x97) - Virtuell subnetval (Definierad i RFC#6607)
Används för att överföra VRF-relaterad information till DHCP-servern i en MPLS-VPN och VXLAN EVPN multi-tenant miljö.Namnet på VRF som klienten befinner sig i överförs.
RFC#5107: Sub-option 11(0xb) — Server ID Override
• Sub-option 11(0xb) - Server ID Override (Definierad i RFC#5107.)
Serveridentifieraren (server ID) override sub-option gör att DHCP-reläagenten kan specificera ett nytt värde för server ID-optionen, som sätts in av DHCP-servern i svaret. Denna sub-option gör att DHCP-reläagenten kan agera som den verkliga DHCP-servern så att förnyelseförfrågningar kommer till reläagenten istället för till DHCP-servern direkt. Server ID override sub-option innehåller den inkommande gränssnitts-IP-adressen, som är IP-adressen på reläagenten som är tillgänglig för klienten. Med denna information skickar DHCP-klienten alla förnyelse- och avbeställningsförfrågningspaket till reläagenten. Reläagenten lägger till alla lämpliga sub-options och vidarebefordrar sedan förnyelse- och avbeställningsförfrågningspaketen till den ursprungliga DHCP-servern. För denna funktion är Cisco's proprietära implementation sub-option 152(0x98). Du kan använda kommandot ip dhcp relay sub-option type cisco för att hantera funktionen.Alternativet används för att klienten ska skicka en begäran om att förlänga hyresavtalet för den IP-adress som används i detta alternativ. (I Cisco VXLAN BGP EVPN – detta är Anycast-adressen för gatewayen som används som standard av klienten.)
RFC#3527: Sub-option 5(0x5) — Länkval
Sub-option 5(0x5) - Länkval (Definierad i RFC#3527.)
Länkval sub-option tillhandahåller en mekanism för att separera subnettet/länken som DHCP-klienten befinner sig i från gatewayadressen (giaddr), som kan användas för att kommunicera med reläagenten av DHCP-servern. Reläagenten kommer att sätta sub-optionen till rätt abonnent-subnet och DHCP-servern kommer att använda det värdet för att tilldela en IP-adress istället för giaddr-värdet. Reläagenten kommer att sätta giaddr till sin egen IP-adress så att DHCP-meddelanden kan vidarebefordras över nätverket. För denna funktion är Cisco's proprietära implementation sub-option 150(0x96). Du kan använda kommandot ip dhcp relay sub-option type cisco för att hantera funktionen.Nätverksadressen från vilken klienten behöver en IP-adress.
Evolutionen av Cisco-dokumentationen kring DHCP-installation på Microsoft Windows Server 2012.
Jag inkluderade detta avsnitt eftersom det finns en positiv trend från leverantören:
Dokumentationen innehåller endast konfigurationen av DHCP Relay på nätverksutrustning.
För att ställa in DHCP på Windows Server 2012 användes en annan artikel:
Denna artikel anger att för varje nätverk/VNI behövs en egen SuperScope-koppling och en egen uppsättning Loopback-adresser:
Om flera DHCP-scopes krävs för flera subnät måste du skapa en LoopbackX per subnet/vlan på alla LEAFS och skapa en superscope med ett loopbackX-område och det faktiska klient-IP-subnetområdet per vlan.
Vi har lagt till inställningar för Windows 2012 Server i dokumentationen för nätverksutrustningskonfiguration. För alla använda adresspooler behövs en SuperScope på datacentret och denna SuperScope är gränsen för datacentret:
Skapa Superscope för alla scopes som du vill använda för Option 82-baserade policys.
Obs!
Superscope ska kombinera alla scopes och fungera som den administrativa gränsen.
Mycket kort beskrivet om allt:
Anta att switchen använder adressen från subnet B (det kan vara backbone-subnet, management-subnet, eller något kundbetecknat subnet för detta ändamål) för att kommunicera med Windows DHCP-servern. I DFA har vi subnät S1, S2, S3, …, Sn för segment s1, s2, s3, …, sn.
För att konfigurera DHCP på Windows-server.
1. Skapa en superscope. Inom superscopen, skapa scope B, S1, S2, S3, …, Sn för subnet B och subnät för varje segment.
2. I scope B, specificera 'Exkluderingsområde' till att vara hela adressområdet (så att det erbjudna adressområdet inte får komma från denna scope).
3. För varje segment scope Si, specificera en policy som matchar Agent Circuit ID med värdet '0108000600XXXXXX', där '0108000600' är ett fast värde för alla segment, de 6 siffrorna "XXXXXX" är segment-ID-värdet i hexadecimal. Kontrollera också att välja kryssrutan för Append wildcard(*).
4. Ställ in policy-adressområdet till hela området för scopen.
DHCP i Microsoft Windows Server (superscope & policy)
Superscope är en administrativ funktion på en DHCP-server som kan användas för att gruppera flera scopes som en enda administrativ enhet. Superscope gör det möjligt för en DHCP-server att tillhandahålla leasingar från mer än en scope till klienter på ett enda fysiskt nätverk. Scopes som läggs till en superscope kallas medlems-scopes. Vad är SuperScope – det är en funktion som gör det möjligt att kombinera flera IP-adresspooler till en administrativ enhet. För att annonsera IP-adresser från flera pooler till användare i ett fysiskt nätverk (i en VLAN). Om en begäran kommer till en adresspool inom en SuperScope, kan adressen utfärdas till klienten från en annan scope som ingår i denna SuperScope.
DHCP-serverrollen i Windows Server 2012 introducerar en ny funktion som låter dig skapa IPv4-policys som specificerar anpassade IP-adress- och alternativstilldelningar för DHCP-klienter baserat på en uppsättning villkor.
Den policybaserade tilldelningsfunktionen (PBA) gör det möjligt att gruppera DHCP-klienter efter specifika egenskaper baserat på fält i DHCP-klientens begärningspaket. PBA möjliggör målinriktad administration och större kontroll över de konfigurationsparametrar som överförs till nätverksenheter med DHCP. Policys – de tillåter att tilldela IP-adresser till användare baserat på användartyp eller parameter. Cisco-ingenjörer använder policies i Windows Server 2012 för filtrering baserat på VNI (Virtual Network Identifier).
Huvuddel
I det här avsnittet presenteras resultaten av forskningen om varför det inte stöds, hur det fungerar (logik), vad som är nytt och hur dessa nyheter kan hjälpa oss.
Varför stöds inte Microsoft Windows Server 2000/2003/2008?
Microsoft Windows Server 2008 och äldre versioner hanterar inte alternativ 82 (Option 82) och skickar tillbaka paketet utan alternativ 82.
- Begäran från klienten skickas som Broadcast (DHCP Discover).
- Utrustningen (Nexus) skickar paketet till DHCP-servern (DHCP Discover + Option 82).
- DHCP-servern tar emot paketet, bearbetar det och skickar tillbaka, men utan alternativ 82. (DHCP Offer – utan option 82)
- Utrustningen (Nexus) tar emot paketet från DHCP-servern. (DHCP Offer) Men skickar inte detta paket till slutkunden.
Snifferdata — på Windows Server 2008 och på DHCP-klientenWindows Server 2008 får begäran från nätverksutrustningen. (Option 82 finns i listan)
Windows Server 2008 skickar svar till nätverksutrustningen. (Option 82 saknas i paketets optionslista)
Begäran från klienten – DHCP Discover finns och DHCP Offer saknas
Statistik på nätverksutrustningen:
NEXUS-9000V-SW-1# show ip dhcp relay statistics
----------------------------------------------------------------------
Message Type 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:
Total Packets Received : 0
Total Packets Forwarded : 0
Total Packets Dropped : 0
Non DHCP:
Total Packets Received : 0
Total Packets Forwarded : 0
Total Packets Dropped : 0
DROP:
DHCP Relay not enabled : 0
Invalid DHCP message type : 0
Interface error : 0
Tx failure towards server : 0
Tx failure towards client : 0
Unknown output interface : 0
Unknown vrf or interface for server : 0
Max hops exceeded : 0
Option 82 validation failed : 0
Packet Malformed : 0
Relay Trusted port not configured : 0
DHCP Request dropped on MCT : 0
* - Dessa räknare visar korrekt värde när switchen
tar emot DHCP-begäran med destinations-IP som broadcast
adress. Om begäran är unicast kommer den att växlas HW
NEXUS-9000V-SW-1#
Varför är installationen så komplicerad i Microsoft Windows Server 2012?
I Microsoft Windows Server 2012 stöds ännu inte RFC#3527 (Option 82 Sub-option 5(0x5) — Link Selection)
Men funktionen Policy har redan implementerats.
Så här fungerar det:
- I Microsoft Windows Server 2012 finns det en super-pool (SuperScope) som innehåller Loopback-adresser och pooler för verkliga nätverk.
- Valet av pool för utdelning av IP-adresser hamnar i SuperScope eftersom svaret kom från DHCP Relay med källadress Loopback, som ingår i SuperScope.
- Genom att använda Policy väljer förfrågan från Superscope den medlemsomfång vars VNI finns i Option 82 Suboption 1 Agent Circuit ID. ("0108000600" + 24 bitar VNI + 24 bitar av värden som jag inte känner till, men sniffaren visar värden 0 i detta fält.)
Hur förenklas installationen i Microsoft Windows Server 2016/2019?
I Microsoft Windows Server 2016 implementerades funktionen RFC#3527. Det vill säga Windows Server 2016 kan känna igen rätt nätverk från attributet Option 82 Sub-option 5(0x5) — Link Selection.
Tre frågor uppstår genast:
- Kan vi klara oss utan Superscope?
- Kan vi klara oss utan Policy och konvertering av VNI till hexadecimalt format?
- Kan vi klara oss utan Scope för Loopback-adresser DHCP Source?
Q. Kan vi klara oss utan Superscope?
A. Ja, scope kan skapas direkt inom IPv4-adressområden.
Q. Kan vi klara oss utan Policy och konvertering av VNI till hexadecimalt format?
A. Ja, nätverksvalet sker baserat på Option 82 Suboption 0x5.
Q. Kan vi klara oss utan Scope för Loopback-adresser DHCP Source?
A. Nej, vi kan inte. Eftersom Microsoft Windows Server 2016/2019 har skydd mot illvilliga DHCP-förfrågningar. Det vill säga alla förfrågningar från adresser som inte finns i DHCP-serverns pool anses vara illvilliga.
Notera
Alla relay-agent IP-adresser (GIADDR) måste vara en del av ett aktivt DHCP-scope IP-adressområde. Alla GIADDR utanför DHCP-scope IP-adressområdena betraktas som en rogue relay och Windows DHCP-servern kommer inte att erkänna DHCP-klienters förfrågningar från dessa relay-agenter.
Ett särskilt scope kan skapas för att "auktorisera" relay-agenter. Skapa ett scope med GIADDR (eller flera om GIADDR:erna är sekventiella IP-adresser), uteslut GIADDR-adressen (-erna) från distribution, och aktivera sedan scopet. Detta kommer att auktorisera relay-agenterna samtidigt som GIADDR-adresserna förhindras att tilldelas.Det vill säga, för att konfigurera en DHCP-pool på Microsoft Windows Server 2016/2019 för VXLAN BGP EVPN-fabriken behövs endast:
- Skapa en pool för källadresser från Relay.
- Skapa en pool för klientnätverk.
Vad som inte är nödvändigt (men kan konfigureras och det kommer att fungera, och inte störa funktionen):
- Skapa Policy.
- Skapa SuperScope.
ExempelExempel på konfiguration av DHCP-server (det finns 2 verkliga DHCP-klienter — klienter kopplade till VXLAN-fabriken)
Exempel på konfiguration av en anpassad pool:
Exempel på konfiguration av en anpassad pool (policys valda — för att bevisa att policies inte användes för korrekt funktion av poolen):
Exempel på konfiguration av en pool för källadresser från DHCP Relay (adressintervallet för utdelning överensstämmer helt med undantaget från adresspoolen):
Installation av DHCP-tjänsten på Microsoft Windows Server 2019.
Konfigurera pool för Loopback-adresser (källa) för DHCP Relay.
Skapa en ny pool (Scope) i IPv4-området.
Guiden för att skapa en pool. "Nästa >"
Konfigurera poolens namn och beskrivning (Description).
Ange IP-adressintervall för Loopback och mask för poolen.
Lägg till undantag. Undantagsintervallet måste matcha poolens intervall helt.
Hyrestid. "Nästa >"
Förfrågan: Kommer du att konfigurera DHCP-alternativ nu (DNS, WINS, Gateway, Domän) eller gör du det senare? Det snabbaste svaret är nej, och sedan aktivera poolen manuellt. Annars kan du gå till slutet utan att fylla i någon information och aktivera poolen vid slutet av guiden.
Vi bekräftar att alternativen inte är inställda, poolen är inte aktiverad. "Avsluta"
Aktivera poolen manuellt. – Välj Scope och i kontextmenyn – välj "Aktivera".
Skapa en pool för användare/servrar.
Skapa en ny pool.
Guiden för att skapa en pool. "Nästa >"
Konfigurera poolens namn och beskrivning (Description).
Ange IP-adressintervall för Loopback och mask för poolen.
Lägg till undantag. (Som standard behövs inga undantag) "Nästa >"
Hyrestid. "Nästa >"
Förfrågan: Kommer du att konfigurera DHCP-alternativ nu (DNS, WINS, Gateway, Domän) eller gör du det senare? Ja, vi konfigurerar nu.
Konfigurera standardgateway-adressen.
Konfigurera domänen och adresserna för DNS-servrar.
Konfigurera IP-adresser för WINS-servrar.
Aktivering av Scope.
Poolen är konfigurerad. "Avsluta"
Slutsats
Att använda Windows Server 2016/2019 minskar komplexiteten i att konfigurera DHCP-servern för VXLAN-fabriken (eller någon annan fabrik). (Ingen särskild överföring av IT-specialister krävs: Network/Agent Circuit ID för att skriva filtren.)
Kommer konfigurationen för Windows Server 2012 att fungera på de nya servrarna 2016/2019 – ja, det kommer att fungera.
Detta dokument innehåller länkar till 2 versioner: 7.X och 9.3. Detta beror på att version 7.0(3)I7(7) är Cisco föreslagen version, medan version 9.3 är den mest innovativa (inklusive stöd för Multicast via VXLAN Multisite).
Källförteckning
Källa: habr.com
