Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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 :

  1. Spécifiez que vous souhaitez configurer la détection de l’liveness.
    • Pour la configuration globale DHCP :

    • Pour la configuration de groupes DHCP :

    Note:

    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.

  2. (Facultatif) Spécifiez que vous souhaitez utiliser le mode proxy relais DHCP.
  3. Spécifiez que vous souhaitez configurer la méthode de détection de l’liveness.
    • Pour la configuration globale DHCP :

    • Pour la configuration de groupes DHCP :

  4. Spécifiez la méthode de détection de l’exactitude que vous souhaitez utiliser DHCP.
    Note:

    Dans les versions antérieures à Junos OS version 17.4R1, la seule méthode prise en charge pour la détection de l’liveness sur toutes les plates-formes est BFD.

    À 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. Les deux méthodes de détection de la vie sont mutuellement exclusives. Consultez la fonctionnalité DHCP Liveness Detection À l’aide des paquets ARP et Neighbor Discovery pour plus d’informations sur la configuration de la détection de l’liveness de couche 2 ARP et ND.

    • Pour la configuration globale DHCP :

    • Pour la configuration de groupes DHCP :

  5. Configurez la méthode de détection de l’liveness comme vous le souhaitez.

    Voir l’exemple : Configuration de la détection globale de l’liveness avec BFD pour les clients d’agents relais DHCP pour un exemple de configuration globale de la détection de l’liveness des relais DHCP avec BFD.

  6. Configurez l’action du routeur en cas d’échec de la détection de la brillance.
    • Pour la configuration globale DHCP :

    • Pour la configuration de groupes 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 :

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 :

  1. Activez la détection de l’liveness dans le monde entier pour les abonnés relais DHCP.

  2. Spécifiez BFD comme méthode de détection de l’liveness pour tous les abonnés relais DHCP créés dynamiquement.

  3. Configurez des instructions spécifiques au BFD pour définir le comportement du protocole.

  4. Configurez l’action du routeur en cas d’échec de la détection de la brillance.

Note:

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 :

  1. Spécifiez que vous souhaitez configurer la détection de l’liveness.

  2. Spécifiez que vous souhaitez configurer la méthode de détection de l’liveness.

  3. Spécifiez BFD comme méthode de détection de l’exactitude que vous souhaitez utiliser DHCP.

  4. Configurez le seuil de temps de détection (en millisecondes) à partir duquel un piège est produit.

  5. Configurez le temps (en millisecondes) pendant lequel BFD reçoit une notification de mise en service de session.

  6. Configurez l’intervalle de transmission et de réception minimal BFD (en millisecondes).

  7. Configurez l’intervalle de réception minimum (en millisecondes).

  8. Configurez une valeur démultiplicatrice pour le temps de détection.

  9. Désactiver la capacité des timeurs d’intervalles BFD à modifier ou à s’adapter aux situations réseau.

  10. Configurez le mode de session BFD.

  11. Configurez le seuil et l’intervalle minimal pour l’intervalle de transmission BFD.

  12. Configurez la version du protocole BFD que vous souhaitez détecter.

  13. 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.

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.

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.

Note:

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 :

  1. Spécifiez que vous souhaitez configurer la détection de l’liveness.
    • Pour la configuration globale DHCP :

    • Pour la configuration de groupes DHCP :

    Note:

    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.

  2. Spécifiez que vous souhaitez configurer la méthode de détection de l’liveness.
    • Pour la configuration globale DHCP :

    • Pour la configuration de groupes DHCP :

  3. Spécifiez la méthode de détection de l’exactitude que vous souhaitez utiliser DHCP.
    Note:

    Dans les versions antérieures à Junos OS version 17.4R1, la seule méthode prise en charge pour la détection de l’liveness sur toutes les plates-formes est BFD.

    À 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. Les deux méthodes de détection de la vie sont mutuellement exclusives. Consultez la fonctionnalité DHCP Liveness Detection À l’aide des paquets ARP et Neighbor Discovery pour plus d’informations sur la configuration de la détection de l’liveness de couche 2 ARP et ND.

    • Pour la configuration globale DHCP :

    • Pour la configuration de groupes DHCP :

  4. Configurez la méthode de détection de l’liveness comme vous le souhaitez.

    Voir l’exemple : Configuration de la détection de l’liveness des groupes avec BFD pour les clients serveurs locaux DHCP pour un exemple de configuration de groupes DHCPv4 pour la détection de l’exactitude des serveurs locaux DHCP avec BFD.

  5. Configurez l’action du routeur en cas d’échec de la détection de la brillance.
    • Pour la configuration globale DHCP :

    • Pour la configuration de groupes 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 :

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 :

  1. Activez la détection de l’liveness pour les groupes d’abonnés au serveur local DHCP (ou client DHCP).

  2. 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.

  3. Configurez des instructions spécifiques au BFD pour définir le comportement du protocole.

  4. Configurez l’action du routeur (commutateur) en cas d’échec de la détection de l’intégrité.

Note:

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 :

  1. Spécifiez que vous souhaitez configurer la détection de l’liveness.

  2. Spécifiez que vous souhaitez configurer la détection de l’liveness pour un groupe de serveurs local DHCP spécifique.

  3. Spécifiez que vous souhaitez configurer la méthode de détection de l’liveness.

  4. Spécifiez BFD comme méthode de détection de l’exactitude que vous souhaitez utiliser DHCP.

  5. Configurez le seuil de temps de détection (en millisecondes) à partir duquel un piège est produit.

  6. Configurez le temps (en millisecondes) pendant lequel BFD reçoit une notification de mise en service de session.

  7. 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-interval pour le BFD transmit-interval et le minimum-receive-interval.

  8. 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.

  9. Configurez une valeur démultiplicatrice pour le temps de détection.

  10. Désactiver la capacité des timeurs d’intervalles BFD à modifier ou à s’adapter aux situations réseau.

  11. Configurez le mode de session BFD.

  12. 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.

  13. Configurez la version du protocole BFD que vous souhaitez détecter.

  14. 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.

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.

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

À 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.

Figure 1 : flux de comportement d’envoi de détection de l’insurité de couche 2 Layer 2 Liveness Detection Send Behavior Flow
  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

Figure 2 : détection de l’insurité de couche 2 Flux comportemental de réception Layer 2 Liveness Detection Receive Behavior Flow

Lorsque le BNG reçoit l’un de ces paquets, il effectue les opérations suivantes :

  1. 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.

  2. 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.

  3. 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é.

  4. Si la session client est liée, le BNG répond au client avec le paquet ARP ou ND approprié.

  5. 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.

Note:

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 :

  1. Spécifiez que vous souhaitez configurer la méthode de détection de l’liveness.
    • Pour la configuration globale DHCPv4 :

    • Pour la configuration de groupe DHCPv4 :

    • Pour la configuration d’un groupe double pile DHCPv4 :

  2. Spécifiez la méthode de détection de l’insurité de couche 2.
    • Pour la configuration globale DHCPv4 :

    • Pour la configuration de groupe DHCPv4 :

    • Pour la configuration d’un groupe double pile DHCPv4 :

  3. (Facultatif) Configurez le nombre de tentatives de nouvelle tentative et le timer d’intervalle.
    • Pour la configuration globale DHCPv4 :

    • Pour la configuration de groupe DHCPv4 :

    • Pour la configuration d’un groupe double pile DHCPv4 :

Pour configurer la fonctionnalité d’envoi pour la détection de l’exactitude des serveurs locaux DHCPv6 :

  1. Spécifiez que vous souhaitez configurer la méthode de détection de l’liveness.

    • Pour la configuration globale DHCPv6 :

    • Pour la configuration de groupe DHCPv6 :

  2. Spécifiez la méthode de détection de l’insurité de couche 2.

    • Pour la configuration globale DHCPv6 :

    • Pour la configuration de groupe DHCPv6 :

  3. (Facultatif) Configurez le nombre de tentatives de nouvelle tentative et le timer d’intervalle.

    • Pour la configuration globale DHCPv6 :

    • Pour la configuration de groupe DHCPv6 :

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.

Note:

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 :

  1. Spécifiez que vous souhaitez configurer la méthode de détection de l’liveness.
    • Pour la configuration globale DHCPv4 :

    • Pour la configuration de groupe DHCPv4 :

    • Pour la configuration d’un groupe double pile DHCPv4 :

  2. Spécifiez la méthode de détection de l’insurité de couche 2.
    • Pour la configuration globale DHCPv4 :

    • Pour la configuration de groupe DHCPv4 :

    • Pour la configuration d’un groupe double pile DHCPv4 :

  3. (Facultatif) Configurez le nombre de tentatives de nouvelle tentative et le timer d’intervalle.
    • Pour la configuration globale DHCPv4 :

    • Pour la configuration de groupe DHCPv4 :

    • Pour la configuration d’un groupe double pile DHCPv4 :

Pour configurer la fonctionnalité d’envoi pour la détection de l’ité du relais DHCPv6 :

  1. Spécifiez que vous souhaitez configurer la méthode de détection de l’liveness.

    • Pour la configuration globale DHCPv6 :

    • Pour la configuration de groupe DHCPv6 :

  2. Spécifiez la méthode de détection de l’insurité de couche 2.

    • Pour la configuration globale DHCPv6 :

    • Pour la configuration de groupe DHCPv6 :

  3. (Facultatif) Configurez le nombre de tentatives de nouvelle tentative et le timer d’intervalle.

    • Pour la configuration globale DHCPv6 :

    • Pour la configuration de groupe DHCPv6 :

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.

Activez la détection de l’liveness de couche 2 dans le monde entier par famille d’adresses.
  • Pour DHCPv4 :

  • Pour DHCPv6 :

Tableau de l’historique des versions
Libération
Description
17.4R1
À 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.
17.4R1
À 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.
17.4R1
À 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.
17.4R1
À 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.