Solution Architecture

Preuve de concept : approche d’intégration de serveur DHCP hors production

Dans cette approche, le serveur DHCP est attaché localement à la fonction de bloc de services de la structure. Pour la redondance, un ESI-LAG est configuré côté fabric et un LAG normal côté serveur. Tous les 4 000+ VLAN possibles sont configurés et exposés sur cette liaison vers le serveur DHCP. La structure elle-même n’a alors pas besoin de configuration supplémentaire du relais DHCP, car les domaines de diffusion de couche 2 de tous les VLAN d’accès sont étendus au serveur DHCP. En configurant les sous-interfaces correspondantes pour écouter, le serveur DHCP peut alors attribuer des baux en écoutant les paquets de diffusion MAC envoyés par les clients. Cela fonctionne à l’ancienne, et de nombreux serveurs DHCP (y compris Junos OS) peuvent répondre à ce trafic.

Note:

Ce n’est clairement pas recommandé dans les conceptions et les déploiements de niveau production. Cela peut aider à mettre le réseau en place plus rapidement, mais il y a de graves risques de sécurité qui viennent avec une telle conception !

La raison pour laquelle vous ne le recommandez pas dans les conceptions de production est que vous ignorez une fonction de sécurité de base de la conception de la structure. Normalement, tous les VRF de fabric sont isolés les uns des autres. Cela oblige tout le trafic entre les VLAN des différents VRF à transiter par le routeur WAN où des fonctions de sécurité telles que des pare-feu peuvent être mises en œuvre. En plaçant tous les VLAN sur le lien vers le serveur DHCP dans le bloc de services, nous contournons le routeur WAN et donc la fonctionnalité de sécurité. Si un attaquant trouve une faille de sécurité, par exemple une connexion administrateur ouverte, ou si quelque chose est mal configuré, il peut passer d’un VLAN à l’autre et peut-être aussi contourner tout filtrage basé sur un routeur WAN entre les VRF. Tenez compte de ce compromis.

Approche d’intégration de serveur DHCP de production recommandée

La solution de production recommandée consiste à suivre une approche basée sur les normes IETF RFC 2131 et RFC 3046 qui exploite le relais DHCP à l’intérieur de la structure pour le transfert vers un serveur DHCP géré par le client.

Dans une fabric de campus, le relais DHCP se trouve généralement à l’endroit où le VRF de la passerelle de couche 3 envoie le trafic des commutateurs d’accès connectés vers les fonctions north. En effet, il s’agit de la démarcation entre le domaine de diffusion de couche 2 et le transfert de couche 3 restant dans le réseau. Un client DHCP demandant un bail adresse toujours l’adresse MAC de diffusion dans ce domaine de couche 2, qui est FF :FF :FF :FF :FF :FF. Une fois qu’un tel message atteint le VRF, il est transféré par la fonction de relais DHCP du VRF (la RFC 2131 appelle cela un agent de relais BOOTP) sous la forme d’un paquet IP UDP vers le serveur DHCP connecté à la structure ou en dehors de celle-ci. Parallèlement à cela, le transfert d’informations supplémentaires est toujours intégré dans le paquet UDP vers le serveur DHCP :

• L’adresse IP de la passerelle (RFC 2131 l’appelle « giaddr ») est l’adresse IP source du paquet DHCP. Les serveurs DHCP renvoient tous les paquets de réponse à cette adresse IP intégrée. Par conséquent, il est important que cette adresse IP soit accessible par les paquets répondants. Cette adresse IP source signalée peut varier en fonction du type de fabric et de la méthode d’intégration du routeur WAN. Les deux méthodes les plus populaires illustrées dans ce JVD sont les suivantes :
  • Pour les petites structures utilisant l’adressage de passerelle virtuelle, l’adresse IP statique de chaque VLAN overlay configuré localement sur chaque VRF de fabric est utilisée comme adresse IP de passerelle.
  • Pour les fabrics de plus grande taille où l’adressage anycast est utilisé, une plage supplémentaire d’adresses IP de bouclage superposées est utilisée par les VRF répartis dans la fabric. Chaque VRF sur tous les nœuds où les VRF sont configurés dans cette fabric reçoit une adresse IP unique utilisée comme adresse IP de passerelle. Vous disposez donc d’un réseau de superposition supplémentaire, mais partagé entre les VRF. Il convient de noter que dans ce cas, il existe deux types d’utilisation de l’adresse IP de bouclage :
    • Il y a toujours les adresses IP de bouclage underlay existantes liées à l’interface lo0.0 sur chaque commutateur de fabric EVPN. Ils sont utilisés pour la signalisation VXLAN, VTEP et EVPN BGP. Ils sont généralement invisibles pour le transport de superposition.
    • Les nouvelles adresses IP de bouclage utilisées pour le relais DHCP sont visibles dans les VLAN superposés. Lors de la définition de ce pool de bouclage superposé, veillez à ce que cette plage ne soit pas utilisée ailleurs par les VLAN superposés. En outre, les adresses IP de ce pool de bouclage superposé doivent uniquement être liées aux nœuds de la fabric EVPN où se trouvent les VRF.
• On s’attend à ce que la fonction de relais DHCP intègre des informations supplémentaires, telles que celles ajoutées par l’option DHCP 82 conformément à la RFC 3046. Cela permet au serveur DHCP d’identifier la source de la demande du client et de mieux gérer la décision d’attribution du bail. Cela est nécessaire car le serveur DHCP ne pourra plus recevoir de demandes de bail DHCP des VLAN locaux, car il est configuré pour écouter sur une interface socket d’adresse IP recevant des paquets UDP. Les attributs qui peuvent être incorporés dans l’option 82 par le fournisseur du serveur DHCP peuvent varier et sont toujours sujets à l’intégration avec la structure.

Comme nous l’avons déjà mentionné, la fabric configure la fonction de relais DHCP à l’emplacement des VRF dans votre fabric. N’essayez pas de le modifier manuellement sur les commutateurs. Dans les champs de configuration de la structure, vous trouverez les options de configuration du relais DHCP dans le volet où vous configurez les réseaux et les VRF. Le reste sera déployé automatiquement par le cloud Juniper Mist™ sur les nœuds nécessaires comme indiqué dans la figure ci-dessous :

Type de fabric	: le relais DHCP sera configuré en fonction	du nombre de nœuds pris en charge
Multihébergement EVPN	Commutateurs centraux réduits	4 maximum
CRB	Commutateurs centraux	4 maximum
ERB	Commutateurs de distribution	beaucoup
IP Clos acheminé au niveau de la périphérie	Commutateurs d’accès	beaucoup

Comparaison fabric de passerelle virtuelle et structure anycast

Selon le type de structure, les VLAN superposés (où se trouve le trafic client) peuvent avoir besoin d’adresses IP supplémentaires à des fins internes, ce qui est le cas pour les structures de passerelle virtuelle. La fabric de campus Juniper Mist configure les types de fabric suivants :

Type	de fabric : fabric de passerelle virtuelle		, fabric Anycast,
Multihébergement EVPN		Oui	---
CRB		Oui	---
ERB		---	Oui
IP Clos Fabric		---	Oui

Dans une structure de passerelle virtuelle, vous disposez généralement d’un nombre très limité de VRF. Ceux-ci sont situés sur les commutateurs centraux ou collapsed core. Le nombre maximal de commutateurs centraux ou Collapsed core pris en charge dans une fabric de campus Juniper Mist est de quatre. Cela signifie qu’un certain VRF peut être dupliqué quatre fois au maximum sur chaque commutateur central ou collapsed core redondant dans la structure. Les fabrics Anycast, par opposition aux fabrics de passerelle virtuelle, conviennent aux conceptions plus évolutives. Par conséquent, l’emplacement des VRF se trouve soit sur les commutateurs de distribution (ERB), soit sur le commutateur d’accès (fabric IP Clos). La nature des fabrics de passerelle virtuelle est que le système nécessite une adresse IP statique supplémentaire unique par VRF pour chaque VLAN situé dans la fabric. Par conséquent, en plus de l’adresse IP de passerelle partagée pour chaque VLAN, jusqu’à quatre adresses IP uniques supplémentaires sur ce sous-réseau sont nécessaires.

Pourquoi un tel design ? Certains trafics sur la structure, tels que le relais DHCP, présentent des avantages. Pour le relais DHCP, le système utilise l’adresse IP statique au lieu de l’adresse IP de la passerelle lors du transfert des demandes du client DHCP. Ce comportement garantit que le paquet de réponse DHCP sera renvoyé au VRF correct, car l’adresse IP statique est unique au VLAN/commutateur central.

Une autre façon de penser à une structure de passerelle virtuelle est de la comparer aux conceptions traditionnelles de basculement de passerelle de couche 2 telles que VRRP. Là, vous avez toujours une VIP qui flotte entre les passerelles (qui sont nos VRF) et chaque passerelle a besoin d’une adresse IP statique unique supplémentaire pour chaque VLAN. Dans une fabric de campus Juniper Mist, le protocole VRRP n’est pas nécessaire, car le plan de contrôle EVPN prend le relais.

Les petits sacrifices nécessaires pour créer ces adresses IP statiques supplémentaires dans chaque sous-réseau sont éliminés dans les fabrics anycast. En effet, les commutateurs de distribution/accès plus évolutifs sur lesquels les VRF sont installés doivent bien planifier leur croissance future lors de la création de VLAN. Les services système, tels que le relais DHCP, fonctionnent un peu différemment dans les fabrics anycast et sont plus complexes en interne.

Quelle adresse IP choisir comme adresse IP de passerelle signalée ?

En règle générale, vous devez choisir entre l’une des approches suivantes pour déterminer l’adresse IP de passerelle incorporée dans les paquets transférés par la fonction de relais DHCP dans la fabric :

• Pour les structures de multihébergement EVPN, l’interface utilisateur ne laisse pas le choix, de sorte que vous utiliserez toujours des adresses IP de passerelle virtuelle pour l’adresse IP de passerelle. Cela permet au serveur DHCP d’identifier le VLAN d’où provient la demande en analysant uniquement l’adresse IP de la passerelle intégrée dans les paquets transférés.
• Pour les fabrics CRB, vous pouvez choisir entre une conception d’adresse IP statique de passerelle virtuelle en laissant le champ « Bouclage par sous-réseau VRF » vide ou en utilisant une conception avec des adresses IP de bouclage superposées attribuées à chaque VRF de la structure lors du remplissage d’un préfixe IP dans la boîte de dialogue « Bouclage par sous-réseau VRF » de la boîte de dialogue Structure de campus.
• Pour les structures plus volumineuses telles que ERB et IP Clos, nous vous recommandons d’entrer un préfixe IP dans le champ « Bouclage par sous-réseau VRF » dans le cadre de la configuration de la structure de campus. Ainsi, la fabric attribuera automatiquement des adresses IP de bouclage de superposition uniques hors de cette plage de pool à chaque VRF de la fabric. Dans ce cas, nous vous recommandons vivement d’utiliser un protocole de routage tel qu’OSPF ou BGP pour l’intégration des routeurs WAN vers la structure, car l’utilisation de ces adresses IP de bouclage superposées peut rendre difficile la prédiction de la manière dont chaque adresse IP de passerelle peut être atteinte à partir du routeur WAN.

Bien qu’il soit techniquement possible de laisser le champ « Bouclage par sous-réseau VRF » vide dans ces fabrics, cela n’est pas recommandé. Si elle n’est pas renseignée, l’adresse IP de la passerelle anycast sera l’adresse IP de passerelle rapportée incorporée dans les paquets transférés. Cela ne cause pas de problèmes sur le chemin vers le serveur DHCP. Toutefois, lorsque la réponse du serveur DHCP est renvoyée, l’adresse IP anycast étant partagée par plusieurs commutateurs au sein de la structure, le paquet de réponse peut être acheminé vers un commutateur qui n’est pas à l’origine de la demande et qui peut se trouver dans un autre PoD ou bâtiment. Si cela se produit, lorsque le paquet arrive à un commutateur qui n’est pas à l’origine de la requête, la fonction de relais DHCP décapsule la réponse et détermine, en fonction de l’adresse MAC du client, que le paquet doit être transféré à un commutateur distant. Pour ce faire, il utilisera un tunnel VXLAN pour renvoyer le paquet est-ouest au commutateur où le client est réellement connecté. Cela crée une conception inefficace.

Où localiser le serveur DHCP ?

L’approche que nous recommandons est l’intégration locale dans le cadre de la structure elle-même.

Dans le cas d’une fabric de campus, la branche de service est appelée fonction de bloc de services et, dans l’exemple suivant, une paire de commutateurs physiques situés au nord de l’endroit où le serveur DHCP est connecté font partie intégrante de la structure.

Le serveur DHCP peut également gérer les baux pour les clients qui ne se trouvent pas dans le même VRF que lui. Cependant, comme il y a toujours une isolation VRF à VRF à l’intérieur de la fabric, les paquets devront être échangés via un routeur WAN.

Lorsqu’une telle intégration locale n’est pas possible, on peut également essayer d’intégrer le serveur DHCP en tant qu’élément externe vers la fabric. Voici ce que vous voyez dans le coin supérieur gauche de la figure suivante :

Ce qu’il faut prendre en compte Lorsque vous utilisez des serveurs DHCP externes ?

Lors de l’intégration de serveurs DHCP externes dans la structure, il y a deux points critiques à garder à l’esprit pour que cette approche réussisse :

• Maintenez la latence entre la structure et les serveurs DHCP aussi faible que possible. N’envisagez pas d’utiliser le serveur DHCP dans un environnement de cloud public si vous ne connaissez pas l’impact de la latence. Certains clients DHCP peuvent se montrer très agressifs lorsqu’ils demandent un bail, ce qui peut entraîner l’empilement des demandes de bail DHCP sans réponse dans un environnement à latence élevée, surchargeant ainsi le serveur DHCP. Étant donné que le comportement du client DHCP est difficilement influençable au niveau de la fabric, nous vous recommandons de tester la conception en vous concentrant sur l’ensemble des temps de latence aller-retour avant de mettre la fabric en production.
• Aucune forme de traduction d’adresses réseau (NAT) n’est prise en charge entre la fabric et le serveur DHCP. La raison en est expliquée dans l’extrait suivant de la RFC 2131 de l’IETF décrivant comment un serveur DHCP doit répondre aux demandes des clients. N’oubliez pas que « giaddr » est l’adresse IP de la passerelle embarquée :

Vous ne savez peut-être pas ce que signifie cette description RFC, c’est pourquoi nous avons fourni un exemple de trafic utilisant un serveur DHCP Microsoft qui ne répond pas aux requêtes DHCP SNAT conformément à la RFC.

Voici l’adresse IP source et le port d’origine du commutateur d’accès créé pour le paquet de relais :

Lorsque le routeur WAN applique le SNAT au message de découverte transféré, il modifie l’adresse IP source et le port comme suit :

Toutefois, la réponse du serveur DHCP renvoie à l’adresse IP de la passerelle intégrée d’origine sur le port 67, qui était l’adresse IP source d’origine dans la fabric avant l’application du SNAT :

Ce paquet n’arrivera jamais au pare-feu SNAT.

Optimisations dans Junos OS pour faciliter la conception de vos relais DHCP

Grâce à la configuration de Junos OS, quelques instructions permettent d’optimiser votre conception. Nous vous présentons les plus critiques au cas où vous voudriez savoir pourquoi la fabric les configure automatiquement :

Dans la configuration de Junos OS, une instruction « forward-only » est nécessaire pour empêcher l’équipement de surveiller le trafic DHCP incontrôlé.

Dans la configuration de Junos OS, l’instruction « relay-option-82 circuit-id vlan-id-only » synchronise le comportement des commutateurs QFX et EX lors du transfert du trafic DHCP de l’option 82 (par défaut, ils utilisent des attributs différents). De plus, cet attribut n’ajoute plus d’informations d’interface indésirables telles que « IRB-irb.1099 :ae10.0 » ou « IRB-irb.1099 :vtep.32769 ». Avec cette configuration ajoutée, seul l’ID VLAN est signalé, ce qui facilite l’analyse de la chaîne dans ce champ, que nous exploitons pour que le serveur DHCP Linux KEA attribue le bon bail.

L’instruction de configuration de Junos OS « relay-option-82 server-id override » est décrite ici et est nécessaire dans notre environnement. Il aide le serveur DHCP Microsoft à l’aide de la sous-option 5 à déterminer la source du paquet et à choisir le pool approprié à attribuer.

L’instruction de configuration « route-suppression destination » de Junos OS est nécessaire lors de l’utilisation d’adresses IP de bouclage en tant qu’adresses IP de passerelle. Il n’est pas utilisé pour les adresses IP statiques d’adresse de passerelle virtuelle en tant qu’adresses IP de passerelle.

Dans la configuration de Junos OS, la fabric configure désormais toutes les interfaces IRB avec l’option « no-dhcp-flood ». Cela permet de limiter la diffusion MAC du client afin que tous les périphériques de relais DHCP ne reçoivent pas la même requête du client dupliquée. Si cette option n’est pas installée, étant donné que toutes les requêtes client sont des paquets diffusés dans un VLAN, la requête d’origine est dupliquée via VXLAN et envoyée à tous les nœuds de fabric sur lesquels ce VRF est configuré, qui effectuent ensuite le relais DHCP vers le routeur WAN.

Note:

Si vous utilisez vJunos-switch en tant qu’instance de commutateur virtuel dans un laboratoire, vous savez que si l’option « no-dhcp-flood » peut être configurée sur un commutateur virtuel, elle n’est actuellement pas implémentée. Par conséquent, vous pouvez observer une inondation et une mauvaise adresse IP de passerelle utilisée. Cependant, cela ne devrait pas affecter votre capacité à tester cela. C’est juste une limitation connue du commutateur vJunos.