Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Haute disponibilité pour les réseaux d’accès abonné

Cette rubrique présente la haute disponibilité des réseaux d’accès DHCP, L2TP et PPP.

ISSU unifié pour la haute disponibilité dans les réseaux d’accès abonné

Une mise à niveau logicielle en service unifiée (ISSU unifiée) vous permet d’effectuer une mise à niveau entre deux versions différentes de Junos OS sans interruption sur le plan de contrôle et avec une interruption minimale du trafic. Les routeurs conservent les sessions d’abonné actives et les services de session tout au long de la mise à niveau, de sorte qu’ils continuent une fois la mise à niveau terminée.

La fonctionnalité ISSU unifiée prend en charge les modèles d’accès PPPoE, DHCP et L2TP pour la gestion des abonnés. La prise en charge ISSU unifiée des modèles d’accès DHCP et L2TP a été ajoutée dans la version 14.1 de Junos OS.

  • Pour l’accès PPPoE statique et dynamique, ISSU unifié prend en charge les éléments suivants :

    • Connexions PPPoE terminées et non tunnelisées, configurées avec des interfaces logiques PPP statiques ou dynamiques et des interfaces sous-jacentes statiques ou dynamiques

    • Services d’abonnés sur des interfaces PPP à liaison unique

    • Conservation des statistiques pour la comptabilité, les filtres et les CoS sur les interfaces MPC/MIC

    Remarque :

    ISSU unifié pour la gestion des abonnés Le modèle d’accès PPPoE ne prend pas en charge les interfaces groupées MLPPP (Multilink Point-to-Point Protocol). Les interfaces d’offre groupée MLPPP nécessitent l’utilisation d’un PIC Adaptive Services ou d’un PIC Multiservices pour fournir des services d’abonné PPP. Ces PIC ne prennent pas en charge l’ISSU unifié.

  • Pour l’accès DHCP, la ISSU unifiée prend en charge les éléments suivants :

    • Serveur local DHCPv4, relais DHCPv4, serveur local DHCPv6, relais DHCPv6 et proxy de relais DHCP

    • Conservation des statistiques de comptabilité, de filtrage et de classe de service (CoS) pour les abonnés DHCP sur les interfaces MPC/MIC des routeurs MX Series

  • Pour l’accès L2TP, l’ISSU unifié prend en charge à la fois le LAC et le LNS. Lorsqu’une mise à niveau est lancée, le LAC termine toutes les négociations L2TP en cours, mais rejette toute nouvelle négociation jusqu’à ce que la mise à niveau soit terminée. Aucun nouveau tunnel ou session n’est établi pendant la mise à niveau. Les déconnexions des abonnés sont enregistrées pendant la mise à niveau et sont terminées une fois la mise à niveau terminée.

Consultez Prise en main de la mise à niveau unifiée des Logiciels en service pour obtenir une description des plates-formes et modules pris en charge, des instructions CLI et des procédures que vous utilisez pour configurer et lancer ISSU unifié. Vous pouvez utiliser l’indicateur issu avec l’instruction pour tracer les traceoptions événements ISSU unifiés de gestion des abonnés. Vous pouvez également utiliser la show system subscriber-management summary commande pour afficher des informations sur l’état ISSU unifié.

Vérification et surveillance de la gestion des abonnés État ISSU unifié

Objet

Affichez l’état de l’ISSU unifié pour les fonctionnalités de gestion des abonnés.

Mesures à prendre

Le premier exemple indique que la mise au repos du plan de contrôle dans le cadre d’un ISSU unifié n’est pas en cours (par exemple, un ISSU unifié n’a pas été démarré, s’est déjà terminé ou la requête du plan de contrôle n’a pas démarré). Le deuxième exemple montre qu’un ISSU unifié est en cours et qu’un démon de gestion d’abonné participant a besoin de 198 secondes pour mettre le plan de contrôle au repos.

Basculement du moteur de routage gracieux pour les réseaux d’accès des abonnés

La fonctionnalité GRES (Graceful moteur de routage switchover) de Junos OS permet à un routeur avec des moteurs de routage redondants de continuer à transférer des paquets, même si l’un d’moteur de routage tombe en panne. GRES préserve les informations sur l’interface et le noyau. Le trafic n’est pas interrompu. Cependant, GRES ne préserve pas le plan de contrôle.

Pour activer la prise en charge GRES sur les routeurs MX Series, incluez l’instruction graceful-switchover au niveau de la [edit chassis redundancy] hiérarchie.

DHCP

Pour les routeurs MX Series, le serveur local DHCP étendu et les applications de l’agent de relais DHCP conservent tous deux l’état des baux de client DHCP actifs dans la base de données de session. L’application DHCP étendue peut récupérer cet état si le processus DHCP échoue ou est redémarré manuellement, empêchant ainsi la perte de clients DHCP actifs dans l’une ou l’autre de ces circonstances. Toutefois, l’état des baux de client DHCP actifs est perdu en cas de panne de courant ou si le noyau cesse de fonctionner (par exemple, lorsque le routeur est rechargé) sur un seul moteur de routage.

Vous ne pouvez pas désactiver la prise en charge du basculement du moteur de routage gracieux pour l’application DHCP étendue lorsque le routeur est configuré pour prendre en charge le basculement du moteur de routage gracieux.

Pour plus d’informations sur l’utilisation du basculement du moteur de routage gracieux, consultez Présentation du basculement du moteur de routage gracieux.

L2TP

GRES est pris en charge sur les routeurs MX Series agissant comme L2TP LAC ou LNS. Dans le cas où L2TP (jl2tpd, le processus de périphérie universel L2TP) redémarre ou si le routeur bascule du moteur de routage (RE) actif vers le RE de secours, L2TP GRES s’assure que ce qui suit se produit :

  • Le LAC et le LNS récupèrent les destinations, les tunnels et les sessions qui étaient déjà établis au moment de la défaillance ou du redémarrage.

  • Le LAC et le LNS répondent aux demandes de keepalive de tunnel reçues lors du basculement pour les tunnels établis, mais ne génèrent aucun keepalive tant que le basculement n’est pas terminé.

  • Le LAC et le LNS suppriment tous les tunnels et sessions qui ne sont pas à l’état Établi.

  • Le LAC et le LNS rejettent les demandes de création de tunnels et de sessions.

  • Le LAC et le LNS envoient une autre notification de déconnexion à l’homologue pour les sessions et les tunnels qui sont déjà à l’état Déconnexion au moment de l’échec ou du redémarrage. Pour les sessions et les tunnels qui arrivaient à ce moment-là, le LAC et le LNS envoient une notification de déconnexion à l’homologue.

  • Le LAC et le LNS redémarrent les minuteries pendant toute la durée du délai d’attente pour les destinations, tunnels et sessions L2TP récupérés.

Si un basculement GRES (Graceful moteur de routage switchover) est déclenché par une commande en mode opérationnel, l’état des interfaces de services agrégés (ASI) n’est pas conservé. Par exemple :

Toutefois, si GRES est déclenché par une validation CLI ou un redémarrage ou un blocage FPC, le moteur de routage de secours met à jour l’état ASI. Par exemple :

Ou :

Minimisez les pertes de trafic dues à la suppression de routes obsolètes après un basculement harmonieux du moteur de routage

Lors d’un basculement GRES ( Graceful moteur de routage switchover ), les routes d’accès et les routes internes à l’accès pour la gestion des abonné DHCP et PPP peuvent devenir obsolètes. Après le GRES, le routeur supprime toutes ces routes obsolètes de la table de transfert. Une partie du trafic est perdue si les routes obsolètes sont supprimées avant d’être réinstallées.

Dans les réseaux d’abonnés sur lesquels des protocoles de redémarrage fluide et de routage tels que BGP et OSPF sont configurés, le routeur purge toutes les routes d’accès obsolètes et internes restantes dès que l’opération de redémarrage progressif est terminée, ce qui peut se produire très peu de temps après la fin du basculement du moteur de routage gracieux.

Dans les réseaux d’abonnés avec un routage actif ininterrompu (NSR) et des protocoles de routage tels que BGP et OSPF configurés, le processus de protocole de routage (rpd) purge immédiatement les routes d’accès obsolètes et les routes internes d’accès qui correspondent aux routes d’abonné.

Vous pouvez réduire le risque de cette perte de trafic en configurant le routeur pour retarder la suppression des routes obsolètes après un GRES. Le délai est de 180 secondes (3 minutes) non configurable. Le routeur conserve les routes obsolètes pendant toute la durée de la période, ce qui est suffisamment long pour que le processus client DHCP (jdhcpd), le processus client PPP (jpppd) ou le processus de protocole de routage (rpd) réinstalle les routes d’accès et les routes internes à l’accès avant que le routeur supprime les routes obsolètes de la table de transfert. Le risque de perte de trafic est réduit car le routeur dispose toujours de routes d’abonné disponibles pour les abonnés DHCP et les abonnés PPP.

Pour configurer le routeur afin de retarder la suppression (rinçage) des routes d’accès et des routes internes d’accès après un basculement gracieux du moteur de routage :

  1. Spécifiez que vous souhaitez configurer la gestion des abonnés.
  2. Configurez le routeur pour qu’il attende 180 secondes avant de supprimer les routes d’accès et les routes internes d’accès après un basculement gracieux du moteur de routage.

Documentation connexe

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
14.1
La prise en charge ISSU unifiée des modèles d’accès DHCP et L2TP a été ajoutée dans la version 14.1 de Junos OS.