SUR CETTE PAGE
Présentation des interfaces abonnés Profils dynamiques pour PPP
Comprendre comment le routeur traite les requêtes PPP Fast Keepalive initiées par les abonnés
Mises à jour de l’état des connexions provenant de RADIUS aux équipements CPE
Empêcher la validation des nombres magiques PPP lors d’échanges keepalive PPP
Attachement de profils dynamiques à des interfaces abonnés PPP statiques
Présentation de la migration de configurations d’abonnés PPP statiques vers des profils dynamiques
Configuration de l’authentification dynamique pour les abonnés PPP
Vérification et gestion de la configuration PPP pour la gestion des abonnés
Présentation des réseaux d’accès abonné PPP
Présentation des interfaces abonnés Profils dynamiques pour PPP
Gestion des abonnés La prise en charge PPP vous permet de créer et de joindre des profils dynamiques pour les interfaces d’abonné 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 la CLI pour attacher des profils dynamiques, qui spécifient les options PPP. Pour les interfaces PPP dynamiques, le profil dynamique crée l’interface, y compris les options PPP.
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 ne permet 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 d’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 défi 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 requêtes PPP Fast Keepalive initiées par les abonnés
Sur les routeurs MX Series avec concentrateurs de ports modulaires/cartes d’interface modulaires (MPC/MIC), le moteur de transfert de paquets d’une 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 de demande d’écho LCP et les paquets de réponse d’écho LCP 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 traités sur un routeur MX Series par le moteur de routage. Le mécanisme par lequel les paquets de demande d’écho LCP sont traités par le moteur de transfert de paquets au lieu du moteur de routage est appelé keepalives rapides PPP.
- Avantages des Fast Keepalives PPP
- Fonctionnement du traitement rapide Keepalive PPP
- Affichage des statistiques pour PPP Fast Keepalive
- Effet de la modification de la configuration de la classe de transfert
- Ignorer une incompatibilité de nombre magique
Avantages des Fast Keepalives PPP
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 de demande d’écho LCP de l’abonné PPP et de répondre avec des paquets de réponse d’écho LCP, sans avoir à envoyer les paquets LCP au moteur de routage pour traitement.
Les keepalives rapides PPP augmentent la bande passante sur le routeur pour prendre en charge un plus grand nombre d’abonnés avec de meilleures performances en évitant au moteur de routage d’avoir à traiter les paquets LCP Echo-Request et Echo-Reply.
Les keepalives rapides PPP utilisent des nombres magiques négociés pour identifier les bouclages potentiels du trafic vers le routeur ou les problèmes réseau. Vous pouvez également désactiver la validation si nécessaire pour empêcher l’interruption indésirable de la session PPP, par exemple lorsque les homologues distants PPP utilisent des nombres arbitraires plutôt que le nombre négocié.
Fonctionnement du traitement rapide Keepalive PPP
Vous n’avez besoin d’aucune configuration spéciale sur un routeur MX Series avec MPC/MIC pour permettre le traitement des requêtes 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 les paquets LCP Echo-Reply sur le moteur de transfert de paquets sur la MPC/MIC :
Le moteur de routage notifie le moteur de transfert de paquets lorsque la transmission de demandes keepalive est activée sur une interface logique PPP. La notification comprend les chiffres magiques du serveur et du client distant.
Le moteur de transfert de paquets reçoit le paquet LCP Echo-Request initié par l’abonné PPP (client)
Le moteur de transfert de paquets valide le nombre magique pair dans le paquet de demande d’écho LCP et transmet le paquet de réponse d’écho LCP correspondant contenant le nombre magique négocié par le routeur.
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 de demande d’écho LCP jusqu’à ce que la condition de boucle soit effacée.
La transmission des demandes keepalive à partir du moteur de transfert de paquets sur le routeur n’est pas activée actuellement.
Affichage des statistiques pour PPP Fast Keepalive
Lorsqu’un routeur MX Series avec MPC/MIC utilise PPP fast keepalive pour une liaison PPP, le Keepalive statistics champ de la sortie de la show interfaces pp0.logical statistics commande opérationnelle n’inclut pas de statistiques pour le nombre de paquets keepalive reçus ou envoyés, ni le temps écoulé depuis que le routeur a reçu ou envoyé le 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 PPP keepalive LCP Echo-Request et LCP Echo-Reply rapides (en ligne) 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é PPP-over-Ethernet (PPPoE), PPP-over-ATM (PPPoA) et L2TP network server (LNS) créées après la modification de configuration, ainsi que pour les PPPoE, PPPoA existants, et les sessions d’abonnés LNS établies avant la modification de configuration.
Ignorer une incompatibilité de nombre magique
Lorsque le moteur de transfert de paquets valide le nombre magique d’homologue dans le paquet de demande d’écho 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 qui a été convenu lors de la négociation du LCP. Le numéro d’homologue distant doit être différent du numéro d’homologue local ; Lorsqu’ils sont identiques, on peut s’attendre à ce qu’il y ait une condition de bouclage (le trafic retourne vers l’homologue local) ou un autre problème 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 Echo-Reply échoués au moteur de routage. Si une réponse écho avec un numéro magique valide n’est pas reçue dans un certain intervalle, PPP considère qu’il s’agit d’un échec continu et interrompt la session PPP.
Certains équipements clients peuvent ne pas négocier leur nombre magique local et insérer à la place une valeur arbitraire comme nombre magique qu’il envoie au routeur dans les paquets keepalive. Ce nombre est identifié comme une incompatibilité et la session est finalement abandonnée. À partir de la version 18.1R1 de Junos OS, vous pouvez éviter ce résultat en configurant le routeur pour qu’il n’effectue pas de vérification de validation du nombre magique. 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 ignore-magic-number-mismatch dans un profil de groupe L2TP, dans le profil dynamique pour les connexions d’abonnés PPP dynamiques terminées au niveau du routeur ou dans le profil dynamique pour les abonnés PPP tunnelisés dynamiques au niveau du LNS.
Voir aussi
Mises à jour de l’état des connexions provenant de RADIUS aux équipements CPE
À partir de la version 20.2R1 de Junos OS, vous pouvez utiliser des messages provenant de RADIUS pour transmettre des informations que la BNG transmet de manière transparente à un équipement CPE, tel qu’une passerelle domestique. Par exemple, ces informations peuvent être la bande passante en amont ou un autre paramètre de débit de connexion dont l’équipement CPE a besoin. Cette fonctionnalité est utile lorsque vous souhaitez appliquer dynamiquement la gestion du trafic aussi près que possible 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 VSA Connection-Status-Message de connexion de 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 de LCP spécifique au fournisseur de Juniper Networks pour envoyer le contenu du VSA Connection-Status-Message à la passerelle d’accueil homaire. 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 d’accès-acceptation de RADIUS pendant la négociation et l’autorisation d’une session PPP
-
Dans une demande CoA RADIUS à tout moment pour une session PPP active
Vous pouvez utiliser ces deux méthodes pour une session donnée pour les abonnés professionnels ou résidentiels. Le message Accès-Acceptation fournit les paramètres de connexion initiaux. La fonctionnalité CoA vous permet de mettre à jour les paramètres de débit de connexion selon les besoins tout au long de la durée de vie d’une session. Les informations transportées dans le VSA Connection-Status-Message sont généralement les taux de trafic appliqués par la configuration locale, telle qu’un profil de service dynamique ou le message ANCP Port Up correspondant.
Si vous n’incluez pas l’option lcp-connection-update PPP dans le profil client dynamique, PPP traite la notification d’authd, mais ne prend aucune mesure. Si LCP sur le routeur n’est pas à l’état Ouvert, PPP ne prend aucune mesure sur le VSA.
Les étapes suivantes décrivent ce qui se passe lorsque RADIUS envoie le VSA dans un message d’accès-acceptation :
-
Le processus authd reçoit le VSA Connection-Status-Message dans un message Access-Accept du serveur RADIUS.
-
Le processus authd envoie le VSA Connection-Status-Message à PPP (jpppd).
-
La négociation PPP NCP a lieu entre le client PPP de passerelle distante et PPP sur le routeur.
-
Une négociation réussie aboutit à une demande d’activation familiale. La session PPP passe à l’état Session active lorsque la famille est activée.
-
Si le profil client dynamique inclut l’option
lcp-connection-updatePPP et que LCP sur le routeur est à l’état 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 demande de mise à jour de connexion LCP, elle renvoie un message de connexion LCP de mise à jour d’accusé de réception au routeur. Le LCP de la passerelle domestique doit être à l’état Ouvert lorsqu’il reçoit la demande, sinon il l’ignore.
-
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.
Remarque :Si la passerelle ne répond pas, le routeur retente la demande de mise à jour. Il utilise les valeurs par défaut PPP d’un maximum de 10 tentatives avec un intervalle de 3 secondes entre les tentatives.
Remarque :Si vous n’incluez pas l’option
lcp-connection-updatePPP dans le profil client dynamique, PPP traite la notification d’authd, mais ne prend aucune mesure. Si l’option est présente mais que LCP sur le routeur n’est pas à l’état Ouvert, PPP ne prend aucune mesure 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 la négociation du PCN a déjà été fructueuse et que la session est active.
-
Le processus authd reçoit le VSA Connection-Status-Message dans une requête CoA du serveur RADIUS.
-
Le processus authd envoie le VSA Connection-Status-Message à PPP (jpppd).
-
Si le profil client dynamique inclut l’option
lcp-connection-updatePPP et que LCP sur le routeur est à l’état 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 demande de mise à jour de connexion LCP, elle renvoie un message de connexion LCP de mise à jour d’accusé de réception au routeur. Le LCP de la passerelle domestique doit être à l’état Ouvert lorsqu’il reçoit la demande, sinon il l’ignore.
-
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.
Remarque :Si la passerelle ne répond pas, le routeur retente la demande de mise à jour. Il utilise les valeurs par défaut PPP d’un maximum de 10 tentatives avec un intervalle de 3 secondes entre les tentatives.
-
Si la passerelle domestique ne parvient pas à recevoir un message Connection-Update-Request, le routeur retente d’envoyer le message. Le routeur retente également la demande lorsqu’il ne reçoit ni Connection-Update-Ack ni 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 le quitter. 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.
RADIUS peut inclure plusieurs instances du VSA Connection-Status-Message dans le message Access-Accept ou une demande CoA. Si cela se produit, authd n’utilise que la première instance et ignore les autres.
Les requêtes Access-Accept ou CoA peuvent contenir d’autres attributs que le VSA Connection-Status-Message, mais il n’y a pas d’interdépendance entre le VSA et les 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 avec succès 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 avec succès le contenu du VSA Connection-Status-Message à la passerelle distante. Cela est vrai même lorsque le CoA ne contient que le VSA Connection-Status-Message. Cette capacité est nécessaire car toutes les passerelles n’acceptent pas l’extension LCP utilisée dans cette fonctionnalité.
Formats de message et d’option
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.
| Champ |
demande de mise à jour de connexion |
connexion-mise à jour-accusé de réception |
|---|---|---|
| Code |
0 pour les fournisseurs spécifiques |
0 pour les fournisseurs spécifiques |
| Identificateur |
Identifiant du paquet spécifique au fournisseur |
Même identifiant que dans le message Connection-Update-Request. Si cette valeur ne correspond pas, le routeur consigne l’erreur et ignore 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 chiffre magique du PPP local |
Valeur négociée pour le chiffre magique du PPP local |
| Identifiant unique de l’organisation (OUI) |
00-21-59 pour Juniper Networks |
00-21-59 pour Juniper Networks |
| Gentil |
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 la façon dont les nombres magiques PPP sont utilisés.
-
Si vous configurez
ignore-magic-number-mismatchl’option PPP, vous empêchez la validation des nombres magiques. PPP ignore une incompatibilité entre les nombres magiques dans la requête 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-mismatchpas l’option PPP, les nombres magiques sont validés. Si le nombre magique dans le 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 comme réponse non valide. Cela permet de réessayer le message de demande, comme si la passerelle ne l’avait pas reçu.
Pour plus d’informations sur les nombres magiques, reportez-vous à la section Empêcher la validation des nombres magiques PPP lors d’échanges keepalive PPP .
La figure 2 montre le format des options Connection-Status-Message. Le Tableau 2 répertorie les valeurs des champs.
de l’option connection-status-message
| Champ |
Valeur |
|---|---|
| Le 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 VSA connection-status-message |
Configurer des profils dynamiques pour PPP
Un profil dynamique agit comme un modèle qui vous permet de créer, de mettre à jour ou de supprimer une configuration qui inclut des attributs d’accès client (par exemple, interface ou protocole) ou de 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 à des 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 :
[edit interfaces interface-name unit logical-unit-number ppp-options] dynamic-profile profile-name;
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 dans le 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 l’accès abonné Junos.
Pour plus d’informations sur l’affectation d’un profil dynamique à une interface PPP, reportez-vous à la section Attachement de profils dynamiques à des interfaces abonnés 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.
Pour cette version, les profils dynamiques des abonnés PPP sont uniquement pris en charge sur les interfaces PPPoE.
Empêcher la validation des nombres magiques PPP lors d’échanges keepalive PPP
Les chiffres magiques des PPP sont négociés entre pairs lors de la négociation du 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 numéro envoyé par l’homologue local, les numéros sont convenus. Sinon, l’échange de numéros magiques se poursuit jusqu’à ce qu’un numéro 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 numéros 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 de demande d’écho échoué au moteur de routage. Si une réponse écho avec un numéro magique valide n’est pas reçue dans un certain intervalle, PPP considère qu’il s’agit d’un échec continu et interrompt la session PPP.
Dans certaines circonstances, ce comportement n’est pas souhaitable. Certains équipements clients ne négocient pas leur chiffre magique local ; Au lieu de cela, il insère une valeur arbitraire comme 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 la vérification de validation du nombre magique. Comme l’incompatibilité n’est jamais identifiée, le routeur continue d’échanger des paquets keepalive PPP avec l’homologue distant.
Désactivez la vérification de validation du nombre magique en incluant l’instruction ignore-magic-number-mismatch comme l’une 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 du nombre magique LCP ou sur l’échange de keepalives lorsque le nombre magique d’homologue distant est le nombre négocié attendu.
Étant donné que la validation du nombre magique n’est pas effectuée, le moteur de transfert de paquets ne détecte pas si l’homologue distant envoie le numéro 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 les négociations du LCP se sont terminées avec succès, ce qui signifie qu’il n’y avait pas de bouclage à 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é PPP dynamiques terminées au niveau du routeur :
[edit dynamic-profiles profile-name interfaces pp0 unit “$junos-interface-unit” ppp-options] user@host# set ignore-magic-number-mismatch
Pour les abonnés PPP tunnelisés dynamiques sur les interfaces de service en ligne LNS :
[edit dynamic-profiles profile-name interfaces "$junos-interface-ifd-name" unit “$junos-interface-unit” ppp-options] user@host# set ignore-magic-number-mismatch
Vous pouvez utiliser la show ppp interface interface-name extensive commande pour voir si les nombres magiques sont ignorés.
Comment configurer les mises à jour de l’état des connexions provenant de RADIUS sur les équipements CPE
Vous pouvez utiliser des messages provenant de RADIUS pour transmettre des informations que la BNG transfère de manière transparente à un équipement CPE, tel qu’une passerelle domestique. Par exemple, ces informations peuvent être la bande passante en amont ou un autre paramètre de débit de connexion dont l’équipement CPE a besoin.
Lorsque vous activez cette fonctionnalité, PPP peut agir sur un VSA Connection-Status-Message (26–218) reçu par authd dans un message RADIUS Access-Accept ou un message CoA. PPP transmet ensuite le contenu du VSA dans un message LCP Connection-Update-Request à l’homologue distant. Cette action nécessite que les éléments suivants soient vrais :
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.
Sinon, le PPP ne prend aucune mesure à l’égard de l’ASV. Si vous n’activez pas l’option lcp-connection-update , PPP traite la notification d’authd, mais ne prend aucune mesure.
Vous configurez cette fonctionnalité dans le profil client dynamique associé aux abonnés à l’aide de l’équipement CPE. En pratique, vous ajoutez cela à de nombreuses autres fonctionnalités du profil client. Cet exemple montre uniquement la configuration spécifique de cette fonctionnalité. Cette fonctionnalité nécessite également que vous configuriez VSA 26-218 sur votre serveur RADIUS ; qui sort du cadre de cette documentation.
Pour configurer les mises à jour de l’état de la connexion dans un profil dynamique pour les interfaces d’abonné PPP :
Vous pouvez utiliser la show ppp interface extensive commande de l’interface logique PPP pour déterminer si les mises à jour de la connexion LCP réussissent. Vous pouvez surveiller les statistiques pertinentes à l’aide de 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 d’abonné PPP statique :
Présentation de la migration de configurations d’abonnés PPP statiques vers des profils dynamiques
Cette rubrique traite de plusieurs considérations relatives à la migration de certaines configurations d’abonnés PPP IPv4 statiques et 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 migrer leurs abonnés statiques vers une gestion avec profils dynamiques sur des routeurs exécutant la gestion améliorée des abonnés (Junos OS version 15.1R4 et versions ultérieures). À partir de la version 18.2R1 de Junos OS, plusieurs améliorations ont été ajoutées pour faciliter la transition de ces configurations statiques de fournisseur de services vers des profils dynamiques.
Authentification locale
Certains fournisseurs ayant des configurations statiques peuvent utiliser des appareils CPE qui ne prennent en charge aucun protocole d’authentification, pas même CHAP ou PAP. Les fournisseurs peuvent utiliser des 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 perdus. 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 sur 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
username-includedans les options PPP de l’interface logique dynamique. Vous pouvez définir le nom en fonction d’un ou de plusieurs des attributs suivants : l’adresse MAC, l’ID du circuit de l’agent, l’ID de la télécommande de l’agent et le 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
passwordoptions PPP de l’interface logique dynamique.
Vous pouvez utiliser le même profil dynamique pour prendre en charge les CPE qui ne prennent pas en charge un protocole d’authentification et les CPE qui le font.
Attribution d’adresses 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 locales 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 la version 18.2R1 de Junos OS, vous pouvez attribuer une adresse générique de 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 demande de configuration IPCP plutôt que d’affecter une autre adresse.
Attribut de route Tag2
Dans certaines configurations, des interfaces d’abonné PPP statiques sont configurées dans différents VRF. Chaque configuration VRF possède des routes statiques qui pointent vers des interfaces d’abonné PPP statiques comme adresse de saut suivant. Ces routes peuvent avoir l’attribut tag2 configuré ; il est tenu par MP-BGP d’appliquer la préférence locale et la communauté appropriées lorsqu’il annonce les itinéraires.
À partir de la version 18.2R1 de Junos OS, 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 qu’il dérive la valeur tag2 de l’attribut Framed-Route (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 fournir une valeur tag2 spécifique pour un préfixe de route d’accès spécifique.
Pour plus d’informations sur les variables prédéfinies, reportez-vous à la section Variables prédéfinies de Junos OS .
Avantages
L’authentification locale permet aux abonnés de s’authentifier avec des mots de passe et des noms d’utilisateur stockés localement lorsque le CPE ne prend pas en charge les protocoles d’authentification tels que PAP et CHAP.
L’attribution d’adresses CPE permet au routeur d’accepter les adresses IP d’abonnés configurées de manière statique demandées par le CPE plutôt que d’attribuer l’adresse à partir d’un pool d’adresses local ou externe.
L’attribut tag2 permet une spécification plus détaillée des itinéraires.
Configuration de l’authentification locale dans les profils dynamiques pour les abonnés PPP IPv4 statiques terminés
Certains fournisseurs ayant des configurations statiques peuvent utiliser des appareils CPE qui ne prennent en charge aucun protocole d’authentification, pas même CHAP ou PAP. Les fournisseurs peuvent utiliser des 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 perdus.
À partir de la version 18.2R1 de Junos OS, 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 :
Le nom d’utilisateur prend le format suivant lorsque vous incluez toutes les options et utilisez le délimiteur par défaut :
mac-address.circuit-id.remote-id@domain-name
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 :
[edit dynamic-profiles profile-name interfaces "$junos-interface-ifd-name" unit "$junos-interface-unit" ppp-options local-authentication] user@host# set username-include circuit-id user@host# set username-include remote-id user@host# set username-include mac-address user@host# set username-include domain-name example.com user@host# set username-include delimiter - user@host# set password $ABC123$ABC123
Cette configuration génère un mot de passe local de 123$ABC123 $ABC 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 statiques terminés
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 routes. Lorsque vous migrez ces abonnés vers l’utilisation de profils dynamiques sur un routeur exécutant la gestion améliorée des abonnés, vous pouvez configurer l’attribut tag2 en configurant une valeur spécifique pour une route 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 une route :
Spécifiez la valeur.
[edit dynamic-profiles profile-name routing-options access route prefix] user@host# set tag2 route-tag2
Pour dériver la valeur tag2 d’un serveur RADIUS :
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 de configuration. La configuration peut ressembler à l’exemple suivant :
user@sub.example.com User-Password := "$ABC123" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Route += "198.51.100.0/24 203.0.113.27 tag 5 distance 10 tag2 3"
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.
[edit dynamic-profiles profile-name routing-options access route "$junos-framed-route-ip-address-prefix] user@host# set tag2 $junos-framed-route-tag2
La variable prédéfinie $junos-framed-route-ip-address-prefix dérive également le préfixe d’adresse IPv4 de 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 pour permettre 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 : le routeur fonctionne toujours comme authentificateur. Lorsque vous configurez l’authentification PPP dans un profil dynamique, l’authentification CHAP prend en charge l’option challenge-length , qui vous permet de configurer la longueur minimale et la longueur maximale du message d’authentification CHAP. Ni l’authentification CHAP ni l’authentification PAP ne prennent en charge d’autres options de configuration, y compris l’instruction passive .
Les profils dynamiques pour les abonnés PPP sont pris en charge uniquement sur les interfaces PPPoE.
Pour configurer l’authentification dans un profil dynamique pour les interfaces d’abonné PPP :
Modification de la durée du défi CHAP
Vous pouvez modifier la longueur minimale et la longueur maximale par défaut du message d’authentification CHAP (Challenge Handshake Authentication Protocol) que le routeur envoie à un client PPP. Le message d’authentification 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 dans la plage de 8 octets à 63 octets.
Nous vous recommandons de configurer la longueur minimale et la longueur maximale du défi CHAP sur au moins 16 octets.
Avant de commencer :
Configurez le protocole CHAP sur l’interface.
Pour les interfaces abonné PPP dynamiques, consultez Configuration de l’authentification dynamique pour les abonnés PPP.
Pour les interfaces statiques avec encapsulation PPP, consultez Configuration du protocole d’authentification PPP Challenge Handshake.
Pour configurer la longueur minimale et maximale du message d’authentification CHAP :
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.
dynamic-profiles {
ppp-profile-1 {
interfaces {
pp0 {
unit "$junos-interface-unit";
}
}
}
}
Vérification et gestion de la configuration PPP pour la gestion des abonnés
Objet
Afficher ou effacer des informations sur la configuration PPP pour la gestion des abonnés.
Mesures à prendre
Pour afficher des informations sur les interfaces PPP :
user@host> show ppp interface
Pour afficher les informations statistiques PPP :
user@host> show ppp statistics
Pour afficher les informations récapitulatives de session PPP :
user@host> show ppp summary
Pour afficher les informations du pool d’adresses PPP :
user@host>show ppp address-pool
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.