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

Les options de session vous permettent de spécifier plusieurs caractéristiques pour les sessions DHCP, L2TP et les sessions d’abonnés 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 les abonnés DHCP, L2TP et PPP terminés. Vous pouvez limiter l’accès des abonnés en fonction de la durée 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 par profil d’accès. Vous pouvez également 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é.

Timeouts des sessions abonnés

Vous pouvez limiter l’accès des abonnés en configurant un délai d’expiration de session ou un délai d’inactivité. Utilisez un délai d’expiration de session pour spécifier une période fixe d’accès à l’abonné. Utilisez un délai d’inactivité pour spécifier une période maximale pendant lequel l’abonné peut être inactif. Vous pouvez utiliser ces délais séparément ou ensemble. Par défaut, aucun délai n’est présent.

Note:

Pour tous les types d’abonnés autres que DHCP (tels que les abonnés à tunnel L2TP et les abonnés avec terminaison PPP), la valeur du délai d’expiration de session limite la session d’abonné. Pour les abonnés DHCP, la valeur du délai d’expiration de session est utilisée pour limiter le bail en l’absence d’une autre configuration de durée de bail. Le bail expire lorsque la valeur du délai d’expiration expire. Si cette valeur n’est pas fournie par la CLI ou RADIUS, le bail DHCP n’expire pas.

Le délai d’inactivité est basé sur des statistiques comptables 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 (entrant) et en aval vers l’utilisateur (sortant). 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 l’un ou l’autre sens.

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’homologue distant même lorsque l’homologue n’est pas opérationnel, par exemple lorsque le LNS n’a pas de fonctions de sauvegarde PPP activées et ne peut donc pas détecter que l’homologue n’est pas opérationnel. Dans cette situation, parce que par défaut, LAC surveille à la fois le trafic entrant et sortant, il détecte le trafic sortant du 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 BAC peut détecter que l’homologue est inactif, puis lancer la déconnexion.

Lorsque l’un ou l’autre délai expire, les abonnés non DHCP sont déconnectés gracieusement, de la même manière qu’une déconnexion lancée par RADIUS ou une déconnexion initiée par 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 timeout de session et un code de 4 pour un délai d’inactivité.

Vous pouvez configurer ces limitations d’accè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 la version 19.4R1 de Junos OS, l’attribut Session-Timeout [27] est pris en charge dans les messages RADIUS CoA. 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 session-timeout, le délai est compté à partir de l’activation de la session. Cela a les conséquences suivantes :

  • Si la valeur de l’attribut est supérieure à la disponibilité de la session actuelle et entre les valeurs de délai d’expiration minimales et maximales, 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 soit activée à 12:00:00 et que le CoA soit reçu à 12:00:30 avec une valeur de 120 secondes. L’abonné est déconnecté à 12:02:00.

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

  • Si la valeur de l’attribut est supérieure à la disponibilité de la session actuelle 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 de l’attribut est supérieure à la disponibilité de la session actuelle, mais supérieure à la valeur de délai d’expiration maximale de 31 622 400 secondes, l’abonné est déconnecté lorsque la disponibilité atteint 31 622 400 secondes.

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

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

Note:

Si la valeur du délai d’expiration de session est 0, tout délai de session existant pour cette session est annulé.

Les fournisseurs de services choisissent souvent d’appliquer les mêmes limitations à 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 renvoyés par la suite pour un abonné particulier connecté avec le profil remplacent les valeurs par instance de routage.

Meilleures pratiques :

Nous vous recommandons de ne pas configurer de délai d’expiration de session pour les abonnés recevant des services vocaux. Étant donné que le délai d’expiration des sessions est uniquement basé sur le temps et non sur l’activité de l’utilisateur, il est susceptible d’interrompre activement les abonnés à l’aide d’un service vocal et de terminer leurs appels de manière inattendue (du point de vue de l’abonné). Ce résultat est particulièrement préoccupant pour les appels de services d’urgence.

Meilleures pratiques :

Nous vous recommandons de ne pas configurer un délai d’expiration inactif pour les abonnés DHCP. Lorsque le délai expire sans activité et que la connexion est résiliée, le protocole n’a aucun moyen d’en informer le client. Par conséquent, ces abonnés sont contraints de redémarrer leur équipement CPE la prochaine fois qu’ils tentent d’accéder à Internet.

Comparez le comportement lorsqu’un délai d’inactivité est configuré pour les abonnés PPP. Dans ce cas, l’expiration du délai d’expiration entraîne l’arrêt par PPP de la liaison avec l’homologue. En fonction de l’équipement CPE, cette terminaison permet à l’homologue de réessayer automatiquement la connexion à la demande ou immédiatement. Dans les deux cas, aucune intervention des abonnés n’est nécessaire.

La plage disponible pour définir un délai d’expiration est la même que vous le configurez dans la CLI ou via les attributs RADIUS :

  • Le délai d’expiration des sessions peut être défini entre 1 minute et 527 040 minutes dans l’interface cli et le nombre de secondes correspondant (60 à 31 622 400) dans l’attribut Session-Timeout [27].

  • Les délais d’inactivité peuvent être définis pendant 10 minutes à 1 440 minutes dans l’interface cli et le nombre de secondes correspondant (600 à 86 400) dans l’attribut Idle-Timeout [28].

Le routeur interprète les valeurs des attributs pour se conformer aux plages prises en charge. Par exemple, pour session-timeout [27] :

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

  • Une valeur comprise entre 1 et 59 est portée à 60 secondes.

  • Une valeur qui dépasse 31 622 400 est réduite à 31 622 400 secondes.

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

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

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

  • Une valeur qui dépasse 86 400 est réduite à 86 400 secondes.

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

Les délais de session et d’inactivité pour supprimer les VLAN dynamiques des abonnés ne sont utiles que dans des cas d’utilisation très limités; en général, aucun délai n’est configuré à cette fin.

Les VLAN dynamiques n’ont pas de protocole de couche supérieure qui permet de déterminer quand le VLAN est supprimé avec l’instruction remove-when-no-subscribers , par exemple, lorsque le VLAN prend en charge IP over Ethernet sans DHCP dans un modèle d’accès commercial avec adresses fixes. Toutefois, l’accès professionnel est généralement un service de niveau supérieur à l’accès résidentiel et, par conséquent, n’est généralement pas soumis à des délais d’inactivité, comme le souhaitent les abonnés résidentiels.

Un délai d’expiration peut être approprié dans certaines situations de gros de couche 2, où la connexion peut être régénérée lorsque n’importe quel paquet est reçu du CPE.

Lorsque vous utilisez le délai d’inactivité pour la suppression dynamique du VLAN, gardez à l’esprit les éléments suivants :

  • Le délai d’expiration inactif 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 d’abonné dynamique.

  • 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 se réinitialise.

  • La suppression des fonctions VLAN d’abonné inactifs uniquement avec des VLAN qui ont été authentifiés.

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

Les abonnés légitimes peuvent partager leurs identifiants de connexion avec des personnes non autorisées, dépensant les ressources du fournisseur de services sans aucun avantage pour le fournisseur. À partir de la version 18.4R1 de Junos OS, vous pouvez contrôler ou empêcher le partage des informations d’identification en limitant le nombre de sessions d’abonné actives autorisées pour un nom d’utilisateur spécifique associé à un profil d’accès. Vous pouvez également réaliser 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’authd reçoit une nouvelle demande de connexion de session. Si le nombre de sessions suivies correspond à la limite, la nouvelle tentative de connexion est rejetée et comptée comme une demande bloquée.

Lorsque l’authd reçoit une demande de déconnexion ou de résiliation client pour une session, le nombre de sessions suivies est décrémenté pour cette entrée de nom d’utilisateur/profil d’accès. Si cela se poursuit jusqu’à ce qu’il n’y ait pas de sessions actives pour la combinaison, l’entrée est supprimée du tableau des limites de session. Toutes les entrées de nom d’utilisateur/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 d’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 ppp avec VLAN autoconfigurés, les deux noms d’utilisateur de la pile sont utilisés pour l’authentification et sont donc tous deux 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 pour un abonné ayant ce nom d’utilisateur et ce profil d’accès.

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

  1. Le nombre de sessions actives est enregistré sous la forme de cinq dans l’entrée de la table de 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 déconnecte, réduisant le nombre de sessions actives à quatre.

  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 encore dépassée (quatre > deux).

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

  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 où un utilisateur malveillant effectue plusieurs tentatives de connexion avec le nom d’utilisateur et le profil d’accès corrects, mais le bon mot de passe. Les nombreuses tentatives de connexion peuvent dépasser la limite de session configurée, mais cela ne se produit pas parce que le nombre de sessions suivies n’est incrémenté que lorsque l’état de la session 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 la CLI

  • Vous permet de limiter le nombre de sessions localement sur le routeur, plutôt que de dépendre 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 de vente en gros de couche 2, certains 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é. Cette modification est également appelée stripping de nom d’utilisateur, car certains des caractères du nom d’utilisateur sont dépouillé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 de l’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 (primaire) par défaut est pris en charge. Étant donné que le grossiste différencie plusieurs détaillants en plaçant chacun dans un LS:RI différent, les noms d’utilisateur sont correctement modifiés pour chaque détaillant.

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

Prenons les exemples suivants :

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

  • Vous spécifiez un délimiteur, @. Le nom d’utilisateur est user1@test@example.com. Dans ce cas, la direction parse entraîne des noms d’utilisateur différents.

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

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

  • Vous spécifiez deux délimiteurs, @ et /. Le nom d’utilisateur est user1@bldg1/example.com. La direction parse se traduit par différents noms d’utilisateur.

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

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

Vous pouvez configurer un profil d’accès abonné de sorte qu’une partie de chaque chaîne de connexion d’abonné soit dépouillée, puis utilisée 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 RADIUS Access-Request, Acct-Start et Acct-Stop, 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 des abonnés

  • 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 de délai d’expiration des sessions des abonnés

Les options de délai d’expiration des sessions des abonnés vous permettent de limiter l’accès des abonnés en fonction de la durée 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 avec tunnel L2TP et aux sessions d’abonnés terminées par PPP. Pour les abonnés DHCP, le délai d’expiration des sessions limite le temps de bail DHCP.

Note:

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

Pour configurer les limitations des sessions des abonnés, configurez les options de session dans le profil du client qui s’applique à l’abonné :

  • Terminez l’abonné lorsque le délai de session configuré expire, quelle que soit l’activité.

  • Terminez l’abonné lorsqu’il n’y a pas de trafic de données entrant ou sortant pendant la durée du délai d’inactivité configuré.

  • Terminez l’abonné lorsqu’il n’y a pas de trafic de données entrant pendant la durée du délai d’inactivité configuré ; ignorer le trafic sortant.

Par exemple, pour configurer les options de timeout de session dans le acc-prof profil du client, en spécifiant un délai d’attente de 15 minutes, que seul le trafic entrant est surveillé et que la session s’arrête après 120 minutes :

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

Vous pouvez contrôler la mesure dans laquelle les abonnés légitimes peuvent partager leurs informations d’identification en limitant le nombre de sessions abonnées 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 par 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 à cinq pour le profil d’accès isp-weg-4 :

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

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

  • Pour tous les noms d’utilisateur sur tous les profils d’accès.

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

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

  • Pour tous les noms d’utilisateur dans 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 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 stripping de nom d’utilisateur, car certains des caractères du nom d’utilisateur sont dépouillé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 de gros de couche 2, où les 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é.

Les paramètres de modification sont appliqués en fonction d’un profil d’accès de l’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 (primaire) par défaut est pris en charge. Étant donné que le grossiste différencie plusieurs détaillants en plaçant chacun dans un LS:RI différent, les noms d’utilisateur sont correctement modifiés pour chaque détaillant.

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

Pour configurer la modification du nom d’utilisateur :

  1. Définissez un profil composé d’un ensemble d’options AAA permettant d’autoriser et de configurer un ou plusieurs abonnés avec un profil d’accès d’abonné.
    1. Spécifiez le nom du profil d’accès de l’abonné qui inclut la configuration de déshabillage du nom d’utilisateur.
    2. (Facultatif) Spécifiez le système logique:routing-instance (LS:RI) que la session d’abonné utilise pour les interactions AAA (RADIUS), comme l’authentification et la comptabilisation. Par exemple, cela peut correspondre au LS:RI d’un fai de vente au détail qui fournit des services à l’abonné.
    3. (Facultatif) Spécifiez le système logique:routing-instance (LS:RI) dans lequel l’interface d’abonné est placée. Par exemple, cela peut correspondre à l’interface de BAC sur le LNS accessible par toutes les demandes provenant d’une résidence d’abonnés.
  2. Configurez les options de session dans le profil d’accès qui spécifient comment les noms d’utilisateur sont retirés.
    1. Spécifiez un ou plusieurs délimiteurs pour marquer la frontière entre les parties rejetées et conservées du nom d’utilisateur d’origine.
    2. (Facultatif) Spécifiez la direction dans laquelle le nom d’utilisateur d’origine est examiné pour trouver un délimiteur. La direction par défaut est de gauche à droite.
  3. (Facultatif) Spécifiez que les options AAA sont par interface lorsque les abonnés dynamiques sont authentifiés.
  4. (Facultatif) Spécifiez que les options AAA font partie des options PPP d’un profil de groupe qui s’applique aux abonnés PPP tunnelnés au LNS.

Dans l’exemple suivant, le profil d’options AAA, aaa1, spécifie un profil d’accès des abonnés, entA, pour les abonnés dans le système logique par défaut et 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élimiteur, @, soit trouvé. Le profil d’options AAA est appliqué aux abonnés PPP tunnelés qui appartiennent 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. Lorsque ce nom est examiné, le délimiteur et la chaîne example.com sont supprimés, laissant un nom d’utilisateur modifié1. Notez que le résultat est le même si la direction parse est définie pour examiner le nom de droite à gauche, car un seul délimiteur est défini et un seul est présent dans le nom d’utilisateur d’origine.

Supposons maintenant que l’abonné se connecte avec son nom d’utilisateur, user1@test@example.com. Pour un nom d’utilisateur comme celui-ci, la direction d’analyse fait une 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 analyse de gauche à droite. Ce délimiteur et la chaîne test@example.com sont supprimés, laissant l’utilisateur1 comme nom d’utilisateur modifié.

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

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

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

Pour le nom d’utilisateur user1@bldg1/example.com, l’analyse de gauche à droite identifie d’abord le @delimiter et le nom d’utilisateur modifié est user1. L’analyse de droite à gauche identifie le / délimiteur en premier et le retire de la chaîne example.com, en laissant un nom d’utilisateur modifié de user1@bldg1.

Suppression des VLAN dynamiques d’abonnés inactifs

Les délais d’expiration des sessions des abonnés vous permettent de limiter l’accès des abonnés en fonction de la durée d’activation de la session, de la durée d’inactivité de l’utilisateur ou des deux. Dans les configurations utilisant des VLAN d’abonnés créés dynamiquement, le délai d’inactivité également :

  • 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, dans le cas où aucune session client n’est créée sur le VLAN dynamique ou à la suite d’une erreur lors de la création de session ou l’authentification du client où aucune session client n’est créée sur le VLAN dynamique).

Note:

Les délais de session ne sont généralement pas utilisés pour supprimer les VLAN dynamiques d’abonnés. Le délai d’expiration ne peut être utile que dans des cas d’utilisation très limités. Un cas peut être lorsque les VLAN dynamiques n’ont pas de protocole de couche supérieure qui permet de déterminer quand le VLAN est supprimé avec l’instruction remove-when-no-subscribers ; par exemple, lorsque le VLAN prend en charge IP over 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 de votre serveur RADIUS.

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

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