Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Pools d’attribution d’adresses pour la gestion des abonnés

Présentation des pools d’attribution d’adresses

Le pool d’attribution d’adresses vous permet de créer des pools d’adresses IPv4 et IPv6 centralisés, indépendamment des applications clientes qui les utilisent. Le processus authd gère les pools et l’allocation des adresses, que les adresses proviennent de pools locaux ou d’un serveur RADIUS.

Par exemple, plusieurs applications clientes, telles que DHCP, peuvent utiliser le même pool d’attribution d’adresses pour fournir des adresses à leurs clients particuliers. Les applications clientes peuvent acquérir des adresses pour des clients authentifiés ou non. Le pool sélectionné pour un abonné, en fonction de la correspondance du serveur ou du réseau RADIUS ou d’une autre règle, est appelé pool de correspondance pour l’abonné.

Types d’attribution d’adresses

Les pools d’attribution d’adresses prennent en charge l’attribution d’adresses dynamique et statique. Dans l’attribution dynamique d’adresses, une adresse du pool d’attribution d’adresses est automatiquement attribuée à un client. Dans l’attribution d’adresses statiques, qui est prise en charge pour les pools IPv4 uniquement, vous réservez une adresse qui est ensuite toujours utilisée par un client particulier. Les adresses réservées à l’affectation statique sont supprimées du pool d’adresses dynamiques et ne peuvent pas être attribuées à d’autres clients.

Plages d’adresses nommées dans le pool d’attribution d’adresses

Vous pouvez configurer des plages d’adresses nommées dans un pool d’attribution d’adresses. Une plage nommée est un sous-ensemble de la plage d’adresses globale. Une application cliente peut utiliser des plages nommées pour gérer l’attribution d’adresses en fonction de critères spécifiques au client. Par exemple, pour les pools d’attribution d’adresses IPv4, vous pouvez créer une plage nommée basée sur une valeur DHCP 82 spécifique. Ensuite, lorsqu’une demande de client DHCP correspond à la valeur de l’option 82 spécifiée, une adresse de la plage spécifiée est affectée au client.

Attribution d’adresses à partir de pools d’adresses liés

Vous pouvez lier des pools d’attribution d’adresses pour fournir des pools de sauvegarde pour l’attribution d’adresses. Lorsqu’aucune adresse n’est disponible dans le pool d’adresses principal ou dans le pool d’adresses correspondant, l’appareil se rend automatiquement dans le pool d’adresses lié (secondaire) pour rechercher une adresse disponible à allouer.

Bien que le premier pool d’une chaîne de pools liés soit généralement considéré comme le pool principal, un pool correspondant n’est pas nécessairement le premier pool de la chaîne.

Prenons un exemple sur le fonctionnement du mécanisme de recherche. Considérons une chaîne de trois pools (A, B et C). Le pool A est le pool principal, le pool B est le pool correspondant pour certains abonnés en fonction des informations renvoyées par le serveur RADIUS. La recherche d’une adresse disponible pour ces abonnés utilise l’ordre suivant :

  • Par défaut, le pool correspondant (pool B) est recherché en premier.

  • La recherche se déplace vers le premier pool (pool A) de la chaîne si l’adresse est introuvable.

  • La recherche se poursuit à travers la chaîne (pool C) jusqu’à ce qu’une adresse disponible soit trouvée et attribuée, ou jusqu’à ce que la recherche détermine qu’aucune adresse n’est libre.

  • Dans chaque pool, toutes les plages d’adresses sont entièrement recherchées pour une adresse.

Vous pouvez configurer l’instruction linked-pool-aggregation pour lancer la recherche dans un bloc d’adresses dans chaque plage du pool correspondant, puis successivement dans les pools liés. La recherche revient ensuite au premier pool de la chaîne et recherche toutes les adresses de toutes les plages de chaque pool dans le dernier pool de la chaîne.

État de maintien du pool d’adresses

Vous pouvez configurer un pool d’attribution d’adresses à l’état d’attente. Lorsque le pool d’adresses est à l’état de hold-down, il n’est plus disponible pour allouer des adresses IP aux abonnés. Cette configuration transforme automatiquement le pool actif en un état inactif lorsque les adresses précédemment allouées sont renvoyées au pool. Lorsque le pool est inactif, vous pouvez effectuer sa maintenance en toute sécurité sans affecter les abonnés actifs.

pool d’attribution d’adresses pour les annonces de routeur de découverte de voisins

Vous pouvez allouer explicitement un pool d’attribution d’adresses pour la publication NDRA (Neighbor Discovery Router Advertisement).

Exclusion d’une adresse ou d’une plage d’adresses spécifiée

Par exemple, vous pouvez réserver certaines adresses ou plages à utiliser uniquement pour les abonnés statiques. Lorsque vous configurez une adresse ou une plage à exclure et que l’adresse ou une adresse comprise dans la plage a déjà été allouée, cet abonné est déconnecté, l’adresse est désallouée et l’adresse est marquée pour exclusion.

Exigences en matière de licence

Cette fonctionnalité nécessite une licence. Pour en savoir plus sur les licences d’accès abonné, consultez Vue d’ensemble des licences d’accès abonné. Veuillez vous référer au Guide des licences de Juniper pour obtenir des informations générales sur la gestion des licences. Veuillez vous référer aux fiches techniques des produits pour plus de détails, ou contacter votre équipe de compte Juniper ou votre partenaire Juniper.

Avantages des pools d’attribution d’adresses

  • La fonctionnalité de pool d’attribution d’adresses prend en charge à la fois la gestion des abonnés et la gestion DHCP.

  • Vous pouvez créer des pools centralisés d’adresses indépendamment des applications clientes.

  • Vous pouvez spécifier des blocs d’adresses, des plages nommées, de sorte qu’un pool d’adresses donné puisse être utilisé pour fournir différentes adresses pour différentes applications clientes ou pour des abonnés qui correspondent à différents ensembles de critères.

  • Vous pouvez lier des pools entre eux pour vous assurer que les pools sont recherchés pour les adresses libres d’une manière spécifique, de manière contiguë ou non contiguë.

  • Vous pouvez faire passer un pool d’adresses actif à inactif en spécifiant qu’aucune autre adresse n’est allouée à partir du pool.

Attribution d’adresses à partir de pools d’adresses liés

Vous pouvez lier des pools d’attribution d’adresses en une chaîne pour fournir des pools de sauvegarde pour l’attribution d’adresses. Le pool sélectionné pour un abonné, en fonction de la correspondance du serveur ou du réseau RADIUS ou d’une autre règle, est appelé le pool correspondant ou correspondant pour l’abonné. Le pool correspondant n’est peut-être pas le premier pool (principal) de la chaîne. Lorsqu’aucune adresse n’est disponible pour l’allocation à partir du pool d’adresses correspondant ou primaire, le routeur ou le commutateur passe automatiquement à un autre pool d’adresses pour rechercher une adresse disponible à allouer. Lorsque la recherche ne révèle aucune adresse disponible nulle part, la recherche s’arrête et aucune adresse n’est attribuée à l’abonné.

Le comportement de recherche détermine non seulement la progression de la recherche le long d’une chaîne de pools liés, mais aussi les plages d’adresses recherchées dans chaque pool. En fonction du point de départ de la recherche, de votre configuration et de la libération des adresses précédemment allouées, la recherche peut se poursuivre dans le prochain pool d’adresses liées de la chaîne ou revenir au premier pool de la chaîne.

La recherche d’une adresse disponible commence dans le pool qui correspond à l’abonné. Dans de nombreux cas, le pool correspondant est également le premier pool de la chaîne. Pour certains abonnés, le pool de correspondance est plus bas dans la chaîne. Par exemple, vous pouvez configurer le serveur RADIUS pour spécifier le deuxième pool d’une chaîne plutôt que le premier en fonction de certains critères auxquels il correspond lors de l’authentification. Pour un autre exemple, vous pouvez spécifier différentes plages d’adresses pour différents groupes d’abonnés ; Le fait qu’un pool particulier corresponde à un abonné dépend alors des pools configurés pour les différentes plages d’adresses.

Les termes suivants sont utilisés pour expliquer les détails du comportement de recherche :

  • lowAddress : adresse la plus basse d’une plage donnée dans un pool d’adresses.

  • highAddress : adresse la plus élevée d’une plage donnée dans un pool d’adresses.

  • nextAddress : adresse suivante après la dernière adresse allouée dans une plage donnée au sein d’un pool d’adresses. Il s’agit de l’adresse qui devrait être attribuée ensuite. Cette adresse, ainsi que la dernière plage utilisée, est enregistrée comme point de départ pour les recherches.

Par exemple, supposons que le pool A ait une plage unique qui inclut les adresses suivantes : 192.0.2.1, 192.0.2.2, 192.0.2.3, 192.0.2.4. Dans ce cas, 192.0.2.1 est la lowAddress et 190.0.2.4 est la highAddress. Si 192.0.2.2 était la dernière adresse allouée à partir de ce pool, nextAddress est 192.0.2.3.

À partir de la version 18.1R1 de Junos OS, vous pouvez configurer les pools liés pour qu’ils fassent l’objet d’une recherche de l’une des deux manières suivantes :

  • Allocation d’adresses contiguës : il s’agit du comportement par défaut. Toutes les adresses de chaque plage d’un pool sont recherchées. La recherche commence dans le pool correspondant, puis se déplace vers le premier pool de la chaîne et, si nécessaire, se poursuit successivement à travers chaque pool lié jusqu’au dernier pool de la chaîne. Dans chaque pool, toutes les adresses de toutes les plages sont recherchées pour une adresse libre. Cette méthode permet d’attribuer des adresses de manière contiguë ; Chaque pool doit être plein avant qu’un autre pool ne soit fouillé.

  • Allocation d’adresses non contiguës (agrégées) : comportement lors de la configuration de l’instruction linked-pool-aggregation . Initialement, seules certaines adresses (de nextAddress à highAddress) sont recherchées dans chaque plage du pool correspondant. La même recherche est effectuée dans le pool lié et, si nécessaire, se poursuit successivement à travers chaque pool lié jusqu’au dernier pool de la chaîne.

    La recherche redémarre ensuite au niveau du premier pool de la chaîne (pas nécessairement le pool correspondant). Cette fois, toutes les adresses de toutes les plages sont recherchées, dans tous les pools jusqu’à la fin de la chaîne.

C’est la fonctionnalité de base, mais les détails des deux recherches sont assez complexes. La figure 1 montre le comportement de recherche par défaut.

Figure 1 : attribution d’adresses par défaut à partir de pools Flowchart showing address allocation from a pool. It matches a pool, searches ranges for a free address, allocates it if found, or continues searching linked pools if not. d’adresses liées

Par exemple, supposons que les conditions suivantes existent :

  • Pools d’adresses liés A, B, C et D. Le pool C est correspondant.

  • Chaque pool a trois plages d’adresses : r1, r2, r3. La dernière plage utilisée était r2 dans chaque groupe.

Si aucune adresse libre n’est trouvée, la recherche se poursuit comme suit : C > A > B > C > D, puis s’arrête.

  1. Le pool C est recherché, nextAddress à highAddress dans la plage r2.

  2. Le pool C est recherché, lowAddress à nextAddress dans la plage r2.

  3. Le pool C est recherché, nextAddress via highAddress dans la plage r3.

  4. Le pool C est recherché, lowAddress à nextAddress dans la plage r3.

  5. Le pool C est recherché, nextAddress à highAddress dans la plage r1.

  6. Le pool C est recherché, lowAddress à nextAddress dans la plage r1.

    Toutes les plages et adresses du pool C ont été recherchées, de sorte que la recherche se déplace vers le premier pool de la chaîne, A.

  7. Le pool A est recherché, nextAddress via highAddress dans la plage r2.

  8. Le pool A est recherché, lowAddress à nextAddress dans la plage r2.

  9. Le pool A est recherché, nextAddress à highAddress dans la plage r3.

  10. Le pool A est recherché, lowAddress à nextAddress dans la plage r3.

  11. Le pool A est recherché, nextAddress à highAddress dans la plage r1.

  12. Le pool A est recherché, lowAddress à nextAddress dans la plage r1.

    Toutes les plages et adresses du pool A ont été recherchées, de sorte que la recherche se déplace vers le pool lié suivant de la chaîne, B.

Ce processus se poursuit jusqu’à ce que toutes les adresses de toutes les plages de tous les pools aient été recherchées. L’ordre de recherche des pools est C > A > B > C > D, puis s’arrête. Selon l’endroit où une adresse est trouvée ou non, le pool correspondant peut être recherché deux fois. Cela est vrai sauf si le pool correspondant est le premier pool de la chaîne. Par exemple, si le pool A est le pool correspondant dans cet ensemble de conditions, la recherche complète (en supposant qu’aucune adresse n’est trouvée) sera A > B > C > D.

La figure 2 montre le comportement de recherche lorsque vous incluez l’instructionlinked-pool-aggregation.

Figure 2 : Attribution agrégée d’adresses à partir de pools Flowchart showing address allocation process from a pool; match pool, search ranges for free address, allocate if found, check all ranges searched and if last pool in chain, move to linked pools or stop search. d’adresses liées

Par exemple, considérez que les mêmes conditions existent que pour l’exemple par défaut :

  • Pools d’adresses liés A, B, C et D. Le pool C est correspondant.

  • Chaque pool a trois plages d’adresses : r1, r2, r3. La dernière plage utilisée était r2 dans chaque groupe.

Si aucune adresse libre n’est trouvée, la recherche se déroule comme suit : C > D > A > B > C > D, puis s’arrête.

  1. Le pool C est recherché, nextAddress à highAddress dans la plage r2.

  2. Le pool C est recherché, nextAddress via highAddress dans la plage r3.

  3. Le pool C est recherché, nextAddress à highAddress dans la plage r1.

    Toutes les plages du pool C ont été recherchées de nextAddress à highAddress, de sorte que la recherche se déplace vers le pool lié suivant de la chaîne, D.

  4. Le pool D est recherché, nextAddress via highAddress dans la plage r2.

  5. Le pool D est recherché, nextAddress à highAddress dans la plage r3.

  6. Le pool D est recherché, nextAddress à highAddress dans la plage r1.

    Toutes les plages du pool D ont été recherchées de nextAddress à highAddress. Le pool D est le dernier pool de la chaîne, de sorte que la recherche se déplace vers le premier pool de la chaîne, A.

  7. Le pool A est recherché, lowAddress à highAddress dans la plage r2.

  8. Le pool A est recherché, lowAddress à highAddress dans la plage r3.

  9. Le pool A est recherché, lowAddress à highAddress dans la plage r1.

    Toutes les plages et adresses du pool A ont été recherchées, de sorte que la recherche se déplace vers le pool lié suivant de la chaîne, B.

  10. Le pool B est recherché, lowAddress à highAddress dans la plage r2.

  11. Le pool B est recherché, lowAddress à highAddress dans la plage r3.

  12. Le pool B est recherché, lowAddress à highAddress dans la plage r1.

    Toutes les plages et adresses du pool B ont fait l’objet d’une recherche, de sorte que la recherche se déplace vers le pool lié suivant de la chaîne, C.

Ce processus se poursuit jusqu’à ce que toutes les adresses de toutes les plages de tous les pools aient été recherchées. L’ordre de recherche des pools est C > D > A > B > C > D, puis s’arrête. Selon l’emplacement et la recherche d’une adresse, tous les pools peuvent faire l’objet d’une recherche deux fois, même lorsque le pool correspondant est le premier pool de la chaîne. Par exemple, si le pool A est le pool correspondant dans cet ensemble de conditions, la recherche complète (en supposant qu’aucune adresse n’est trouvée) sera A > B > C > D > A > B > C > D.

Présentation de la configuration du pool d’attribution d’adresses

La fonctionnalité de pool d’attribution d’adresses prend en charge la fonctionnalité de gestion des abonnés en vous permettant de créer des pools d’adresses qui peuvent être partagés par différentes applications clientes. Un pool d’attribution d’adresses peut prendre en charge les adresses IPv4 ou IPv6. Vous ne pouvez pas utiliser le même pool pour les deux types d’adresse.

Remarque :

Les pools d’attribution d’adresses sont complètement distincts des pools d’adresses LNS L2TP basés sur PIC, que vous créez avec l’instruction address-pool au niveau de la [edit access] hiérarchie, et des pools NAT, que vous créez avec l’instruction pool au niveau de la [edit services nat] hiérarchie.

Pour configurer un pool d’attribution d’adresses :

  1. Configurez le nom du pool d’attribution d’adresses et spécifiez les adresses du pool.

    Voir Configuration d’un nom et d’adresses d’un pool d’attribution d’adresses.

  2. (Facultatif) Configurez des plages nommées (sous-ensembles) d’adresses.

    Voir Configuration d’une plage d’adresses nommée pour l’attribution dynamique d’adresses.

  3. (Facultatif) Exclure l’allocation d’adresses ou d’une plage d’adresses dans des pools d’adresses.

    Voir Empêcher l’attribution d’adresses à partir d’un pool d’adresses.

  4. (Facultatif) Configurez la liaison pool-attribution d’adresses et spécifiez le pool secondaire à utiliser lorsque le pool principal est entièrement alloué.

    Voir Configuration de la liaison de pool d’attribution d’adresses.

  5. (Facultatif) Configurez la conservation du pool d’attribution d’adresses, afin qu’aucune adresse supplémentaire ne soit allouée à partir du pool identifié. Ceci est également connu sous le nom de drain passif.

    Voir Configuration du maintien du pool d’attribution d’adresses.

  6. (Facultatif) Configurez le drain rapide du pool d’attribution d’adresses, également appelé drain actif, pour empêcher l’attribution d’adresses supplémentaires à partir du pool et empêcher les clients existants de renouveler les baux pour les adresses du pool.

    Reportez-vous à la section Configuration de la vidange rapide du pool d’adresses DHCP locales.

  7. (Facultatif) Créez des liaisons d’adresses statiques (IPv4 uniquement).

    Voir Configuration de l’attribution d’adresses statiques.

  8. (Facultatif) Activez la protection contre les doublons d’adresses pour éviter que les adresses ne soient utilisées plus d’une fois.

    Voir Configuration de la protection contre les adresses IPv4 en double pour AAA.

  9. (Facultatif) Configurez les attributs des clients DHCP.

    Voir Configuration des attributs DHCP spécifiques au client appliqués lorsque les clients obtiennent une adresse.

Voir aussi

Configuration d’un nom et d’adresses d’un pool d’attribution d’adresses

Pour configurer un pool d’attribution d’adresses, vous devez spécifier le nom du pool et configurer les adresses du pool.

Pour configurer un pool d’attribution d’adresses IPv4 :

  1. Configurez le nom du pool et spécifiez la famille IPv4.
  2. Configurez l’adresse réseau et la longueur du préfixe des adresses dans le pool.

Pour configurer un pool d’attribution d’adresses IPv6 :

  1. Configurez le nom du pool et spécifiez la famille IPv6.

  2. Configurez le préfixe de réseau IPv6 pour le pool d’adresses. La spécification du préfixe est requise lorsque vous configurez un pool d’attribution d’adresses IPv6.

Configuration d’une plage d’adresses nommées pour l’attribution dynamique d’adresses

Vous pouvez éventuellement configurer plusieurs plages nommées, ou sous-ensembles, d’adresses dans un pool d’attribution d’adresses. Lors de l’attribution dynamique d’adresses, un client peut se voir attribuer une adresse d’une plage nommée spécifique. Pour créer une plage nommée, vous spécifiez un nom pour la plage et définissez la plage d’adresses.

Pour créer une plage nommée dans un pool d’attribution d’adresses IPv4 :

  1. Spécifiez le nom du pool d’attribution d’adresses et la famille IPv4.
  2. Configurez le nom de la plage et les limites inférieure et supérieure des adresses de la plage.

Pour créer une plage nommée dans un pool d’attribution d’adresses IPv6 :

  1. Spécifiez le nom du pool d’attribution d’adresses et de la famille IPv6.

  2. Configurez le nom de la plage et définissez-la. Vous pouvez définir la plage en fonction des limites inférieure et supérieure des préfixes de la plage, ou en fonction de la longueur des préfixes de la plage.

Empêcher l’attribution d’adresses à partir d’un pool d’adresses

Vous pouvez exclure des adresses ou des plages d’adresses spécifiées pour éviter qu’elles ne soient allouées à partir d’un pool d’adresses. Par exemple, vous pouvez réserver certaines adresses ou plages à utiliser uniquement pour les abonnés statiques. Lorsque vous configurez une adresse ou une plage d’adresses à exclure et que l’adresse ou une adresse dans la plage a déjà été allouée, l’abonné qui a reçu cette adresse est déconnecté, l’adresse est désallouée et l’adresse est marquée pour exclusion.

Pour exclure l’allocation d’une adresse ou d’une plage d’adresses d’un pool d’adresses :

  • Spécifiez une adresse individuelle.

  • Spécifiez et nommez une plage d’adresses consécutives.

Par exemple, la configuration partielle suivante pour un pool d’adresses IPv4 définit une plage, r1, d’adresses à allouer, de 192.168.0.10 à 192.168.128.250. Il exclut une seule adresse, 192.168.110.10. Il définit en outre deux plages, exclude1 et exclude2, qui spécifient deux ensembles d’adresses consécutives qui ne peuvent pas être allouées à partir du pool.

De même, la configuration de pool v6-pool définit une plage d’adresses à allouer et une plage d’adresses exclues de l’allocation.

Pour afficher des informations sur les adresses exclues, vous pouvez utiliser l’une des commandes suivantes :

Configuration des pièges de seuil d’utilisation des pools d’attribution d’adresses

Vous pouvez recevoir un avertissement préalable indiquant qu’un pool d’adresses ou un ensemble lié de pools d’adresses manque d’adresses disponibles en définissant des pièges de seuil d’utilisation (utilisation). Les termes « utilisation » et « utilisation » sont utilisés de manière interchangeable pour désigner le pourcentage d’adresses actuellement attribuées dans un pool d’adresses. Un pool d’adresses est associé aux seuils SNMP suivants, qui permettent au serveur d’adresses local de signaler les interruptions SNMP lorsque certaines conditions existent :

  • seuil d’utilisation élevée : lorsque le pourcentage d’adresses attribuées à partir d’un pool d’adresses dépasse cette valeur, une interruption SNMP d’utilisation élevée est générée. Le système envoie des messages d’avertissement tant que ce seuil est dépassé.

  • Seuil d’utilisation réduite : lorsque le pourcentage d’adresses attribuées à partir d’un pool d’adresses tombe en dessous de cette valeur, une interruption d’utilisation réduite est générée. Le système cesse d’envoyer les messages d’avertissement. En règle générale, vous définissez le seuil d’utilisation réduite sur une valeur inférieure au seuil d’utilisation élevée ; vous ne pouvez pas le définir plus haut.

Les seuils n’ont pas de valeurs par défaut. Si vous ne configurez pas ces seuils, le système n’envoie pas de notification d’épuisement imminent lorsque le pourcentage d’adresses attribuées approche les 100 %. Le système envoie une interruption hors adresse uniquement lorsque toutes les adresses du pool d’adresses ont été affectées.

Remarque :

À partir de la version 19.2R1 de Junos OS, l’interruption hors adresse n’est envoyée que si le seuil d’utilisation élevée et le seuil d’utilisation réduite sont configurés. Lorsque l’interruption de désadresse est envoyée, un message syslog désadresse est également envoyé.
Remarque :

Vous pouvez configurer des seuils pour tous les pools d’adresses au niveau de la [edit access address-assignment] hiérarchie ou uniquement pour les pools d’adresses d’une instance de routage spécifiée au niveau de la [edit routing-instance routing-instance-name] hiérarchie. Les configurations ci-dessous n’affichent que la [edit access] configuration.

Pour définir les interruptions de seuil :

  • Spécifiez le seuil d’utilisation élevé pour les pools d’adresses IPv4 ou IPv6.

  • Spécifiez le seuil d’utilisation réduite pour les pools d’adresses IPv4 ou IPv6.

Dans l’exemple suivant, le seuil élevé est défini sur 95 % d’utilisation et le seuil réduit est défini sur 90 % d’utilisation pour les pools d’adresses IPv4. Lorsque le nombre d’adresses attribuées dépasse 95 % du pool d’adresses, une interruption d’utilisation élevée est générée. Si toutes les adresses sont affectées à partir du pool, une interruption hors adresse est générée et un message syslog hors adresse est envoyé. Lorsque le nombre d’adresses attribuées passe en dessous de 90 % du pool d’adresses, l’interruption d’utilisation réduite est générée.

Configuration de la liaison de pools d’attribution d’adresses

La liaison de pool d’attribution d’adresses vous permet de spécifier un pool d’adresses secondaires que le routeur doit utiliser lorsque le pool d’attribution d’adresses correspondant ou principal est entièrement alloué. Vous pouvez créer une chaîne de plusieurs pools liés. Par exemple, vous pouvez lier le groupe A au groupe B et lier le groupe B au groupe C. Vous pouvez lier n’importe quel nombre de pools en série dans une chaîne, mais vous ne pouvez pas créer plusieurs liens vers ou depuis le même pool. Par exemple, vous ne pouvez pas créer de liens du pool A vers le pool B et le pool C. De même, le pool C ne peut pas être lié à la fois du pool A et du pool B. En outre, tous les pools d’adresses d’une chaîne doivent appartenir au même type de famille, IPv4 ou IPv6.

Lorsque le pool d’adresses correspondant aux abonnés n’a pas d’adresses disponibles, le routeur bascule automatiquement vers le pool lié et alloue des adresses à partir de ce pool. Le routeur utilise un pool lié uniquement lorsque le pool d’attribution d’adresses correspondante est entièrement alloué.

À partir de la version 18.1 de Junos OS, le comportement change quant à la recherche et à l’allocation d’une adresse libre dans une chaîne de pools d’adresses. Vous pouvez configurer les pools liés pour qu’ils fassent l’objet d’une recherche de deux manières :

  • Allocation d’adresses contiguës : comportement par défaut. Toutes les adresses de chaque plage d’un pool sont recherchées. La recherche commence dans le pool correspondant, puis se déplace vers le premier pool de la chaîne et, si nécessaire, se poursuit successivement à travers chaque pool lié jusqu’au dernier pool de la chaîne. Dans chaque pool, toutes les adresses de toutes les plages sont recherchées pour une adresse libre. Cette méthode permet d’attribuer des adresses de manière contiguë ; Chaque pool doit être plein avant qu’un autre pool ne soit fouillé.

  • Allocation d’adresses non contiguës (agrégées) : comportement lorsque linked-pool-aggregation est configuré. Initialement, seules certaines adresses (de nextAddress à highAddress) sont recherchées dans chaque plage du pool correspondant. La même recherche est effectuée dans le pool lié, si nécessaire, et se poursuit à travers chaque pool lié successif jusqu’au dernier pool de la chaîne.

    La recherche redémarre ensuite au niveau du premier pool de la chaîne (pas nécessairement le pool correspondant). Cette fois, toutes les adresses de toutes les plages sont recherchées, dans tous les pools jusqu’à la fin de la chaîne.

Il peut être souhaitable d’inclure cette linked-pool-aggregation instruction si vous configurez votre serveur RADIUS pour qu’il utilise uniquement l’adresse IP pour identifier les abonnés. En règle générale, les abonnés sont identifiés par le serveur RADIUS à l’aide de l’ID de session de l’abonné et d’autres critères. Si vous utilisez uniquement l’adresse IP, vous pouvez rencontrer le problème suivant avec le comportement par défaut lorsque l’instruction n’est linked-pool-aggregation pas configurée. Un abonné peut se déconnecter et cette adresse peut être attribuée à l’abonné suivant. Le message Acct-Start pour le deuxième abonné peut être envoyé avant l’envoi du message Acct-Stop pour l’abonné déconnecté. Lorsque l’Acct-Stop est reçu, le nouvel abonné, identifié uniquement par l’adresse IP, peut être déconnecté.

Vous pouvez éviter cette situation en incluant l’instruction linked-pool-aggregation ou en configurant votre serveur RADIUS pour qu’il utilise l’ID de session de l’abonné (au lieu de l’adresse IP) pour l’identification.

Avant de commencer, configurez vos pools d’adresses. Voir Vue d’ensemble de la configuration du pool d’attribution d’adresses.

Pour lier un pool d’attribution d’adresses à un pool secondaire :

  1. Spécifiez les noms des pools à lier.
  2. (Facultatif) Configurez la recherche pour permettre l’allocation d’adresses non contiguës.

Par exemple, les liens de configuration suivants Pool_A vers Pool_B, puis vers Pool_B Pool_C.

Configuration de la rétention du pool d’attribution d’adresses

La fonctionnalité de maintien du pool d’attribution d’adresses (également appelée drain passif) vous permet de faire passer en douceur un pool d’adresses actif à un état inactif. Lorsque le pool est à l’état inactif, vous pouvez effectuer sa maintenance en toute sécurité sans affecter les abonnés actuels (par exemple, ajout, modification ou suppression d’adresses).

Lorsqu’un pool d’attribution d’adresses est à l’état d’attente, aucune adresse supplémentaire n’est allouée à partir de ce pool. Toutefois, l’état d’attente n’affecte pas les abonnés existants qui utilisent des adresses précédemment attribuées à partir du pool. Lorsque les abonnés existants se déconnectent, leurs adresses IP sont marquées comme libres dans le pool, mais elles ne sont pas réallouées en raison de l’état de blocage du pool. Finalement, lorsque tous les abonnés se sont déconnectés et que leurs adresses sont renvoyées dans le pool, le pool devient inactif.

Pour placer un pool d’attribution d’adresses actif à l’état d’attente :

  1. Spécifiez le nom du pool d’attribution d’adresses.
  2. Spécifiez que le pool est à l’état d’attente afin qu’aucune adresse supplémentaire ne puisse être allouée à partir du pool.

Configuration de la vidange rapide du pool d’adresses locales DHCP

Vous pouvez forcer le serveur local DHCP à arrêter l’allocation d’adresses à partir d’un pool d’adresses local spécifique en configurant le pool en mode de vidange active. Ce mode permet au serveur de résilier en douceur les abonnés qui utilisent déjà les adresses attribuées à partir de ce pool et de les faire passer à un autre pool. Lorsqu’un abonné DHCP tente de renouveler (au moment du renouvellement T1) le bail d’une adresse IP d’un pool maintenant configuré pour le mode drain actif, le serveur local DHCP répond avec un NAK à la demande de renouvellement de l’abonné. Cette réponse oblige l’abonné à renégocier un bail. Le serveur alloue ensuite une nouvelle adresse IP à partir d’un autre pool d’adresses qui n’est pas configuré pour le drain actif.

Le mode de drainage actif permet de drainer rapidement les abonnés d’un pool d’adresses. Par conséquent, plus la durée de bail configurée pour les abonnés est longue, plus le mode de vidange active peut être utile. Si vous ne configurez pas le mode de drainage actif pour un pool, pour arrêter l’allocation de ses adresses, vous devez configurer le mode de drainage passif ou supprimer le pool.

  • Le mode de drainage passif place le pool d’adresses dans un état de hold-down. Aucune autre adresse n’est allouée à partir du pool, mais les abonnés qui utilisent actuellement une adresse attribuée à partir du pool ne sont pas affectés. Les abonnés existants sont autorisés à expirer. Lorsque l’abonné se déconnecte (ou est déconnecté par un opérateur), l’adresse est libérée, mais ne peut pas être réattribuée. Finalement, tous les abonnés ont libéré leurs adresses et le pool n’est plus actif. Étant donné que les baux des abonnés actifs sont renouvelés sur demande, le mode de drainage passif peut prendre beaucoup plus de temps que le mode de drainage actif pour récupérer toutes les adresses du pool.

  • La suppression d’un pool perturbe le trafic pour chaque abonné actuel qui utilise une adresse de pool aussi longtemps que nécessaire pour que le bail expire et que l’abonné renégocie et obtienne un nouveau bail. Le serveur supprime tous les abonnés avec une adresse du pool supprimé. Les abonnés tentent de prolonger le bail mais échouent car le bail a été supprimé sur le serveur. Lorsque les souscripteurs tentent par la suite de renégocier un nouveau bail, il peut être accordé avec une adresse d’un autre pool ou de RADIUS.

Vous pouvez supprimer la configuration de drain actif avant que le pool d’adresses ne soit vidé. Dans ce cas, des prolongations de bail peuvent être accordées aux abonnés ayant encore des adresses de ce pool. Cette récupération est le meilleur effort, car certains abonnés sont en train d’être déconnectés par le serveur lorsque la configuration est supprimée. Ces souscripteurs ne peuvent pas être réintégrés au pool et doivent renégocier un bail. Ces abonnés peuvent ensuite se voir attribuer une adresse à partir de ce pool (car il est à nouveau actif) ou d’un autre pool.

Si le client DHCP ne reçoit pas de notification indiquant que le pool d’adresses est en cours de drainage, il peut continuer à accorder des prolongations de bail aux abonnés utilisant ce pool. Cette condition est indiquée lorsque l’adresse reste liée au client au-delà de l’heure T1 (jusqu’à l’heure T2) où elle aurait dû être récupérée par le pool. Dans ce cas, supprimez la configuration active-drain, puis reconfigurez-la pour le pool afin de vous assurer que le pool est vidangé en temps opportun.

En cas de redémarrage d’authd ou de jdhcpd, ou de basculement harmonieux du moteur de routage, les adresses de pool peuvent encore être utilisées par certains abonnés pour lesquels aucune NAK n’a été envoyée pour initier la déconnexion. Lorsque le redémarrage ou GRES est terminé, authd envoie une notification jdhcpd avec une liste d’abonnés ayant encore des adresses du pool configuré pour le drain actif. La vidange de la piscine peut alors continuer.

Remarque :

À partir de la version 18.4R1 de Junos OS, la méthode d’attribution des adresses détermine le comportement ultérieur lorsqu’authd informe le processus DHCP qu’un pool d’adresses est supprimé ou en cours de vidange.

  • Lorsque des adresses sont allouées à la demande, la famille avec l’adresse dans ce pool est déconnectée immédiatement lorsque le pool est supprimé, ou déconnectée automatiquement par le processus de drainage lorsqu’un message de renouvellement ou de liaison DHCP est reçu.

  • Lorsque les adresses sont préallouées, les adresses des deux familles sont supprimées immédiatement lorsque le pool est supprimé, ou supprimées gracieusement par le processus de drainage lorsqu’un message de renouvellement ou de reliaison DHCP est reçu.

Pour configurer le serveur local DHCP afin d’arrêter l’attribution d’adresses à partir d’un pool d’adresses :

  1. Accédez à la configuration du pool d’adresses.
  2. Spécifiez le mode de vidange active pour la piscine.

Vous pouvez utiliser la commande pour confirmer que le show network-access aaa statistics drain actif est configuré pour un pool.

Remarque :

La fonctionnalité de drain actif est prioritaire sur la conservation de l’adresse du préfixe. La préservation d’adresses peut garantir que le même préfixe délégué est attribué à l’abonné en fonction de l’identifiant de circuit d’accès (ACI). Lorsqu’un abonné avec un préfixe conservé se déconnecte, l’ACI et le préfixe sont stockés dans la table de préservation des adresses. Lorsque cet abonné tente de se reconnecter, l’adresse et l’ACI sont recherchés dans le tableau.

Le mode de vidange actif affecte ce comportement. Lorsque le préfixe fait actuellement partie d’un pool défini sur le mode de drainage actif, il est supprimé de la table et n’est pas affecté au abonné lorsque le abonné tente de se reconnecter.

Si le drain actif est annulé alors que le client est en train de se déconnecter, le préfixe et la chaîne ACI sont conservés dans la table. Dans ce cas, le préfixe peut être affecté à cette chaîne ACI lorsque l’abonné se reconnecte. Toutefois, si le drain actif est annulé après que le client s’est déjà déconnecté et que la table a été vidée de l’association prefix/ACI, l’abonné à une connexion ultérieure obtient un préfixe du pool qui est réactivé et le préfixe peut être différent.

Voir aussi

Configuration de l’attribution d’adresses statiques

Vous pouvez éventuellement créer une liaison d’adresse IPv4 statique en réservant une adresse spécifique à un client particulier. L’adresse est supprimée du pool d’attribution d’adresses afin qu’elle ne soit pas affectée à un autre client. Lorsque vous réservez une adresse, vous identifiez l’hôte client et créez une liaison entre l’adresse MAC du client et l’adresse IP attribuée. Les pools d’attribution d’adresses IPv6 ne prennent pas en charge la liaison d’adresses statiques.

Pour configurer une liaison statique pour une adresse IPv4 :

  1. Spécifiez le nom du pool d’attribution d’adresses IPv4 contenant l’adresse IP que vous souhaitez réserver au client.
  2. Spécifiez le nom du client pour la liaison statique, l’adresse MAC du client et l’adresse IP à réserver pour le client. Cette configuration spécifie que l’adresse IP 192.168.44.12 est toujours affectée au client dont l’adresse MAC est 00:00:5E :00:53:90.

Configuration de la protection contre les adresses IPv4 en double pour AAA

À partir de la version 14.1 de Junos OS, si vous utilisez AAA pour fournir des adresses IPv4, vous pouvez activer la protection contre les doublons d’adresses pour empêcher que les adresses ne soient utilisées plus d’une fois. Si cette option est activée, les attributs suivants reçus des serveurs externes sont vérifiés :

  • Framed-IP-Address

  • Framed-Pool

Le routeur effectue alors l’une des actions suivantes :

  • Si une adresse correspond à une adresse d’un pool d’adresses, l’adresse est extraite du pool, à condition qu’elle soit disponible.

  • Si l’adresse est déjà utilisée, elle est rejetée comme indisponible et l’abonné existant qui l’utilise reste intact.

Pour configurer la protection contre les doublons d’adresses :

  1. Entrez la access configuration.
  2. Activez la protection contre les doublons.

À partir de Junos OS version 18.4R1, vous pouvez éventuellement activer la réaffectation d’une adresse en cours d’utilisation lorsque la protection des adresses est configurée en incluant l’option reassign-on-match . Une fois configuré, le routeur déconnecte l’abonné existant et permet au nouvel abonné de renégocier. L’effet de cette configuration est que l’adresse utilisée est toujours réattribuée au nouvel abonné.

Un cas d’utilisation de cette capacité de remplacement se produit lorsqu’un abonné mobile est accidentellement exclu du nœud de prise en charge GPRS de la passerelle (GGSN), mais que le GGSN maintient la session L2TP de l’abonné pendant un certain temps. Lorsque le client tente de se reconnecter via un autre nœud, la session ne peut pas se connecter, car la session d’origine est toujours active. La réaffectation d’adresse permet à la nouvelle session de préempter la session existante, ce qui permet à l’abonné de se reconnecter.

Remarque :

L’abonné existant n’est déconnecté que lorsque l’adresse provient d’un pool d’adresses provenant de RADIUS. Lorsque l’adresse provient d’un pool d’adresses configuré localement, la session d’abonné existante reste intacte.
Bonne pratique :

N’utilisez pas cette reassign-on-match option lorsque RADIUS alloue des adresses contenues dans un pool d’adresses configuré localement, car le risque de collision d’adresses est plus élevé. Nous vous recommandons de ne pas chevaucher les adresses provenant de RADIUS avec des pools d’adresses locaux.

L’option reassign-on-match fonctionne de la manière suivante :

  1. Un abonné négocie l’accès avec une adresse IP donnée.

  2. Le routeur détermine si cette adresse est utilisée et d’où elle vient.

    • Lorsqu’un abonné est déjà connecté avec cette adresse, celle-ci ne fait pas partie d’un pool configuré localement et la protection des adresses est activée :

      • Le routeur envoie une NAK au nouvel abonné, rejetant la demande.

      • Le routeur envoie une demande de déconnexion à l’abonné existant. La demande de déconnexion inclut un ID d’arrêt pour signaler la cause de la déconnexion.

      • Le nouvel abonné (rejeté) peut renégocier et l’adresse IP lui est attribuée.

    • Lorsqu’un abonné est déjà connecté avec cette adresse et que l’adresse a été allouée à partir d’un pool d’adresses local :

      • Le routeur envoie une NAK au nouvel abonné, rejetant la demande.

      • Le routeur n’envoie pas de demande de déconnexion à l’abonné existant.

Lorsque vous ajoutez reassign-on-match à une configuration existante de protection des adresses en double, cela prend effet immédiatement pour les abonnés existants. De même, si vous supprimez reassign-on-match d’une configuration, elle prend effet immédiatement, de sorte qu’une demande d’accès ultérieure avec une adresse en cours d’utilisation n’entraîne pas la résiliation de l’abonné existant.

Pour activer la réaffectation d’adresses :

Voir aussi

Exemple : configuration d’un pool d’attribution d’adresses

Exigences

Créez le pool d’attribution d’adresses d’accès réseau. Pour développer automatiquement le pool lorsqu’il atteint 100 % d’utilisation, pour faire correspondre les nouvelles plages de pools à la taille de pool d’origine, utilisez un masque de réseau différent pour chaque pool.

Remarque : Il existe une restriction pour la plage d’adresses IP lorsque nous lions deux pools d’attribution d’adresses. Nous ne pouvons pas créer 2 pools d’adresses avec le même préfixe réseau. Nous pouvons créer des pools d’adresses avec différents préfixes réseau et les lier si nécessaire.

Vue d’ensemble

La configuration

Cet exemple montre une configuration de pool d’attribution d’adresses qui crée deux pools, un pour les clients DHCP IPv4 (isp_1) et un second pool (chi-fiber-ra) utilisé pour routeur publication.

Configuration rapide de la CLI

Cet exemple crée un pool d’attribution d’adresses IPv4 nommé isp-1, qui contient deux plages d’adresses nommées, southeast et northeast. Le pool d’attribution d’adresses contient également une liaison statique pour le client host host.example.net. La configuration du pool ISP_1 inclut également l’instruction indiquant que le pool est utilisé pour les dhcp-attributes clients DHCP. Si l’entrée de l’option 82 circuit-id correspond à la chaîne fiber, DHCP attribue au client une adresse de la northeast plage. Si l’option 82 circuit-id correspond à la chaîne cable_net, DHCP affecte une adresse de la southeast plage.

Le deuxième pool d’attribution d’adresses créé dans cet exemple est chi-fiber-ra. L’instruction neighbor-discovery-router-advertisement au début de la syntaxe spécifie que ce pool d’attribution d’adresses nommé est utilisé pour routeur publication. La syntaxe à la fin de l’exemple configure le pool d’attribution d’adresses nommé chi-fiber-ra.

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.

Libération
Descriptif
19.2R1
À partir de la version 19.2R1 de Junos OS, l’interruption hors adresse n’est envoyée que si le seuil d’utilisation élevée et le seuil d’utilisation réduite sont configurés.
18.4R1
À partir de Junos OS version 18.4R1, vous pouvez éventuellement activer la réaffectation d’une adresse en cours d’utilisation lorsque la protection des adresses est configurée en incluant l’option reassign-on-match .
18.1R1
À partir de la version 18.1R1 de Junos OS, le mécanisme de recherche d’une adresse disponible passe par une chaîne de pools liés. Ce comportement permet au DHCP de rechercher des adresses de manière contiguë.
18.1R1
À partir de la version 18.1R1 de Junos OS, vous pouvez exclure une adresse ou une plage d’adresses consécutives spécifiées pour empêcher leur attribution à partir d’un pool d’adresses.
18.1R1
À partir de la version 18.1 de Junos OS, le comportement change quant à la recherche et à l’allocation d’une adresse libre dans une chaîne de pools d’adresses.
14.1
À partir de la version 14.1 de Junos OS, si vous utilisez AAA pour fournir des adresses IPv4, vous pouvez activer la protection contre les doublons d’adresses pour empêcher que les adresses ne soient utilisées plus d’une fois.