Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Options de session pour l’accès des abonnés

Les options de session vous permettent de spécifier plusieurs caractéristiques pour les sessions d’abonnés DHCP, L2TP et PPP terminées. Les options de session sont configurées dans des profils d’accès qui déterminent les paramètres d’accès, d’authentification, d’autorisation et de comptabilisation des abonnés.

Comprendre les options de session pour l’accès des abonnés

Vous pouvez utiliser des profils d’accès pour configurer plusieurs caractéristiques des sessions créées pour DHCP, L2TP et les abonnés PPP terminés. Vous pouvez limiter l’accès des abonnés en fonction de la durée de fonctionnement de la session, de la durée d’inactivité de l’utilisateur, ou des deux. Vous pouvez limiter les sessions d’abonnés par nom d’utilisateur et par profil d’accès. Vous pouvez également définir des paramètres qui modifient le nom d’utilisateur d’un abonné à la connexion en fonction du profil d’accès de l’abonné.

Délais d’expiration de session pour les abonnés

Vous pouvez limiter l’accès des abonnés en configurant un délai d’expiration de session ou un timeout d’inactivité. Utilisez un délai d’expiration de session pour spécifier une période d’accès fixe à laquelle l’abonné est autorisé. Utilisez un délai d’arrêt au ralenti pour spécifier une période maximale d’inactivité de l’abonné. Vous pouvez utiliser ces délais séparément ou ensemble. Par défaut, aucun délai d’expiration n’est présent.

Note:

Pour tous les types d’abonnés autres que DHCP (par exemple les abonnés L2TP et les abonnés terminés par PPP), la valeur de délai d’expiration de session limite la session d’abonné. Pour les abonnés DHCP, la valeur de délai d’expiration de session est utilisée pour limiter le contrat de location lorsqu’aucune autre configuration du temps de location n’est présente. Le contrat de location expire à l’expiration de la valeur du délai d’expiration. Si cette valeur n’est pas fournie par l’interface CLI ou RADIUS, le bail DHCP n’expire pas.

Le délai d’arrêt inactif est basé sur la comptabilisation des statistiques pour l’abonné. Le routeur détermine l’inactivité des abonnés en surveillant le trafic de données, à la fois en amont de l’utilisateur (entrée) et en aval vers l’utilisateur (sortie). Le trafic de contrôle est ignoré. L’abonné n’est pas considéré comme inactif tant que le trafic de données est détecté dans les deux directions.

Vous pouvez éventuellement spécifier que seul le trafic entrant des abonnés est surveillé ; le trafic sortant est ignoré. Cette configuration est utile dans les cas où le LNS envoie du trafic à l’pair distant même lorsque celui-ci n’est pas opérationnel, par exemple lorsque le LNS ne dispose pas de keepalives PPP et ne peut donc pas détecter que l’pair n’est pas opérationnel. Dans ce cas, étant donné que, par défaut, lac surveille le trafic entrant et sortant, il détecte le trafic sortant depuis le réseau LNS et ne déconnecte pas l’abonné ou retarde la détection de l’inactivité jusqu’à ce que le trafic sortant cesse. Lorsque vous spécifiez que seul le trafic entrant est surveillé, le LAC peut détecter que l’appairage est inactif, puis lancer la déconnexion.

Lorsque la période d’expiration du délai d’expiration expire, les abonnés non DHCP sont normalement déconnectés, de la même manière qu’une déconnexion lancée par RADIUS ou une déconnexion lancée par l’interface CLI. Les abonnés DHCP sont déconnectés. La valeur Acct-Terminate-Cause [RADIUS attribute 49] inclut un code de raison de 5 pour un délai d’expiration de session et un code de 4 pour un timeout d’inactivité.

Vous pouvez configurer ces limites pour l’accès des abonnés par abonné à l’aide des attributs RADIUS Session-Timeout [27] et Idle-Timeout [28]. RADIUS renvoie ces attributs dans les messages Access-Accept en réponse aux messages Access-Request du serveur d’accès. À partir de Junos OS Version 19.4R1, l’attribut Session-Timeout [27] est pris en charge dans les messages CoA RADIUS. Cette fonctionnalité est utile, par exemple lorsque les abonnés achètent un accès Internet pour une période spécifique et doivent se déconnecter lorsque la session expire.

Lorsqu’un CoA arrive avec un délai d’expiration de session, le délai d’expiration est compté depuis le moment où la session a été activée. Les conséquences sont les suivantes :

  • Si la valeur d’attribut est supérieure à la disponibilité de session en cours et entre les valeurs de délai d’expiration minimale et maximale, l’abonné est déconnecté lorsque ce nombre de secondes s’est écoulé depuis l’activation de la session. Par exemple, supposons que la session est activée à 12h00 et que le CoA est reçu à 12h00/30 d’une valeur de 120 secondes. L’abonné est connecté à 12:02:00.

    Une autre façon de regarder cela avec les mêmes valeurs est que la disponibilité de session actuelle est de 30 secondes et la valeur d’attribut est de 120 secondes. L’abonné est déconnecté lorsque 90 secondes de plus se sont écoulées.

  • Si la valeur d’attribut est supérieure à la disponibilité de session en cours mais inférieure à la valeur de délai d’expiration minimale de 60 secondes, l’abonné est déconnecté lorsque la disponibilité atteint 60 secondes.

  • Si la valeur d’attribut est supérieure à la disponibilité de session en cours, mais supérieure à la valeur maximale de délai d’expiration de 31 622 400 secondes, l’abonné est alors déconnecté lorsque la disponibilité atteint 31 622 400 secondes.

  • Si la valeur d’attribut est inférieure à la disponibilité de la session en cours, le délai d’expiration de session n’est pas appliqué. AAA répond au message de CoA avec un NAK. Par exemple, la session n’est pas affectée si le délai d’expiration de session est de 60 secondes, mais celui de 100 secondes.

L’application d’un délai d’expiration de session conformément aux règles ci-dessus dépend également du succès de tous les autres aspects de la CoA. Par exemple, si la coA inclut une activation de service et que celle-ci échoue, le délai d’expiration de session n’est pas appliqué. AAA répond au message de CoA avec un NAK.

Note:

Si la valeur d’expiration de session est 0, l’expiration de session existante pour cette session est annulée.

Les fournisseurs de services choisissent souvent d’appliquer les mêmes limites à un grand nombre d’abonnés. Vous pouvez réduire les efforts de provisionnement RADIUS pour ce scénario en définissant les limites pour les abonnés dans un profil d’accès par instance de routage. Si vous le faites, les attributs RADIUS sont ensuite renvoyés pour un abonné connecté avec le profil remplacent les valeurs par instance de routage.

Meilleures pratiques :

Il est recommandé de ne pas configurer de délai d’expiration de session pour les abonnés qui reçoivent des services vocaux. Le délai d’expiration de session étant uniquement basé sur l’heure et non sur l’activité de l’utilisateur, il est susceptible d’interrompre les abonnés activement à l’aide d’un service voix et de terminer leurs appels de manière inattendue (du point de vue des abonnés). Ce résultat est particulièrement préoccupant pour les appels des services d’urgence.

Meilleures pratiques :

Il est recommandé de ne pas configurer de délai d’arrêt inactif pour les abonnés DHCP. Lorsque le délai d’expiration expire sans activité et que la connexion est interrompue, le protocole n’a aucun moyen d’informer le client. Par conséquent, ces abonnés sont obligés de redémarrer leur équipement CPE la prochaine fois qu’ils tentent d’accéder à Internet.

Contrastez le comportement lorsqu’un timeout d’inactivité est configuré pour les abonnés PPP. Dans ce cas, l’expiration du délai d’expiration oblige PPP à mettre fin au lien avec le pair. Selon l’équipement CPE, cette terminaison permet à l’appairage de réessayer automatiquement la connexion à la demande ou immédiatement. Dans les deux cas, aucune intervention d’abonné n’est requise.

La plage disponible pour la définition d’un délai d’expiration est la même, que vous la configurez dans l’interface de ligne de commande ou via les attributs RADIUS :

  • Les délais d’expiration de session peuvent être définis sur une durée de 1 minute à 527 040 minutes dans l’interface de ligne de commande et sur le nombre correspondant de secondes (60 à 31 622 400) dans l’attribut Session-Timeout [27].

  • Les délais d’arrêt au ralenti peuvent être définis pour 10 minutes à 1 440 minutes dans l’interface de ligne de commande et le nombre de secondes correspondant (600 à 86 400) dans l’attribut Idle-Timeout [28].

Le routeur interprète les valeurs des attributs pour les conformer aux plages prises en charge. Par exemple, pour le délai d’expiration de session [27] :

  • Une valeur zéro est traitée comme aucun délai d’expiration.

  • Une valeur de la plage 1 à 59 est portée à 60 secondes.

  • La valeur supérieure à 31 622 400 est ramenée à 31 622 400 secondes.

Pour le délai d’inactivité [28] :

  • Une valeur zéro est traitée comme aucun délai d’expiration.

  • Une valeur comprise entre 1 et 599 est portée à 600 secondes.

  • La valeur supérieure à 86 400 est ramenée à 86 400 secondes.

Dans les configurations utilisant des VLAN d’abonnés créés de manière dynamique, le délai d’inactivité supprime également les VLAN d’abonnés inactifs lorsque le seuil d’inactivité a été atteint. En plus de supprimer les VLAN d’abonnés dynamiques inactifs, le délai d’arrêt au ralenti supprime également les VLAN dynamiques lorsqu’aucune session client n’a jamais été créée (par exemple, si aucune session client n’est créée sur le VLAN dynamique ou suite à l’apparition d’une erreur lors de la création de session ou de l’authentification client où aucune session client n’est créée sur le VLAN dynamique).

Les délais d’expiration de session et d’inactivité pour la suppression des VLAN d’abonnés dynamiques ne sont utiles que dans des cas d’utilisation très limités. en général, aucun délai d’expiration n’est configuré à cet effet.

Lorsqu’ils peuvent s’avérer utiles, il peut s’agir de situations où les VLAN dynamiques ne disposent d’aucun protocole de couche supérieure permettant de déterminer le moment où le VLAN est retiré avec l’instruction remove-when-no-subscribers . Par exemple, lorsque le VLAN prend en charge IP sur Ethernet sans DHCP dans un modèle d’accès professionnel avec des adresses fixes. Cependant, l’accès professionnel est généralement un service de niveau supérieur que l’accès résidentiel et, par conséquent, n’est généralement pas soumis à des délais d’expiration en raison de l’inactivité que l’on peut désirer pour les abonnés résidentiels.

Un délai d’arrêt au ralenti peut être approprié dans certaines situations de gros de couche 2, où la connexion peut être régénérée lorsqu’un paquet est reçu du CPE.

Lorsque vous utilisez le délai d’arrêt au ralenti pour la suppression dynamique du VLAN, gardez à l’esprit les éléments suivants :

  • La période d’inactivité commence après la création d’une interface VLAN d’abonné dynamique ou l’arrêt de l’activité du trafic sur une interface VLAN dynamique d’abonné.

  • Si une nouvelle session client est créée ou qu’une session client est réactivée avec succès, le délai d’inactivité du client est réinitialisé.

  • La suppression des fonctions VLAN d’abonnés inactives n’est disponible qu’avec les VLAN authentifiés.

Limites des sessions d’abonnés par nom d’utilisateur et profil d’accès

Les abonnés autorisés peuvent partager leurs identifiants de connexion avec des personnes non autorisées, dépensant ainsi des ressources pour les fournisseurs de services sans en bénéficier. À partir de Junos OS Version 18.4R1, vous pouvez contrôler ou empêcher le partage des données d’identification de connexion en limitant le nombre de sessions d’abonnés actives autorisées pour un nom d’utilisateur spécifique associé à un profil d’accès. Vous pouvez également obtenir ce contrôle avec RADIUS, mais la configuration locale de la limite sur le BNG élimine la dépendance vis-à-vis d’un serveur externe.

Lorsque vous configurez une limite, les sessions actives pour la combinaison nom d’utilisateur/profil d’accès sont suivies. Le nombre de sessions suivies est vérifié lorsque l’utilisateur reçoit une nouvelle demande de connexion à la session. Si le nombre de sessions suivies correspond à la limite, la nouvelle tentative de connexion est rejetée et considérée comme une requête bloquée.

Lorsque l’utilisateur authd reçoit une demande de déconnexion ou de résiliation du client pour une session, le nombre de sessions suivies est décrémenté pour ce nom d’utilisateur/profil d’accès. Si cette action se poursuit jusqu’à l’absence de sessions actives pour la combinaison, l’entrée est supprimée dans la table des limites de session. Toutes les entrées de nom d’utilisateur/de profil d’accès associées sont supprimées du tableau si vous supprimez le profil d’accès ou la limite de session de votre configuration.

Le nombre total de sessions pour un nom d’utilisateur peut dépasser la limite configurée pour un profil d’accès particulier, car le même nom d’utilisateur peut être utilisé avec plusieurs profils d’accès.

Note:

Pour les sessions d’abonnés empilées telles que les PPP avec VLAN configurés automatiquement, les deux nom d’utilisateur de la pile sont utilisés pour l’authentification et par conséquent, les deux sont comptés dans la limite de session.

La limite configurée s’applique aux abonnés actifs existants, mais les sessions existantes ne sont pas détruites si le nombre de sessions actives dépasse la limite d’un abonné avec cette combinaison de nom d’utilisateur et de profil d’accès.

Prenons le cas où cinq sessions sont actuellement actives pour une combinaison nom d’utilisateur/profil d’accès donné lorsque vous configurez une limite de deux.

  1. Le nombre de sessions actives est enregistré comme cinq dans l’entrée de la table limite de session pour la combinaison.

  2. Un nouvel abonné ayant le même nom d’utilisateur et le même profil d’accès tente de se connecter. La tentative est bloquée car la limite de deux sessions est déjà dépassée (cinq > deux).

  3. Un abonné existant se connecte et compte quatre sessions actives.

  4. Un nouvel abonné ayant le même nom d’utilisateur et le même profil d’accès tente de se connecter. La tentative est bloquée car la limite de deux sessions est toujours dépassée (quatre > deux).

  5. Trois abonnés se connectent, ce qui réduit le nombre de sessions actives à un.

  6. Un nouvel abonné ayant le même nom d’utilisateur et le même profil d’accès tente de se connecter. La tentative est autorisée car la limite de deux sessions n’a pas encore été atteinte (une < deux).

La conception de la limite de session empêche un événement de déni de service lorsqu’un utilisateur malveillant tente plusieurs connexions avec le nom d’utilisateur et le profil d’accès corrects, mais avec le mauvais mot de passe. Les nombreuses tentatives de connexion peuvent dépasser la limite de session configurée, mais cela ne se produit pas car le nombre de sessions suivies n’est incrémenté que lorsque l’état de session de l’abonné passe à l’état actif, ce que les connexions malveillantes n’atteignent pas.

Avantages de la limitation des sessions pour les noms d’utilisateur avec l’interface de ligne de commande

  • Vous permet de limiter le nombre de sessions localement sur le routeur, plutôt que d’être dépendant d’un serveur RADIUS externe pour fournir la limite.

  • Empêche certaines attaques par déni de service basées sur plusieurs connexions.

Modification du nom d’utilisateur de l’abonné

Pour les applications wholesale de couche 2, certains fournisseurs de services réseau utilisent la modification du nom d’utilisateur pour diriger les abonnés vers le réseau d’entreprise de vente au détail approprié. Cette modification est également appelée suppression des noms d’utilisateur, car certains des caractères du nom d’utilisateur sont retirés et jetés. Le reste de la chaîne devient le nouveau nom d’utilisateur modifié. Le nom d’utilisateur modifié est utilisé par un serveur AAA externe pour l’authentification et la comptabilisation des sessions. Les paramètres de modification sont appliqués en fonction d’un profil d’accès abonné qui détermine également le contexte de l’abonné et de la session ; c’est-à-dire le système logique:instance de routage (LS:RI) utilisé par l’abonné. Seul le système logique (principal) par défaut est pris en charge. Étant donné que le grossiste différencie plusieurs détaillants en plaçant chacun d’entre eux dans un LS:RI différent, les nom d’utilisateur sont modifiés de manière appropriée pour chaque détaillant.

Vous pouvez sélectionner jusqu’à huit caractères comme délimitateurs pour marquer la limite entre les parties jetées et conservées du nom d’utilisateur d’origine ; il n’y a pas de limiteur par défaut. La partie du nom à droite du délimitateur sélectionné est jetée avec le délimitateur. En configurant plusieurs délimitateurs, une structure de nom d’utilisateur donné peut entraîner différentes modifications de nom d’utilisateur. Vous pouvez configurer la direction dans laquelle le nom d’origine est étudié pour déterminer quel délimitateur marque la limite. Par défaut, la direction de l’analyse est de gauche à droite.

Prenons les exemples suivants :

  • Vous spécifiez un délimitateur, @. Le nom d’utilisateur est user1@example.com. Dans ce cas, la direction de l’analyse n’a pas d’importance. Dans les deux cas, le délimitateur unique est trouvé et example.com est jeté. Le nom d’utilisateur modifié est utilisateur1.

  • Vous spécifiez un délimitateur, @. Le nom d’utilisateur est user1@test@example.com. Dans ce cas, la direction d’analyse donne différents nom d’utilisateur.

    • La direction parse est de gauche à droite : le plus à gauche est identifié comme le délimitateur et test@example.com est jeté. Le nom d’utilisateur modifié est utilisateur1.

    • La direction parse est de droite à gauche : le plus à droite @ est identifié comme le délimitateur et example.com est jeté. Le nom d’utilisateur modifié est user1@test.

  • Vous spécifiez deux délimitateurs : @ et /. Le nom d’utilisateur est user1@bldg1/example.com. La direction de l’analyse donne différents nom d’utilisateur.

    • La direction parse est de gauche à droite : l’adresse @ est identifiée comme le délimitateur et le fichier bldg1/example.com est jeté. Le nom d’utilisateur modifié est utilisateur1.

    • La direction du parse est de droite à gauche : le / est identifié comme le délimitateur et example.com est jeté. Le nom d’utilisateur modifié est user1@bldg1.

Vous pouvez configurer un profil d’accès d’abonné de sorte qu’une partie de chaque chaîne de connexion d’abonné soit retirée et utilisée par la suite comme nom d’utilisateur modifié par un serveur AAA externe pour l’authentification et la comptabilisation des sessions. Le nom d’utilisateur modifié apparaît, par exemple, dans les messages Access-Request, Acct-Start et Acct-Stop de RADIUS, ainsi que dans les demandes de déconnexion et de modification d’autorisation (CoA) lancées par RADIUS.

Avantages de la modification du nom d’utilisateur de l’abonné

  • Permet aux fournisseurs de services réseau wholesale de couche 2 d’orienter facilement les abonnés vers le réseau d’entreprise de vente au détail approprié.

Options d’expiration de session pour les abonnés

Les options d’expiration de session pour les abonnés vous permettent de limiter l’accès à l’abonné en fonction de la durée d’utilisation de la session, de la durée d’inactivité de l’utilisateur ou des deux. Les options de session d’abonné s’appliquent aux sessions d’abonnés L2TP et PPP. Pour les abonnés DHCP, le délai d’expiration de session limite le temps de location DHCP.

Note:

Pour configurer les attributs de délai d’expiration dans RADIUS, reportez-vous à la documentation relative à votre serveur RADIUS.

Pour configurer les limites des sessions d’abonnés, configurez les options de session du profil client qui s’appliquent à l’abonné :

  • Mettre fin à l’abonné lorsque l’expiration de l’expiration de session configurée expire, quelle que soit l’activité.

  • Mettre fin à l’abonné lorsqu’il n’y a pas de trafic de données entrant ou sortant pendant toute la durée du délai d’arrêt au ralenti configuré.

  • Mettre fin à l’abonné lorsqu’il n’y a pas de trafic de données entrant pendant la durée du délai d’arrêt configuré ; ignorez le trafic sortant.

Par exemple, pour configurer les options d’expiration de session dans le acc-prof profil du client, en spécifiant un délai d’inactivité de 15 minutes, que seul le trafic entrant est surveillé et que les temps de session sont terminés au bout de 120 minutes :

Limitation du nombre de sessions actives par nom d’utilisateur et profil d’accès

Vous pouvez contrôler le degré de partage des informations d’identification des abonnés légitimes en limitant le nombre de sessions d’abonnés actives autorisées pour un nom d’utilisateur spécifique associé à un profil d’accès.

Pour limiter le nombre de sessions actives par nom d’utilisateur et profil d’accès :

  • [edit access profile profile-name]
    user@host# set session-limit-per-username number
    

Par exemple, pour définir le nombre maximal de sessions actives par nom d’utilisateur sur cinq pour le profil d’accès isp-weg-4 :

Vous pouvez utiliser cette commande pour afficher des show network-access aaa statistics session-limit-per-username statistiques sur les sessions actives et les requêtes bloquées.

Vous pouvez utiliser cette clear network-access aaa statistics session-limit-per-username username commande comme aide au débogage en supprimant les statistiques de requête bloquées pour l’un des cas suivants :

  • Pour tous les nom d’utilisateur et tous les profils d’accès.

  • Pour un nom d’utilisateur spécifique à tous les profils d’accès.

  • Pour un nom d’utilisateur spécifique dans un profil d’accès spécifique.

  • Pour tous les nom d’utilisateur d’un profil d’accès spécifique.

Configuration de la modification du nom d’utilisateur pour les sessions d’abonnés

Vous pouvez utiliser les options de session de l’abonné pour définir des paramètres qui modifient le nom d’utilisateur d’un abonné lors de la connexion en fonction du profil d’accès de l’abonné. Cette modification est également appelée suppression des noms d’utilisateur, car certains des caractères du nom d’utilisateur sont retirés et jetés. Le reste de la chaîne devient le nouveau nom d’utilisateur modifié. Le nom d’utilisateur modifié est utilisé par un serveur AAA externe pour l’authentification et la comptabilisation des sessions. Cette fonctionnalité peut être utile, par exemple, dans les implémentations wholesale de couche 2, où les fournisseurs de services réseau utilisent la modification de nom d’utilisateur pour diriger les abonnés vers le réseau d’entreprise de vente au détail approprié.

Les paramètres de modification sont appliqués en fonction d’un profil d’accès abonné qui détermine également le contexte de l’abonné et de la session ; c’est-à-dire le système logique:instance de routage (LS:RI) utilisé par l’abonné. Seul le système logique (principal) par défaut est pris en charge. Étant donné que le grossiste différencie plusieurs détaillants en plaçant chacun d’entre eux dans un LS:RI différent, les nom d’utilisateur sont modifiés de manière appropriée pour chaque détaillant.

Vous pouvez sélectionner jusqu’à huit caractères comme délimitateurs pour marquer la limite entre les parties jetées et conservées du nom d’utilisateur d’origine ; il n’y a pas de limiteur par défaut. La partie du nom à droite du délimitateur sélectionné est jetée avec le délimitateur. En configurant plusieurs délimitateurs, une structure de nom d’utilisateur donné peut entraîner différentes modifications de nom d’utilisateur. Vous pouvez configurer la direction dans laquelle le nom d’origine est étudié pour déterminer quel délimitateur marque la limite. Par défaut, la direction de l’analyse est de gauche à droite.

Pour configurer la modification du nom d’utilisateur :

  1. Définir un profil comprenant un ensemble d’options AAA pour autoriser et configurer un abonné ou un ensemble d’abonnés ayant un profil d’accès.
    1. Indiquez le nom du profil d’accès de l’abonné qui inclut la configuration de suppression de nom d’utilisateur.
    2. (Facultatif) Indiquez le système logique:instance de routage (LS:RI) que la session d’abonné utilise pour des interactions AAA (RADIUS) telles que l’authentification et la comptabilisation. Par exemple, cela peut correspondre à LS:RI pour un FAI de vente au détail qui fournit des services à l’abonné.
    3. (Facultatif) Indiquez le système logique :instance de routage (LS:RI) dans lequel l’interface abonnée est placée. Par exemple, cela peut correspondre à l’interface lac-facing sur le LNS accessible par toutes les demandes émanant d’une résidence d’abonné.
  2. Configurez les options de session du profil d’accès qui spécifient comment les nom d’utilisateur sont supprimés.
    1. Indiquez un ou plusieurs délimitateurs pour marquer la limite entre les parties jetées et conservées du nom d’utilisateur d’origine.
    2. (Facultatif) Indiquez la direction dans laquelle le nom d’utilisateur d’origine est examiné pour trouver un délimitateur. La direction par défaut est de gauche à droite.
  3. (Facultatif) Indiquez que les options AAA sont disponibles par interface lorsque les abonnés dynamiques sont authentifiés.
  4. (Facultatif) Indiquez que les options AAA font partie des options PPP dans un profil de groupe qui s’applique aux abonnés PPP tunnelnés sur le LNS.

Dans l’exemple suivant, aaa1, le profil d’options AAA spécifie un profil d’accès d’abonné, entA, pour les abonnés du système logique par défaut et de l’instance de routage 1. Le profil d’accès, entA, spécifie que les noms d’utilisateur sont examinés de gauche à droite jusqu’à ce que le délimitateur, @, soit trouvé. Le profil d’options AAA est appliqué aux abonnés PPP tunnelnés appartenant au profil de groupe FD1.

Compte tenu de cette configuration, supposons qu’un abonné tente de se connecter avec le nom d’utilisateur user1@example.com. Lors de l’examen de ce nom, le délimitateur et la chaîne example.com sont jetés, laissant ainsi un nom d’utilisateur modifié de l’utilisateur1. Notez que le résultat est le même si la direction de l’analyse est définie pour examiner le nom de droite à gauche, car un seul délimitateur est défini et un seul est présent dans le nom d’utilisateur d’origine.

Supposons que l’abonné se connecte au nom d’utilisateur user1@test@example.com. Pour un nom d’utilisateur comme celui-ci, la direction d’analyse fait la différence dans le nom d’utilisateur modifié. La configuration détermine que la première instance du délimiteur @ est trouvée en premier, car le nom est étudié de gauche à droite. Ce délimitateur et la chaîne test@example.com sont jetés, laissant l’utilisateur1 comme nom d’utilisateur modifié.

Que se passe-t-il lorsque la configuration définit une autre direction d’analyse ?

Dans ce cas, pour le nom d’utilisateur user1@test@example.com, la deuxième instance du délimitateur est identifiée et elle est jetée avec la chaîne @example.com. Le nom d’utilisateur modifié est user1@test.

Vous pouvez obtenir les mêmes résultats que pour les différents noms d’utilisateur modifiés en fonction de la direction de l’analyse en configurant plusieurs délimitateurs comme dans la configuration suivante, où vous spécifiez deux délimitateurs , @ et /.

Pour le nom d’utilisateur user1@bldg1/example.com, l’analyse de gauche à droite identifie d’abord le délimitateur @ et le nom d’utilisateur modifié est utilisateur1. Parse plutôt de droite à gauche, identifie d’abord le /délimitateur et le retire avec la chaîne example.com, laissant ainsi un nom d’utilisateur modifié de user1@bldg1.

Suppression des VLAN d’abonnés dynamiques inactifs

Les délais d’expiration de session pour les abonnés vous permettent de limiter l’accès à l’abonné en fonction de la durée d’utilisation de la session, de la durée d’inactivité de l’utilisateur ou des deux. Dans les configurations utilisant VLANS abonné créé de manière dynamique, le délai d’arrêt au ralenti permet également de :

  • Supprime les VLAN d’abonnés inactifs lorsque le seuil d’inactivité a été atteint.

  • Supprime les VLAN dynamiques lorsqu’aucune session client n’a jamais été créée (par exemple, si aucune session client n’est créée sur le VLAN dynamique ou suite à l’occurrence d’une erreur lors de la création d’une session ou de l’authentification du client où aucune session client n’est créée sur le VLAN dynamique).

Note:

Les délais d’expiration de session ne sont généralement pas utilisés pour supprimer les VLAN d’abonnés dynamiques. Le délai d’expiration peut n’être utile que dans des cas d’utilisation très limités. Par exemple, lorsque les VLAN dynamiques ne disposent d’aucun protocole de couche supérieure permettant de déterminer le moment où le VLAN est retiré avec l’instruction remove-when-no-subscribers . Par exemple, lorsque le VLAN prend en charge IP via Ethernet sans DHCP dans un modèle d’accès professionnel avec des adresses fixes.

Note:

Pour configurer l’attribut de délai d’inactivité dans RADIUS, reportez-vous à la documentation relative à votre serveur RADIUS.

Pour supprimer les VLANS dynamiques d’abonnés inactifs :

  1. Modifiez les options de session pour le profil d’accès au routeur.
  2. Configurez la période maximale qu’une session d’abonné peut rester inactive.
Tableau Historique des versions
Libération
Description
19.4R1
À partir de Junos OS Version 19.4R1, l’attribut Session-Timeout [27] est pris en charge dans les messages CoA RADIUS.
18.4R1
À partir de Junos OS Version 18.4R1, vous pouvez contrôler ou empêcher le partage des données d’identification de connexion en limitant le nombre de sessions d’abonnés actives autorisées pour un nom d’utilisateur spécifique associé à un profil d’accès.