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 des abonnés

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

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

Une mise à niveau logicielle unifiée en service (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 un minimum de perturbation 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 se poursuivent 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 Junos OS version 14.1.

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

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

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

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

    Note:

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

  • Pour l’accès DHCP, ISSU unifié 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, ISSU unifié prend en charge à la fois le LAC et le LNS. Lorsqu’une mise à niveau est lancée, le BAC termine toutes les négociations L2TP en cours, mais rejette toute nouvelle négociation tant que la mise à niveau n’est pas 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.

Reportez-vous à la section Prise en main de la mise à niveau logicielle unifiée 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 l’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é

But

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

Action

Le premier exemple indique que la mise au repos du plan de contrôle dans le cadre d’ISSU unifié n’est pas en cours (par exemple, l’ISSU unifié n’a pas été démarré, 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 des abonnés participant a besoin de 198 secondes pour mettre le plan de contrôle au repos.

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

La fonction GRES (Graceful Routing Engine Switchover ) de Junos OS permet à un routeur doté de moteurs de routage redondants de continuer à transférer des paquets, même en cas de défaillance d’un moteur de routage. GRES préserve les informations sur l’interface et le noyau. Le trafic n’est pas interrompu. Toutefois, GRES ne préserve pas le plan de contrôle.

Pour activer la prise en charge de 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 clients 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, évitant ainsi la perte de clients DHCP actifs dans l’une ou l’autre de ces circonstances. Toutefois, l’état des baux clients DHCP actifs est perdu si une panne de courant se produit 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 Graceful Routing Engine pour l’application DHCP étendue lorsque le routeur est configuré pour prendre en charge le basculement Graceful Routing Engine.

Pour plus d’informations sur l’utilisation du basculement Graceful Routing Engine, consultez Présentation du basculement Graceful Routing Engine.

L2TP

GRES est pris en charge sur les routeurs MX Series agissant comme L2TP LAC ou LNS. En cas de redémarrage de L2TP (jl2tpd, processus de périphérie universelle L2TP) ou de basculement du routeur du moteur de routage actif (RE) vers le RE de secours, L2TP GRES garantit que les événements suivants se produisent :

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

  • Le LAC et le LNS répondent aux demandes de keepalive de tunnel reçues pendant le basculement pour les tunnels établis, mais ne génèrent aucun keepalife 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.

  • BAC et le LNS rejettent les demandes de création de nouveaux tunnels et 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 la défaillance 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.

  • Les minuteurs de redémarrage LAC et LNS pour la période d’expiration complète des destinations, tunnels et sessions L2TP récupérés.

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

Toutefois, si GRES est déclenché par un commit 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 des routes périmées après un basculement progressif du moteur de routage

Lors d’un basculement GRES (Graceful Routing Engine Switchover ), les routes d’accès et les routes internes d’accès pour la gestion des abonnés 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 qu’elles ne soient réinstallées.

Dans les réseaux d’abonnés sur lesquels les protocoles de redémarrage progressif et de routage tels que BGP et OSPF sont configurés, le routeur purge toutes les routes d’accès obsolètes restantes et les routes internes d’accès 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 non-stop (NSR) et des protocoles de routage tels que BGP et OSPF configurés, le processus RPD (Routing Protocol Process) purge immédiatement les routes d’accès obsolètes et les routes internes d’accès qui correspondent aux routes abonnés.

Vous pouvez réduire le risque de 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, qui est suffisamment longue 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 d’accès avant que le routeur ne supprime les routes obsolètes de la table de transfert. Le risque de perte de trafic est minimisé car le routeur dispose toujours de routes d’abonnés disponibles pour les abonnés DHCP et PPP.

Pour configurer le routeur de manière à retarder la suppression (vidage) des routes d’accès et des routes internes d’accès après un basculement progressif 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 progressif du moteur de routage.

Documentation connexe

Tableau de l’historique des versions
Libération
Description
14.1
La prise en charge ISSU unifiée des modèles d’accès DHCP et L2TP a été ajoutée dans Junos OS version 14.1.