Détection de la vivacité DHCP
La détection DHCP de la vivacité des sessions IP des clients DHCP utilise un protocole de détection active de la vivacité pour effectuer des vérifications de détection de la vivacité des clients concernés. Lorsqu’il est configuré avec un protocole de détection d’activité, si un client donné ne répond pas à un nombre configuré de demandes consécutives de détection d’activité, la liaison client est supprimée et ses ressources sont libérées. Pour plus d’informations, consultez cette rubrique.
Présentation de la détection de vivacité DHCP
Contrairement à PPP, DHCP ne définit pas de mécanisme keepalive natif dans le cadre des protocoles DHCPv4 ou DHCPv6. Sans mécanisme de rétention, 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 des messages standard de session d’abonné DHCP ou de session de session client DHCP.
Souvent, les clients DHCP n’envoient pas de messages de version DHCP avant de quitter le réseau. La découverte de leur absence dépend des mécanismes DHCP existants, de durée de bail et de demande de libération. Ces mécanismes sont souvent insuffisants lorsqu’il s’agit de vérifier l’état 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 location DHCP sont généralement trop longs pour fournir un temps de réponse adéquat en cas de défaillance de l’intégrité de la session, et que la configuration de temps de location DHCP courts peut représenter une charge excessive pour le traitement du plan de contrôle, l’implémentation d’un mécanisme de détection de la vivacité DHCP permet de mieux surveiller les clients DHCP liés. Lorsqu’il est configuré avec un protocole de détection d’activité, si un abonné (ou client) donné ne répond pas à un nombre configuré de demandes consécutives de détection d’activité, la liaison d’abonné (ou client) est supprimée et ses ressources libérées.
La détection de vivacité DHCP pour les sessions IP d’abonné DHCP ou IP cliente DHCP utilise un protocole de détection active de la vivacité pour instituer des vérifications de détection de vivacité pour les clients concernés. Les clients doivent répondre aux demandes de détection de vivacité 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 détection de vivacité échoue et une action d’échec est implémentée.
Parmi les exemples de protocoles de détection d’activité, citons la détection de transfert bidirectionnel (BFD) pour les abonnés DHCPv4 et DHCPv6, le protocole de résolution d’adresse IPv4 (ARP) pour les abonnés DHCPv4 et la détection d’inaccessibilité de voisinage (NUD) IPv6 à l’aide de paquets ND (Neighbor Discovery) pour les abonnés DHCPv6.
À partir de la version 17.4R1 de Junos OS, l’utilisation de paquets ARP pour DHCPv4 et de paquets ND pour DHCPv6 est prise en charge sur les routeurs MX Series pour la détection de la vivacité de couche 2 en plus de la détection de la vivacité BFD. Dans les versions antérieures, seul BFD était pris en charge pour toutes les plates-formes.
Les deux méthodes de détection de la vivacité s’excluent mutuellement.
Lors de la configuration de la détection de vivacité BFD, gardez à l’esprit les points suivants :
Vous pouvez configurer la détection d’activité pour le serveur local DHCP et le relais DHCP.
Vous pouvez configurer la détection de vivacité DHCPv4 et DHCPv6 globalement ou par groupe DHCPv4 ou DHCPv6.
Les clients d’accès abonné DHCPv4 ou DHCPv6 qui ne prennent pas en charge BFD ne sont pas affectés par la configuration de détection de vivacité. Ces clients peuvent continuer à accéder au réseau (après validation) même si la détection de vivacité BFD est activée sur le routeur (ou le commutateur).
Lorsqu’il est configuré, DHCPv4 ou DHCPv6 lance des vérifications de détection de vivacité pour les clients qui prennent en charge BFD lorsque ces derniers entrent dans un état lié.
Une fois que des messages spécifiques au protocole sont initiés pour un client BFD, ils sont envoyés régulièrement à l’adresse IP de l’abonné (ou du client) du client et les réponses à ces demandes de détection d’activité sont attendues dans un délai configuré.
Si aucune réponse de détection d’activité n’est reçue des clients qui prennent en charge BFD dans le délai configuré pour un nombre configuré de tentatives consécutives, la vérification de détection d’activité est considérée comme ayant échoué. Une action d’échec 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’activité de couche 2 est
clear-binding.
Lors de la configuration de la détection d’activité DHCP ARP et ND de couche 2 sur MX Series, gardez à l’esprit les points suivants :
Vous pouvez configurer la détection d’activité pour le serveur local DHCP et le relais DHCP.
Vous pouvez configurer la détection de la vivacité DHCPv4 et DHCPv6 ARP et ND globalement, par groupe DHCPv4 ou DHCPv6 et par groupe à double pile.
La détection de vivacité ARP/ND s’applique uniquement aux clients DHCP qui :
sont directement connectés via des VLAN dynamiques.
Avoir des entrées permanentes de couche 2.
Les clients DHCPv6 doivent disposer d’une adresse MAC source et d’une adresse locale de liaison uniques. Une seule entrée de détection d’activité est utilisée pour toutes les adresses IPv6 associées à une session client spécifique.
Avantages de la détection de la vivacité DHCP
La détection DHCP de vivacité permet d’agir sur les sessions IP dès que les vérifications de détection d’activité échouent. Ce temps de réponse plus rapide permet de :
Comptabilisation temporelle plus précise des sessions d’abonnés (ou de clients DHCP).
Mieux préserver les ressources du routeur (commutateur).
Aide à réduire la fenêtre de vulnérabilité à certaines attaques de sécurité.
Configuration de la détection de la connectivité du client proxy du relais DHCP ou du relais DHCP avec BFD
Vous pouvez configurer la détection d’activité avec la détection de transfert bidirectionnel (BFD) pour les sessions IP d’abonné DHCP ou les sessions IP client DHCP afin de vérifier la connectivité des clients de relais DHCP. Les clients doivent répondre aux demandes de détection de vivacité 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 détection de vivacité échoue et une action d’échec est implémentée.
Pour configurer la détection d’activité pour le relais DHCP :
Exemple : Configuration de la détection globale de vivacité avec BFD pour les clients de l’agent de relais DHCP
Cet exemple montre comment configurer la détection d’activité pour les abonnés de l’agent de relais DHCP à l’aide de la méthode de détection de transfert bidirectionnel (BFD) comme méthode de détection de l’activité.
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. Reportez-vous à la section Présentation de l’agent de relais DHCP étendu.
Aperçu
Dans cet exemple, vous configurez la détection d’activité pour les abonnés de l’agent de relais DHCP en effectuant les opérations suivantes :
Activez la détection de l’activité à l’échelle mondiale pour les abonnés au relais DHCP.
Spécifiez BFD comme méthode de détection d’activité pour tous les abonnés relais DHCP créés dynamiquement.
Configurez les instructions spécifiques à BFD pour définir le comportement du protocole.
Configurez l’action du routeur en cas d’échec de la détection d’activité.
Cet exemple explique comment configurer la détection d’activité pour un réseau DHCPv4. La détection de vivacité est également prise en charge pour les configurations DHCPv6. Pour configurer la détection de la vivacité de DHCPv6, incluez l’instruction liveness-detection et toutes les instructions de configuration suivantes au niveau de la [edit forwarding-options dhcp-relay dhcpv6] [edit forwarding-options dhcp-relay dhcpv6 group group-name] hiérarchie.
Configuration
Procédure
Procédure étape par étape
Pour configurer la détection d’activité pour le relais DHCP :
Indiquez que vous souhaitez configurer la détection de vivacité.
[edit forwarding-options dhcp-relay] user@host# edit liveness-detection
Indiquez que vous souhaitez configurer la méthode de détection de vivacité.
[edit forwarding-options dhcp-relay liveness-detection] user@host# edit method
Spécifiez BFD comme méthode de détection de l’activité que vous souhaitez utiliser pour 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 généré.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set detection-time threshold 50000
Configurez l’heure (en millisecondes) pendant laquelle BFD retient une notification de session.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set holddown-interval 50
Configurez l’intervalle minimum d’émission et de réception BFD (en millisecondes).
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set minimum-interval 45000
Configurez l’intervalle de réception minimal (en millisecondes).
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set minimum-receive-interval 60000
Configurez une valeur multiplicatrice pour l’heure de détection.
[edit forwarding-options dhcp-relay liveness-detection method bfd] user@host# set multiplier 100
Désactivez la possibilité pour les temporisateurs d’intervalle BFD de changer ou de s’adapter aux situations du 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 minimum 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 d’activité. Dans cet exemple, l’action d’échec consiste à effacer la session client uniquement lorsqu’un échec de détection d’activité se produit et que l’interface locale est détectée comme étant active.
[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 plage d’interfaces configurées dans le groupe de 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 terminé de configurer l’appareil, passez commit en mode de configuration.
Configuration de la détection de la connectivité client-serveur local DHCP avec BFD
Vous pouvez configurer la détection de vivacité avec la détection de transfert bidirectionnel (BFD) pour les sessions IP d’abonné DHCP ou les sessions IP client DHCP afin de vérifier la connectivité des clients de serveur local DHCP. Les clients doivent répondre aux demandes de détection de vivacité 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 détection de vivacité échoue et une action d’échec est implémentée.
Vous pouvez également configurer la détection de vivacité DHCP pour le relais DHCP.
Pour configurer la détection d’activité pour le serveur local DHCP :
Exemple : Configuration de la détection de la vivacité du groupe avec BFD pour les clients du serveur local DHCP
Cet exemple montre comment configurer la détection d’activité de groupe pour les abonnés au serveur local DHCP ou les clients DHCP à l’aide de la détection de transfert bidirectionnel (BFD) comme méthode de détection de l’activité.
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. Reportez-vous à la section Comprendre les différences entre le DHCP hérité et le DHCP étendu.
Aperçu
Dans cet exemple, vous allez configurer la détection de la vivacité de groupe pour les abonnés (clients) du serveur local DHCP en effectuant les opérations suivantes :
Activez la détection d’activité pour les groupes d’abonnés au serveur local DHCP (ou les groupes clients DHCP).
Spécifiez BFD comme méthode de détection de l’activité pour tous les abonnés (clients) du serveur local DHCP créés dynamiquement.
Configurez les instructions spécifiques à BFD pour définir le comportement du protocole.
Configurez l’action du routeur (commutateur) en cas d’échec de la détection d’activité.
Cet exemple explique comment configurer la détection d’activité pour un réseau DHCPv4. La détection de vivacité est également prise en charge pour les configurations DHCPv6. Pour configurer la détection de la vivacité de DHCPv6, incluez l’instruction liveness-detection et toutes les instructions de configuration suivantes au niveau de la [edit system services dhcp-local-server dhcpv6] [edit system services dhcp-local-server dhcpv6 group group-name] hiérarchie.
Configuration
Procédure
Procédure étape par étape
Pour configurer la détection d’activité de groupe pour le serveur local DHCP :
Indiquez que vous souhaitez configurer la détection de vivacité.
[edit system services dhcp-local-server ] user@host# edit liveness-detection
Indiquez que vous souhaitez configurer la détection d’activité pour un groupe de serveurs local DHCP spécifique.
[edit system services dhcp-local-server liveness-detection] user@host# edit group local_group_1
Indiquez que vous souhaitez configurer la méthode de détection de vivacité.
[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’activité que vous souhaitez utiliser pour 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 généré.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set detection-time threshold 30000
Configurez l’heure (en millisecondes) pendant laquelle BFD retient une notification 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 minimum d’émission et de réception BFD (en millisecondes).
Note:Vous n’avez pas besoin de configurer l’intervalle minimum de transmission et de réception BFD si vous configurez le
minimum-intervalpour l’instruction 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 minimal (en millisecondes).
Note:Vous n’avez pas besoin de configurer l’intervalle de réception minimum BFD si vous configurez l’intervalle minimum d’émission et de réception 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 multiplicatrice pour l’heure de détection.
[edit system services dhcp-local-server group local_group_1 liveness-detection method bfd] user@host# set multiplier 100
Désactivez la possibilité pour les temporisateurs d’intervalle BFD de changer ou de s’adapter aux situations du 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 minimum 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 minimal d’émission et de réception 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 d’activité. Dans cet exemple, l’action d’échec consiste à effacer la session client uniquement lorsqu’un échec de détection d’activité se produit et que l’interface locale est détectée comme étant active.
[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 terminé de configurer l’appareil, passez commit en mode de configuration.
Détection de la vivacité DHCP à l’aide de paquets ARP et de découverte de voisins
- Fonctionnement de la détection de la vivacité DHCP avec ARP et les paquets de découverte de voisins
- 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 des paquets ARP et ND
- Configuration de la détection de la connectivité client par l’hôte DHCP avec des paquets ARP et ND
Fonctionnement de la détection de la vivacité DHCP avec ARP et les paquets de découverte de voisins
À partir de Junos OS version 17.4R1, vous pouvez configurer la détection de vivacité à l’aide du protocole ARP (Address Resolution Protocol) IPv4 pour les clients DHCPv4 et de la détection de l’inaccessible de voisinage IPv6 pour les clients DHCPv6. Cette détection d’activité 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é d’envoi et fonctionnalité de réception . Vous pouvez configurer la détection d’activité de couche 2 pour le serveur local DHCP et les clients relais DHCP.
Fonctionnalité d’envoi
La BNG utilise la fonctionnalité d’envoi pour vérifier 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 requête à chaque client DHCP à un intervalle configurable, puis attend une réponse. Le BNG relance les demandes lorsqu’il ne reçoit pas de réponse dans les délais. Il envoie des requêtes ARP pour les clients DHCPv4 et des requêtes ND (Neighbor Discovery) pour les clients DHCPv6.
Si la BNG reçoit une réponse du client avant l’expiration de l’intervalle, elle attend l’expiration du minuteur, puis envoie une autre requête à ce client.
Si le BNG ne reçoit pas de réponse avant l’expiration de l’intervalle, il règle le minuteur sur 30 secondes et envoie une autre demande. Il s’agit de la première nouvelle tentative. La minuterie n’est pas configurable.
Si le BNG reçoit une réponse du client avant l’expiration du minuteur, il attend que le minuteur s’exécute, le réinitialise à la valeur configurable d’origine, envoie une autre requête et démarre le minuteur.
Si le minuteur de 30 secondes expire avant qu’une réponse ne soit reçue, le BNG le règle sur 10 secondes et envoie une autre demande. Cette valeur de minuterie n’est pas configurable.
Si le BNG reçoit une réponse du client avant l’expiration du minuteur, il attend que le minuteur s’exécute, le réinitialise à la valeur configurable d’origine, envoie une autre requête et démarre le minuteur.
Si le BNG ne reçoit pas de réponse dans l’intervalle de 10 secondes, il envoie une autre requête et redémarre le minuteur de 10 secondes. Le BNG continue d’envoyer des requêtes toutes les 10 secondes jusqu’à ce qu’il reçoive une réponse du client avant l’expiration de l’intervalle ou qu’il épuise le nombre de nouvelles tentatives.
La première tentative utilise l’intervalle de 30 secondes. Les tentatives suivantes ont lieu toutes les 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 ne reçoit jamais de réponse d’un client dans l’intervalle précédant l’épuisement des nouvelles tentatives, la vérification de la détection de vivacité échoue et l’action d’échec de liaison claire est implémentée. La session client est effacé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 vérifie 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 ou l’autre de ces paquets, il effectue les opérations suivantes :
Vérifie si la détection d’activité de couche 2 pour la gestion des abonnés est activée globalement pour la famille d’adresses concernée, inet ou inet6.
Si la détection de vivacité 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 d’activité est activée pour la famille, le BNG vérifie si la session client est toujours à 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 permet à l’hôte de déterminer que le BNG considère que la session est inactive.
L’utilité de la fonctionnalité de réception dépend de la capacité de l’hôte client DHCP à récupérer des ressources auprès du client obsolète en fonction de l’absence d’un 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 vivacité de couche 2 à l’aide du protocole de résolution d’adresse IPv4 (ARP) pour les clients DHCPv4 et de la détection de l’inaccessible de voisinage IPv6 pour les clients DHCPv6 pour vérifier la connectivité des clients du serveur local DHCP.
La fonctionnalité d’envoi permet au BNG de déterminer si une session client est inactive en raison d’une absence de réponse du client DHCP aux paquets de demande ARP ou ND qu’il envoie au client.
La détection de vivacité DHCP peut également être configurée à l’aide de la détection de transfert bidirectionnel (BFD). La détection de vivacité BFD et la détection de vivacité ARP/ND s’excluent mutuellement.
Pour configurer la fonctionnalité d’envoi pour la détection de vivacité du serveur local DHCPv4 :
Pour configurer la fonctionnalité d’envoi pour la détection de la vivacité du serveur local DHCPv6 :
Indiquez que vous souhaitez configurer la méthode de détection de vivacité.
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’activité 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 minuteur 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 des paquets ARP et ND
Cette procédure vous montre comment configurer la fonctionnalité d’envoi de la détection d’activité de couche 2 à l’aide du protocole de résolution d’adresse IPv4 (ARP) pour les clients DHCPv4 et de la détection de l’inaccessible de voisinage IPv6 pour les clients DHCPv6 afin de vérifier la connectivité des clients relais DHCP.
La fonctionnalité d’envoi permet au BNG de déterminer si une session client est inactive en raison d’une absence de réponse du client DHCP aux paquets de demande ARP ou ND qu’il envoie au client.
La détection de vivacité DHCP peut également être configurée à l’aide de la détection de transfert bidirectionnel (BFD). La détection de vivacité BFD et la détection de vivacité ARP/ND s’excluent mutuellement.
Pour configurer la fonctionnalité d’envoi pour la détection de vivacité du relais DHCPv4 :
Pour configurer la fonctionnalité d’envoi pour la détection de vivacité du relais DHCPv6 :
Indiquez que vous souhaitez configurer la méthode de détection de vivacité.
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’activité 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 minuteur 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 de la connectivité client par l’hôte DHCP avec des paquets ARP et ND
Cette procédure vous montre comment configurer la fonctionnalité de réception de la détection de vivacité de couche 2 à l’aide du protocole de résolution d’adresse IPv4 (ARP) pour les clients DHCPv4 et de la détection de l’inaccessible de voisinage IPv6 pour les clients DHCPv6 afin de vérifier la connectivité des clients du serveur local DHCP.
La fonctionnalité de réception permet à l’hôte client DHCP de déterminer si une session client est inactive en raison d’une absence de réponse du BNG aux paquets ARP ou ND qu’il envoie au BNG. Vous configurez globalement la fonctionnalité de réception pour DHCP par famille d’adresses en remplacement de 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
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.