🥇Configuration de Microsoft Windows Server 2016/2019 pour fournir des services DHCP pour VXLAN (DFA)

L'objectif de cet article est de simplifier la configuration du service DHCP pour l'usine VXLAN BGP EVPN et DFA en utilisant Microsoft Windows Server 2016/2019.

Dans la documentation officielle, le service DHCP basé sur Microsoft Windows Server 2012 pour l'usine est configuré comme SuperScope, contenant un pool Loopback (dans ce pool, la particularité est l'exclusion de tous les adresses IP du pool (excluded IP address = pool)) et des pools d'attribution d'adresses IP pour les réseaux réels (ici, la particularité est que des politiques sont configurées – qui filtrent l'ID de circuit de relais DHCP et que cet ID de circuit relais DHCP contient VNI pour le réseau, c'est-à-dire que pour un autre pool, cet ID de relais DHCP sera légèrement différent).

Pour configurer DHCP sur un serveur Windows. 

1. Créer un super scope. À l'intérieur du super scope, créer le scope B, S1, S2, S3, …, Sn pour le sous-réseau B et les sous-réseaux pour chaque segment. 
2. Dans le scope B, spécifiez la 'Plage d'Exclusion' pour être la totalité de la plage d'adresses (afin que la plage d'adresses offertes ne provienne pas de ce scope). 
3. Pour chaque scope segment Si, spécifiez une politique qui correspond à l'ID de circuit d'agent avec la valeur '0108000600XXXXXX', où '0108000600' est une valeur fixe pour tous les segments, les 6 chiffres "XXXXXX" étant la valeur de l'ID segment en hexadécimal. Assurez-vous aussi de cocher la case Append wildcard(*). 
4. Définissez la plage d'adresses de la politique sur l'ensemble de la plage du scope.

Cet article contient des réponses aux questions suivantes :

Contenu

Introduction
Partie principale
Conclusion
Liste des sources

Introduction

Cette section énumère brièvement toutes les données sources : Instructions pour la configuration de l'équipement réseau, RFC utilisés dans les paquets DHCP dans les usines eVPN, ainsi qu'une évolution des configurations du serveur DHCP sur Microsoft Windows Server 2012 dans la documentation Cisco. De plus, un aperçu bref sur Superscope et Policy dans le service DHCP sur les serveurs Microsoft Windows Server.

Comment configurer le relais DHCP sur l'usine VXLAN BGP EVPN, DFA

La configuration du relais DHCP sur l'usine VXLAN BGP EVPN n'est pas le sujet principal de cet article, car elle est relativement simple. Je fournis des liens vers la documentation et un aperçu des configurations sur l'équipement réseau.

Exemple de configuration du relais DHCP sur Nexus 9000V v9.2(3)

service dhcp
ip dhcp relay
ip dhcp relay information option
ip dhcp relay information option vpn
interface loopback10
  vrf member VRF1
  ip address 10.120.0.1/32 tag 1234567
interface Vlan12
  no shutdown
  vrf member VRF1
  no ip redirects
  ip address 10.120.251.1/24 tag 1234567
  no ipv6 redirects
  fabric forwarding mode anycast-gateway
  ip dhcp relay address 10.0.0.5
  ip dhcp relay source-interface loopback10

RFC mises en œuvre dans le service DHCP Relay dans les usines VXLAN BGP EVPN

RFC#6607: Sous-option 151(0x97) — Sélection de sous-réseau virtuel

•	Sous-option 151(0x97) - Sélection de sous-réseau virtuel (Définie dans RFC#6607)
Utilisée pour transmettre des informations relatives au VRF au serveur DHCP dans un environnement multi-locataire MPLS-VPN et VXLAN EVPN.

Le « nom » du VRF dans lequel se trouve le client est transmis.

RFC#5107: Sous-option 11(0xb) — Remplacement de l'ID du serveur

•	Sous-option 11(0xb) - Remplacement de l'ID du serveur (Définie dans RFC#5107.) 
La sous-option de remplacement de l'identifiant du serveur (ID serveur) permet à l'agent de relais DHCP de spécifier une nouvelle valeur pour l'option d'ID serveur, qui est insérée par le serveur DHCP dans le paquet de réponse. Cette sous-option permet à l'agent de relais DHCP d'agir en tant que véritable serveur DHCP de sorte que les demandes de renouvellement parviennent à l'agent de relais plutôt qu'au serveur DHCP directement. La sous-option de remplacement de l'ID du serveur contient l'adresse IP de l'interface entrante, qui est l'adresse IP sur l'agent de relais accessible par le client. À l'aide de ces informations, le client DHCP envoie toutes les demandes de renouvellement et de libération à l'agent de relais. L'agent de relais ajoute toutes les sous-options appropriées, puis transmet les paquets de renouvellement et de libération au serveur DHCP d'origine. Pour cette fonction, l'implémentation propriétaire de Cisco est la sous-option 152(0x98). Vous pouvez utiliser la commande ip dhcp relay sub-option type cisco pour gérer cette fonction.

L'option est utilisée pour permettre au client d'envoyer une demande de renouvellement de bail d'adresse vers l'adresse IP utilisée dans cette option. (Dans Cisco VXLAN BGP EVPN – c'est l'adresse anycast du gateway par défaut pour le client.)

RFC#3527: Sous-option 5(0x5) — Sélection de lien

Sous-option 5(0x5) - Sélection de lien (Définie dans RFC#3527.) 

La sous-option de sélection de lien fournit un mécanisme pour séparer le sous-réseau/lien sur lequel se trouve le client DHCP de l'adresse de passerelle (giaddr), qui peut être utilisée pour communiquer avec l'agent de relais par le serveur DHCP. L'agent de relais définira la sous-option au bon sous-réseau d'abonné et le serveur DHCP utilisera cette valeur pour attribuer une adresse IP plutôt que la valeur giaddr. L'agent de relais définira le giaddr à sa propre adresse IP afin que les messages DHCP puissent être transférés sur le réseau. Pour cette fonction, l'implémentation propriétaire de Cisco est la sous-option 150(0x96). Vous pouvez utiliser la commande ip dhcp relay sub-option type cisco pour gérer cette fonction.

Adresse réseau à partir de laquelle le client a besoin d'une adresse IP.

Évolution de la documentation Cisco concernant la configuration du DHCP sur Microsoft Windows Server 2012

J'ai inclus cette section car il existe une tendance positive de la part du fournisseur :

Nexus 9000 Guide de configuration VXLAN 7.3

La documentation fournit uniquement la configuration de DHCP Relay sur le matériel réseau.

Un autre article a été utilisé pour configurer DHCP sur Windows Server 2012 :

Configuration de Microsoft Windows Server 2012 pour fournir des services DHCP dans un scénario eVPN (VXLAN, Cisco One Fabric, etc.)

Cet article indique qu'un lien SuperScope et un jeu d'adresses Loopback sont nécessaires pour chaque réseau/VNI :

Si plusieurs plages DHCP sont nécessaires pour plusieurs sous-réseaux, vous devez créer une LoopbackX par sous-réseau/vlan sur tous les LEAFS et créer un superscope avec une plage LoopbackX et une plage de sous-réseau client IP par vlan.

Guide de Configuration VXLAN Nexus 9000 9.3

Nous avons ajouté les paramètres du serveur Windows 2012 à la documentation sur la configuration du matériel réseau. Un seul SuperScope est nécessaire pour tous les pools d'adresses utilisés dans le Data Center, et ce SuperScope constitue la frontière du Data Center :

Créez un Superscope pour toutes les plages que vous souhaitez utiliser pour les politiques basées sur l'Option 82.
Note
Le Superscope doit combiner toutes les plages et agir comme la limite administrative.

Automatisation des Fabrications Dynamiques Cisco

Tout est expliqué de manière concise :

Supposons que le commutateur utilise l'adresse du sous-réseau B (il peut s'agir du sous-réseau de backbone, du sous-réseau de gestion ou de tout sous-réseau désigné par le client à cette fin) pour communiquer avec le serveur DHCP Windows. Dans DFA, nous avons des sous-réseaux S1, S2, S3, …, Sn pour les segments s1, s2, s3, …, sn.

Pour configurer le DHCP sur le serveur Windows.

1. Créez un super scope. Dans le super scope, créez la plage B, S1, S2, S3, …, Sn pour le sous-réseau B et les sous-réseaux pour chaque segment.
2. Dans la plage B, spécifiez la 'Plage d'Exclusion' pour être l'ensemble de la plage d'adresses (de sorte que la plage d'adresses offerte ne doit pas provenir de cette plage).
3. Pour chaque plage de segment Si, spécifiez une politique qui correspond à l'ID de Circuit d'Agent avec la valeur '0108000600XXXXXX', où '0108000600' est une valeur fixe pour tous les segments, les 6 chiffres "XXXXXX" est la valeur d'identification du segment en hexadecimal. Veillez également à cocher la case d'Ajouter le caractère générique (*).
4. Définissez la plage d'adresses de la politique pour être l'ensemble de la plage de la plage.

DHCP dans Microsoft Windows Server (superscope & politique)

SuperScope

Le Superscope est une fonctionnalité administrative d'un serveur DHCP qui peut être utilisée pour regrouper plusieurs plages en une seule entité administrative. Le Superscope permet à un serveur DHCP de fournir des leases provenant de plus d'une plage à des clients sur un réseau physique unique. Les plages ajoutées à un superscope s'appellent des plages membres.

Qu'est-ce que le SuperScope – c'est une fonctionnalité qui permet de regrouper plusieurs pools d'adresses IP en une seule unité administrative. Cela permet d'annoncer aux utilisateurs d'un même réseau physique (dans un même VLAN) des adresses IP provenant de plusieurs pools. Si une demande parvient à un pool d'adresses faisant partie du SuperScope, il est possible d'attribuer une adresse à un client issue d'un autre Scope intégré dans ce SuperScope.

Politique

Le rôle du serveur DHCP dans Windows Server 2012 introduit une nouvelle fonctionnalité qui vous permet de créer des politiques IPv4 spécifiant des attributions d'adresses IP et d'options personnalisées pour les clients DHCP en fonction d'un ensemble de conditions.

La fonctionnalité d'attribution basée sur la politique (PBA) vous permet de regrouper les clients DHCP en fonction d'attributs spécifiques basés sur les champs contenus dans le paquet de demande du client DHCP. La PBA permet une administration ciblée et un meilleur contrôle des paramètres de configuration fournis aux appareils réseau avec DHCP.

Les politiques – permettent d'attribuer des adresses IP aux utilisateurs en fonction du type d'utilisateur ou d'un paramètre. Les ingénieurs Cisco utilisent des politiques dans Windows Server 2012 pour filtrer par VNI (Identifiant de Réseau Virtuel).

Partie principale

Cette section présente les résultats de recherches sur les raisons pour lesquelles cela n'est pas pris en charge, comment cela fonctionne (logique), ce qui est nouveau et comment cela peut nous aider.

Pourquoi Microsoft Windows Server 2000/2003/2008 n'est-il pas pris en charge ?

Microsoft Windows Server 2008 et les versions antérieures ne traitent pas l'option 82 (Option 82) et renvoient le paquet sans cette option.

Problème DHCP Win2k8 R2 avec Option82

La demande du client est envoyée en Broadcast (DHCP Discover).
L'équipement (Nexus) envoie un paquet au serveur DHCP (DHCP Discover + Option 82).
Le serveur DHCP reçoit le paquet, le traite et renvoie, mais sans option 82. (DHCP Offer – sans option 82)
L'équipement (Nexus) reçoit un paquet du serveur DHCP. (DHCP Offer) Mais ne renvoie pas ce paquet à l'utilisateur final.

Données du sniffer — sur Windows Server 2008 et sur le client DHCPWindows Server 2008 reçoit une demande de l'équipement réseau. (L'Option 82 est présente dans la liste)

Windows Server 2008 envoie une réponse à l'équipement réseau. (L'Option 82 est absente de la liste des options dans le paquet)

Demande du client – présence de DHCP Discover et absence de DHCP Offer

Statistiques sur l'équipement réseau :

NEXUS-9000V-SW-1# show ip dhcp relay statistics 
----------------------------------------------------------------------
Type de message             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 de paquets reçus                           :         0
Total de paquets transférés                      :         0
Total de paquets tombés                           :         0
Non DHCP:
Total de paquets reçus                           :         0
Total de paquets transférés                      :         0
Total de paquets tombés                           :         0
DROP:
DHCP Relay non activé                           :         0
Type de message DHCP invalide                    :         0
Erreur d'interface                                :         0
Échec de Tx vers le serveur                      :         0
Échec de Tx vers le client                      :         0
Interface de sortie inconnue                     :         0
VRF ou interface inconnue pour le serveur         :         0
Hops maximum dépassé                              :         0
Validation de l'option 82 échouée                :         0
Paquet malformé                                   :         0
Port fiable de relay non configuré                :         0
Demande DHCP tombée sur MCT                      :         0
*  -  Ces compteurs afficheront la valeur correcte lorsque le switch 
recevra un paquet de demande DHCP avec une adresse IP de destination en broadcast.
Si la demande est unicast, elle sera commutée par HW
NEXUS-9000V-SW-1#

Pourquoi la configuration dans Microsoft Windows Server 2012 est-elle si complexe ?

Dans Microsoft Windows Server 2012, RFC#3527 (Option 82 Sous-option 5(0x5) — Sélection de la liaison) n'est pas encore pris en charge.
Cependant, la fonctionnalité Policy est déjà mise en œuvre.

Comment cela fonctionne :

Microsoft Windows Server 2012 dispose d'un sur-pool (SuperScope) qui contient des adresses Loopback et des pools pour des réseaux réels.
Le choix du pool pour la distribution d'adresses IP est inscrit dans le SuperScope, car la réponse provient d'un DHCP Relay avec une adresse source Loopback, faisant partie du SuperScope.
En utilisant Policy, la requête choisit parmi le Superscope le membre scope dont le VNI est contenu dans l'Option 82 Sous-option 1 Agent Circuit ID. (“0108000600” + 24 bits de VNI + 24 bits de valeurs que je ne connais pas, mais un sniffer montre des valeurs 0 dans ce champ.)

Comment la configuration est-elle simplifiée dans Microsoft Windows Server 2016/2019 ?

Dans Microsoft Windows Server 2016, la fonctionnalité RFC#3527 est mise en œuvre. C'est-à-dire que Windows Server 2016 peut reconnaître le bon réseau à partir de l'attribut Option 82 Sous-option 5(0x5) — Sélection de la liaison.

Trois questions se posent immédiatement :

Pouvons-nous nous passer de Superscope ?
Pouvons-nous nous passer de Policy et de la conversion du VNI en format hexadécimal ?
Pouvons-nous nous passer de Scope pour les adresses Loopback DHCP Source ?

Q. Pouvons-nous nous passer de Superscope ?
R. Oui, le scope peut être créé directement dans la zone des adresses IP IPv4.
Q. Pouvons-nous nous passer de Policy et de la conversion du VNI en format hexadécimal ?
R. Oui, le choix du réseau se fait sur la base de l'Option 82 Sous-option 0x5.
Q. Pouvons-nous nous passer de Scope pour les adresses Loopback DHCP Source ?
R. Non, nous ne pouvons pas. Car dans Microsoft Windows Server 2016/2019, une protection contre les requêtes DHCP malveillantes est en vigueur. C'est-à-dire que toutes les requêtes provenant d'adresses qui ne sont pas dans le pool du serveur DHCP sont considérées comme malveillantes.

Options de sélection de sous-réseau DHCP

 Remarque
Tous les adresses IP des agents de relais (GIADDR) doivent faire partie d'une plage d'adresses IP active dans un scope DHCP. Toute GIADDR en dehors des plages d'adresses IP du scope DHCP est considérée comme un relais indésirable et le serveur DHCP de Windows ne reconnaîtra pas les demandes des clients DHCP provenant de ces agents de relais.

Un scope spécial peut être créé pour "autoriser" les agents de relais. Créez un scope avec le GIADDR (ou plusieurs si les GIADDR sont des adresses IP séquentielles), excluez les adresses GIADDR de la distribution, puis activez le scope. Cela autorisera les agents de relais tout en empêchant l'attribution des adresses GIADDR.

C'est-à-dire que pour configurer un pool DHCP pour une usine VXLAN BGP EVPN sur Microsoft Windows Server 2016/2019, il est seulement nécessaire :

De créer un pool pour les adresses sources des relais.
De créer un pool pour les réseaux clients.

Ce qui n'est pas nécessaire (mais peut être configuré et cela fonctionnera et ne nuira pas au bon fonctionnement) :

De créer une Policy.
De créer un SuperScope.

ExempleExemple de configuration d'un serveur DHCP (deux clients DHCP réels sont présents — les clients sont connectés à l'usine VXLAN).

Exemple de configuration d'un pool personnalisé :

Exemple de configuration d'un pool personnalisé (politiques sélectionnées — pour prouver que les politiques n'ont pas été utilisées pour le bon fonctionnement du pool) :

Exemple de configuration d'un pool pour les adresses sources DHCP Relay (la plage d'adresses à distribuer correspond complètement à l'exclusion des adresses du pool) :

Configuration du service DHCP sur Microsoft Windows Server 2019

Configuration du pool pour les adresses Loopback (source) pour DHCP Relay.

Créons un nouveau pool (Scope) dans l'espace IPv4.

Assistant de création de pool. « Suivant > »

Nous configurons le nom du pool et la description (Description) du pool.

Définissons la plage d'adresses IP pour Loopback et le masque pour le pool.

Ajoutons des exceptions. La plage d'exceptions doit correspondre exactement à la plage du pool.

Durée du bail. « Suivant > »

Demande : Allez-vous configurer les options DHCP maintenant (DNS, WINS, passerelle, domaine) ou le ferez-vous plus tard ? Il sera plus rapide de répondre non, puis d'activer le pool manuellement. Sinon, vous pouvez terminer sans remplir aucune information et activer le pool à la fin de l'assistant.

Nous confirmons que les options ne sont pas configurées, le pool n'est pas activé. « Terminer »

Activons le pool manuellement. — Sélectionnez le Scope et dans le menu contextuel — choisissez « Activer ».

Créons un pool pour les utilisateurs/serveurs.

Créons un nouveau pool.

Assistant de création de pool. « Suivant > »

Nous configurons le nom du pool et la description (Description) du pool.

Définissons la plage d'adresses IP pour Loopback et le masque pour le pool.

Ajoutons des exceptions. (Par défaut, aucune exception n'est nécessaire) « Suivant > »

Durée du bail. « Suivant > »

Demande : Allez-vous configurer les options DHCP maintenant (DNS, WINS, passerelle, domaine) ou le ferez-vous plus tard ? Oui, configurons maintenant.

Nous configurons l'adresse de la passerelle par défaut.

Nous configurons le domaine et les adresses des serveurs DNS.

Nous configurons les adresses IP des serveurs WINS.

Activation du Scope.

Le pool est configuré. « Terminer »

Conclusion

L'utilisation de Windows Server 2016/2019 réduit la complexité de la configuration du serveur DHCP pour une usine VXLAN (ou toute autre usine). (Aucune transmission spéciale aux spécialistes IT n'est requise : Network/Agent Circuit ID pour l'écriture des filtres.)

La configuration pour Windows Server 2012 fonctionnera-t-elle sur les nouveaux serveurs 2016/2019 ? Oui, elle fonctionnera.

Ce document contient des liens vers 2 versions : 7.X et 9.3. Cela est dû au fait que la version 7.0(3)I7(7) est la version suggérée par Cisco, tandis que la version 9.3 est la plus innovante (y compris le support de Multicast via VXLAN Multisite).

Liste des sources

Source : habr.com