Présentation de la vente en gros de couche 2 avec VLAN déclenchés par ANCP

Autorisation RADIUS pour les VLAN déclenchés par ANCP

Lorsqu’un abonné se connecte, le message de demande d’accès envoyé au serveur RADIUS inclut un nom d’utilisateur et, éventuellement, un mot de passe généré localement sur le routeur. Vous pouvez configurer le routeur pour créer un nom d’utilisateur unique avec la valeur des TLV ANCP (Access-Loop-Circuit-ID, Access-Loop-Remote-Id ou les deux) tel que reçu dans le message ANCP Port Up du nœud d’accès. Par ailleurs, si vous configurez le routeur pour transmettre des attributs de boucle d’accès ANCP en tant que VSA Juniper Networks (dans ce cas Acc-Loop-Cir-Id (26-110) et Acc-Loop-Remote-Id (26-182), le message Access-Request inclut suffisamment d’informations uniques sur la ligne d’accès pour que le serveur RADIUS puisse déterminer si la boucle d’accès est vendue en gros à un détaillant ou conservée pour le grossiste.

Le serveur RADIUS répond à la demande d’accès par l’un des messages suivants :

• Accès-Acceptation : dans ce cas, le VLAN déclenché par le message Port Up est vendu en gros à un NSP de détail. L’autorisation est similaire à celle des sessions PPPoE. L’acceptabilité d’accès inclut le VSA de routeur virtuel (26-1) avec une valeur qui correspond à l’instance de routage unique et non par défaut du NSP. Le message peut éventuellement inclure des services client, tels que des attributs pour le CoS paramétré, des filtres de pare-feu et des stratégies pour l’interface logique, ainsi que des activations de service de couche 2.

• Access-Reject : dans ce cas, soit le VLAN déclenché par le message Port Up est l’un des abonnés du grossiste, soit RADIUS refuse d’accorder l’accès au réseau. Dans les deux cas, l’entrée VLAN est supprimée de la SDB ANCP. À moins qu’un message Port Down ne soit reçu en premier, le routeur ignore les messages Port Up suivants pour cet abonné. Cependant, la détection automatique VLAN empilée dynamique conventionnelle peut être initiée par la négociation de protocoles d’accès, telle que PPPoE.

Instanciation d’un VLAN dynamique déclenché par ANCP et détecté automatiquement

Lorsque le serveur RADIUS renvoie un message d’accès-acceptation, le profil dynamique affecté à la plage de VLAN détectée automatiquement est instancié avec les résultats suivants :

1. L’interface logique VLAN dynamique qui représente le service de vente en gros de couche 2 au sein de l’instance de routage unique du NSP est créée.

2. Une interface physique orientée cœur est sélectionnée par une méthode de répartition pondérée de la charge parmi l’ensemble d’interfaces éligibles attribuées à l’instance de routage du NSP. Une interface physique est éligible lorsqu’elle est opérationnelle et qu’au moins une balise VLAN peut être attribuée.

3. La balise VLAN externe orientée accès et détectée automatiquement est mappée à une balise VLAN interne unique. La balise VLAN externe est dérivée du TLV Access-Aggregation-Circuit-ID-Binary transporté dans le message ANCP Port Up. La balise VLAN interne est allouée à partir de la plage de VLAN configurée pour l’interface physique centrale.

4. La balise VLAN interne est remplacée par la balise VLAN externe lorsque le trafic d’abonné est tunnelisé vers le NSP. Dans le profil dynamique, la balise VLAN interne est fournie par la variable prédéfinie, $junos-inner-vlan-map-id.

5. La balise VLAN externe détectée automatiquement est échangée avec la balise VLAN interne lorsque les paquets en aval du NSP (qui incluent la balise VLAN interne allouée) sont transférés à l’abonné.

   Vous pouvez configurer chaque interface physique orientée cœur avec une plage allant jusqu’à 4 094 ID de VLAN. La plage d’échange VLAN interne est affectée à l’interface physique localement. Cela signifie que les plages de VLAN internes de différentes interfaces physiques peuvent se chevaucher complètement, partiellement ou pas du tout.

6. Si vous le souhaitez, avant que les paquets d’abonné ne soient transférés à un fournisseur de services réseau, l’identificateur de protocole de balise VLAN (TPID) externe des paquets d’abonné peut être remplacé par un TPID pour répondre aux exigences d’un fournisseur de services réseau (NSP) individuel. Dans ce cas, la valeur d’origine est échangée avec le TPID NSP pour les paquets transférés à l’abonné.

7. Une balise VLAN supplémentaire, l’ID de VLAN trunk, est utilisée en interne pour identifier l’interface physique principale provisionnée afin que le trafic d’abonné puisse être tunnelisé vers l’interface allouée. Dans le profil dynamique, cet ID est fourni par la variable prédéfinie, $junos-vlan-map-id. Cet identifiant permet de différencier plusieurs interfaces physiques trunk orientées cœur pour un même NSP.

8. Tous les services client, tels que les filtres CoS ou de pare-feu, sont appliqués à la session de l’abonné. Ces services sont spécifiés de manière facultative dans la configuration RADIUS et transmis dans le message RADIUS en tant que VSA Juniper Networks.

9. La session VLAN est activée après la création et la configuration de l’interface logique pour la session VLAN dynamique. L’activation de la session déclenche un message de démarrage de la comptabilité RADIUS. Tous les services reçus de RADIUS lors de l’autorisation sont désormais activés.

10. Une fois le VLAN dynamique créé, les messages ANCP Port Up suivants n’entraînent pas de nouvelle autorisation de la session du VLAN dynamique. Au lieu de cela, lorsque l’agent ANCP reçoit un autre message Port Up pour la boucle d’accès, il met à jour la SDB ANCP avec toute modification des attributs ANCP.

Équilibrage de charge pondéré pour les sessions d’abonnés sur les interfaces physiques centrales éligibles

Le routeur utilise une répartition pondérée de la charge au lieu d’une distribution circulaire pour attribuer des sessions d’abonnés de vente en gros de couche 2 sur plusieurs interfaces physiques orientées vers le cœur en fonction du poids de l’interface. Le poids d’une interface est corrélé au nombre de balises VLAN disponibles dans les plages d’échange d’ID de VLAN internes (orientées vers le cœur) agrégées de l’interface.

La façon dont vous configurez les plages d’échange d’ID de VLAN internes détermine la pondération relative des interfaces :

• L’interface avec le plus grand nombre de balises d’ID VLAN internes disponibles a le poids le plus élevé.

• L’interface avec le deuxième plus grand nombre de balises a le poids le plus élevé, et ainsi de suite.

• L’interface avec le plus petit nombre de balises disponibles a le poids le plus faible.

L’utilisation des balises d’ID de VLAN internes disponibles dans les plages d’échange plutôt que des balises VLAN totales agrégées signifie que les pondérations relatives des interfaces sont plus dynamiques. Le mécanisme de répartition pondérée de la charge peut répondre plus rapidement aux déconnexions d’abonnés, à la migration de la propriété des abonnés d’un grossiste à un détaillant et d’un détaillant à un grossiste, aux transitions d’état d’interface physique de cœur (y compris le déplacement vers les interfaces de cœur de réseau éligibles restantes lorsqu’un état d’interface passe de Haut à Bas) et aux défaillances de l’une des interfaces physiques de cœur de réseau. Lorsqu’une interface se rétablit (transitions de bas en haut), la répartition pondérée de la charge favorise généralement cette interface pour les sessions en attente ou pour les nouvelles sessions de vente en gros de couche 2 qui se produisent par la suite.

Avec la répartition pondérée de la charge, le routeur sélectionne les interfaces de manière aléatoire, mais les sessions sont réparties entre les interfaces proportionnellement en fonction du poids des interfaces. Le routeur génère un nombre aléatoire dans une plage égal au total agrégé de toutes les balises d’ID VLAN internes disponibles à partir des plages de permutation de toutes les interfaces physiques orientées vers le cœur. Le routeur associe ensuite une partie de la plage (un pool de nombres) à chaque interface proportionnellement à son poids. Une interface avec une pondération plus élevée est associée à une plus grande partie de la plage (un pool plus important) qu’une interface avec une pondération plus faible. Une interface est sélectionnée lorsque le nombre aléatoire se trouve dans son pool de nombres associé. Le nombre aléatoire est plus susceptible, en moyenne, de se trouver dans un pool plus grand, de sorte qu’une interface avec une pondération plus élevée (pool plus grand) est plus susceptible d’être sélectionnée qu’une interface avec un poids plus faible (pool plus petit).

Prenons l’exemple de deux interfaces physiques orientées vers le cœur, IFD1 et IFD2. En se basant sur les plages d’échange d’ID de VLAN internes configurées pour ces deux interfaces, IFD1 dispose de 1000 balises VLAN disponibles et IFD2 n’en a que 500. Les sessions d’abonnés sont réparties de manière aléatoire sur les deux interfaces en fonction de leur poids relatif ; L’IFD1 a un poids plus élevé que l’IFD2. Étant donné que l’IFD1 a deux fois plus de balises disponibles que l’IFD2, le pool de numéros associés à l’IFD1 est également deux fois plus élevé que pour l’IFD2. Le nombre aléatoire généré par le routeur a deux fois plus de chances de se trouver dans le pool pour IFD1 que pour IFD2. Par conséquent, IFD1 est favorisé 2:1 par rapport à IFD2, et les sessions d’abonnés ont deux fois plus de chances d’être attribuées à IFD1 qu’à IFD2.

Mises à jour comptables intermédiaires de RADIUS

Les rapports comptables intermédiaires envoyés à l’AAA pour les VLAN dynamiques hors bande déclenchés et à détection automatique sont pris en charge de la même manière que pour les VLAN conventionnels à détection automatique, dynamiques et autorisés ou les sessions client (telles que les sessions PPPoE). L’agent ANCP envoie une notification à AAA lorsqu’il reçoit une mise à jour du nœud d’accès. Par défaut, AAA ne signale la mise à jour au serveur RADIUS qu’à l’intervalle configuré.

Vous pouvez configurer l’agent ANCP de sorte que lorsqu’il notifie AAA, un message de demande de comptabilité de mise à jour provisoire soit immédiatement envoyé au serveur RADIUS. Des mises à jour comptables intermédiaires immédiates peuvent être envoyées pour une session VLAN dynamique déclenchée par ANCP uniquement lorsqu’une modification de certains attributs ANCP clés de la ligne d’accès associée peut influencer le comportement du système. Pour éviter une charge supplémentaire sur le serveur RADIUS pour les modifications apportées aux attributs ANCP moins critiques, les modifications apportées aux autres attributs ANCP ne déclenchent pas de messages accounting-interim-update immédiats. Au lieu de cela, ces modifications sont signalées dans le prochain message Accounting-Interim-Update.

Des mises à jour comptables intermédiaires immédiates peuvent être envoyées pour les modifications apportées à l’un des attributs ANCP suivants pour une session existante correspondant à la ligne d’accès (en fonction du TLV Access-Loop-Circuit-ID) :

• Actual-Net-Data-Rate-Upstream : lorsque le débit en amont calculé (ajusté) entraîne une modification de cet attribut, le message de comptabilité signale l’attribut dans le VSA Act-Data-Rate-Up de Juniper Networks (26-113). Le changement de vitesse calculé est rapporté dans le VSA Upstream-Calculated-QoS-Rate (26-142).

• Actual-Net-Data-Rate-Downstream : lorsque le débit en aval calculé (ajusté) entraîne une modification de cet attribut, le message de comptabilité indique l’attribut dans la VSA Act-Data-Rate-Dn de Juniper Networks (26-114). Le changement de vitesse calculé est rapporté dans le VSA Downstream-Calculated-QoS-Rate (26-141).

Lorsque l’instruction ancp-speed-change-immediate-update est configurée au niveau de la [edit access profile profile-name accounting] hiérarchie, des mises à jour comptables intermédiaires immédiates de RADIUS sont envoyées pour les modifications apportées aux TLV Actual-Net-Data-Rate-Upstream et Actual-Net-Data-Rate-Aval.

Lorsqu’en plus l’instruction auto-configure-trigger interface interface-name est configurée au niveau de la [edit protocols ancp neighbor ip-address] hiérarchie, des mises à jour comptables intermédiaires immédiates sont également envoyées pour les modifications apportées aux TLV Access-Loop-Remote-ID et Access-Aggregation-Circuit-ID-Binary.

Pour plus d’informations sur les mises à jour comptables intermédiaires immédiates de RADIUS, consultez Configuration des mises à jour comptables intermédiaires immédiates de RADIUS en réponse aux notifications ANCP.

Suppression du service wholesale de couche 2

L’un des événements suivants peut supprimer l’interface logique du VLAN dynamique qui représente le service d’accès fourni par le grossiste de couche 2 :

• Réception d’un message ANCP Port Down pour la boucle d’accès correspondante. Les mêmes attributs ANCP qui initient la création de VLAN dynamiques initient également la destruction de VLAN dynamique.

  Aucune action n’est entreprise pour un message ANCP Port Down pour lequel l’une des conditions suivantes est vraie :

  • Il n’existe aucune session d’abonné correspondante.

  • Une session d’abonné correspondante est présente, mais est en cours de suppression.

  • Le message fait référence à une session conventionnelle à détection automatique (qui est supprimée par le traitement normal du protocole).

• Réinitialisation explicite de la connexion entre l’agent ANCP et le nœud d’accès, ce qui déclenche une déconnexion massive de toutes les sessions VLAN dynamiques affectées qui prennent en charge les connexions d’accès de couche 2 vendues en gros. Les sessions pour les propres abonnés du grossiste ne sont pas affectées.

• Suppression ou transition vers un état d’arrêt opérationnel de l’interface physique orientée abonné ou de l’interface physique orientée cœur.

• La perte de contiguïté entre le voisin et l’agent ANCP.

• Émission de la clear auto-configuration interfaces commande de déconnexion du VLAN ou de la clear ancp access-loop commande visant à forcer la réinitialisation d’un abonné.

• Réception d’un message de déconnexion initié par RADIUS.

L’un de ces événements désactive également la session d’abonné pour empêcher de futures activations de service et émet un message d’arrêt de comptabilité RADIUS pour les services associés et pour la session d’abonné VLAN dynamique. Le profil dynamique est ensuite instancié pour supprimer d’abord l’interface logique du VLAN dynamique, puis l’entrée de session correspondante dans la SDB VLAN.

Vous pouvez surveiller le nombre de sessions d’abonnés interconnectés de couche 2 par port. Utilisez la show subscribers summary port extensive commande pour afficher le nombre d’abonnés par port par type de client (VLAN-OOB) et type de connexion (Corss-connected). En outre, l’ID d’objet jnxSubscriberPortL2CrossConnectCounter dans la table jnxSubscriberPortCountTable de la MIB d’abonnés spécifique à l’entreprise de Juniper Networks affiche le nombre de sessions d’abonnés interconnectés de couche 2 sur les ports qui ont des sessions actives.

Interactions entre la détection automatique des VLAN intrabande et hors bande

L’implémentation de la vente en gros de couche 2 déclenchée par ANCP convient à la fois aux abonnés vendus en gros à un détaillant et aux abonnés appartenant au grossiste. Toute session d’abonné détectée sur l’interface physique orientée accès peut être l’une ou l’autre. Cela signifie qu’il existe un chevauchement entre la plage de balises externe pour les VLAN hors bande à détection automatique et celle pour les VLAN intrabandes, détectés automatiquement et empilés.

Une session PPPoE et une session wholesale peuvent être tentées pour la même boucle d’accès. Pour éviter la charge indésirable qui peut s’ensuivre sur le routeur et le serveur RADIUS, l’ordre de négociation des sessions est déterminé par l’ordre dans lequel les paquets (message PPPoE PADI ou ANCP Port Up) sont reçus pour la même interface physique d’accès et la même balise externe VLAN.

La séquence d’événements suivante se produit lorsqu’un paquet PADI PPPoE est reçu sur un canal de contrôle intrabande avant qu’un message ANCP Port Up ne soit reçu sur un canal de contrôle hors bande, pour la même boucle d’accès :

1. Le reçu PADI déclenche la création d’une interface logique VLAN empilée dynamique. Des négociations sur les PPPoE et les PPP sont en cours.

2. Le message ANCP Port-Up est reçu pour la boucle d’accès. Étant donné que l’interface logique VLAN intrabande correspondante existe déjà pour la même interface physique orientée accès et la même balise VLAN externe, l’agent ANCP stocke simplement les attributs de la ligne d’accès ANCP et le nom de l’interface physique dans la base de données de session. L’agent n’entreprend aucune autre action pour le message tant que la session PPP (interface logique PPP et interface logique VLAN dynamique sous-jacente) est maintenue.

3. La négociation PPP se termine en raison d’un échec d’authentification (réponse RADIUS Access-Reject) ou d’une déconnexion normale, ce qui déclenche le nettoyage de la session PPP et la suppression de l’interface logique PPP.

4. Étant donné que l’instruction remove-when-no-subscribers est configurée, la suppression de l’interface logique PPP entraîne la suppression du VLAN empilé dynamique.

5. L’événement suivant dépend de la tentative d’autorisation du message ANCP Port Up auparavant.

   • Si l’autorisation n’a pas été tentée auparavant :

     1. Une session SDB VLAN-OOB est créée et l’autorisation de la boucle d’accès est initiée.

     2. Tous les paquets PADI PPPoE faisant l’objet d’exceptions reçus par la détection automatique d’un VLAN intrabande sont ignorés jusqu’à ce que RADIUS réponde à la demande d’autorisation.

     3. Le résultat de l’autorisation détermine la suite des étapes suivantes :

        • Si l’autorisation réussit (RADIUS renvoie un message d’accès-acceptation), une interface logique dynamique de vente en gros de couche 2 est créée dans l’instance de routage du fournisseur de services de distribution (NSP).

        • Si l’autorisation échoue (RADIUS renvoie un message Access-Reject), la session VLAN-OOB est nettoyée. Le traitement reprend pour tous les paquets PADI PPPoE exceptionnels qui sont ensuite reçus par la détection automatique VLAN intrabande.

   • Si l’autorisation a déjà été tentée, aucune action n’est entreprise, car l’échec de la négociation de session PPP est supposé être un échec de connexion en dehors du contexte de vente en gros de couche 2. Ce comportement empêche les autorisations inutiles en réponse au message ANCP Port-Up chaque fois qu’une session PPPoE se termine et se nettoie à partir d’une déconnexion normale d’abonné.

La séquence d’événements suivante se produit lorsqu’un message ANCP Port Up est reçu sur un canal de contrôle hors bande avant qu’un paquet PADI PPPoE pour une boucle d’accès ne soit reçu sur un canal de contrôle intrabande, tous deux pour la même boucle d’accès :

1. La réception du message ANCP Port Up déclenche l’autorisation de la boucle d’accès.

2. Un paquet PADI PPPoE est reçu. Le paquet est ignoré, car l’autorisation est déjà en cours pour la même interface physique d’accès et la même balise VLAN externe.

3. Le résultat de l’autorisation détermine la suite des étapes suivantes :

   • Si l’autorisation réussit (RADIUS renvoie un message d’accès-acceptation), représenté par une session VLAN-OOB dans la SDB, la création dynamique de l’interface logique VLAN est lancée pour une session de vente en gros de couche 2. Lorsque l’interface est créée, les paquets PADI PPPoE suivants détectés par la détection automatique VLAN intrabande sont ignorés et ne font plus l’objet d’exceptions.

   • En cas d’échec de l’autorisation (RADIUS renvoie un message Access-Reject), la session VLAN-OOB est nettoyée.

     1. La réception d’un paquet PADI PPPoE ultérieur initie la création d’un VLAN empilé dynamique.

     2. Les négociations PPPoE et PPP ont lieu et les événements se déroulent comme d’habitude pour un VLAN conventionnel à détection automatique dynamique.

Migration de la propriété des abonnés du grossiste au détaillant

Les abonnés appartenant à des grossistes sont connectés au moyen d’interfaces PPPoE dynamiques sur des VLAN dynamiques. Pour chaque abonné, la session PPPoE doit être déconnectée et l’interface logique PPP correspondante supprimée avant que les messages ANCP Port Up pour la même interface physique sous-jacente et la même balise externe VLAN puissent servir de déclencheurs hors bande pour la détection automatique dynamique des VLAN.

Une approche pour migrer de la vente en gros à la propriété au détail consiste à effectuer les opérations suivantes :

1. Mettre à jour la base de données du serveur RADIUS afin que l’authentification des abonnés pour les lignes d’accès concernées entraîne une réponse RADIUS Access-Reject. Cela provoque l’échec des tentatives ultérieures de négociation PPPoE pour la ligne d’accès.

2. Initier la déconnexion des sessions PPPoE dynamiques ; par exemple, en émettant une déconnexion initiée par RADIUS. Cela déclenche le nettoyage de l’interface logique PPPoE et des services associés, ce qui inclut l’émission de messages RADIUS Accounting-Stop pour les services de session et actifs, ainsi que la suppression de l’interface logique PPPoE dynamique.

   Si la migration nécessite le remplacement du périphérique CPE actuel par un autre et que la session PPPoE n’est pas déconnectée sans autorisation, la désactivation du CPE entraîne un échec de maintien PPP sur le routeur et déclenche la déconnexion de session.

3. Supprimez l’interface logique VLAN dynamique sous-jacente. Cela se produit automatiquement lorsque l’instruction remove-when-no-subscribers est incluse au niveau de la [edit interfaces interface-name auto-configure] hiérarchie de l’interface physique orientée accès. Sinon, exécutez la clear auto-configuration interfaces interface-name commande pour supprimer l’interface logique du VLAN dynamique.

4. Déclenchez une notification Port Up pour lancer la détection, l’autorisation et la création dynamiques de VLAN par l’une des méthodes suivantes :

   • Mettez le CPE sous tension, avec un délai suffisant entre la mise hors tension et la remise sous tension de l’appareil, de sorte qu’un message Port Down soit envoyé, suivi d’un message Port Up et que le routeur dispose de suffisamment de temps pour détecter une défaillance de keepalive indiquant la perte de la session.

   • Lancez une clear ancp access-loop commande.

   • Lancez une request ancp oam port-up commande.

Migration de la propriété des abonnés du détaillant au grossiste

Une approche pour migrer de la vente au détail à la vente en gros consiste à effectuer les opérations suivantes :

1. Mettre à jour la base de données du serveur RADIUS afin que l’autorisation VLAN dynamique pour les lignes d’accès concernées entraîne une réponse d’accès-rejet RADIUS. Cela entraîne l’ignorance des messages ANCP Port Up suivants.

2. Initier la déconnexion des sessions VLAN dynamiques prenant en charge le service d’accès de vente en gros ; par exemple, en émettant une déconnexion initiée par RADIUS. Cela déclenche le nettoyage de la session, qui comprend l’émission de messages RADIUS Accounting-Stop pour la session, la suppression de l’interface logique VLAN dynamique et des services actifs, et la libération de la balise VLAN interne allouée associée à l’interface physique orientée cœur pour l’affectation à une autre session d’abonné de vente en gros de couche 2.

   Si la migration nécessite de remplacer le périphérique CPE actuel par un autre, la désactivation du CPE entraîne un message ANCP Port Down qui déclenche la déconnexion et le nettoyage de la session.

3. Permettre aux abonnés de se connecter au réseau du grossiste à l’aide de la détection automatique VLAN dynamique classique, suivie de négociations PPPoE et PPP et de la création d’interfaces logiques PPP.

Migration de la propriété des abonnés entre les marchands

En règle générale, vous migrez l’accès entre les détaillants NSP en déclenchant un redémarrage de la session VLAN dynamique existante. Le redémarrage déclenche une déconnexion de la session, suivie d’une détection, d’une autorisation et d’une création dynamiques immédiates de VLAN dans l’instance de routage correspondant au nouveau NSP. Un redémarrage est une séquence logique de ports descendants et actifs pour la boucle d’accès correspondante du VLAN. Vous pouvez utiliser l’une des méthodes suivantes pour redémarrer une interface logique de VLAN dynamique donnée :

• Lancez un message de demande de déconnexion RADIUS ou configurez votre serveur RADIUS pour envoyer le message. L’attribut Acct-Terminate-Cause RADIUS du message (49) doit être défini sur la valeur 16 (rappel). Cette cause est traitée comme une déconnexion (déconnexion) suivie immédiatement d’une reconnexion (connexion) uniquement pour les VLAN dynamiques créés par un message ANCP Port Up. Les autres clients réagissent à cette valeur avec seulement une déconnexion.

• Incluez l’option reconnect lorsque vous déconnectez les abonnés à l’aide de la clear network-access aaa subscriber commande. Vous pouvez spécifier les abonnés par l’identifiant de session ou le nom d’utilisateur. Cette option tente de reconnecter une session effacée en tant que session de vente en gros de couche 2 lorsque la session d’abonné a été entièrement déconnectée. Ce comportement équivaut à émettre une déconnexion initiée par RADIUS configurée pour la reconnexion ; c’est-à-dire lorsque le message inclut Acct-Terminate-Cause (attribut RADIUS 49) avec une valeur de rappel (16).

• Déclenchez un message Port Inactif suivi d’un message Port UP par l’une des méthodes suivantes :

  • Mettez le CPE sous tension, avec un délai suffisant entre la mise hors tension et la remise sous tension de l’appareil, de sorte qu’un message Port Down soit envoyé, suivi d’un message Port Up et que le routeur dispose de suffisamment de temps pour détecter une défaillance de keepalive indiquant la perte de la session.

  • Lancez une clear ancp access-loop commande.

Modification de l’identifiant de ligne d’accès ou de l’identifiant de VLAN de port

Lorsque l’identificateur de ligne ou l’identificateur VLAN de port d’une boucle d’accès est modifié, le nœud d’accès signale la modification dans un message Port Up à l’agent ANCP. Le message transmet l’ID de ligne dans le TLV Access-Loop-Remote-ID et l’ID de VLAN de port dans le TLV Access-Aggregation-Circuit-ID-Binary.

Le nœud d’accès doit envoyer un message Port Down pour la boucle d’accès avant de modifier l’un des attributs d’identification d’une session existante. Le message Port Down déclenche le nettoyage de la session de vente en gros de couche 2 correspondante. Si le nœud d’accès n’envoie pas de port inactif dans ce cas, le comportement suivant a le même effet que l’insertion du message Port inactif indiquant que le nœud d’accès n’a pas pu envoyer :

• Pour une modification d’ID de ligne, l’agent ANCP traite la reconfiguration comme un message logique Port Down pour la ligne d’accès identifiée par l’Access-Loop-Remote-Id précédent, suivi d’un message Port Up pour la ligne d’accès identifiée par le nouvel Access-Loop-Remote-Id.

• Pour une modification de l’ID VLAN de port, l’agent ANCP traite la reconfiguration comme un message logique Port Down pour la ligne d’accès identifiée par le précédent Access-Aggregation-Circuit-Id-Binary, suivi d’un message Port Up pour la ligne d’accès identifiée par le nouveau Access-Aggregation-Circuit-Id-Binary.

Dans les deux cas, l’agent ANCP notifie le démon d’autoconfiguration (autoconfd), qui effectue les actions suivantes :

1. Déconnecte la session de vente en gros de couche 2 correspondante.

2. Envoie un message RADIUS Accounting-Stop avec les statistiques finales des sessions de service et des sessions client associées.

3. Supprime l’interface logique VLAN dynamique.

4. Tente de rétablir la session de vente en gros de couche 2 au moyen d’une séquence de connexion, y compris l’authentification, la création de l’interface logique VLAN dynamique, l’activation de tous les services et, en cas de succès, l’envoi de messages de démarrage de comptabilité RADIUS pour les sessions service et client.

Vous devez vous déconnecter manuellement de toute session PPPoE correspondant à la ligne d’accès avec les identifiants précédents, même si le nœud d’accès envoie le message Port Down approprié lorsque les valeurs changent.

Déconnexion des sessions PPPoE et tentative automatique de reconnexion en tant que sessions wholesale de couche 2

Vous pouvez utiliser les messages de déconnexion initiés par RADIUS pour déconnecter et déconnecter des sessions PPPoE existantes et tenter de les rétablir en tant que sessions de vente en gros de couche 2. Utilisez des messages de rejet d’accès pour empêcher l’accès des abonnés PPPoE et tenter de vous reconnecter en tant que session de vente en gros de couche 2. Utilisez cette fonctionnalité lorsque vous souhaitez migrer des sessions de PPPoE vers la vente en gros de couche 2. Le message de déconnexion et de rejet initié par RADIUS doit inclure Acct-Terminate-Cause (attribut RADIUS 49) avec une valeur de rappel (16) ; callback provoque la tentative de reconnexion. L’instruction remove-when-no-subscribers doit être configurée sur l’interface physique sous-jacente.

1. Le comportement initial des messages est le suivant :

   • Message d’accès-rejet : lorsqu’un PADI PPPoE est reçu et qu’une nouvelle session PPPoE est demandée, RADIUS répond au message de demande d’accès par un message de rejet d’accès. La session est rejetée, complètement déconnectée et l’interface logique du VLAN dynamique sous-jacente est supprimée.

   • Message de déconnexion initiée par RADIUS : lorsqu’un message de déconnexion initiée par RADIUS est reçu pour une session PPPoE existante, la session PPPoE dynamique est déconnectée et l’interface logique VLAN dynamique sous-jacente est supprimée.

2. L’action suivante est la même pour les deux messages :

   • Si un message ANCP Port Up a été reçu pour la ligne d’accès correspondante, le routeur tente d’autoriser la ligne d’accès et de créer une interface logique VLAN de vente en gros dynamique de couche 2 à la place de l’interface logique VLAN dynamique sous-jacente qui a été supprimée.

   • Si aucun message de transfert vers le haut n’a été reçu, cette action est différée jusqu’à ce que le message soit reçu.

   • Si un PADI PPPoE est reçu avant un message ANCP Port Up, RADIUS répond à la demande d’accès pour une nouvelle session PPPoE par un message Access-Reject. La session est rejetée, complètement déconnectée et l’interface logique du VLAN dynamique sous-jacente est supprimée.

Si le message de déconnexion ou de rejet d’accès initié par RADIUS est reçu pour une session non PPPoE, telle que DHCP, la session est déconnectée, mais la demande de reconnexion est ignorée. Aucune tentative n’est faite pour établir une session de vente en gros de couche 2.

Si la déconnexion initiée par RADIUS n’inclut pas Acct-Terminate-Cause avec une valeur de rappel, la renégociation PPPoE après la déconnexion peut réussir, mais si un message ANCP Port Up est reçu pour la ligne d’accès avant l’établissement d’une session PPPoE, une session de vente en gros de couche 2 est tentée.

Au lieu de la déconnexion initiée par RADIUS, vous pouvez déconnecter manuellement la session PPPoE à l’aide de la clear network-access aaa subscriber commande. Spécifiez l’abonné par nom d’utilisateur ou ID de session. Lorsque vous incluez l’option reconnect , elle tente de reconnecter la session effacée en tant que session de vente en gros de couche 2 lorsque la session d’abonné a été entièrement déconnectée.

Conséquences d’un changement d’état dans l’interface physique orientée accès

Le comportement suivant se produit lorsque l’état de l’interface physique orientée accès passe de Haut à Bas :

• La détection automatique VLAN intrabande conventionnelle s’arrête pour l’interface.

• Les messages de port activé provenant ANCP de l’interface sont ignorés. L’action sur les messages Port Up nouveaux ou non traités est différée jusqu’à ce que l’interface passe à l’état Up. Si la connexion ANCP est dans la bande avec le trafic d’abonné sur l’interface, tout le trafic ANCP s’arrête ; si la panne dure assez longtemps, la contiguïté ANCP est perdue.

• Toutes les sessions de vente en gros de couche 2 affectées à l’interface sont traitées comme si l’agent ANCP avait reçu un message Port Down pour la ligne d’accès correspondante. Chaque session est susceptible d’être déconnectée. La déconnexion ou non d’une session dépend du minuteur de maintien de perte d’adjacence ANCP. Le minuteur commence à s’exécuter lorsque l’agent ANCP détecte la transition d’état vers Inactif. L’abonné continue d’utiliser la session d’origine si les trois conditions suivantes se produisent avant l’expiration du minuteur :

  1. L’interface physique réapparaît.

  2. La contiguïté ANCP est rétablie.

  3. Un message Port Up est reçu sur l’interface.

  Sinon, autoconfd effectue les actions suivantes :

  1. Déconnecte la session.

  2. Envoie un message RADIUS Accounting-Stop avec les statistiques finales des sessions de service et des sessions client associées.

  3. Supprime l’interface logique VLAN dynamique.

  Ces sessions peuvent être rétablies lorsque l’interface physique est rétablie, sauf si un message ANCP Port Down est reçu.

• Le démon d’autoconfiguration ne supprime pas automatiquement les interfaces logiques VLAN dynamiques et détectées automatiquement. Les interfaces des VLAN de vente en gros de couche 2 déclenchés par ANCP sont maintenues, car une panne est supposée de courte durée. Si la panne n’est pas de courte durée, un message suivant de Port Down interrompt la session et supprime l’interface.

  Pour les VLAN dynamiques conventionnels à détection automatique, l’interface est supprimée uniquement lorsque l’instruction remove-when-no-subscribers est configurée sur l’interface physique orientée accès et que toutes les références à l’interface logique du VLAN à partir d’une interface logique ou d’une session supérieure sont supprimées. Ce mécanisme ne s’applique pas aux VLAN de vente en gros de couche 2 déclenchés par ANCP, car ils n’ont pas de références de session supérieures.

Le comportement suivant se produit lorsque l’état de l’interface physique d’accès passe de bas en haut :

1. La détection automatique VLAN intrabande conventionnelle reprend pour l’interface. Les sessions PPPoE appartenant au fournisseur d’accès qui ont été déconnectées en raison du passage de Haut à Bas peuvent être renégociées et subir une séquence de connexion complète.

2. Les actions appropriées sont prises pour tous les messages ANCP Port Up de l’interface, y compris les messages qui ont été différés en raison de l’état Down précédent de l’interface. Si la connexion ANCP est dans la bande avec le trafic d’abonné, tout le trafic ANCP reprend.

3. Le transfert reprend pour toutes les interfaces logiques VLAN dynamiques et détectées automatiquement qui n’ont pas été supprimées lorsque l’interface est tombée en panne.

La suppression d’une interface physique orientée accès déclenche la déconnexion et la suppression de toutes les interfaces logiques du VLAN dynamique supérieur et de leurs sessions correspondantes.

Conséquences d’un changement d’état de haut en bas dans l’interface physique orientée cœur

Le comportement suivant se produit lorsque l’état de l’interface physique centrale passe de Haut à Bas :

• L’interface physique orientée vers le cœur n’est plus éligible pour attribuer des lignes d’accès nouvelles ou en attente dans cette instance de routage en fonction de l’autorisation RADIUS d’origine.

• Toutes les sessions de vente en gros de couche 2 affectées à l’interface sont traitées comme si l’agent ANCP avait reçu une séquence de messages Port Down/Port Up pour la ligne d’accès correspondante. Chaque session est susceptible d’être déconnectée. La déconnexion ou non d’une session dépend du minuteur de maintien de perte d’adjacence ANCP. Le minuteur commence à s’exécuter lorsque l’agent ANCP détecte la transition d’état vers Inactif. L’abonné continue d’utiliser la session d’origine si les trois conditions suivantes se produisent avant l’expiration du minuteur :

  1. L’interface physique réapparaît.

  2. La contiguïté ANCP est rétablie.

  3. Un message Port Up est reçu sur l’interface.

  Sinon, autoconfd effectue les actions suivantes :

  1. Déconnecte la session.

  2. Supprime l’entrée de session de la base de données.

  3. Envoie un message RADIUS Accounting-Stop avec les statistiques finales des sessions de service et des sessions client associées.

  4. Supprime l’interface logique VLAN dynamique.

• Ensuite, autoconfd tente de migrer les sessions vers les connexions disponibles sur toutes les interfaces physiques principales éligibles restantes affectées à la même instance de routage :

  1. La demande d’origine est placée dans une file d’attente de nouvelle tentative.

  2. Une séquence de connexion est tentée pour chaque session, y compris l’authentification, la création d’interfaces logiques VLAN dynamiques, l’activation de tous les services et l’envoi de messages de démarrage de comptabilité RADIUS pour les sessions service et client.

     • Si la séquence de connexion réussit, la demande est supprimée de la file d’attente des nouvelles tentatives.

     • Si la connexion échoue, la session est déconnectée, l’entrée de session est supprimée de la SDB et la ligne d’accès correspondante est définie sur un état en attente.

  Lorsque toutes les connexions disponibles sont utilisées (lorsqu’il n’y a plus de balises VLAN disponibles dans les plages d’échange d’ID VLAN internes configurées) à la suite de reconnexions réussies, aucune tentative de connexion des sessions de vente en gros de couche 2 restantes n’est effectuée. Bien que l’authentification puisse réussir, la création d’interfaces logiques VLAN dynamiques échoue lors de l’instanciation du profil. Dans ce cas, la session est terminée, l’entrée de session est supprimée de la SDB et la ligne d’accès correspondante est définie sur un état en attente.

• Les lignes d’accès en attente qui représentent ces sessions non migrées peuvent être rétablies si l’interface se rétablit ou si des connexions VLAN supplémentaires deviennent disponibles ; par exemple, par une modification de configuration qui augmente la plage d’échange d’ID de VLAN interne pour une ou plusieurs interfaces physiques principales restantes ou ajoute de nouvelles interfaces physiques centrales supplémentaires. Toutefois, si l’agent ANCP reçoit un message Port Down pour une ligne d’accès en attente, la session correspondante n’est pas rétablie.

Vous pouvez utiliser la commande pour afficher le show auto-configuration out-of-band pending nombre de lignes d’accès en attente par instance de routage.

Conséquences d’un passage d’état de bas en haut dans l’interface physique orientée cœur

Le comportement suivant se produit lorsque l’état de l’interface physique orientée vers le cœur passe de bas en haut :

• L’interface physique peut désormais attribuer de nouvelles sessions d’abonné de vente en gros de couche 2.

• L’agent ANCP notifie le démon d’autoconfiguration (autoconfd), qui tente de rétablir les sessions de vente en gros de couche 2 qui correspondent à la ligne d’accès en attente en lançant une séquence de connexion conventionnelle. Cette séquence comprend l’authentification, la création d’interfaces logiques VLAN dynamiques, l’activation de tous les services et l’envoi de messages de démarrage de comptabilité RADIUS pour les sessions service et client.

• Les sessions en attente sont rétablies jusqu’à ce qu’il n’en reste plus ou qu’une erreur se produise, généralement en raison de l’épuisement des balises VLAN internes des plages de permutation sur l’interface. Dans ce dernier cas, les sessions sont déconnectées, l’entrée de session est supprimée de la SDB et la ligne d’accès est définie sur un état en attente.

Vous pouvez utiliser la commande pour afficher le show auto-configuration out-of-band pending nombre de lignes d’accès en attente par instance de routage.

Ces comportements se produisent également dans les cas suivants :

• Des ressources de connexion VLAN supplémentaires deviennent disponibles par une modification de configuration qui augmente la plage d’échange d’ID VLAN interne pour une ou plusieurs interfaces physiques principales restantes ou ajoute de nouvelles interfaces physiques centrales supplémentaires. L’interface physique nouvellement ajoutée doit être à l’état Actif pour prendre en charge les sessions de vente en gros de couche 2.

• Une déconnexion initiée par RADIUS est reçue lorsqu’une session de vente en gros de couche 2 existante affectée à cette instance de routage est déconnectée (déconnexion uniquement). Pour une déconnexion avec un qualificateur de reconnexion, la session affectée est privilégiée pour se reconnecter sur les lignes d’accès en attente.

• Vous émettez la request auto-configuration reconnect-pendingcommande , clear ancp access-loopou request ancp oam port-up .

Perte de contiguïté TCP ANCP

L’agent ANCP peut perdre sa contiguïté TCP avec un voisin dans l’une des circonstances suivantes :

• Le nœud d’accès renégocie la connexion ; par exemple, en raison d’une perte de synchronisation. La renégociation déclenche le changement de l’État local d’établi à non établi. L’état redevient établi lorsque la session est renégociée avec succès.

• Un message de fin de fichier (EOF) est reçu sur le socket indiquant que la contiguïté est fermée. Cela peut se produire lorsque la configuration ANCP est supprimée sur le nœud d’accès.

• Une défaillance de keepalive d’adjacence se produit. Lorsqu’aucune réponse n’est reçue pendant trois sondages consécutifs, la contiguïté est déclarée perdue.

L’agent ANCP traite la perte d’adjacence comme s’il avait reçu un message Port Down pour chaque boucle d’accès représentée par la connexion ANCP. L’agent notifie autoconfd, qui effectue les actions suivantes :

• Déconnecte toutes les sessions de vente en gros de couche 2 déclenchées par cette connexion ANCP.

• Envoie un message RADIUS Accounting-Stop avec les statistiques finales des sessions de service et des sessions client associées.

• Supprime l’interface logique VLAN dynamique.

Si l’interface physique affectée à l’accès ou au cœur est à l’état Inactif, les sessions en attente déclenchées par cette connexion ANCP ne peuvent pas être rétablies lorsque l’interface revient à l’état actif.

Les interfaces logiques VLAN dynamiques à détection automatique, telles que celles qui prennent en charge les sessions PPPoE, ne sont pas affectées par la perte d’adjacence TCP.

Si l’adjacence est rétablie, le comportement attendu est une relecture complète des messages Port Down et Port Up pour toutes les lignes d’accès configurées associées. Les sessions de vente en gros de couche 2 pour lesquelles l’agent ANCP reçoit des messages Port Up sont rétablies.

Vous pouvez atténuer les effets des pertes d’adjacence à court terme en configurant un temps d’attente de perte d’adjacence. Le minuteur démarre lorsque la contiguïté est perdue. Même si la contiguïté est perdue, les sessions établies sont conservées pendant l’exécution du minuteur, sauf si un message Port Down est reçu pour la ligne d’accès correspondante.

Toute ligne d’accès pour laquelle l’agent ANCP n’a pas reçu de message Port Up au moment de l’expiration du minuteur est traitée comme si l’agent avait reçu un message Port Down pour la ligne. L’agent ANCP notifie autoconfd, qui effectue les actions suivantes :

• Déconnecte toutes les sessions de vente en gros de couche 2 correspondant à la ligne d’accès.

• Envoie un message RADIUS Accounting-Stop avec les statistiques finales des sessions de service et des sessions client associées.

• Supprime l’interface logique VLAN dynamique.

Les messages Port Up reçus après l’expiration du minuteur remplissent à nouveau la table de ligne d’accès SDB et rétablissent les sessions de vente en gros de couche 2

Le compte à rebours de maintien de la perte d’adjacence a les fonctions suivantes :

• Atténue l’effet de la perte d’adjacence de courte durée, ce qui permet de maintenir les sessions de vente en gros de couche 2 existantes.

• Détecte la suppression d’une configuration de ligne d’accès sur le nœud d’accès. Par exemple, dans certaines circonstances, vous souhaiterez peut-être supprimer la configuration d’une ligne d’accès sur un voisin. Vous devez d’abord déconnecter la session ANCP entre un voisin et le BNG, supprimer la configuration sur le voisin, puis rétablir la connexion ANCP avec le BNG. Le voisin n’émet pas de message Port Bas. si le temporisateur d’attente de perte d’adjacence est configuré, l’agent ANCP détecte une ligne d’accès pour laquelle il n’a pas reçu de message Port Up ou Port Down, et déclenche par conséquent la déconnexion et la suppression de la session de vente en gros de couche 2 correspondante.