Détection de l’liveness DHCP
La détection de l’liveness DHCP pour les sessions IP du client DHCP utilise un protocole de détection active de l’liveness pour effectuer des vérifications de la qualité de vie des clients concernés. Lorsqu’il est configuré à l’aide d’un protocole de détection de l’exactitude, si un client donné ne répond pas à un nombre configuré de requêtes de détection consécutives, la liaison client est supprimée et ses ressources sont libérées. Pour plus d’informations, lisez ce sujet.
Présentation de la détection de l’liveness DHCP
Contrairement à PPP, DHCP ne définit pas de mécanisme de keepalive natif dans le cadre des protocoles DHCPv4 ou DHCPv6. Sans un mécanisme de maintien, le serveur local DHCP, le relais DHCP et le proxy de relais DHCP ne peuvent pas détecter rapidement si l’un d’entre eux a perdu la connectivité avec un abonné ou un client DHCP. Au lieu de cela, ils doivent s’appuyer sur les messages standard de session d’abonné DHCP ou de terminaison de session client DHCP.
Souvent, les clients DHCP n’envoient pas de messages de publication DHCP avant de quitter le réseau. La découverte de leur absence dépend du temps de bail DHCP existant et des mécanismes de demande de libération. Ces mécanismes sont souvent insuffisants pour vérifier l’intégrité de la session des clients d’un accès abonné DHCP ou d’un réseau géré par DHCP. Étant donné que les délais de bail DHCP sont généralement trop longs pour fournir un temps de réponse approprié à une défaillance d’intégrité de session, et la configuration de courts temps de bail DHCP peut représenter une charge excessive sur le traitement du plan de contrôle, la mise en œuvre d’un mécanisme de détection de l’intégrité DHCP permet de mieux surveiller les clients DHCP liés. Lorsqu’elle est configurée avec un protocole de détection de la capacité de vie, si un abonné (ou un client) donné ne répond pas à un nombre configuré de demandes de détection de l’exactitude consécutives, la liaison abonné (ou client) est supprimée et ses ressources sont libérées.
La détection DHCP de l’liveness pour les sessions IP d’abonnés DHCP ou de clients IP DHCP utilise un protocole de détection de l’activité pour effectuer des vérifications de la qualité de vie pour les clients concernés. Les clients doivent répondre aux demandes de détection de l’actualité dans un délai spécifié. Si les réponses ne sont pas reçues dans ce délai pour un nombre donné de tentatives consécutives, la vérification de la présence échoue et une action de défaillance est mise en œuvre.
Des exemples de protocoles de détection de la disponibilité comprennent la détection de transfert bidirectionnel (BFD) pour les abonnés DHCPv4 et DHCPv6, le protocole de résolution d’adresses IPv4 (ARP) pour les abonnés DHCPv4 et la détection de l’inachabilité des voisins (NUD) IPv6 à l’aide de paquets Neighbor Discovery (ND) pour les abonnés DHCPv6.
À partir de la version 17.4R1 de Junos OS, l’utilisation de paquets ARP pour les paquets DHCPv4 et ND pour DHCPv6 est prise en charge sur les routeurs MX Series pour la détection de l’habité de couche 2 en plus de la détection de l’habité BFD. Dans les versions précédentes, seul BFD est pris en charge pour toutes les plates-formes.
Les deux méthodes de détection de la vie sont mutuellement exclusives.
Lors de la configuration de la détection de l’BFD, gardez à l’esprit les éléments suivants :
Vous pouvez configurer la détection de l’liveness pour le serveur local DHCP et le relais DHCP.
Vous pouvez configurer la détection de l’liveness DHCPv4 et DHCPv6 soit globalement, soit par groupe DHCPv4 ou DHCPv6.
Les clients d’accès d’abonnés DHCPv4 ou DHCPv6 qui ne prennent pas en charge le BFD ne sont pas affectés par la configuration de détection de l’état de vie. Ces clients peuvent continuer à accéder au réseau (une fois qu’ils ont été validés) même si la détection de la BFD est activée sur le routeur (ou le commutateur).
Une fois configurés, DHCPv4 ou DHCPv6 lancent des vérifications de détection de l’exactitude pour les clients qui prennent en charge le BFD lorsque ces clients entrent dans un état lié.
Une fois que des messages spécifiques au protocole sont lancés pour un client BFD, ils sont régulièrement envoyés à l’adresse IP de l’abonné (ou du client) du client et les réponses à ces demandes de détection de l’actualité sont attendues dans un délai configuré.
Si les clients qui prennent en charge BFD ne reçoivent pas de réponses de détection de l’insurité dans le temps configuré pour un nombre de tentatives consécutives configurés, la vérification de la présence est réputée avoir échoué. Une action de défaillance configurée pour effacer la liaison client est appliquée.
La seule action de défaillance prise en charge pour la détection de l’habité de couche 2 est
clear-binding.
Lors de la configuration de la détection de l’ité de couche 2 DHCP ARP et ND sur MX Series, gardez les éléments suivants à l’esprit :
Vous pouvez configurer la détection de l’liveness pour le serveur local DHCP et le relais DHCP.
Vous pouvez configurer la détection de la vie DHCPv4 et DHCPv6 ARP et ND à l’échelle mondiale, par groupe DHCPv4 ou DHCPv6 et par groupe double pile.
La détection de l’activité ARP/ND s’applique uniquement aux clients DHCP qui :
Sont directement connectés via des VLAN dynamiques.
Avoir des entrées de couche 2 permanentes.
Les clients DHCPv6 doivent avoir une adresse MAC source unique et une adresse locale de liaison. Une seule entrée de détection de la durée de vie est utilisée pour toutes les adresses IPv6 associées à une session client spécifique.
Avantages de la détection de l’liveness DHCP
À l’aide de la détection de l’liveness DHCP, les sessions IP sont mises en place dès que les vérifications de détection de l’brillance échouent. Ce temps de réponse plus rapide permet de :
Fournissez une comptabilisation temporelle plus précise des sessions abonnées (ou client DHCP).
Mieux préserver les ressources du routeur (commutateur).
Réduisez la fenêtre de vulnérabilité de certaines attaques de sécurité.
Configuration de la détection de la connectivité client de relais DHCP ou de proxy de relais DHCP avec BFD
Vous pouvez configurer la détection du caractère vivant avec la détection de transfert bidirectionnel (BFD) pour les sessions IP d’abonnés DHCP ou les sessions IP client DHCP pour vérifier la connectivité des clients relais DHCP. Les clients doivent répondre aux demandes de détection de l’actualité dans un délai spécifié. Si les réponses ne sont pas reçues dans ce délai pour un nombre donné de tentatives consécutives, la vérification de la présence échoue et une action de défaillance est mise en œuvre.
Pour configurer la détection de l’liveness pour le relais DHCP :
Exemple : configuration de la détection globale de l’liveness avec BFD pour les clients d’agents relais DHCP
Cet exemple montre comment configurer la détection de l’liveness pour les abonnés des agents relais DHCP à l’aide de la méthode BFD (Bidirectional Forwarding Detection).
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
Routeurs MX Series de Juniper Networks.
Junos OS Version 12.1 ou ultérieure
Avant de commencer :
Configurez l’agent de relais DHCP. Voir la présentation de l’agent de relais DHCP étendu.
Aperçu
Dans cet exemple, vous configurez la détection de l’liveness pour les abonnés des agents relais DHCP en effectuant les opérations suivantes :
Activez la détection de l’liveness dans le monde entier pour les abonnés relais DHCP.
Spécifiez BFD comme méthode de détection de l’liveness pour tous les abonnés relais DHCP créés dynamiquement.
Configurez des instructions spécifiques au BFD pour définir le comportement du protocole.
Configurez l’action du routeur en cas d’échec de la détection de la brillance.
Cet exemple explique comment configurer la détection de l’liveness pour un réseau DHCPv4. La détection du temps de vie est également prise en charge pour les configurations DHCPv6. Pour configurer la détection de l’exactitude DHCPv6, incluez l’instruction liveness-detection et toutes les déclarations de configuration ultérieures, au niveau ou [edit forwarding-options dhcp-relay dhcpv6 group group-name] de la [edit forwarding-options dhcp-relay dhcpv6] hiérarchie.
Configuration
Procédure
Procédure étape par étape
Pour configurer la détection de l’liveness pour le relais DHCP :
Spécifiez que vous souhaitez configurer la détection de l’liveness.
[edit forwarding-options dhcp-relay] user@host# edit liveness-detection
Spécifiez que vous souhaitez configurer la méthode de détection de l’liveness.
[edit forwarding-options dhcp-relay liveness-detection] user@host# edit method
Spécifiez BFD comme méthode de détection de l’exactitude que vous souhaitez utiliser DHCP.
[edit forwarding-options dhcp-relay liveness-detection method] user@host# edit bfd
Configurez le seuil de temps de détection (en millisecondes) à partir duquel un piège est produit.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set detection-time threshold 50000
Configurez le temps (en millisecondes) pendant lequel BFD reçoit une notification de mise en service de session.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set holddown-interval 50
Configurez l’intervalle de transmission et de réception minimal BFD (en millisecondes).
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set minimum-interval 45000
Configurez l’intervalle de réception minimum (en millisecondes).
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set minimum-receive-interval 60000
Configurez une valeur démultiplicatrice pour le temps de détection.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set multiplier 100
Désactiver la capacité des timeurs d’intervalles BFD à modifier ou à s’adapter aux situations réseau.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set no-adaptation
Configurez le mode de session BFD.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set session-mode automatic
Configurez le seuil et l’intervalle minimal pour l’intervalle de transmission BFD.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set transmit-interval threshold 60000 minimum-interval 45000
Configurez la version du protocole BFD que vous souhaitez détecter.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set version automatic
Configurez l’action du routeur en cas d’échec de la détection de la brillance. Dans cet exemple, l’action d’échec consiste à effacer la session du client uniquement lorsqu’un échec de détection de l’intégrité se produit et que l’interface locale est détectée comme étant en service.
[edit forwarding-options dhcp-relay liveness-detection] user@host# edit failure-action action
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show forwarding-options commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour la corriger. La sortie suivante montre également une gamme d’interfaces configurées dans le groupe francfort.
[edit]
user@host# show forwarding-options
dhcp-relay {
liveness-detection {
failure-action clear-binding-if-interface-up;
method {
bfd {
version automatic;
minimum-interval 45000;
minimum-receive-interval 60000;
multiplier 100;
no-adaptation;
transmit-interval {
minimum-interval 45000;
threshold 60000;
}
detection-time {
threshold 50000;
}
session-mode automatic;
holddown-interval 50;
}
}
}
}
Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.
Configuration de la détection de la connectivité client serveur local DHCP avec BFD
Vous pouvez configurer la détection de l’liveness avec la détection de transfert bidirectionnel (BFD) pour les sessions IP d’abonnés DHCP ou les sessions IP client DHCP pour vérifier la connectivité des clients serveurs LOCAUX DHCP. Les clients doivent répondre aux demandes de détection de l’actualité dans un délai spécifié. Si les réponses ne sont pas reçues dans ce délai pour un nombre donné de tentatives consécutives, la vérification de la présence échoue et une action de défaillance est mise en œuvre.
Vous pouvez également configurer la détection de l’liveness DHCP pour le relais DHCP.
Pour configurer la détection de l’liveness pour le serveur local DHCP :
Exemple : configuration de la détection de l’liveness en groupe avec BFD pour les clients serveurs locaux DHCP
Cet exemple montre comment configurer la détection de l’liveness de groupe pour les abonnés serveurs locaux DHCP ou les clients DHCP à l’aide de la méthode BFD (Bidirectional Forwarding Detection).
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
Routeurs MX Series de Juniper Networks
Commutateurs EX Series De Juniper Networks
Junos OS Version 12.1 ou ultérieure
Avant de commencer :
Configurez le serveur local DHCP. Voir comprendre les différences entre DHCP hérité et DHCP étendu.
Aperçu
Dans cet exemple, vous configurez la détection de l’liveness des groupes pour les abonnés (clients) serveurs locaux DHCP en effectuant les opérations suivantes :
Activez la détection de l’liveness pour les groupes d’abonnés au serveur local DHCP (ou client DHCP).
Spécifiez BFD comme méthode de détection de l’liveness pour tous les abonnés (clients) de serveurs locaux DHCP créés dynamiquement.
Configurez des instructions spécifiques au BFD pour définir le comportement du protocole.
Configurez l’action du routeur (commutateur) en cas d’échec de la détection de l’intégrité.
Cet exemple explique comment configurer la détection de l’liveness pour un réseau DHCPv4. La détection du temps de vie est également prise en charge pour les configurations DHCPv6. Pour configurer la détection de l’exactitude DHCPv6, incluez l’instruction liveness-detection et toutes les déclarations de configuration ultérieures, au niveau ou [edit system services dhcp-local-server dhcpv6 group group-name] de la [edit system services dhcp-local-server dhcpv6] hiérarchie.
Configuration
Procédure
Procédure étape par étape
Pour configurer la détection de l’liveness des groupes pour le serveur local DHCP :
Spécifiez que vous souhaitez configurer la détection de l’liveness.
[edit system services dhcp-local-server ] user@host# edit liveness-detection
Spécifiez que vous souhaitez configurer la détection de l’liveness pour un groupe de serveurs local DHCP spécifique.
[edit system services dhcp-local-server liveness-detection] user@host# edit group local_group_1
Spécifiez que vous souhaitez configurer la méthode de détection de l’liveness.
[edit system services dhcp-local-server group local_group_1 liveness-detection] user@host# edit method
Spécifiez BFD comme méthode de détection de l’exactitude que vous souhaitez utiliser DHCP.
[edit system services dhcp-local-server group local_group_1 liveness-detection method] user@host# edit bfd
Configurez le seuil de temps de détection (en millisecondes) à partir duquel un piège est produit.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set detection-time threshold 30000
Configurez le temps (en millisecondes) pendant lequel BFD reçoit une notification de mise en service de session.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set holddown-interval 50
Configurez l’intervalle de transmission et de réception minimal BFD (en millisecondes).
Note:Vous n’avez pas besoin de configurer l’intervalle de transmission et de réception minimum BFD si vous configurez l’instruction
minimum-intervalpour le BFDtransmit-intervalet leminimum-receive-interval.[edit system services dhcp-local-servergroup local_group_1 liveness-detection method bfd] user@host# set minimum-interval 45000
Configurez l’intervalle de réception minimum (en millisecondes).
Note:Vous n’avez pas besoin de configurer l’intervalle de réception minimal BFD si vous configurez l’intervalle de transmission et de réception minimal BFD.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set minimum-receive-interval 60000
Configurez une valeur démultiplicatrice pour le temps de détection.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set multiplier 100
Désactiver la capacité des timeurs d’intervalles BFD à modifier ou à s’adapter aux situations réseau.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set no-adaptation
Configurez le mode de session BFD.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set session-mode automatic
Configurez le seuil et l’intervalle minimal pour l’intervalle de transmission BFD.
Note:Vous n’avez pas besoin de configurer les valeurs de l’intervalle de transmission si vous avez déjà configuré l’intervalle de transmission et de réception minimal pour BFD.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set transmit-interval threshold 60000 minimum-interval 45000
Configurez la version du protocole BFD que vous souhaitez détecter.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set version automatic
Configurez l’action du routeur (commutateur) en cas d’échec de la détection de l’intégrité. Dans cet exemple, l’action d’échec consiste à effacer la session du client uniquement lorsqu’un échec de détection de l’intégrité se produit et que l’interface locale est détectée comme étant en service.
[edit system services dhcp-local-server group local_group_1 liveness-detection] user@host# edit failure-action action
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show system commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour la corriger.
[edit]
user@host# show system
services {
dhcp-local-server {
group local_group_1 {
liveness-detection {
failure-action clear-binding-if-interface-up;
method {
bfd {
version automatic;
minimum-interval 45000;
minimum-receive-interval 60000;
multiplier 100;
no-adaptation;
transmit-interval {
minimum-interval 45000;
threshold 60000;
}
detection-time {
threshold 30000;
}
session-mode automatic;
holddown-interval 50;
}
}
}
}
}
}
Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.
Détection de l’liveness DHCP à l’aide des paquets ARP et Neighbor Discovery
- Fonctionnement de la détection de l’liveness DHCP avec ARP et Neighbor Discovery Packets
- Configuration de la détection BNG de la connectivité client serveur local DHCP avec les paquets ARP et ND
- Configuration de la détection BNG de la connectivité client relais DHCP avec les paquets ARP et ND
- Configuration de la détection des hôtes DHCP de la connectivité client avec les paquets ARP et ND
Fonctionnement de la détection de l’liveness DHCP avec ARP et Neighbor Discovery Packets
À partir de la version 17.4R1 de Junos OS, vous pouvez configurer la détection de l’accessibilité à l’aide du protocole ARP (Address Resolution Protocol) IPv4 pour les clients DHCPv4 et de la détection de l’accessibilité des voisins IPv6 pour les clients DHCPv6. Cette détection du caractère actif de couche 2 offre des mécanismes distincts pour l’hôte client DHCP et pour le routeur agissant comme une passerelle réseau haut débit (BNG) afin de déterminer la validité et l’état des sessions client DHCP. Ces mécanismes sont appelés fonctionnalités d’envoi et de réception . Vous pouvez configurer la détection de l’liveness de couche 2 pour les serveurs locaux DHCP et les clients relais DHCP.
Fonctionnalité d’envoi
Le BNG utilise la fonctionnalité d’envoi pour effectuer une vérification de la connectivité de l’hôte sur ses clients DHCPv4 et DHCPv6 directement connectés, afin de déterminer la validité et l’état de la session client DHCP, et de nettoyer les sessions inactives. La figure 1 illustre la fonctionnalité d’envoi.
Le BNG envoie des paquets de demande à chaque client DHCP à un intervalle configurable, puis attend une réponse. Le BNG retente les demandes lorsqu’il ne reçoit pas de réponse en temps opportun. Il envoie des requêtes ARP pour les clients DHCPv4 et des requêtes Neighbor Discovery (ND) pour les clients DHCPv6.
Si le BNG reçoit une réponse du client avant l’expiration de l’intervalle, il attend que le délai expire, puis envoie une autre demande à ce client.
Si le BNG ne reçoit pas de réponse avant l’arrêt de l’intervalle, il définit la minuteur à 30 secondes et envoie une autre requête. Il s’agit de la première tentative de nouvelle tentative; le timer n’est pas configurable.
Si le BNG reçoit une réponse du client avant l’expiration du timer, alors le BNG attend que le compteur s’exécute, le réinitialise à la valeur d’origine configurable, envoie une autre demande et lance le compteur.
Si le délai de 30 secondes expire avant qu’une réponse ne soit reçue, le BNG définit le timer à 10 secondes et envoie une autre requête. Cette valeur du timer n’est pas configurable.
Si le BNG reçoit une réponse du client avant l’expiration du timer, alors le BNG attend que le compteur s’exécute, le réinitialise à la valeur d’origine configurable, envoie une autre demande et lance le compteur.
Si le BNG ne reçoit pas de réponse dans l’intervalle de 10 secondes, il envoie une autre requête et recommment le délai de 10 secondes. Le BNG continue d’envoyer des requêtes à des intervalles de 10 secondes jusqu’à ce qu’il reçoive une réponse du client avant que l’intervalle ne s’arrête ou qu’il épuise le nombre de tentatives de nouvelle tentative.
La première tentative de nouvelle tentative utilise l’intervalle de 30 secondes. Les tentatives ultérieures se produisent à des intervalles de 10 secondes. Le nombre de tentatives possibles de 10 secondes est donc le nombre total moins 1. Par exemple, si vous configurez 5 tentatives, il y a une nouvelle tentative de 30 secondes et jusqu’à quatre tentatives de 10 secondes.
Si le BNG n’envoie jamais de réponse d’un client dans l’intervalle précédant l’épuisement des tentatives, alors la vérification de l’existence échoue et l’action de défaillance claire est mise en œuvre. La session client est bloquée.
Fonctionnalité de réception
La fonctionnalité de réception permet à un hôte client DHCP de déterminer l’état de la session client DHCPv4 ou DHCPv6 du point de vue d’un BNG. Le BNG effectue une vérification de la connectivité de l’hôte sur ses clients DHCPv4 et DHCPv6 directement connectés lorsqu’il reçoit des paquets ARP ou ND. La figure 2 illustre la fonctionnalité de réception.
Lorsque le BNG reçoit l’un de ces paquets, il effectue les opérations suivantes :
Vérifie si la détection de l’activité de couche 2 pour la gestion des abonnés est activée dans le monde entier pour la famille d’adresses concernée, inet ou inet6.
Si la détection de l’activité de couche 2 n’est pas activée, le BNG répond comme d’habitude aux paquets reçus sans vérifier l’état de la session client.
Si la détection du caractère actif est activée pour la famille, alors le BNG vérifie si la session client est toujours dans l’état lié.
Si la session client est liée, le BNG répond au client avec le paquet ARP ou ND approprié.
Si la session n’est pas liée, le BNG abandonne le paquet reçu. Il n’envoie pas de paquet de réponse ARP ou ND à l’hôte, ce qui lui permet de déterminer si le BNG considère la session comme étant en panne.
L’utilité de la fonctionnalité de réception dépend de la capacité de l’hôte client DHCP à récupérer des ressources du client obsolète en fonction de l’absence de paquet de réponse du BNG pour une session client non liée. Si cette fonctionnalité nécessite une modification de l’implémentation du client, vous pouvez utiliser la fonctionnalité d’envoi.
Configuration de la détection BNG de la connectivité client serveur local DHCP avec les paquets ARP et ND
Cette procédure vous montre comment configurer la fonctionnalité d’envoi de la détection de l’accessibilité de couche 2 à l’aide du protocole IPv4 de résolution d’adresses (ARP) pour les clients DHCPv4 et de la détection de l’accessibilité des voisins IPv6 pour les clients DHCPv6 pour vérifier la connectivité des clients de serveurs locaux DHCP.
La fonctionnalité d’envoi permet au BNG de déterminer si une session client est en panne en raison d’un manque de réponse du client DHCP aux paquets de requête ARP ou ND qu’il envoie au client.
La détection de l’liveness DHCP peut également être configurée à l’aide de la détection de transfert bidirectionnel (BFD). La détection du caractère vivant BFD et la détection de la vie ARP/ND sont mutuellement exclusives.
Pour configurer la fonctionnalité d’envoi pour la détection de l’exactitude des serveurs locaux DHCPv4 :
Pour configurer la fonctionnalité d’envoi pour la détection de l’exactitude des serveurs locaux DHCPv6 :
Spécifiez que vous souhaitez configurer la méthode de détection de l’liveness.
Pour la configuration globale DHCPv6 :
[edit system services dhcp-local-server dhcpv6] user@host# edit liveness-detection method
Pour la configuration de groupe DHCPv6 :
[edit system services dhcp-local-server dhcpv6] user@host# edit group group-name liveness-detection method
Spécifiez la méthode de détection de l’insurité de couche 2.
Pour la configuration globale DHCPv6 :
[edit system services dhcp-local-server dhcpv6 liveness-detection method] user@host# set layer2-liveness-detection
Pour la configuration de groupe DHCPv6 :
[edit system services dhcp-local-server dhcpv6 group group-name liveness-detection method] user@host# set layer2-liveness-detection
(Facultatif) Configurez le nombre de tentatives de nouvelle tentative et le timer d’intervalle.
Pour la configuration globale DHCPv6 :
[edit system services dhcp-local-server dhcpv6 liveness-detection method] user@host# edit layer2-liveness-detection user@host# set max-consecutive-retries number user@host# set transmit-interval seconds
Pour la configuration de groupe DHCPv6 :
[edit system services dhcp-local-server dhcpv6 group group-name liveness-detection method] user@host# edit layer2-liveness-detection user@host# set max-consecutive-retries number user@host# set transmit-interval seconds
Configuration de la détection BNG de la connectivité client relais DHCP avec les paquets ARP et ND
Cette procédure vous montre comment configurer la fonctionnalité d’envoi de la détection de l’accessibilité de couche 2 à l’aide du protocole IPv4 de résolution d’adresses (ARP) pour les clients DHCPv4 et de la détection de l’accessibilité des voisins IPv6 pour les clients DHCPv6 pour vérifier la connectivité des clients relais DHCP.
La fonctionnalité d’envoi permet au BNG de déterminer si une session client est en panne en raison d’un manque de réponse du client DHCP aux paquets de requête ARP ou ND qu’il envoie au client.
La détection de l’liveness DHCP peut également être configurée à l’aide de la détection de transfert bidirectionnel (BFD). La détection du caractère vivant BFD et la détection de la vie ARP/ND sont mutuellement exclusives.
Pour configurer la fonctionnalité d’envoi pour la détection de l’ité du relais DHCPv4 :
Pour configurer la fonctionnalité d’envoi pour la détection de l’ité du relais DHCPv6 :
Spécifiez que vous souhaitez configurer la méthode de détection de l’liveness.
Pour la configuration globale DHCPv6 :
[edit forwarding-options dhcp-relay dhcpv6] user@host# edit liveness-detection method
Pour la configuration de groupe DHCPv6 :
[edit forwarding-options dhcp-relay dhcpv6] user@host# edit group group-name liveness-detection method
Spécifiez la méthode de détection de l’insurité de couche 2.
Pour la configuration globale DHCPv6 :
[edit forwarding-options dhcp-relay dhcpv6 liveness-detection method] user@host# set layer2-liveness-detection
Pour la configuration de groupe DHCPv6 :
[edit forwarding-options dhcp-relay dhcpv6 group group-name liveness-detection method] user@host# set layer2-liveness-detection
(Facultatif) Configurez le nombre de tentatives de nouvelle tentative et le timer d’intervalle.
Pour la configuration globale DHCPv6 :
[edit forwarding-options dhcp-relay dhcpv6 liveness-detection method] user@host# edit layer2-liveness-detection user@host# set max-consecutive-retries number user@host# set transmit-interval seconds
Pour la configuration de groupe DHCPv6 :
[edit forwarding-options dhcp-relay dhcpv6 group group-name liveness-detection method] user@host# edit layer2-liveness-detection user@host# set max-consecutive-retries number user@host# set transmit-interval seconds
Configuration de la détection des hôtes DHCP de la connectivité client avec les paquets ARP et ND
Cette procédure vous montre comment configurer la fonctionnalité de réception de la détection de l’accessibilité de couche 2 à l’aide du protocole IPv4 de résolution d’adresses (ARP) pour les clients DHCPv4 et de la détection de l’accessibilité des voisins IPv6 pour les clients DHCPv6 afin de vérifier la connectivité des clients de serveurs locaux DHCP.
La fonctionnalité de réception permet à l’hôte client DHCP de déterminer si une session client est en panne en raison d’un manque de réponse du BNG aux paquets ARP ou ND qu’il envoie au BNG. Vous configurez la fonctionnalité de réception globale pour DHCP par famille d’adresses pour remplacer la configuration globale de gestion des abonnés.
Pour DHCPv4 :
[edit system services subscriber-management overrides] user@host# set interfaces family inet layer2-liveness-detection
Pour DHCPv6 :
[edit system services subscriber-management overrides] user@host# set interfaces family inet6 layer2-liveness-detection