Méthodes de requête DHCP
Dans un réseau d’accès par abonné, un serveur local DHCP conserve une quantité importante d’informations de liaison liées aux adresses IP ou aux préfixes délégués DHCPv6 que le serveur a loués aux clients DHCP. Lorsque les clients DHCP sont connectés au serveur DHCP par le biais d’un agent de relais DHCP, celui-ci glane les données des paquets DHCP qu’il transfère, telles que l’adresse IP, nécessaires pour atteindre le point de terminaison. L’agent de relais gère les informations sur la location et l’acheminement pertinentes pour les clients DHCP. L’agent de relais utilise cette information lorsqu’il fournit des services d’abonné aux clients. Lorsque l’agent de relais est redémarré ou lorsque l’appareil hôte de l’agent est redémarré ou remplacé, l’agent de relais perd ces informations. Vous pouvez utiliser une request commande pour déclencher l’envoi par l’agent de relais d’un message leasequery au serveur local afin de récupérer les informations de liaison des clients DHCP afin que l’agent de relais puisse restaurer sa base de données d’informations de bail.
La gestion des abonnés prend en charge les types d’opérations de requête de bail suivants :
Requête de bail individuel : fournit des informations sur le bail pour une liaison unique sur demande (mode de requête et de réponse).
Bulk leasequery : fournit des informations sur le bail pour plusieurs liaisons sur demande (mode requête et réponse).
Leasequery actif : fournit un flux de mises à jour en direct pour plusieurs liaisons configurées.
Avantages de DHCP Leasequery
-
Leasequery fournit à un agent de relais DHCPv4 ou DHCPv6 un moyen léger de récupérer les informations d’emplacement faisant autorité liées aux adresses IP/IPv6 DHCP louées et aux préfixes délégués à partir du serveur local DHCP lorsque l’agent de relais a été redémarré ou remplacé.
-
Bulk LeaseQuery supprime le besoin d’interroger les liaisons individuelles pour des clients spécifiques, permettant à une seule requête de renvoyer des informations pour des centaines ou des milliers d’abonnés. Cette méthode n’attend pas que le trafic de données déclenche une requête, elle s’adapte donc mieux qu’un leasequery individuel lorsque l’agent a des milliers de clients. Dans le cas de DHCPv6, l’agent de relais peut ne pas être en mesure de former des requêtes individuelles.
-
La requête active fournit des mises à jour continues en temps réel des informations de liaison à un ou plusieurs agents de relais lorsqu’elle est configurée. Outre les mises à jour entre l’agent de relais et le serveur local, vous pouvez configurer une relation d’appairage entre les agents de relais. Cela permet aux pairs de synchroniser en permanence leurs informations de liaison les unes avec les autres, fournissant une redondance si un pair tombe en panne ou est redémarré. L’homologue actif maintient immédiatement le service pour les clients qui utilisaient l’agent de relais affecté.
DHCP Leasequery individuel
À partir de la version 16.1 de Junos OS, la gestion des abonnés prend en charge la fonctionnalité de requête de bail individuelle, qui permet à l’agent de relais DHCPv4 ou DHCPv6 d’obtenir rapidement et efficacement les informations de bail actuelles à partir d’un serveur local DHCP. L’agent de relais peut perdre les informations de bail stockées localement pour diverses raisons, par exemple parce que l’appareil de l’agent de relais a été redémarré. Lorsque l’agent de relais reçoit par la suite du trafic de données d’un client pour le transfert, il ne dispose plus des informations pour le faire. Une interaction leasequery avec le serveur local peut restaurer les informations afin que l’agent de relais puisse servir correctement ses clients.
Pour configurer des opérations de leasequery individuelles, vous activez la prise en charge à la fois sur l’agent de relais DHCP et sur le serveur DHCP. Vous pouvez configurer les détails de la communication entre l’agent de relais et le serveur. Vous devez exécuter la request dhcp leasequery commande ou request dhcpv6 leasequery pour que l’agent de relais envoie la requête.
Par défaut, l’agent de relais envoie la requête à tous les serveurs locaux connus. Vous pouvez limiter les serveurs avec lesquels il communique en spécifiant une adresse de serveur ou un groupe nommé de serveurs. Vous pouvez également limiter la requête aux serveurs d’un système logique, d’une instance de routage ou d’une combinaison LS :RI particulière.
DHCPv4 Leasequery individuel
La requête de bail DHCPv4 peut être de plusieurs types, une requête par adresse, ID client ou adresse MAC. Vous déterminez le type de requête lorsque vous déclenchez la requête en exécutant la request dhcp relay leasequery commande. Vous spécifiez que l’agent de relais DHCPv4 inclut dans le message DHCPLEASEQUERY l’une des valeurs suivantes pour permettre au serveur local d’identifier les informations de liaison demandées par l’agent :
Adresse IP d’un bail client : le serveur local renvoie des informations de liaison pour le client le plus récent auquel cette adresse IP a été attribuée.
Identificateur client du périphérique client : le serveur local renvoie des informations de liaison pour l’adresse IP qui a été utilisée pour la dernière fois par un client disposant de l’identificateur client spécifié (option 61). L’identifiant est unique dans le domaine d’administration du serveur. Si ce client a accédé à d’autres adresses IP via ce serveur, le serveur renvoie une liste de ces adresses dans l’option IP associée (option 92).
Adresse MAC du périphérique client : le serveur local renvoie des informations de liaison pour le client le plus récent qui possède cette adresse MAC. Si ce client a accédé à d’autres adresses IP via ce serveur, le serveur renvoie une liste de ces adresses dans l’option IP associée (option 92).
L’agent de relais DHCP inclut l’option de liste de demandes de paramètres (option 55) dans le message DHCPLEASEQUERY. Cette liste inclut des options spécifiques liées aux informations de liaison pour l’adresse IP renvoyée par le serveur local. Par exemple, la liste des demandes comprend généralement l’option d’information sur l’agent de relais (option 82). Le serveur local inclut les informations demandées dans un DHCPLEASEACTIVE envoyé à l’agent de relais.
Le message DHCPLEASEACTIVE comprend l’option de l’heure de la dernière transaction du client (option 91). La valeur de cette option est l’intervalle en secondes entre le moment où l’adresse IP a été utilisée pour la dernière fois dans une interaction entre le client et le serveur et le moment où le sérer envoie le message DHCPLEASEACTIVE. Par exemple, si la dernière interaction a eu lieu à 08:00:00 et que le message est envoyé à 09:00:00, la valeur de l’option est 3600.
Le Tableau 1 décrit les types de messages pour les requêtes de bail individuelles DHCPv4.
Message Type |
Valeur de type Option 53 |
Descriptif |
|---|---|---|
DHCSPLEASEQUERY |
10 |
Envoyé par l’agent de relais au serveur local DHCP pour restaurer les informations. |
DHCPLEASEUNASSIGNED |
11 |
Réponse du serveur local lorsque l’adresse IP associée au client est contrôlée par le serveur mais n’est pas actuellement louée. Cette réponse est envoyée uniquement pour une requête par adresse IP. |
DHCPLEASEUNKNOWN |
12 |
Réponse du serveur local lorsque celui-ci n’a pas connaissance des informations contenues dans la requête. |
DHCPLEASEACTIVE |
13 |
Réponse du serveur local lorsqu’il a loué une adresse au client. La réponse comprend des informations contractuelles complètes sur cette adresse. |
DHCPv6 Leasequery individuel
Le type de requête est transmis dans l’option LQ_Query (option 44). Le type de requête de l’agent de relais DHCPv6 peut être par adresse ou par ID client. Vous déterminez le type de requête lorsque vous déclenchez la requête en exécutant la request dhcpv6 relay leasequery commande. Vous spécifiez que l’agent de relais DHCPv6 inclut dans le message LEASEQUERY l’une des valeurs suivantes dans l’option de demande d’option (option 6) pour permettre au serveur local d’identifier les informations de liaison demandées par l’agent :
Adresse IPv6 d’un bail client : le serveur local renvoie des informations de liaison pour le client le plus récent qui est lié à cette adresse ou à qui un préfixe contenant l’adresse a été délégué. Le champ des options de requête de l’option 44 comprend l’option IAADDR (option 5).
Identifiant unique DHCP (DUID) de l’appareil client : le serveur local renvoie des informations de liaison pour l’adresse IP qui a été utilisée pour la dernière fois par un client disposant du DUID spécifié. Le DUID est l’identifiant IPv6 du client. L’identifiant est unique dans le domaine d’administration du serveur. Le serveur local peut renvoyer une liste d’adresses si le client se trouve sur plusieurs adresses de liaison. Le champ query-options de l’option 44 comprend l’option Identificateur client (option 1).
Le champ query-options de l’option 44 peut également inclure l’option de demande d’option (option 6) pour répertorier les codes d’option DHCPv6 pour des informations spécifiques souhaitées sur le serveur local pour chaque client.
Le message LEASEQUERY-REPLY inclut l’option de données client (option 45) pour fournir des informations sur un seul client sur une seule liaison. Ces informations sont transmises sous forme d’options DHCPv6 dans le champ client-options. L’option 45 comprend au minimum les options suivantes et toutes les autres options demandées par l’agent de relais dans l’option de demande d’option LEASEQUERY (option 6) :
Identificateur de client (option 1) : DUID qui identifie le client DHCPv6.
IAADDR (option 5) : adresse dans une association d’identité pour les adresses temporaires (IA_TA) ou non temporaires (IA_NA). Peut être inclus avec l’option IAPREFIX.
IAPREFIX (option 26) : préfixe dans une association d’identité pour la délégation de préfixe (IA_). Peut être inclus avec l’option IAADDR.
Option CLT (option 46) : temps en secondes écoulé depuis la dernière interaction du serveur avec le client sur cette liaison. Cette option correspond à l’option de l’heure de la dernière transaction du client DHCPv4.
Les options suivantes sont des exemples d’options supplémentaires qui peuvent être incluses dans le message LEASEQUERY-REPLY :
Option de données de relais LQ (option 47) : informations complètes sur l’agent de relais qui ont été utilisées lors de la dernière communication du client avec ce serveur. Le serveur local renvoie cette option uniquement lorsqu’elle est demandée dans l’option de demande d’options LEASEQUERY (option 6).
Option de liaison du client LQ (option 48) : identifie les adresses de liaison sur lesquelles le client a au moins une liaison. Le message LEASEQUERY-REPLY inclut cette option lorsque les deux conditions suivantes sont vraies : LEASEQUERY ne spécifie pas d’adresse de lien et le client se trouve sur plusieurs liens. Lorsque l’agent de relais reçoit cette information, il peut soumettre une nouvelle requête LEASEQUERY pour chaque adresse inscrite à l’option 48.
Le Tableau 2 décrit les types de messages pour les requêtes de bail individuelles DHCPv6.
Message Type |
Valeur de type DHCPv6 |
Descriptif |
|---|---|---|
LEASEQUERY |
14 |
Envoyé par l’agent de relais au serveur local DHCP pour restaurer les informations. Comprend l’option LQ (option 44) pour spécifier le type de requête, une adresse de lien et toute information d’option particulière requise à partir du serveur local. |
LEASEQUERY-REPLY |
15 |
Réponse du serveur local lorsque l’adresse IP associée au client est contrôlée par le serveur mais n’est pas actuellement louée. Cette réponse est envoyée uniquement pour une requête par adresse IP. |
Le message LEASEQUERY-REPLY envoyé par le serveur local DHCPv6 peut renvoyer l’option de code d’état (option 13) pour fournir des informations sur l’état de la requête. Le Tableau 3 répertorie les codes d’état.
Code |
Statut |
Descriptif |
|---|---|---|
7 |
UnknownQueryType |
Le serveur ne reconnaît pas ou ne prend pas en charge la requête. |
8 |
MalformedQuery |
La requête n’est pas valide ; par exemple, il manque peut-être une option obligatoire. |
9 |
NotConfigured (en anglais) |
Le serveur local n’a pas l’adresse requise dans sa configuration. |
10 |
Non autorisé |
Le serveur local ne permet pas à l’agent de relais d’envoyer ce type de requête. |
DHCP en blocrequête
À partir de la version 16.1 de Junos OS, la gestion des abonnés prend en charge la fonctionnalité Bulk LeaseQuery, qui permet à chaque demande de l’agent de relais DHCP de récupérer les informations de bail de plusieurs abonnés en bloc à partir d’un serveur DHCP configuré de manière programmée. La requête de bail en bloc est plus économe en ressources que l’utilisation de plusieurs requêtes de bail individuelles pour collecter les mêmes informations. Ceci est particulièrement utile dans les environnements évolutifs avec des milliers de clients par agent de relais.
Bulk LeaseQuery utilise une connexion TCP entre l’agent de relais DHCP et un serveur DHCP configuré dans le même système logique/instance de routage. La connexion TCP est plus fiable et consomme moins de ressources que la connexion UDP utilisée pour le processus de requête de bail individuel. Bulk leasequery étend également la requête de bail individuelle en fournissant des options de requête et des fonctionnalités supplémentaires.
Pour configurer des opérations de leasequery en bloc, vous activez la prise en charge à la fois sur l’agent de relais DHCP et sur le serveur DHCP. Vous pouvez configurer les détails de la communication entre l’agent de relais et le serveur. Vous devez exécuter la request dhcp bulk-leasequery commande or request dhcpv6 bulk-leasequery pour que l’agent de relais envoie la requête de bail.
Par défaut, l’agent de relais envoie la requête à tous les serveurs locaux connus. Vous pouvez limiter les serveurs avec lesquels il communique en spécifiant une adresse pour un serveur ou un groupe nommé de serveurs. Vous pouvez également limiter la requête aux serveurs d’un système logique, d’une instance de routage ou d’une combinaison LS :RI particulière.
DHCPv4 Bulk Leasequery
Pour la requête de bail en bloc DHCPv4, l’agent de relais DHCPv4 ouvre une connexion TCP via le port 67 vers le serveur local DHCPv4. Une fois la connexion établie, l’agent de relais envoie un message DHCPBULKLEASEQUERY au serveur. La requête peut contenir l’un des éléments suivants pour permettre au serveur local d’identifier les informations dont l’agent a besoin :
Toutes les adresses IP configurées : le serveur local renvoie des informations de liaison pour toutes les adresses IP configurées dans le serveur local. Les informations sont renvoyées, que les adresses IP fassent partie ou non d’une liaison active. Cela permet à l’agent de relais de mettre à jour sa base de données avec tous les changements d’adresse survenus après un certain temps.
Identificateur client du périphérique client : le serveur local renvoie des informations de liaison pour l’adresse IP qui a été utilisée pour la dernière fois par un client disposant de l’identificateur client spécifié (option 61). L’identifiant est unique dans le domaine d’administration du serveur.
Remarque :Contrairement à leasequery individuel, le serveur n’utilise pas l’option IP associée (option 92) pour renvoyer une liste d’autres adresses IP auxquelles le client a accédé via ce serveur. Au lieu de cela, le serveur renvoie des informations de liaison pour toutes ces adresses IP
Adresse MAC du périphérique client : le serveur local renvoie des informations de liaison pour le client le plus récent qui possède cette adresse MAC.
Remarque :Contrairement à leasequery individuel, le serveur n’utilise pas l’option IP associée (option 92) pour renvoyer une liste d’autres adresses IP auxquelles le client a accédé via ce serveur. Au lieu de cela, le serveur renvoie des informations de liaison pour toutes ces adresses IP
Identificateur d’agent de relais : le serveur local renvoie des informations de liaison pour tous les baux actuellement actifs attribués au client qui possède l’identificateur d’agent de relais spécifié (option 82, sous-option 12). L’identifiant est unique dans le domaine d’administration du serveur.
ID distant d’un circuit d’accès utilisé par le client pour identifier le circuit au client DHCP : le serveur local renvoie des informations de liaison pour tous les baux actuellement actifs attribués aux clients qui utilisent cet ID distant d’agent (option 82, sous-option 2). Cette requête est particulièrement utile dans les environnements à grande échelle avec des milliers de clients par agent de relais. Les autres requêtes ne renvoient pas les informations de location consolidées pour tous les clients d’un circuit.
Le serveur local DHCPv4 répond à l’agent de relais avec les mêmes messages DHCPLEASEACTIVE et DHCPLEASEUNASSIGNED utilisés pour les requêtes de bail individuelles, comme décrit dans Types de messages de leasequery individuels DHCPv4. Chaque message correspond à une liaison unique identifiée par la requête.
Lorsque le serveur a renvoyé toutes les liaisons associées à la demande, il envoie un message DHCPLEASEQUERYDONE à l’agent de relais. Si une connexion est perdue lors du traitement d’une requête de bail en bloc, DHCP ne peut pas déterminer la quantité d’informations demandées que l’agent de relais a reçues avant l’interruption de la connexion. Par conséquent, l’agent de relais doit retenter la requête.
Pour toutes les méthodes de requête, l’agent de relais DHCP peut inclure le qualificatif suivant :
query-start-time : renvoie les liaisons qui ont été modifiées à la date spécifiée dans la requête ou après cette date.
query-end-time : renvoie les liaisons qui ont été modifiées au plus tard à l’heure spécifiée dans la requête.
Ces temps de requête permettent à un agent de récupérer uniquement les informations de liaison qu’il a perdues depuis la dernière fois qu’il a validé toutes ses informations dans un stockage stable.
Le Tableau 4 décrit les types de messages spécifiques à DHCPv4 bulk leasequery.
Message Type |
Valeur de type Option 53 |
Descriptif |
|---|---|---|
DHCPBULKLEASEQUERY |
14 |
Envoyé par l’agent de relais au serveur local DHCP pour restaurer les informations. |
DHCPLEASEQUERYDONE |
15 |
Réponse du serveur local lorsqu’il a renvoyé toutes les informations de liaison associées à la demande groupée. |
Les messages envoyés par le serveur local DHCPv4 peuvent renvoyer l’option de code d’état (option 151) pour fournir des informations sur l’état de la requête. Dans les messages DHCPLEASEACTIVE et DHCPLEASEUNASSIGNED, le code correspond au statut de la demande de liaison individuelle. Dans les messages DHCPLEASEQUERYDONE, le code correspond à la demande de requête en bloc dans son ensemble. Le Tableau 5 répertorie les codes d’état.
Code |
Statut |
Descriptif |
|---|---|---|
0 |
Succès |
La demande a été traitée avec succès. L’absence de l’option 151 indique également le succès. |
1 |
UnSpecFail |
La demande a échoué pour une raison non spécifiée. |
2 |
QueryTerminated |
Le serveur local n’a pas pu exécuter la requête ou l’a terminée prématurément. Dans ce dernier cas, une chaîne de texte indique la cause. |
3 |
MalformedQuery |
La requête n’a pas été comprise par le serveur local. |
4 |
Non autorisé |
La requête était comprise mais pas autorisée. |
DHCPv6 Bulk Leasequery
Pour la requête de bail en bloc DHCPv6, l’agent de relais DHCPv6 ouvre une connexion TCP via le port 67 vers le serveur local DHCPv6. Lorsque la connexion est établie, l’agent de relais envoie un message LEASEQUERY au serveur. Le type de requête est transmis dans l’option LQ_Query (option 44). Le type de requête peut être l’un des suivants pour permettre au serveur local d’identifier les informations nécessaires à l’agent :
Toutes les adresses IP configurées : le serveur local renvoie des informations de liaison pour toutes les adresses IP configurées dans le serveur local. Les informations sont renvoyées, que les adresses IP fassent partie ou non d’une liaison active. Cela permet à l’agent de relais de mettre à jour sa base de données avec tous les changements d’adresse survenus après un certain temps.
Identificateur client du périphérique client : le serveur local renvoie des informations de liaison pour l’adresse IP qui a été utilisée pour la dernière fois par un client disposant de l’identificateur client spécifié (option 61). L’identifiant est unique dans le domaine d’administration du serveur.
Remarque :Contrairement à leasequery individuel, le serveur n’utilise pas l’option IP associée (option 92) pour renvoyer une liste d’autres adresses IP auxquelles le client a accédé via ce serveur. Au lieu de cela, le serveur renvoie des informations de liaison pour toutes ces adresses IP
Adresse MAC du périphérique client : le serveur local renvoie des informations de liaison pour le client le plus récent qui possède cette adresse MAC.
Remarque :Contrairement à leasequery individuel, le serveur n’utilise pas l’option IP associée (option 92) pour renvoyer une liste d’autres adresses IP auxquelles le client a accédé via ce serveur. Au lieu de cela, le serveur renvoie des informations de liaison pour toutes ces adresses IP
Identificateur d’agent de relais : le serveur local renvoie des informations de liaison pour tous les baux actuellement actifs attribués au client qui possède l’identificateur d’agent de relais spécifié (option 82, sous-option 12). L’identifiant est unique dans le domaine d’administration du serveur.
ID distant d’un circuit d’accès utilisé par le client pour identifier le circuit au client DHCP : le serveur local renvoie des informations de liaison pour tous les baux actuellement actifs attribués aux clients qui utilisent cet ID distant d’agent (option 82, sous-option 2). Cette requête est particulièrement utile dans les environnements à grande échelle avec des milliers de clients par agent de relais. Les autres requêtes ne renvoient pas les informations de location consolidées pour tous les clients d’un circuit.
Pour une requête de bail en bloc DHCPv6, vous pouvez éventuellement spécifier l’option trigger automatic permettant de configurer l’agent de relais DHCPv6 pour lancer automatiquement l’opération de requête en bloc chaque fois que le jdhcpd processus démarre une connexion avec la base de données de session (SDB) et qu’aucun abonné lié n’est présent dans la base de données. Par exemple, le processus automatique garantit que la requête en bloc met toujours à jour les informations du relais DHCP après un redémarrage, une opération GRES ou ISSU et s’il n’y a pas d’abonnés liés.
DHCPv6 bulk leasequery utilise les messages LEASEQUERY et LEASEQUERY-REPLY utilisés par DHCPv6 single leasequery, mais leur comportement et leur signification sont légèrement différents pour bulkquery. Le Tableau 6 répertorie ces messages et décrit deux autres types de messages spécifiques à DHCPv6 bulk leasequery.
Message Type |
Valeur de type DHCPv6 |
Descriptif |
|---|---|---|
LEASEQUERY |
14 |
Envoyé par l’agent de relais au serveur local DHCP pour restaurer les informations. |
LEASEQUERY-REPLY |
15 |
Réponse du serveur local pour indiquer la réussite ou l’échec de la requête. Il transmet également des informations, telles que l’ID du serveur et l’ID du client, qui ne changent pas dans le contexte d’une seule requête et réponse. Lorsque la requête réussit, une seule LEASEQUERY-REPLY est renvoyée. Ce message inclut également les informations de liaison pour le premier client. Des données de liaison supplémentaires sont renvoyées dans le message LEASEQUERY-DATA. Lorsque la requête échoue, une seule LEASEQUERY-REPLY est renvoyée sans information de liaison. |
LEASEQUERY-DONE |
16 |
Réponse du serveur local indiquant la fin d’un groupe de réponses leasequery associées. Un seul message LEASEQUERY-DONE est envoyé une fois que toutes les réponses à la demande ont été envoyées à l’agent de relais. La connexion TCP entre l’agent de relais et le serveur est fermée à la réception de ce message. |
LEASEQUERY-DATA |
17 |
Réponse du serveur local avec des informations sur les baux d’un seul client DHCPv6 ou sur les liaisons de délégation de préfixe sur une seule liaison. Ce message est envoyé uniquement lorsque la requête en bloc renvoie des données pour plusieurs clients. Dans ce cas, le message LEASEQUERY-REPLY transmet des informations pour le premier client, puis un message LEASEQUERY-DATA est envoyé pour chacun des autres clients. |
Les messages envoyés par le serveur local DHCPv6 peuvent renvoyer l’option de code d’état (option 13) pour fournir des informations sur l’état de la requête. Dans les messages LEASEQUERY-REPLY, le code correspond au statut de la demande de liaison individuelle. Dans les messages LEASEQUERY-DONE, le code correspond à la demande de requête en bloc dans son ensemble. Les messages LEASEQUERY-DATA n’incluent pas de code d’état. DHCPv6 prend en charge les codes d’état de leasequery individuels DHCPv6 répertoriés dans Codes d’état de leasequery individuels DHCPv6. Les messages peuvent également inclure le code d’état ajouté pour la requête de bail en bloc décrite dans le tableau 7.
Code |
Statut |
Descriptif |
|---|---|---|
11 |
QueryTerminated |
Le serveur local ne peut pas exécuter de requête ou l’a terminée prématurément pour une raison quelconque. Par exemple, le serveur local est en train d’être arrêté ou ne dispose pas de ressources suffisantes pour collecter les informations demandées. |
DHCP Active Leasequery
À partir de la version 19.1R1 de Junos OS, la requête de bail DHCP active résout la situation où il est souhaitable que l’agent de relais reçoive des mises à jour périodiques des informations du client pour suivre l’activité de liaison DHCP dynamique. Leasequery individuel et groupé ne fournit des informations que lorsqu’elles sont demandées ; Si les informations client sont mises à jour ultérieurement sur le serveur local, ces informations ne sont pas transmises à l’agent de relais, sauf si l’agent de relais envoie une autre requête au serveur local.
Active LeaseQuery permet aux serveurs de fournir des mises à jour en direct des informations client chaque fois que l’état de la liaison change. Vous pouvez éventuellement configurer active leasequery pour envoyer les mises à jour en direct des informations de liaison à plusieurs homologues d’agent de relais, ce qui prend en charge la redondance au niveau du châssis de l’agent de relais. La mise à jour en direct est lancée lorsque l’agent de relais démarre une connexion TCP avec un serveur ou un homologue d’agent de relais et envoie le message ACTIVELEASEQUERY pour indiquer que la connexion doit rester ouverte.
DHCP ne ferme pas la connexion TCP sauf si certaines conditions se produisent, principalement liées au délai d’expiration configurable ou aux périodes d’inactivité :
-
Lorsqu’une demande de connexion est reçue dans un système logique ou une instance de routage qui n’est pas configurée pour un leasequery actif.
-
Lorsque la connexion est bloquée pendant les opérations de lecture/écriture TCP suffisamment longtemps pour que le délai d’expiration expire, la connexion est fermée et peut être redémarrée. L’opération de lecture se produit lorsque l’agent de relais tente de lire les réponses à la requête. L’opération d’écriture se produit lorsque le serveur ou l’agent de relais d’homologue tente d’envoyer des réponses à un agent de relais
-
Lorsqu’aucun trafic n’est reçu sur la connexion pendant la durée du délai d’inactivité.
Pendant les opérations de leasequery actives, les informations de liaison sont mises à jour uniquement lorsqu’elles changent. Par conséquent, il y a des périodes pendant lesquelles le serveur ou l’agent de relais pair n’envoie aucune information. Si la période est plus longue que le délai d’inactivité, la connexion est interrompue. Pour éviter les pertes de connexion inappropriées, le serveur ou l’agent de relais d’homologue envoie des messages DHCPLEASEACTIVE (DHCPv4) ou LEASEQUERY-DATA (DHCPv6) à des intervalles égaux à la moitié du délai d’inactivité. Ces messages ne contiennent aucune information de liaison car ils sont envoyés alors qu’aucune mise à jour n’est disponible. Ces messages maintiennent la connexion active en servant de messages de bonjour ou de maintien signalant que le manque d’activité n’est pas un problème.
Lorsque la connexion TCP se ferme, l’agent de relais tente de rétablir la connexion. Les nouvelles tentatives incluent une option qui signale au serveur ou à l’agent de relais pair d’envoyer des informations de liaison qui ont changé depuis l’arrêt de la connexion TCP. Ces informations sont parfois appelées informations de rattrapage. L’option spécifie l’horodatage absolu à l’arrêt de la connexion ; c’est-à-dire l’heure de la dernière communication réussie avec le serveur ou l’agent de relais pair. DHCPv4 utilise l’option query-start-time (option 154). DHCPv6 utilise l’option LQ_START_TIME (option 101).
Dans certains cas, le serveur ou l’agent de relais homologue ne dispose pas de toutes les informations nécessaires pour lier les modifications depuis l’horodatage. Par exemple, l’appareil peut ne pas avoir assez de mémoire pour tout stocker. Dans ces cas, l’appareil renvoie un message DHCPLEASEQUERYSTATUS (DHCPv4) ou LEASEQUERY-REPLY (DHCPv6) avec un code d’état DataMissing (5).
Avant de configurer le leasequery actif, vous devez d’abord configurer le leasequery en bloc, car le leasequery actif utilise le mécanisme de leasequery en bloc. La configuration de leasequery active échoue à la vérification de validation si leasequery en bloc n’est pas configuré.
Pour configurer des opérations de leasequery actives, vous activez la prise en charge à la fois sur l’agent de relais DHCP et sur le serveur DHCP. Vous pouvez configurer les détails de la communication pour l’agent de relais et le serveur local. Contrairement à leasequery individuel et en bloc, le leasequery actif n’a pas de type de requête. Vous ne déclenchez pas de leasequery active avec une request commande. Au lieu de cela, le déclencheur est automatique lorsque la requête de bail active est configurée.
- Leasequery actif DHCPv4
- DHCPv6 Leasequery actif
- Redondance au niveau du châssis avec Active Leasequery
Leasequery actif DHCPv4
Pour la requête de bail DHCPv4 active, l’agent de relais DHCPv4 ouvre une connexion TCP via le port 67 vers le serveur local DHCPv4. Lorsque la connexion est établie, l’agent de relais envoie un message DHCPACTIVELEASEQUERY au serveur. Le message indique qu’il s’agit d’une connexion à long terme. Il ne ferme qu’à la suite d’un délai d’attente.
Le serveur local DHCPv4 répond à l’agent de relais avec les mêmes messages DHCPLEASEACTIVE et DHCPLEASEUNASSIGNED utilisés pour les requêtes de bail individuelles, comme décrit dans Types de messages de leasequery individuels DHCPv4. Chaque message correspond à une liaison unique identifiée par la requête. Le serveur local DHCP continue d’envoyer les messages de réponse chaque fois que les informations de liaison changent. Le Tableau 8 décrit les types de messages spécifiques à DHCPv4 active leasequery.
| Message Type |
Valeur de type Option 53 |
Descriptif |
|---|---|---|
| DHCPACTIVELEASEQUERY |
16 |
Envoyé par l’agent de relais au serveur local DHCP pour permettre la mise à jour en direct des informations de liaison sur l’agent de relais chaque fois que ces informations changent sur le serveur local. Peut également être envoyé entre les agents de relais pairs pour fournir une redondance de secours à chaud pour les informations de liaison. |
| DHCPLEASEQUERYSTATUS |
17 |
Réponse du serveur local lorsqu’il a renvoyé les informations de liaison associées à la requête. La connexion TCP étant de longue durée, ce message est également envoyé régulièrement lorsque les connexions sont inactives (aucune mise à jour de liaison n’est envoyée). Dans ce cas, le message comprend un code d’état ConnectionActive (6) pour informer l’agent de relais que la connexion est toujours établie. |
Les messages envoyés par le serveur local peuvent renvoyer l’option de code d’état (option 151). Dans les messages DHCPLEASEACTIVE et DHCPLEASEUNASSIGNED, le code correspond au statut de la réponse individuelle. Dans les messages DHCPLEASEQUERYSTATUS, le code correspond au flux de messages de la demande de requête de bail active dans son ensemble. DHCPv4 active leasequery prend en charge les codes d’état de leasequery en bloc répertoriés dans Codes d’état de leasequery en bloc DHCPv4. Les messages peuvent également inclure les codes d’état ajoutés pour la requête de bail active décrite dansle Tableau 9.
| Code |
Statut |
Descriptif |
|---|---|---|
| 5 |
Données manquantes |
Les informations contraignantes demandées ne sont pas disponibles. Par exemple, lorsque le serveur local ou l’homologue ne dispose pas des données suffisantes demandées avec l’option query-start-time, ce code d’état est envoyé immédiatement dans un message LEASEQUERY-REPLY. |
| 6 |
ConnectionActive |
La connexion TCP est toujours active. |
| 7 |
RattrapageComplet |
Le serveur local a envoyé toutes les données sauvegardées demandées par l’agent de relais. |
DHCPv6 Leasequery actif
Pour la requête de bail DHCPv6 active, l’agent de relais DHCPv6 ouvre une connexion TCP via le port 67 vers le serveur local DHCPv4. Lorsque la connexion est établie, l’agent de relais envoie un message ACTIVELEASEQUERY au serveur. Le message indique qu’il s’agit d’une connexion à long terme. Il ne ferme qu’à la suite d’un délai d’attente.
Le serveur local DHCPv6 répond à l’agent de relais avec les mêmes messages LEASEQUERY-REPLY, LEASEQUERY-DATA et LEASEQUERY-DONE que ceux utilisés pour LeaseQuery en bloc. Chaque message correspond à une liaison unique identifiée par la requête. Le serveur local DHCP continue d’envoyer les messages de réponse chaque fois que les informations de liaison changent. Le Tableau 10 répertorie ces messages et le type de message de requête spécifique à DHCPv6 active leasequery.
| Message Type |
Valeur de type DHCPv6 |
Descriptif |
|---|---|---|
| ACTIVELEASEQUERY |
22 |
Envoyé par l’agent de relais au serveur local DHCP pour permettre la mise à jour en direct des informations de liaison sur l’agent de relais chaque fois que ces informations changent sur le serveur local. Peut également être envoyé entre les agents de relais pairs pour fournir une redondance de secours à chaud pour les informations de liaison. |
| LEASEQUERY-REPLY |
15 |
Réponse du serveur local pour indiquer la réussite ou l’échec de la requête. Il transmet également des informations, telles que l’ID du serveur et l’ID du client, qui ne changent pas dans le contexte d’une seule requête et réponse. Lorsque la requête réussit, une seule LEASEQUERY-REPLY est renvoyée. Ce message inclut également les informations de liaison pour le premier client. Des données de liaison supplémentaires sont renvoyées dans le message LEASEQUERY-DATA. Lorsque la requête échoue, une seule LEASEQUERY-REPLY est renvoyée sans information de liaison. |
| LEASEQUERY-DONE |
16 |
Réponse du serveur local indiquant que la connexion doit être interrompue. Par exemple, le serveur peut l’envoyer avec un code d’état QueryTerminated (11) lorsque le serveur est arrêté. |
| LEASEQUERY-DATA |
17 |
Réponse du serveur local avec des informations sur les baux d’un seul client DHCPv6 ou sur les liaisons de délégation de préfixe sur une seule liaison. Ce message est envoyé uniquement lorsque leasequery renvoie des données pour plusieurs clients. Dans ce cas, le message LEASEQUERY-REPLY transmet des informations pour le premier client, puis un message LEASEQUERY-DATA est envoyé pour chacun des autres clients. |
Les messages envoyés par le serveur local DHCPv6 peuvent renvoyer l’option de code d’état (option 13). DHCPv6 active leasequery prend en charge les codes d’état leasequery individuels et leasequery en bloc répertoriés dans les codes d’état DHCPv6 Individual Leasequery et DHCPv6 Bulk Leasequery Status Code, respectivement. Les messages peuvent également inclure les codes d’état ajoutés pour la requête de bail active décrite dans le tableau 11.
| Code |
Statut |
Descriptif |
|---|---|---|
| 12 |
Données manquantes |
Les informations contraignantes demandées ne sont pas disponibles. |
| 13 |
RattrapageComplet |
Le serveur local a envoyé toutes les données sauvegardées demandées par l’agent de relais. |
| 14 |
Non pris en charge |
Le serveur local a envoyé toutes les données sauvegardées demandées par l’agent de relais. |
Redondance au niveau du châssis avec Active Leasequery
Vous pouvez utiliser la requête de bail active pour permettre la synchronisation des informations de liaison entre plusieurs homologues d’agent de relais DHCP. Pour simplifier, cette discussion explique le comportement avec seulement deux pairs. Lorsqu’un agent de relais homologue redémarre ou que son appareil redémarre, l’autre relais peut prendre le relais et fournir des services à tous les clients DHCP sans panne visible. Lorsque l’agent de relais d’homologation réapparaît, il rétablit la connexion TCP avec l’homologue actif. Les pairs synchronisent ensuite les informations de liaison. La figure 1 montre une topologie DHCP simple prenant en charge la redondance des agents de relais avec les caractéristiques suivantes :
-
Chaque client DHCP se connecte aux deux agents de relais.
-
Les deux agents de relais se connectent au même serveur DHCP.
-
Lorsque vous configurez l’instruction
active leasequerysur chaque agent de relais, vous spécifiez également l’autre agent de relais en tant qu’homologue. -
Les homologues utilisent les mêmes messages de leasequery actifs pour la communication, comme expliqué dans les tableaux 8 et 10. Bien que cela ne soit pas illustré ici, lorsqu’un serveur RADIUS externe fait partie de la topologie, il n’y a aucune différence dans les interactions avec le serveur RADIUS.
La séquence suivante décrit comment les agents de relais établissent la relation d’homologue et partagent les informations de liaison lorsque la requête de bail active est configurée sur les deux. Cet exemple concerne DHCPv4, mais le mécanisme est le même pour DHCPv6.
-
Les deux agents de relais ont des liaisons client DHCP actives, mais la requête de bail active n’est pas encore configurée.
-
Vous configurez une requête de bail active sur les deux agents de relais, vous vous spécifiez mutuellement en tant qu’homologues et vous validez la configuration.
-
Les deux agents homologues tentent d’établir une connexion TCP lorsque la configuration est validée. Supposons que l’agent de relais L’agent de relais 1 établisse avec succès la connexion. La tentative de l’agent de relais pair 2 est abandonnée.
-
L’agent de relais 1 envoie ensuite un message ACTIVELEASEQUERY à l’agent de relais 2.
-
L’agent de relais 2 envoie des informations sur les liaisons dans sa base de données d’abonnés à l’agent de relais 1. Il envoie également son propre message ACTIVELEASEQUERY à l’agent de relais 1 pour collecter les informations client de l’homologue.
-
L’agent de relais 1 envoie ses informations de liaison à l’agent de relais 2. L’agent de relais 1 et l’agent de relais 2 traitent chacun les informations de liaison reçues et les valident dans leurs bases de données respectives.
-
Lorsque chaque agent de relais met à jour les informations de liaison de ses propres clients (renouvellements de licence, nouvelles demandes, expirations de bail, etc.), il envoie un message de réponse leasequery avec les informations mises à jour à son homologue à chaque modification.
-
Supposons maintenant que l’agent de relais 1 soit redémarré. La connexion TCP est interrompue. L’agent de relais 2 tente de rétablir la connexion avec l’agent de relais 1. Pendant ce temps, le trafic d’abonné DHCP qui passait par l’agent de relais 1 passe maintenant par l’agent de relais 2 sans interruption.
-
La requête de bail active est déclenchée sur l’agent de relais 1 lorsqu’elle revient. La connexion TCP est rétablie et les pairs échangent des messages ACTIVELEASEQUERY. L’agent de relais 1 n’a pas d’informations contraignantes à partager à ce stade. L’agent de relais 2 envoie toutes ses informations de liaison actuelles à l’agent de relais 1 ; cette information a peut-être changé pendant que l’agent de relais 1 était hors service. Le résultat est que les deux agents de relais ont maintenant des bases de données synchronisées.
Instructions pour la configuration de la prise en charge des opérations Leasequery individuelles, en bloc et actives
Lorsque vous configurez la prise en charge de leasequery individuelle, en bloc ou active, tenez compte des instructions suivantes :
Le routeur prend en charge la configuration simultanée de leasequery individuel, de leasequery en bloc et de leasequery actif. La requête de bail active nécessite la configuration de leasequery en bloc.
Le routeur prend en charge la configuration simultanée à double pile pour DHCPv4 et DHCPv6. Toutefois, pour les environnements à double pile, vous devez déclencher les opérations leasequery individuelles DHCPv4 et DHCPv6 ou les opérations leasequery en bloc séparément.
L’agent de relais DHCP prend en charge les requêtes de bail individuelles ou les requêtes de bail en bloc sur des interfaces statiques et dynamiques. La requête de bail active n’est prise en charge que sur les interfaces statiques orientées serveur ou les interfaces statiques homologues pour la redondance du châssis.
Le serveur local DHCP prend en charge les requêtes en bloc uniquement sur les interfaces statiques orientées relais.
Le serveur local DHCP écoute les requêtes de bail en bloc et les demandes de leasequery actives de l’agent de relais DHCP sur la connexion TCP sur le port 67 pour DHCPv4 et sur le port 547 pour DHCPv6.
Les requêtes de bail en bloc et les requêtes de bail actives ne sont pas prises en charge pour DHCP sur PPP/PPPoE.
La requête de bail active est prise en charge sur les combinaisons de piles suivantes :
DHCP sur interfaces statiques (ge/ae/xe/irb/ps) (Prise en charge des interfaces ps ajoutée dans Junos OS version 20.1R1.)
Interfaces DHCP sur IP Demux
DHCP sur VLAN Interfaces Démux
DHCP sur IP sur VLAN Interfaces Demux
À partir de la version 19.1R1 de Junos OS, l’agent de relais DHCPv4 insère l’option Relay-ID dans chaque paquet qu’il transfère au serveur local DHCP de la manière suivante :
L’agent de relais insère toujours l’option dans les paquets non surveillés.
L’agent de relais insère l’option dans les paquets espionnés uniquement lorsque la requête en bloc est configurée dans ce LS :RI.
Si le réseau comprend des interfaces IRB (Integrated Routing and Bridging), vous devez configurer l’agent de relais DHCP pour qu’il inclue le nom de l’interface de couche 2 ainsi que le nom IRB dans l’ID de circuit de l’option 82. L’agent de relais DHCP utilise le nom de l’interface de couche 2 lors de l’utilisation de leasequery ou de leasequery en bloc pour restaurer la base de données de location.
Configuration et utilisation de DHCP Leasequery individuel
L’opération leasequery individuelle met à jour la base de données de bail d’un agent de relais DHCP avec des informations relatives à un seul abonné spécifié. Vous identifiez les abonnés DHCPv4 par l’adresse IPv4, l’adresse MAC ou l’ID client du client DHCP. Vous identifiez les abonnés DHCPv6 par l’adresse IPv6 ou l’ID client du client DHCP.
Avant de commencer, lisez Instructions pour la configuration de la prise en charge des opérations Leasequery individuelles, en bloc et actives et assurez-vous que la prise en charge requise suivante est configurée sur l’agent de relais DHCP.
(DHCPv4 uniquement) L’agent de relais DHCP insère l’option 82, sous-option 1 (ID de circuit de l’agent), dans les paquets DHCP qu’il transfère aux serveurs DHCP. Voir Utilisation des informations de l’option 82 de l’agent de relais DHCP.
Si le réseau comprend des interfaces IRB (Integrated Routing and Bridging), vous devez également inclure l’instruction
include-irb-and-l2, comme indiqué dans l’exemple suivant. Cette instruction configure l’agent de relais DHCP pour inclure le nom de l’interface de couche 2 ainsi que le nom IRB dans l’ID de circuit de l’option 82. L’agent de relais DHCP utilise le nom de l’interface de couche 2 lors de la restauration de la base de données de bail à l’aide de leasequery ou de leasequery en bloc.[edit forwarding-options dhcp-relay] user@host# set relay-option-82 circuit-id include-irb-and-l2
(DHCPv4 uniquement) L’agent de relais DHCP inclut toujours les informations de la nouvelle option 82 dans les paquets DHCP que le relais transfère aux serveurs DHCP. Voir Remplacement des renseignements sur l’option 82.
[edit forwarding-options dhcp-relay] user@host# set overrides always-write-option-82
(DHCPv6 uniquement) L’agent de relais DHCP insère l’ID d’interface DHCPv6 (option 18) dans les paquets que le relais transfère aux serveurs DHCPv6. Consultez Insertion de l’option d’ID d’interface DHCPv6 (option 18) dans les paquets DHCPv6.
Si votre réseau comprend des interfaces IRB (Integrated Routing and Bridging), vous devez également inclure l’instruction
include-irb-and-l2, comme illustré dans l’exemple suivant. Cette instruction configure l’agent de relais DHCPv6 pour inclure le nom de l’interface de couche 2 ainsi que le nom IRB dans l’ID de circuit de l’option 82. L’agent de relais DHCP utilise le nom de l’interface de couche 2 lors de l’utilisation de leasequery ou de leasequery en bloc pour restaurer la base de données de location.[edit forwarding-options dhcp-relay dhcpv6] user@host# set relay-agent-interface-id include-irb-and-l2
Procédez comme suit pour configurer et utiliser l’opération leasequery individuelle.
Utilisez les commandes supported show and pour clear gérer et afficher des informations sur l’opération de leasequery en bloc pour l’agent de relais DHCP et le serveur local DHCP. Voir Vérification et gestion des configurations DHCP de LeaseQuery individuelles et en bloc.
Configuration et utilisation de DHCP Bulk Leasequery
L’opération de leasequery en bloc met à jour la base de données de bail d’un agent de relais DHCP avec des informations sur plusieurs abonnés, par opposition à la requête de bail individuelle, qui interroge les liaisons individuelles pour les cibles connues uniquement. Bulk leasequery étend également la requête de bail individuelle en fournissant des options de requête et des fonctionnalités supplémentaires.
Avant de commencer, lisez Instructions pour la configuration de la prise en charge des opérations Leasequery individuelles, en bloc et actives et assurez-vous que la prise en charge requise suivante est configurée sur l’agent de relais DHCP.
(DHCPv4 uniquement) L’agent de relais DHCP insère l’option 82, sous-option 1 (ID de circuit de l’agent), dans les paquets DHCP qu’il transfère aux serveurs DHCP. Voir Utilisation des informations de l’option 82 de l’agent de relais DHCP.
Si le réseau comprend des interfaces IRB (Integrated Routing and Bridging), vous devez également inclure l’instruction
include-irb-and-l2, comme indiqué dans l’exemple suivant. Cette instruction configure l’agent de relais DHCPv6 pour inclure le nom de l’interface de couche 2 ainsi que le nom IRB dans l’ID de circuit de l’option 82. L’agent de relais DHCP utilise le nom de l’interface de couche 2 lors de l’utilisation de leasequery ou de leasequery en bloc pour restaurer la base de données de location.[edit forwarding-options dhcp-relay] user@host# set relay-option-82 circuit-id include-irb-and-l2
(DHCPv4 uniquement) L’agent de relais DHCP inclut toujours les informations de la nouvelle option 82 dans les paquets DHCP que le relais transfère aux serveurs DHCP. Voir Remplacement des renseignements sur l’option 82.
[edit forwarding-options dhcp-relay] user@host# set overrides always-write-option-82
(DHCPv6 uniquement) L’agent de relais DHCP insère l’ID d’interface DHCPv6 (option 18) dans les paquets transférés aux serveurs DHCPv6. Consultez Insertion de l’option d’ID d’interface DHCPv6 (option 18) dans les paquets DHCPv6.
[edit forwarding-options dhcp-relay dhcpv6] user@host# set relay-agent-interface-id
Si votre réseau comprend des interfaces IRB (Integrated Routing and Bridging), vous devez également inclure l’instruction
include-irb-and-l2, comme illustré dans l’exemple suivant. Cette instruction configure l’agent de relais DHCPv6 pour inclure le nom de l’interface de couche 2 ainsi que le nom IRB dans l’ID de circuit de l’option 82. L’agent de relais DHCP utilise le nom de l’interface de couche 2 lors de l’utilisation de leasequery ou de leasequery en bloc pour restaurer la base de données de location.[edit forwarding-options dhcp-relay dhcpv6] user@host# set relay-agent-interface-id include-irb-and-l2
Procédez comme suit pour configurer et utiliser l’opération de requête de bail en bloc.
Utilisez les commandes supported show and pour clear gérer et afficher des informations sur l’opération de leasequery en bloc pour l’agent de relais DHCP et le serveur local DHCP. Voir Vérification et gestion des configurations DHCP de LeaseQuery individuelles et en bloc.
Configuration et utilisation de DHCP Active Leasequery
Avant de commencer, lisez Instructions pour la configuration de la prise en charge des opérations Leasequery individuelles, en bloc et actives et assurez-vous que la prise en charge requise suivante est configurée sur l’agent de relais DHCP.
-
(DHCPv4 uniquement) L’agent de relais DHCP insère l’option 82, sous-option 1 (ID de circuit de l’agent), dans les paquets DHCP qu’il transfère aux serveurs DHCP. Voir Utilisation des informations de l’option 82 de l’agent de relais DHCP.
Si le réseau comprend des interfaces IRB (Integrated Routing and Bridging), vous devez également inclure l’instruction
include-irb-and-l2, comme indiqué dans l’exemple suivant. Cette instruction configure l’agent de relais DHCPv6 pour inclure le nom de l’interface de couche 2 ainsi que le nom IRB dans l’ID de circuit de l’option 82. L’agent de relais DHCP utilise le nom de l’interface de couche 2 lors de l’utilisation de leasequery ou de leasequery en bloc pour restaurer la base de données de location.[edit forwarding-options dhcp-relay] user@host# set relay-option-82 circuit-id include-irb-and-l2
-
(DHCPv4 uniquement) L’agent de relais DHCP inclut toujours les informations de la nouvelle option 82 dans les paquets DHCP que le relais transfère aux serveurs DHCP. Voir Remplacement des renseignements sur l’option 82.
[edit forwarding-options dhcp-relay] user@host# set overrides always-write-option-82
-
(DHCPv6 uniquement) L’agent de relais DHCP insère l’ID d’interface DHCPv6 (option 18) dans les paquets transférés aux serveurs DHCPv6. Consultez Insertion de l’option d’ID d’interface DHCPv6 (option 18) dans les paquets DHCPv6.
Si votre réseau comprend des interfaces IRB (Integrated Routing and Bridging), vous devez également inclure l’instruction
include-irb-and-l2, comme illustré dans l’exemple suivant. Cette instruction configure l’agent de relais DHCPv6 pour inclure le nom de l’interface de couche 2 ainsi que le nom IRB dans l’ID de circuit de l’option 82. L’agent de relais DHCP utilise le nom de l’interface de couche 2 lors de l’utilisation de leasequery ou de leasequery en bloc pour restaurer la base de données de location.[edit forwarding-options dhcp-relay dhcpv6] user@host# set relay-agent-interface-id include-irb-and-l2
-
Pour la redondance de l’agent de relais DHCP au niveau du châssis, les instructions suivantes s’appliquent :
-
Les homologues de redondance de l’agent de relais DHCP doivent tous avoir des configurations d’abonnés identiques afin d’avoir des bases de données synchronisées.
-
Les noms complets des interfaces d’accès (
ge,xeouae) sur lesquelles les abonnés apparaissent doivent être identiques sur les homologues de redondance de l’agent de relais DHCP.
-
-
Étant donné que le leasequery actif est une extension du leasequery en bloc, vous devez configurer leasequery en bloc pour que le leasequery actif fonctionne. Voir Configuration et utilisation de DHCP Bulk Leasequery.
L’opération de leasequery active envoie des mises à jour en direct aux agents de relais DHCP pour plusieurs abonnés lorsque les informations de liaison DHCP changent sur le serveur local. Vous pouvez également utiliser active leasequery dans le cadre d’une configuration pour assurer la redondance des informations de liaison entre les agents de relais pair.
Procédez comme suit pour configurer et utiliser l’opération LeaseQuery active.
Ces étapes ne dupliquent aucune des configurations de leasequery en bloc. Par exemple, les étapes n’incluent pas la configuration du nombre maximal de connexions TCP, car cela fait partie de la configuration de leasequery en bloc requise.
Utilisez les commandes supported show and pour clear gérer et afficher des informations sur l’opération de leasequery en bloc pour l’agent de relais DHCP et le serveur local DHCP. Voir Vérification et gestion des configurations DHCP de LeaseQuery individuelles et en bloc.
Synchronisation de relais dynamiques EVPN-MPLS DHCPv6-pour les modes actif-actif (ACX7100-32C, ACX7100-48L, ACX7332, ACX7348, ACX7509, ACX7024 et ACX7024X)
Cette fonctionnalité de synchronisation de relais dynamiques DHCPv6-prend en charge la configuration de délégation de préfixe DHCPv6, qui comprend :
-
Synchronisation entre deux nœuds Leaf EVPN-MPLS en mode actif-actif
-
Délégation de préfixe DHCPv6 pour automatiser la délégation des préfixes IPv6 au CPE.
- Prise en charge de la requête de bail en bloc sur un agent de relais DHCPv6.
- Configuration des paramètres que l’agent de relais DHCP utilise lors de l’envoi de messages de demande de bail DHCP en bloc pour obtenir des informations de bail à partir des serveurs locaux DHCP dans le système logique/l’instance de routage.
-
Synchronisation de l’état DHCPv6 EVPN-VXLAN à l’aide de Active-lease-query/Bulk-lease-query sur IRB.
[ Voir Protocoles pris en charge sur une interface IRB dans EVPN-VXLAN, Méthodes de requête DHCP, active-leasequery (agent de relais DHCP) et bulk-leasequery (agent de relais DHCP) . ]
Exemple de configuration :
L’exemple suivant affiche une configuration Actif-Actif avec le paramètre stale-timer. Une configuration de minuterie obsolète est nécessaire pour prendre en charge une requête de bail actif-actif. Cette configuration optimise le temps de synchronisation lorsque les deux homologues reçoivent les paquets de sollicitation en même temps.
dhcp-relay
{
dhcpv6
{
group v6relay
{
active-server-group v6server;
interface irb.0;
}
relay-agent-interface-id
{
include-irb-and-l2;
}
server-group
{
v6server
{
1000::1;
}
}
bulk-leasequery;
active-leasequery
{
peer-address
{
1003::1;
}
}
}
overrides
{
always-write-option-82;
}
relay-option-82
{
circuit-id
{
include-irb-and-l2;
}
}
server-group {
v4server {
100.0.0.1;
}
}
group v4relay {
active-server-group v4server;
interface irb.0;
}
stale-timer 20;
bulk-leasequery;
active-leasequery {
peer-address {
103.0.0.1;
}
}
}
dhcp-relay {
dhcpv6 {
group v6relay {
active-server-group v6server;
interface irb.0;
}
relay-agent-interface-id {
include-irb-and-l2;
}
server-group {
v6server {
1000::1;
}
}
bulk-leasequery;
active-leasequery {
peer-address {
1002::1;
}
}
}
overrides {
always-write-option-82;
}
relay-option-82 {
circuit-id {
include-irb-and-l2;
}
}
server-group {
v4server {
100.0.0.1;
}
}
group v4relay {
active-server-group v4server;
interface irb.0;
}
stale-timer 20;
bulk-leasequery;
active-leasequery {
peer-address {
102.0.0.1;
}
}
}
Lancement d’une requête DHCP pour mettre à jour la base de données de bail de l’agent de relais DHCP
Vous devez exécuter une commande request pour que l’agent de relais DHCP lance une opération leasequery individuelle ou en bloc, qui demande des informations sur le bail actuel aux serveurs DHCP locaux. Chaque requête de bail met à jour la base de données de location de l’agent de relais DHCP avec les informations d’un client individuel. Chaque requête de bail en bloc met à jour la base de données de location de l’agent de relais pour plusieurs clients. Le Tableau 12 répertorie les différentes options de requête disponibles pour DHCPv4, DHCPv6, leasequery individuel et leasequery en bloc.
Option de requête |
DHCPv4 Leasequery individuel |
DHCPv4 Bulk Leasequery |
DHCPv6 Leasequery individuel |
DHCPv6 Bulk Leasequery |
|---|---|---|---|---|
ID à distance de l’agent |
– |
✓ |
– |
✓ |
Client ID |
✓ |
✓ |
– |
– |
ID client (DUID) |
– |
– |
✓ |
✓ |
Adresse de passerelle |
✓ obligatoire |
– |
– |
– |
Adresse IPv4 |
✓ |
✓ |
– |
– |
Préfixe IPv6 |
– |
– |
✓ |
✓ |
Adresse du lien |
– |
– |
– |
✓ |
Adresse MAC |
✓ |
✓ |
– |
– |
ID de l’agent de relais |
– |
✓ |
– |
✓ |
Lorsque vous avez configuré DHCPv6 bulk leasequery sur un agent de relais avec l’instruction bulk-leasequery et l’option trigger automatic , vous ne lancez pas la requête avec une request commande. Au lieu de cela, la requête est automatiquement déclenchée chaque fois que le processus jdhcpd sur l’agent de relais démarre (par exemple, après un redémarrage jdhcpd, un redémarrage de périphérique d’agent de relais, un basculement de moteur de moteur de routage gracieux ou un ISSU unifié) et qu’il n’y a pas d’abonnés liés dans la base de données de session. La requête automatique de bail en bloc est toujours basée sur l’option Relay-ID de l’agent de relais (option 53).
Lorsque la prise en charge du déclencheur automatique est configurée, vous pouvez toujours utiliser la request commande pour déclencher manuellement des requêtes de bail en bloc distinctes des requêtes automatiques.
La requête de bail active ne nécessite pas de request commande pour le lancement. Au lieu de cela, il est automatiquement lancé lorsque vous le configurez. La requête de bail active nécessite que vous configuriez une requête de bail en bloc.
Les agents de relais DHCPv4 peuvent avoir plusieurs interfaces avec des adresses IP différentes, de sorte que chaque interface peut agir comme une passerelle pour différents ensembles de clients. Cela signifie que vous devez toujours spécifier l’adresse de la passerelle dans votre demande.
Pour lancer une requête de bail individuelle DHCPv4 afin de mettre à jour les informations de liaison, vous devez toujours spécifier l’adresse IP de passerelle de l’agent de relais. Vous devez également spécifier le type de requête :
Spécifiez une adresse IP louée au client.
user@host> request dhcp relay leasequery ipv4-address gateway-address giaddr
Spécifiez l’adresse MAC du client.
user@host> request dhcp relay leasequery mac-address gateway-address giaddr
Spécifiez l’identifiant du client (option 61).
user@host> request dhcp relay leasequery client-id gateway-address giaddr
Pour lancer une requête de bail en bloc DHCPv4 afin de mettre à jour les informations de liaison, vous pouvez :
Spécifiez une adresse IP louée au client.
user@host> request dhcp relay bulk-leasequery ipv4-address
Spécifiez l’adresse MAC du client.
user@host> request dhcp relay bulk-leasequery mac-address
Spécifiez l’option d’identifiant client (option 61).
user@host> request dhcp relay bulk-leasequery client-id
Spécifiez la sous-option Identificateur d’agent de relais (sous-option 12) de l’option d’informations sur l’agent de relais DHCP (option 82).
user@host> request dhcpv6 relay bulk-leasequery relay-id relay-id
Par défaut, l’opération de leasequery en bloc utilise l’ID de relais de l’agent de relais DHCPv4 si vous ne spécifiez explicitement aucune des options suivantes : client-id, , relay-idipv4-addressmac-address, ou .remote-id
user@host> request dhcpv6 relay bulk-leasequery
Spécifiez l’ID à distance de l’agent (sous-option 2) de l’option d’informations sur l’agent de relais DHCPv4 (option 82).
user@host> request dhcpv6 relay bulk-leasequery remote-id remote-id
Pour lancer une requête de bail DHCPv6 individuelle afin de mettre à jour les informations de liaison, vous pouvez :
Spécifiez l’ID client (option 1).
user@host> request dhcpv6 relay leasequery client-id
Spécifiez une adresse IPv6 louée au client.
user@host> request dhcpv6 relay leasequery ipv6-prefix
Pour lancer une requête de bail en bloc DHCPv6 afin de mettre à jour les informations de liaison, vous pouvez :
Spécifiez l’ID client (option 1).
user@host> request dhcpv6 relay bulk-leasequery client-id
Spécifiez le préfixe IPv6.
user@host> request dhcpv6 relay bulk-leasequery ipv6-prefix
Spécifiez l’adresse de liaison IPv6.
user@host> request dhcpv6 relay bulk-leasequery link-address ipv6-link-address
Spécifiez l’option Relay-ID (option 53).
user@host> request dhcpv6 relay bulk-leasequery relay-id relay-id
Par défaut, l’opération de leasequery en bloc utilise l’ID de relais de l’agent de relais DHCPv6 si vous ne spécifiez explicitement aucune des options suivantes : client-id, , relay-idipv6-prefixipv6-link-address, ou .remote-id
user@host> request dhcpv6 relay bulk-leasequery
Spécifiez l’option Identification à distance de l’agent de relais (option 37).
user@host> request dhcpv6 relay bulk-leasequery remote-id remote-id
Pour toute demande de requête de bail individuelle et en bloc, en plus des options répertoriées ci-dessus, vous pouvez éventuellement spécifier des qualificateurs pour limiter la requête à des serveurs DHCP particuliers. Sinon, la requête est envoyée à tous les serveurs DHCP connus de l’agent de relais.
Vous pouvez spécifier une adresse pour le serveur local ou le nom d’un groupe de serveurs locaux. Vous pouvez spécifier un système logique, une instance de routage ou les deux, seul ou en plus de l’adresse ou du groupe du serveur.
Dans l’exemple suivant, option désigne toute option configurable comme indiqué précédemment. Par souci de concision, l’exemple ne montre qu’une requête de bail individuelle DHCPv4 et seulement certaines des possibilités. Pour plus d’informations, consultez les rubriques de commande individuelles : request dhcp relay leasequery, request dhcpv6 relay leasequery, request dhcp relay bulk-leasequery et request dhcpv6 relay bulk-leasequery.
Spécifiez une adresse pour le serveur local.
user@host> request dhcp relay leasequery option server-address address
Spécifier un système logique.
user@host> request dhcp relay leasequery option logical-system logical-system-name
Spécifiez une instance de routage et un groupe nommé de serveurs locaux.
user@host> request dhcp relay leasequery option routing-instance routing-instance-name server-group group-name
Vérification et gestion des configurations DHCP individuelles et en bloc de Leasequery
Objet
Afficher ou effacer des informations sur les opérations DHCP, de leasequery individuel et de leasequery en bloc. Utilisez les commandes et prises en charge show pour clear gérer et afficher des informations sur les opérations leasequery et leasequery en bloc ; pour l’agent de relais DHCP et le serveur local DHCP.
Pour active leasequery , consultez Vérification et gestion des opérations DHCP de leasequery actives.
Mesures à prendre
Utilisez les commandes supported show et clear pour gérer et afficher des informations sur les opérations leasequery pour l’agent de relais DHCP et le serveur local DHCP.
Pour afficher les informations de leasequery pour l’agent de relais DHCPv4 ou DHCPv6 :
user@host> show dhcp relay statistics (leasequery | bulk-leasequery-connections) user@host> show dhcpv6 relay statistics (leasequery | bulk-leasequery-connections)
Pour effacer les informations de leasequery pour l’agent de relais DHCPv4 ou DHCPv6 :
user@host> clear dhcp relay statistics (leasequery | bulk-leasequery-connections) user@host> clear dhcpv6 relay statistics (leasequery | bulk-leasequery-connections)
Pour afficher les informations de leasequery pour le serveur local DHCPv4 ou DHCPv6 :
user@host> show dhcp server statistics bulk-leasequery-connections user@host> show dhcpv6 server statistics bulk-leasequery-connections
Pour effacer les informations de leasequery pour le serveur local DHCPv4 ou DHCPv6 :
user@host> clear dhcp server statistics bulk-leasequery-connections user@host> clear dhcpv6 server statistics bulk-leasequery-connections
Vérification et gestion des opérations DHCP actives de Leasequery
Objet
Afficher ou effacer des informations sur les opérations DHCP de leasequery actives. Utilisez les commandes supported show and clear pour gérer et afficher des informations sur les opérations leasequery actives ; pour l’agent de relais DHCP et le serveur local DHCP.
Pour les requêtes DHCP individuelles et en bloc, consultez Vérification et gestion des configurations DHCP individuelles et en bloc de LeaseQuery.
Mesures à prendre
Utilisez les commandes supported show et clear pour gérer et afficher des informations sur les opérations leasequery pour l’agent de relais DHCP et le serveur local DHCP.
Pour afficher des informations de leasequery actives pour les agents de relais homologue DHCPv4 ou DHCPv6 :
user@host> show dhcp relay active-leasequery user@host> show dhcpv6 relay active-leasequery
Pour effacer les informations de leasequery actives pour l’agent de relais DHCPv4 ou DHCPv6 :
user@host> clear dhcp relay active-leasequery statistics user@host> clear dhcpv6 relay active-leasequery statistics
Pour afficher des informations sur les voisins de requête de bail actifs :
user@host> show dhcp active-leasequery neighbors user@host> show dhcpv6 active-leasequery neighbors
Vous pouvez afficher des informations générales pour tous les pairs. Vous pouvez également afficher des statistiques pour des pairs et des interfaces d’accès spécifiques. Par exemple :
Pour chaque interface pseudowire sur le BNG, affichez l’adresse IP du voisin BNG associé à l’interface.
user@host> show dhcp active-leasequery neighbors Interface Neighbor Address ps2.0 198.51.100.5 ps1.0 198.51.100.7Affiche les statistiques des homologues DHCPv4 et DHCPv6.
user@host> show dhcp relay active-leasequery statistics peer 198.51.100.1 peer : 198.51.100.1 Topology-Discover Configured : No State : Connected Bindings Sent : 0 Bindings Received : 0 Bindings Installed Successfully : 0 Bindings Failed to install : 0 Last Synchronization Time : None ALQ Transmit Buffer count : 0x ffff Max Leasequery Transmit Rate : 60 Local Interface count : 2 Remote Interface count : 2user@host> show dhcpv6 relay active-leasequery statistics peer 2001:db8::2 peer : 2001:db8::2 Topology-Discover Configured : No State : Connected Bindings Sent : 8112 Bindings Received : 12382 Bindings Installed Successfully : 0 Bindings Failed to install : 0 Last Synchronization Time : 2020-02-05 01:27:54 IST ALQ Transmit Buffer count : 0x ffff Max Leasequery Transmit Rate : 60 Local Interface count : 2 Remote Interface count : 2
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.