Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Présentation des réseaux d’accès des abonnés PPP

Présentation des profils dynamiques pour les interfaces abonnés PPP

Gestion des abonnés La prise en charge PPP vous permet de créer et d’attacher des profils dynamiques pour les interfaces abonnés PPP. Lorsque l’abonné PPP se connecte, le routeur instancie le profil dynamique spécifié, puis applique les attributs définis dans le profil à l’interface.

Les profils dynamiques sont utilisés pour les interfaces PPP statiques et dynamiques. Pour les interfaces PPP statiques, vous utilisez l’interface de ligne de commande pour attacher des profils dynamiques, qui spécifient des options PPP. Pour les interfaces PPP dynamiques, le profil dynamique crée l’interface, y compris les options PPP.

Note:

Les interfaces créées dynamiquement ne sont prises en charge que sur les interfaces PPPoE.

Contrairement à la prise en charge PPP traditionnelle, la gestion des abonnés n’autorise pas l’authentification PPP bidirectionnelle : l’authentification est effectuée uniquement par le routeur, jamais par l’homologue distant. Le processus AAA du routeur gère l’authentification et l’attribution des adresses pour la gestion des abonnés. Lorsque vous configurez les options PPP pour un profil dynamique, vous pouvez configurer l’authentification CHAP (Challenge Handshake Authentication Protocol) ou PAP (Password Authentication Protocol), et vous pouvez contrôler l’ordre dans lequel le routeur négocie les protocoles CHAP et PAP. En outre, pour l’authentification CHAP, vous pouvez modifier la longueur par défaut du message de stimulation CHAP. Les autres options PPP, couramment utilisées ou obligatoires pour une configuration d’interface PPP traditionnelle, ne sont pas prises en charge dans les profils dynamiques de gestion des abonnés.

Comprendre comment le routeur traite les demandes PPP Fast Keepalive initiées par les abonnés

Sur les routeurs MX Series équipés de concentrateurs de ports modulaires/cartes d’interface modulaires (MPC/MIC), le moteur de transfert de paquets d’un MPC/MIC traite et répond aux paquets de demande d’écho LCP (Link Control Protocol) que l’abonné PPP (client) initie et envoie au routeur. Les paquets LCP Echo-Request et LCP Echo-Reply font partie du mécanisme keepalive PPP qui permet de déterminer si une liaison fonctionne correctement.

Auparavant, les paquets LCP Echo-Request et LCP Echo-Reply étaient gérés sur un routeur MX Series par le moteur de routage. Le mécanisme par lequel les paquets LCP Echo-Request sont traités par le moteur de transfert de paquets au lieu du moteur de routage est appelé PPP fast keepalives.

Avantages de PPP Fast Keepalives

  • Les keepalives rapides PPP réduisent le temps nécessaire aux échanges keepalive en permettant au moteur de transfert de paquets de recevoir des paquets LCP Echo-Request de l’abonné PPP et de répondre avec des paquets LCP Echo-Reply, sans avoir à envoyer les paquets LCP au moteur de routage pour traitement.

  • Les keepalives rapides PPP fournissent une bande passante accrue sur le routeur pour prendre en charge un plus grand nombre d’abonnés avec des performances améliorées en soulageant le moteur de routage d’avoir à traiter les paquets LCP Echo-Request et Echo-Reply.

  • Les trajets rapides PPP utilisent des nombres magiques négociés pour identifier les bouclages de trafic potentiels vers le routeur ou les problèmes de réseau. Vous pouvez également désactiver la validation si nécessaire pour éviter l’arrêt indésirable d’une session PPP, par exemple lorsque les homologues distants PPP utilisent des nombres arbitraires plutôt que le nombre négocié.

Comment fonctionne le traitement PPP Fast Keepalive

Vous n’avez pas besoin d’une configuration spéciale sur un routeur MX Series avec MPC/MICs pour activer le traitement des demandes PPP fast keepalive sur le moteur de transfert de paquets. La fonctionnalité est activée par défaut et ne peut pas être désactivée.

La séquence suivante décrit comment un routeur MX Series traite les paquets LCP Echo-Request et LCP Echo-Reply sur le moteur de transfert de paquets sur le MPC/MIC :

  1. Le moteur de routage avertit le moteur de transfert de paquets lorsque la transmission de demandes keepalive est activée sur une interface logique PPP. La notification inclut les nombres magiques du serveur et du client distant.

  2. Le moteur de transfert de paquets reçoit le paquet LCP Echo-Request initié par l’abonné PPP (client).

  3. Le moteur de transfert de paquets valide le nombre magique homologue dans le paquet LCP Echo-Request et transmet le paquet d’écho-réponse LCP correspondant contenant le nombre magique négocié par le routeur.

  4. Si le moteur de transfert de paquets détecte une condition de boucle dans la liaison, il envoie le paquet de demande d’écho LCP au moteur de routage pour un traitement ultérieur.

    Le moteur de routage continue de traiter les paquets LCP Echo-Request jusqu’à ce que la condition de boucle soit effacée.

La transmission des requêtes keepalive à partir du moteur de transfert de paquets sur le routeur n’est actuellement pas activée.

Affichage des statistiques pour PPP Fast Keepalive

Lorsqu’un routeur MX Series avec MPC/MICs utilise PPP fast keepalive pour une liaison PPP, le champ de sortie de la show interfaces pp0.logical statistics commande opérationnelle n’inclut pas de statistiques sur le nombre de paquets keepalive reçus ou envoyés, ni sur le temps écoulé depuis que le routeur a reçu ou envoyé le Keepalive statistics dernier paquet keepalive.

Effet de la modification de la configuration de la classe de transfert

Pour modifier l’affectation de file d’attente par défaut (classe de transfert) pour le trafic sortant généré par le moteur de routage, vous pouvez inclure l’instruction forwarding-class class-name au niveau de la [edit class-of-service host-outbound-traffic] hiérarchie.

Pour les paquets d’écho-demande LCP PPP rapide (en ligne) et LCP Echo-Reply transmis entre un routeur MX Series avec MPC/MIC et un client PPP, la modification de la configuration de la classe de transfert prend effet immédiatement pour les nouvelles sessions d’abonnés PPP-over-Ethernet (PPPoE), PPP-over-ATM (PPPoA) et LNS créées après le changement de configuration, ainsi que pour les PPPoE, PPPoA existants, et les sessions d’abonnés LNS établies avant le changement de configuration.

Ignorer une incompatibilité de nombre magique

Lorsque le moteur de transfert de paquets valide le nombre magique homologue dans le paquet d’écho-demande LCP reçu, il vérifie si le nombre magique est inattendu. Le numéro reçu doit correspondre au numéro de l’homologue distant convenu lors de la négociation LCP. Le numéro d’homologue distant doit être différent du numéro d’homologue local ; Lorsqu’ils sont identiques, on s’attend à ce qu’il existe une condition de bouclage (le trafic retourne en boucle vers l’homologue local) ou un autre problème de réseau.

Lorsque le contrôle de validation détermine qu’une incompatibilité est présente, ce qui signifie que le numéro d’homologue distant reçu est différent du numéro négocié, le moteur de transfert de paquets envoie les paquets d’écho-réponse échoués au moteur de routage. Si un Echo-Reply avec un nombre magique valide n’est pas reçu dans un certain intervalle, PPP considère qu’il s’agit d’un échec persistant et détruit la session PPP.

Certains équipements clients peuvent ne pas négocier leur nombre magique local et insérer à la place une valeur arbitraire comme le nombre magique qu’ils envoient au routeur dans les paquets keepalive. Ce numéro est identifié comme une incompatibilité et la session est finalement abandonnée. À partir de Junos OS version 18.1R1, ce résultat peut être évité en configurant le routeur pour qu’il n’effectue pas de vérification de validation des nombres magiques. Comme l’incompatibilité n’est jamais identifiée, le routeur continue d’échanger des paquets keepalive PPP avec l’homologue distant. Pour configurer ce comportement, incluez l’instruction dans un profil de groupe L2TP, dans le profil dynamique pour les connexions d’abonnés ignore-magic-number-mismatch PPP dynamiques terminées au routeur ou dans le profil dynamique pour les abonnés PPP tunnelisés dynamiques au niveau du LNS.

Mises à jour de l’état de connexion provenant de RADIUS pour les périphériques CPE

À partir de Junos OS version 20.2R1, vous pouvez utiliser des messages provenant de RADIUS pour transmettre des informations que le BNG transmet de manière transparente à un équipement CPE, tel qu’une passerelle domestique. Par exemple, ces informations peuvent concerner la bande passante en amont ou un autre paramètre de débit de connexion dont le périphérique CPE a besoin. Cette fonctionnalité est utile lorsque vous souhaitez appliquer dynamiquement la gestion du trafic au plus près des abonnés.

En règle générale, vous pouvez utiliser l’attribut standard RADIUS Reply-Message (18) pour transmettre ces informations au périphérique CPE lors de l’authentification PPP. Toutefois, si vous utilisez déjà cet attribut pour autre chose, vous pouvez également utiliser le message d’état de connexion Juniper Networks (26-4874–218). Ce VSA est une extension logique de l’attribut Reply-Message (18) et a le même format et la même sémantique.

PPP utilise une extension LCP spécifique au fournisseur de Juniper Networks pour envoyer le contenu du message VSA Connection-Status-Message à la passerelle d’accueil homologue. PPP inclut ces informations dans l’option Connection-Status-Message d’un message LCP Connection-Update-Request.

RADIUS peut envoyer le VSA Connection-Status-Message à authd des manières suivantes :

  • Dans le message RADIUS Access-Accept pendant la négociation et l’autorisation d’une session PPP

  • Dans une demande de CoA RADIUS, à tout moment pour une session PPP active

Vous pouvez utiliser ces deux méthodes pour n’importe quelle session donnée pour les abonnés professionnels ou résidentiels. Le message Access-Accept fournit les paramètres de connexion initiaux. La fonctionnalité CoA vous permet de mettre à jour les paramètres de débit de connexion selon vos besoins tout au long de la durée de vie d’une session. Les informations fournies dans le VSA Connection-Status-Message sont généralement des taux de trafic appliqués par configuration locale, telle qu’un profil de service dynamique ou le message ANCP Port Up correspondant.

Note:

Si vous n’incluez pas l’option PPP dans le profil client dynamique, PPP traite la notification de l’authentification, mais n’entreprend lcp-connection-update aucune action. Si LCP sur le routeur n’est pas à l’état Ouvert, PPP n’entreprend aucune action sur le VSA.

Les étapes suivantes décrivent ce qui se passe lorsque RADIUS envoie le VSA dans un message Access-Accept :

  1. Le processus d’authentification reçoit le message d’état de connexion VSA dans un message d’acceptation d’accès du serveur RADIUS.

  2. Le processus authd envoie le VSA Connection-Status-Message à PPP (jpppd).

  3. La négociation PPP NCP a lieu entre le client PPP de la passerelle distante et PPP sur le routeur.

  4. Une négociation réussie aboutit à une demande d’activation familiale. La session PPP passe à l’état Session précédente lorsque la famille est activée.

  5. Si le profil client dynamique inclut l’option PPP et que LCP sur le routeur est à l’état lcp-connection-update Ouvert, PPP envoie un message LCP Connection-Update-Request à la passerelle. Ce message inclut les informations VSA dans l’option Connection-Status-Message.

    • Si la passerelle prend en charge la LCP Connection-Update-Request, elle renvoie un message LCP Connection-Update-Ack au routeur. Le LCP de la passerelle d’accueil doit être à l’état Ouvert lorsqu’il reçoit la demande, sinon il ignore la demande.

    • Si la passerelle ne prend pas en charge la demande de mise à jour de connexion LCP, elle renvoie un message de rejet de code LCP au routeur.

    Note:

    Si la passerelle ne répond pas, le routeur retente la demande de mise à jour. Il utilise les valeurs par défaut PPP allant jusqu’à un maximum de 10 tentatives avec un intervalle de 3 secondes entre les tentatives.

    Note:

    Si vous n’incluez pas l’option PPP dans le profil client dynamique, PPP traite la notification de l’authentification, mais n’entreprend lcp-connection-update aucune action. Si l’option est présente mais que LCP sur le routeur n’est pas à l’état Ouvert, PPP n’entreprend aucune action concernant le VSA.

Les étapes suivantes décrivent ce qui se passe lorsque RADIUS envoie le VSA dans une requête CoA. Cela suppose que les négociations du PCN ont déjà été fructueuses et que la session est active.

  1. Le processus d’authentification reçoit le VSA Connection-Status-Message dans une demande CoA du serveur RADIUS.

  2. Le processus authd envoie le VSA Connection-Status-Message à PPP (jpppd).

  3. Si le profil client dynamique inclut l’option PPP et que LCP sur le routeur est à l’état lcp-connection-update Ouvert, PPP envoie un message LCP Connection-Update-Request à la passerelle. Ce message inclut les informations VSA dans l’option Connection-Status-Message.

    • Si la passerelle prend en charge la LCP Connection-Update-Request, elle renvoie un message LCP Connection-Update-Ack au routeur. Le LCP de la passerelle d’accueil doit être à l’état Ouvert lorsqu’il reçoit la demande, sinon il ignore la demande.

    • Si la passerelle ne prend pas en charge la demande de mise à jour de connexion LCP, elle renvoie un message de rejet de code LCP au routeur.

    Note:

    Si la passerelle ne répond pas, le routeur retente la demande de mise à jour. Il utilise les valeurs par défaut PPP allant jusqu’à un maximum de 10 tentatives avec un intervalle de 3 secondes entre les tentatives.

Si la passerelle domestique ne reçoit pas de message Connection-Update-Request, le routeur réessaie d’envoyer le message. Le routeur retente également la demande lorsqu’il ne reçoit pas de retour Connection-Update-Ack ou LCP Code-Reject de la passerelle, ou lorsque quelque chose ne va pas avec le message Ack. L’intervalle de nouvelle tentative par défaut est de 3 secondes. Le routeur réessaiera le message jusqu’à la valeur par défaut 10 fois avant de se fermer. Si le routeur épuise toutes les nouvelles tentatives sans recevoir un message Connection-Update-Ack approprié, il enregistre le message comme s’il avait reçu un message PPP Code-Reject (Rejet de code PPP).

Note:

RADIUS peut inclure plusieurs instances du VSA Connection-Status-Message dans le message Access-Accept ou dans une demande CoA. Si cela se produit, authd utilise uniquement la première instance et ignore toutes les autres.

Les demandes Access-Accept ou CoA peuvent contenir d’autres attributs que le VSA Connection-Status-Message, mais il n’existe aucune interdépendance entre le VSA et d’autres attributs. Cela est vrai même lorsque le message inclut les VSA Activate-Service (26–65) ou Deactivate-Service (26–66). L’absence de dépendance signifie que même si authd n’applique pas correctement les autres attributs, il envoie toujours les informations de connexion à PPP, qui à son tour envoie le contenu VSA à la passerelle domestique.

De même, authd applique tous les autres attributs et renvoie une réponse CoA, que PPP communique ou non le contenu du VSA Connection-Status-Message à la passerelle distante. Cela est vrai même lorsque le CoA contient uniquement le VSA Connection-Status-Message. Cette fonctionnalité est nécessaire car toutes les passerelles n’acceptent pas l’extension LCP utilisée dans cette fonctionnalité.

Formats des messages et des options

La figure 1 montre le format des messages Connection-Update-Request et Connection-Update-Ack. Les formats sont les mêmes, mais le tableau 1montre que certaines valeurs de champ sont différentes pour les deux messages.

Figure 1 : format de message Connection-Update-Request et Connection-Update-Ack Connection-Update-Request and Connection-Update-Ack Message Format
Tableau 1 : valeurs de champ pour les messages Connection-Update-Request et Connection-Update-Ack

Champ

Demande de mise à jour de connexion

connexion-mise à jour-ack

Code

0 pour les fournisseurs spécifiques

0 pour les fournisseurs spécifiques

Identificateur

Identificateur du paquet spécifique au fournisseur

Même identificateur que dans le message Connection-Update-Request. Si cette valeur ne correspond pas, le routeur consigne l’erreur et rejette le paquet. Cela permet de réessayer le message de demande, comme si la passerelle ne l’avait pas reçu.

Longueur

Nombre d’octets dans le paquet : 12 plus la longueur de l’option Connection-Status-Message

Nombre d’octets dans le paquet Connection-Update-Ack : 12

Nombre magique

Valeur négociée pour le nombre magique PPP local

Valeur négociée pour le nombre magique PPP local

Identificateur unique de l’organisation (OUI)

21/00/59 pour Juniper Networks

21/00/59 pour Juniper Networks

Genre

1 pour la mise à jour de session

2 pour Session-ack. Pour toute autre valeur, le routeur consigne l’erreur et rejette le paquet. Cela permet de réessayer le message de demande, comme si la passerelle ne l’avait pas reçu.

Valeurs

Option Connection-Status-Message au format TLV

Aucune valeur n’est prise en charge

Vous pouvez configurer l’utilisation des nombres magiques PPP.

  • Si vous configurez ignore-magic-number-mismatch l’option PPP, vous empêchez la validation des nombres magiques. PPP ignore une incompatibilité entre les nombres magiques dans la demande et les messages Ack. S’il n’y a pas d’autres erreurs de validation, PPP accepte le message Connection-Update-Ack.

  • Si vous ne configurez ignore-magic-number-mismatch pas l’option PPP, les chiffres magiques passent par la validation. Si le nombre magique du message Ack ne correspond pas au nombre magique de la passerelle établi lors de la négociation LCP, le routeur consigne l’erreur et ignore le message Connection-Update-Ack en tant que réponse non valide. Cela permet de réessayer le message de demande, comme si la passerelle ne l’avait pas reçu.

Voir Empêcher la validation des nombres magiques PPP pendant les échanges PPP Keepalive pour plus d’informations sur les nombres magiques .

La figure 2 montre le format des options Connection-Status-Message. Le tableau 2 répertorie les valeurs des champs.

Figure 2 : format Connection-Status-Message Option Format de l’option Connection-Status-Message
Tableau 2 : valeurs de champ pour l’option Connection-Status-Message

Champ

Valeur

Type

1

Longueur

Nombre d’octets dans l’option ; 2 plus la longueur du message. La longueur du message peut être comprise entre 1 et 247 octets.

Message d’état

Contenu du message d’état de connexion VSA

Configurer les profils dynamiques pour PPP

Un profil dynamique agit comme un modèle qui vous permet de créer, mettre à jour ou supprimer une configuration qui inclut des attributs pour l’accès client (tel que l’interface ou le protocole) ou le service (tel que IGMP). À l’aide de profils dynamiques, vous pouvez consolider tous les attributs communs d’un client (et éventuellement d’un groupe de clients) et appliquer les attributs simultanément.

Une fois les profils dynamiques créés, ils résident dans une bibliothèque de profils sur le routeur. Vous pouvez ensuite utiliser l’instruction dynamic-profile pour attacher des profils aux interfaces. Pour affecter un profil dynamique à une interface PPP, vous pouvez inclure l’instruction dynamic-profile au niveau de la [edit interfaces interface-name unit logical-unit-number ppp-options] hiérarchie :

Pour surveiller la configuration, exécutez la show interfaces interface-name commande.

Pour plus d’informations sur les profils dynamiques, reportez-vous à la section Présentation des profils dynamiques du Guide de configuration de l’accès abonné Junos.

Pour plus d’informations sur la création de profils dynamiques, reportez-vous à la section Configuration d’un profil dynamique de base dans le Guide de configuration de Junos Subscriber Access.

Pour plus d’informations sur l’affectation d’un profil dynamique à une interface PPP, reportez-vous à la section Attachement de profils dynamiques à des interfaces d’abonné PPP statiques dans le Guide de configuration de l’accès abonné Junos.

Pour plus d’informations sur l’utilisation de profils dynamiques pour authentifier les abonnés PPP, consultez Configuration de l’authentification dynamique pour les abonnés PPP.

Note:

Les profils dynamiques des abonnés PPP ne sont pris en charge que sur les interfaces PPPoE de cette version.

Empêcher la validation des nombres magiques PPP lors des échanges PPP keepalive

Les nombres magiques PPP sont négociés entre pairs lors de la négociation LCP. Les pairs doivent avoir des nombres magiques différents. Lorsque les chiffres sont identiques, cela indique qu’il peut y avoir un bouclage dans le trafic envoyé par l’homologue local. Dans ce cas, l’homologue local envoie un nouveau numéro à l’homologue distant. Si le nombre magique renvoyé par l’homologue distant est différent du dernier nombre envoyé par l’homologue local, les nombres sont acceptés. Sinon, l’échange de numéros magiques se poursuit jusqu’à ce qu’un nombre valide (différent) soit reçu ou que le processus expire, auquel cas la session est abandonnée.

Une fois les nombres convenus, les pairs incluent leurs nombres magiques respectifs lorsqu’ils échangent des paquets PPP keepalive (Echo-Request/Echo-Reply). Le moteur de transfert de paquets valide le nombre magique reçu pour chaque échange. Une incompatibilité se produit lorsque le nombre magique PPP reçu de l’homologue distant ne correspond pas à la valeur convenue lors de la négociation LCP. Lorsque le contrôle de validation détermine qu’une incompatibilité est présente, le moteur de transfert de paquets envoie le paquet d’écho-demande échoué au moteur de routage. Si un Echo-Reply avec un nombre magique valide n’est pas reçu dans un certain intervalle, PPP considère qu’il s’agit d’un échec persistant et détruit la session PPP.

Dans certaines circonstances, ce comportement n’est pas souhaitable. Certains équipements clients ne négocient pas leur numéro magique local ; Au lieu de cela, il insère une valeur arbitraire comme le nombre magique qu’il envoie au routeur dans les paquets keepalive. Par défaut, ce nombre est identifié comme une incompatibilité et la session est finalement abandonnée. Ce résultat peut être évité en empêchant le moteur de transfert de paquets d’effectuer le contrôle de validation des nombres magiques. Comme l’incompatibilité n’est jamais identifiée, le routeur continue d’échanger des paquets keepalive PPP avec l’homologue distant.

Désactivez le contrôle de validation des nombres magiques en incluant l’instruction comme l’une ignore-magic-number-mismatch des options PPP appliquées dans un profil PPP dynamique, un profil dynamique LNS L2TP ou un profil de groupe L2TP. La configuration de cette instruction n’a aucun effet sur la négociation des nombres magiques LCP ou sur l’échange de keepalives lorsque le nombre magique de l’homologue distant est le nombre négocié attendu.

Note:

Étant donné que la validation des nombres magiques n’est pas effectuée, le moteur de transfert de paquets ne détecte pas si l’homologue distant envoie le nombre magique de l’homologue local, ce qui indiquerait un bouclage ou un autre problème de réseau. Cette situation est considérée comme peu probable, car la négociation du LCP s’est terminée avec succès, ce qui signifie qu’aucun bouclage n’était présent à ce moment-là.

Pour configurer des profils dynamiques afin d’empêcher le moteur de transfert de paquets de détecter les incompatibilités dans les nombres magiques :

Configurez l’option PPP.

  • Pour les connexions d’abonnés PPP dynamiques terminées au routeur :

  • Pour les abonnés PPP tunnelisés dynamiques sur les interfaces de service en ligne LNS :

Vous pouvez utiliser la show ppp interface interface-name extensive commande pour voir si les nombres magiques sont ignorés.

Procédure de configuration des mises à jour de l’état de connexion provenant de RADIUS pour les périphériques CPE

Vous pouvez utiliser des messages provenant de RADIUS pour transmettre des informations que le BNG transmet de manière transparente à un périphérique CPE, tel qu’une passerelle domestique. Par exemple, ces informations peuvent concerner la bande passante en amont ou un autre paramètre de débit de connexion dont le périphérique CPE a besoin.

Lorsque vous activez cette fonctionnalité, PPP peut agir sur un message VSA d’état de connexion (26–218) reçu par authentification dans un message d’accès-acceptation RADIUS ou un message CoA. PPP transmet ensuite le contenu du VSA dans un message LCP Connection-Update-Request à l’homologue distant. Cette action requiert que les conditions suivantes soient remplies :

  • Au moins la première famille d’adresses a été négociée avec succès et la session est active.

  • Le LCP du routeur est à l’état Ouvert.

Dans le cas contraire, le PPP ne prend aucune mesure à l’égard de la VSA. Si vous n’activez pas l’option, PPP traite la notification à partir de authd, mais n’entreprend lcp-connection-update aucune action.

Vous configurez cette fonctionnalité dans le profil client dynamique associé aux abonnés à l’aide du périphérique CPE. En pratique, vous l’ajoutez à de nombreuses autres fonctionnalités du profil client. Cet exemple montre uniquement la configuration spécifique de cette fonctionnalité. Cette fonctionnalité nécessite également de configurer VSA 26-218 sur votre serveur RADIUS ; qui n’entrent pas dans le cadre de la présente documentation.

Pour configurer les mises à jour de l’état de connexion dans un profil dynamique pour les interfaces abonnés PPP :

  1. Modifiez les options PPP dans le profil client.
  2. Activez les mises à jour de l’état de la connexion.

Vous pouvez utiliser la commande de l’interface logique PPP pour déterminer si les show ppp interface extensive mises à jour de connexion LCP réussissent. Vous pouvez surveiller les statistiques pertinentes avec la show system subscriber-management statistics ppp commande.

Attachement de profils dynamiques à des interfaces abonnés PPP statiques

Vous pouvez attacher un profil dynamique à une interface d’abonné PPP statique. Lorsqu’un abonné PPP se connecte, le profil dynamique spécifié est instancié et les services définis dans le profil sont appliqués à l’interface.

Pour attacher un profil dynamique à une interface abonnée PPP statique :

  1. Spécifiez que vous souhaitez configurer les options PPP.
  2. Spécifiez le profil dynamique que vous souhaitez associer à l’interface.

Présentation de la migration des configurations d’abonnés PPP statiques vers les profils dynamiques

Cette rubrique traite de plusieurs considérations relatives à la migration de certaines configurations d’abonnés PPP IPv4 statiques terminées vers des configurations dynamiques à l’aide de profils dynamiques. Les fournisseurs de services qui gèrent des abonnés statiques sur des routeurs dotés d’anciennes versions de Junos OS (antérieures à Junos OS version 15.1R4) doivent faire migrer leurs abonnés statiques pour qu’ils soient gérés avec des profils dynamiques sur des routeurs exécutant une gestion améliorée des abonnés (Junos OS version 15.1R4 et versions ultérieures). À partir de Junos OS version 18.2R1, plusieurs améliorations ont été ajoutées pour faciliter la transition de ces configurations statiques de fournisseurs de services vers des profils dynamiques.

Authentification locale

Certains fournisseurs ayant des configurations statiques peuvent utiliser des périphériques CPE qui ne prennent en charge aucun protocole d’authentification, pas même CHAP ou PAP. Les fournisseurs peuvent utiliser les tables de noms de service PPPoE comme méthode rudimentaire pour authentifier et autoriser les abonnés sur des interfaces logiques PPPoE statiques. Si l’ACI ou l’ARI de l’abonné ne correspond pas à une entrée de table, les paquets PPP PADI et PADR sont généralement abandonnés. Les anciennes versions de Junos OS ne prennent pas en charge les abonnés configurés sans authentification pour la méthode d’authentification .

Pour les abonnés pour lesquels le CPE ne prend pas en charge les protocoles d’authentification tels que PAP et CHAP, vous pouvez configurer les noms d’utilisateur et les mots de passe localement. Le routeur utilise ces valeurs lorsqu’il contacte le serveur RADIUS pour l’authentification.

  • Pour configurer le nom d’utilisateur pour l’authentification locale, incluez l’instruction dans les options PPP de l’interface username-include logique dynamique. Vous pouvez définir le nom en fonction d’un ou de plusieurs des attributs suivants : adresse MAC, ID de circuit de l’agent, ID distant de l’agent et nom de domaine. Par défaut, un point (.) est le délimiteur entre les éléments du nom, mais vous pouvez définir d’autres caractères à la place.

  • Pour configurer le mot de passe pour l’authentification locale, incluez l’instruction dans les options PPP de l’interface password logique dynamique.

Vous pouvez utiliser le même profil dynamique pour prendre en charge à la fois les CPE qui ne prennent pas en charge un protocole d’authentification et les CPE qui le font.

Attribution d’adresses provenant de CPE

Pour certaines configurations statiques, l’adresse de l’abonné n’est pas attribuée à l’aide de RADIUS ou d’un pool d’adresses local sur le routeur. Au lieu de cela, le CPE a une adresse statique configurée pour l’abonné ; lors de la négociation IPCP, le CPE demande au routeur d’attribuer cette adresse à l’abonné.

À partir de Junos OS version 18.2R1, vous pouvez attribuer une adresse générique 255.255.255.255 à l’attribut Framed-Route-Address [8] dans la configuration de votre serveur RADIUS. Lorsque RADIUS renvoie l’attribut avec cette valeur, jpppd accepte automatiquement l’attribution d’adresse IP d’abonné fournie par le client dans un message de requête de configuration IPCP plutôt que d’attribuer une autre adresse.

Attribut de route Tag2

Dans certaines configurations, des interfaces abonnés PPP statiques sont configurées dans différents VRF. Chaque configuration VRF a des routes statiques qui pointent vers des interfaces d’abonné PPP statiques comme adresse de saut suivant. L’attribut tag2 peut être configuré pour ces routes ; le MP-BGP est tenu d’appliquer la préférence locale et la communauté appropriées lorsqu’il annonce les itinéraires.

À partir de Junos OS version 18.2R1, vous pouvez configurer votre serveur RADIUS pour inclure l’attribut tag2 dans l’attribut Framed-Route [22] lorsqu’il authentifie un abonné.

Vous devez également configurer le profil dynamique pour dériver la valeur tag2 de l’attribut Framed-Route. Pour ce faire, spécifiez la variable prédéfinie $junos-framed-route-tag2 à utiliser lorsque la route d’accès est instanciée dynamiquement. Vous pouvez également configurer le profil dynamique pour qu’il fournisse une valeur tag2 spécifique pour un préfixe de route d’accès spécifique.

Voir Variables prédéfinies Junos OS pour plus d’informations sur les variables prédéfinies.

Avantages

  • L’authentification locale permet l’authentification avec des mots de passe et des noms d’utilisateur stockés localement pour les abonnés lorsque le CPE ne prend pas en charge les protocoles d’authentification tels que PAP et CHAP.

  • L’attribution d’adresses provenant du CPE permet au routeur d’accepter les adresses IP d’abonnés configurées statiquement demandées par le CPE plutôt que d’attribuer l’adresse d’un pool d’adresses local ou externe.

  • L’attribut tag2 permet de spécifier plus en détail les itinéraires.

Configuration de l’authentification locale dans les profils dynamiques pour les abonnés PPP IPv4 terminés statiques

Certains fournisseurs ayant des configurations statiques peuvent utiliser des périphériques CPE qui ne prennent en charge aucun protocole d’authentification, pas même CHAP ou PAP. Les fournisseurs peuvent utiliser les tables de noms de service PPPoE comme méthode rudimentaire pour authentifier et autoriser les abonnés sur des interfaces logiques PPPoE statiques. Si l’ACI ou l’ARI de l’abonné ne correspond pas à une entrée de table, les paquets PPP PADI et PADR sont généralement abandonnés.

À partir de Junos OS version 18.2R1, vous pouvez configurer les noms d’utilisateur et les mots de passe localement pour les clients qui ne prennent pas en charge les protocoles d’authentification tels que PAP et CHAP. Le routeur utilise ces valeurs lorsqu’il contacte le serveur RADIUS pour l’authentification. Cela facilite la migration des abonnés statiques vers l’utilisation de profils dynamiques sur un routeur exécutant une gestion améliorée des abonnés.

Pour configurer l’authentification locale :

  1. Configurez le nom d’utilisateur à l’aide d’une ou plusieurs des options disponibles.
    1. (Facultatif) Spécifiez que l’identificateur de circuit de l’agent (ACI) est inclus dans le nom d’utilisateur. L’ACI est dérivé des balises PPPoE.

    2. (Facultatif) Spécifiez que l’ID distant de l’agent (ARI) est inclus dans le nom d’utilisateur. L’ARI est dérivé des balises PPPoE.

    3. (Facultatif) Spécifiez que l’adresse MAC de la PDU client est incluse dans le nom d’utilisateur. L’adresse MAC est dérivée du paquet PPPoE.

    4. (Facultatif) Spécifiez le nom de domaine client pour terminer le nom d’utilisateur. Le routeur ajoute le caractère @ comme délimiteur pour cette option.

    5. (Facultatif) Spécifiez un délimiteur pour séparer les composants qui composent le nom d’utilisateur. Le délimiteur par défaut est un point (.). Le routeur utilise toujours le caractère @ comme délimiteur avant le nom de domaine.

  2. Configurez le mot de passe de l’abonné.

Le nom d’utilisateur prend le format suivant lorsque vous incluez toutes les options et utilisez le délimiteur par défaut :

Par exemple, considérons l’exemple de configuration suivant, où l’ACI est aci1002, l’ARI est ari349 et l’adresse MAC est 00 :00 :5e :00 :53 :ff :

Cette configuration génère un mot de passe local de $ABC 123$ABC123 pour le nom d’utilisateur local unique suivant :

0000.5e00.53ff-aci1002-ari349@example.com

Configuration des attributs Tag2 dans les profils dynamiques pour les abonnés PPP IPv4 terminés statiques

Dans certaines configurations, les abonnés PPP utilisent des routes statiques avec un attribut tag2. Par exemple, MP-BGP utilise tag2 pour lui permettre d’appliquer la préférence locale et la communauté appropriées lorsqu’il annonce des itinéraires. Lorsque vous migrez ces abonnés vers l’utilisation de profils dynamiques sur un routeur exécutant une gestion améliorée des abonnés, vous pouvez configurer l’attribut tag2 en configurant une valeur spécifique pour un itinéraire ou en dérivant la valeur d’un serveur RADIUS. Cette prise en charge est disponible pour la première fois dans Junos OS version 18.2R1.

  • Pour configurer une valeur tag2 spécifique pour un itinéraire :

    • Spécifiez la valeur.

  • Pour dériver la valeur tag2 d’un serveur RADIUS :

    1. Configurez votre serveur RADIUS pour inclure l’attribut tag2 dans l’attribut Framed-Route [22] lorsqu’il authentifie un abonné. Consultez la documentation de votre serveur RADIUS pour obtenir des informations sur la configuration. La configuration peut ressembler à l’exemple suivant :

    2. Configurez le profil dynamique pour utiliser la variable prédéfinie $junos-framed-route-tag2 afin de dériver dynamiquement la valeur tag2 de l’attribut Framed-Route.

      La variable prédéfinie $junos-framed-route-ip-address-prefix dérive également le préfixe d’adresse IPv4 pour la route d’accès de l’attribut Framed-Route.

Configuration de l’authentification dynamique pour les abonnés PPP

Vous pouvez configurer un profil dynamique qui inclut l’authentification PPP qui permet aux clients PPP d’accéder dynamiquement au réseau. Vous pouvez spécifier l’authentification CHAP ou PAP. Vous pouvez également contrôler l’ordre dans lequel le routeur négocie les protocoles CHAP et PAP.

Pour les interfaces dynamiques, le routeur prend uniquement en charge l’authentification unidirectionnelle : il joue toujours le rôle d’authentificateur. Lorsque vous configurez l’authentification PPP dans un profil dynamique, l’authentification CHAP prend en charge cette challenge-length option, qui vous permet de configurer la longueur minimale et maximale du message de stimulation CHAP. Ni l’authentification CHAP ni l’authentification PAP ne prennent en charge d’autres options de configuration, y compris l’instruction passive .

Note:

Les profils dynamiques des abonnés PPPoE ne sont pris en charge que sur les interfaces PPPoE.

Pour configurer l’authentification dans un profil dynamique pour les interfaces abonnés PPP :

  1. Nommez le profil dynamique.
  2. Configurez les interfaces et l’unité pour le profil dynamique. Utilisez pp0 pour le type d’interface et la variable prédéfinie pour l’unité.
  3. Configurez les options PPP.
  4. Spécifiez le protocole d’authentification utilisé dans le profil dynamique. Vous pouvez configurer le protocole CHAP ou PAP. Il n’y a pas d’options supplémentaires pour l’un ou l’autre protocole d’authentification.
  5. (Facultatif) Configurez la longueur minimale et maximale du message de défi CHAP.
  6. (Facultatif) Configurez l’ordre dans lequel le routeur négocie les protocoles d’authentification CHAP et PAP.
  7. (Facultatif) Configurez le routeur pour inviter le CPE à négocier les adresses DNS des abonnés PPPoE dynamiques pendant la négociation IPCP.

Modification de la longueur du défi CHAP

Vous pouvez modifier la longueur minimale et maximale par défaut du message de défi CHAP (Challenge Handshake Authentication Protocol) que le routeur envoie à un client PPP. Le message de stimulation CHAP, qui contient des informations uniques à une session d’abonné PPP particulière, est utilisé dans le cadre du mécanisme d’authentification entre le routeur et le client pour vérifier l’identité du client pour accéder au routeur.

Par défaut, la longueur minimale du défi CHAP est de 16 octets et la longueur maximale est de 32 octets. Vous pouvez remplacer cette valeur par défaut pour configurer la longueur minimale et la longueur maximale du défi CHAP comprises entre 8 octets et 63 octets.

Meilleure pratique :

Nous vous recommandons de configurer la longueur minimale et la longueur maximale de la commande CHAP sur au moins 16 octets.

Avant de commencer :

Pour configurer la longueur minimale et maximale du message de stimulation CHAP :

  1. Spécifiez que vous souhaitez configurer les options PPP.
    • Pour les interfaces d’abonnés PPP dynamiques :

    • Pour les interfaces statiques avec encapsulation PPP :

  2. Spécifiez que vous souhaitez configurer les options CHAP.
    • Pour les interfaces d’abonnés PPP dynamiques :

    • Pour les interfaces statiques avec encapsulation PPP :

  3. Spécifiez la durée minimale et maximale du défi CHAP.
    • Pour les interfaces d’abonnés PPP dynamiques :

    • Pour les interfaces statiques avec encapsulation PPP :

    Par exemple, l’instruction suivante challenge-length dans un profil dynamique nommé pppoe-client-profile définit la longueur minimale de la commande CHAP sur 20octets et la longueur maximale sur 40octets.

Exemple : profil dynamique PPPoE minimal

Cet exemple montre la configuration minimale d’un profil dynamique utilisé pour les interfaces PPPoE statiques. La configuration doit inclure la interfaces pp0 strophe.

Vérification et gestion de la configuration PPP pour la gestion des abonnés

But

Afficher ou effacer les informations sur la configuration PPP pour la gestion des abonnés.

Action

  • Pour afficher des informations sur les interfaces PPP :

  • Pour afficher des informations statistiques sur les PPA :

  • Pour afficher les informations récapitulatives de session PPP :

  • Pour afficher les informations du pool d’adresses PPP :

Tableau de l’historique des versions
Libération
Description
20.2R1
À partir de Junos OS version 20.2R1, vous pouvez utiliser des messages provenant de RADIUS pour transmettre des informations que le BNG transmet de manière transparente à un équipement CPE, tel qu’une passerelle domestique.
18.2R1
À partir de Junos OS version 18.2R1, plusieurs améliorations ont été ajoutées pour faciliter la transition de ces configurations statiques de fournisseurs de services vers des profils dynamiques.
18.1R1
À partir de Junos OS version 18.1R1, ce résultat peut être évité en configurant le routeur pour qu’il n’effectue pas de vérification de validation des nombres magiques.