Options de session pour l’accès abonné
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 abonné, d’authentification, d’autorisation et de comptabilisation.
Présentation des options de session pour l’accès abonné
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 résilié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 et 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é.
- Délais d’expiration des sessions de l’abonné
- Limites de sessions d’abonnés par nom d’utilisateur et profil d’accès
- Avantages de la limitation des sessions pour les noms d’utilisateur avec la CLI
- Modification du nom d’utilisateur de l’abonné
- Avantages de la modification du nom d’utilisateur de l’abonné
Délais d’expiration des sessions de l’abonné
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 d’accès fixe pendant laquelle l’abonné est autorisé à y accéder. Utilisez un délai d’inactivité pour spécifier une période maximale pendant laquelle l’abonné peut être inactif. Vous pouvez utiliser ces délais d’attente séparément ou ensemble. Par défaut, aucun délai d’attente n’est présent.
Pour tous les types d’abonnés autres que DHCP (par exemple, les abonnés tunnelisés L2TP et terminés par 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 la session est utilisée pour limiter le bail lorsqu’aucune autre configuration de durée de bail n’est présente. 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 les statistiques comptables de l’abonné. Le routeur détermine l’inactivité de l’abonné 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 un sens ou dans l’autre.
Si vous le souhaitez, vous pouvez 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 celui-ci n’est pas actif, par exemple lorsque le LNS n’a pas activé les keepalives PPP et ne peut donc pas détecter que l’homologue n’est pas actif. Dans ce cas, étant donné que par défaut le 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 LAC peut détecter que l’homologue est inactif, puis initier la déconnexion.
À l’expiration de l’un ou l’autre des délais d’expiration, les abonnés non-DHCP sont déconnectés avec élégance, de la même manière qu’une déconnexion initiée par RADIUS ou une déconnexion initiée par l’interface de ligne de commande. Les abonnés DHCP sont déconnectés. La valeur Acct-Terminate-Cause [attribut RADIUS 49] inclut un code motif de 5 pour un délai d’expiration de session et un code de 4 pour un délai d’inactivité.
Vous pouvez configurer ces limitations d’accès abonné 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 donnée et doivent se déconnecter à l’expiration de la session.
Lorsqu’un CoA arrive avec un délai d’expiration de session, le délai d’expiration est compté à partir du moment où la session s’est activée. Les conséquences sont les suivantes :
Si la valeur de l’attribut est supérieure à la disponibilité de la session en cours et comprise entre les valeurs minimale et maximale du délai d’expiration, 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 voir cela avec les mêmes valeurs est que le temps de 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 supplémentaires se sont écoulées.
Si la valeur de l’attribut est supérieure à la durée de disponibilité de la session en cours, mais inférieure à la valeur minimale du délai d’expiration de 60 secondes, l’abonné est déconnecté lorsque la disponibilité atteint 60 secondes.
Si la valeur de l’attribut est supérieure à la durée de disponibilité de la session en cours, mais supérieure à la valeur maximale du délai d’expiration 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 en cours, le délai d’expiration de la session n’est pas appliqué. AAA répond au message CoA par un NAK. Par exemple, la session n’est pas affectée si le délai d’expiration de la session est de 60 secondes, mais que le temps de 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 cette activation échoue, le délai d’expiration de la session n’est pas appliqué. AAA répond au message CoA par un NAK.
Si la valeur du délai d’expiration de la session est 0, tout délai d’expiration de session existant pour cette session est annulé.
Les fournisseurs de services choisissent souvent d’appliquer les mêmes restrictions à un grand nombre d’abonnés. Vous pouvez réduire l’effort de provisionnement RADIUS pour ce scénario en définissant les limites pour les abonnés d’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.
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 de la session est basé uniquement sur l’heure et non sur l’activité de l’utilisateur, il est susceptible d’interrompre les abonnés qui utilisent activement un service vocal et de mettre fin à leurs appels de manière inattendue (du point de vue de l’abonné). Ce résultat est particulièrement préoccupant pour les appels des services d’urgence.
Nous vous recommandons de ne pas configurer de délai d’inactivité 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’en informer le client. Par conséquent, ces abonnés sont obligés de redémarrer leur appareil 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 la résiliation du lien PPP avec l’homologue. En fonction de l’appareil CPE, cette interruption permet à l’homologue de réessayer automatiquement la connexion, soit à la demande, soit immédiatement. Dans les deux cas, aucune intervention de l’abonné n’est requise.
La plage disponible pour définir un délai d’expiration est la même, que vous le configuriez dans l’interface de ligne de commande ou via les attributs RADIUS :
Les délais d’expiration de session peuvent être définis de 1 minute à 527 040 minutes dans l’interface de ligne de commande 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 de 10 minutes à 1440 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 qu’elles correspondent aux plages prises en charge. Par exemple, pour Session-Timeout [27] :
Une valeur de zéro est considérée comme un délai d’expiration.
Une valeur comprise entre 1 et 59 est portée à 60 secondes.
Une valeur supérieure à 31 622 400 est réduite à 31 622 400 secondes.
Pour le délai d’inactivité [28] :
Une valeur de zéro est considérée comme un délai d’expiration.
Une valeur comprise entre 1 et 599 est portée à 600 secondes.
Une valeur supérieure à 86 400 est réduite à 86 400 secondes.
Dans les configurations utilisant des VLAN abonnés créés dynamiquement, le délai d’inactivité supprime également les VLAN abonnés inactifs lorsque le seuil d’inactivité est atteint. Outre la suppression des VLAN d’abonnés dynamiques 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 suite à l’apparition d’une erreur lors de la création de session ou de l’authentification du client alors qu’aucune session client n’est créée sur le VLAN dynamique).
Les délais d’expiration de session et d’inactivité pour la suppression de VLAN d’abonnés dynamiques ne sont utiles que dans des cas d’utilisation très limités. En règle générale, aucun des deux délais d’attente n’est configuré à cet effet.
Une circonstance où ils peuvent être utiles est lorsque les VLAN dynamiques n’ont pas de protocole de couche supérieure permettant de déterminer quand le VLAN est supprimé 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. Toutefois, l’accès d’entreprise 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’attente dus à l’inactivité, comme cela pourrait être souhaitable pour les abonnés résidentiels.
Un délai d’inactivité peut être approprié dans certaines situations de vente en 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’inactivité pour la suppression dynamique des VLAN, gardez les points suivants à l’esprit :
Le délai d’inactivité commence après la création d’une interface VLAN d’abonné dynamique ou l’arrêt de l’activité de trafic sur une interface VLAN d’abonné dynamique.
Si une nouvelle session client est créée ou si une session client est réactivée avec succès, le délai d’inactivité du client est réinitialisé.
La suppression des VLAN abonnés inactifs ne fonctionne qu’avec les VLAN qui ont été authentifiés.
Limites de 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 ainsi des ressources du fournisseur de services sans bénéfice pour le fournisseur. À partir de Junos OS version 18.4R1, vous pouvez contrôler ou empêcher le partage des identifiants 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 réaliser ce contrôle avec RADIUS, mais la configuration locale de la limite sur le BNG élimine la dépendance à 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 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 comptabilisée comme une demande bloquée.
Lorsque authd reçoit une demande de déconnexion ou de fermeture du client pour une session, le nombre de sessions suivies est décrémenté pour cette entrée de nom d’utilisateur/de profil d’accès. Si cette opération persiste jusqu’à ce qu’il n’y ait plus de sessions actives pour la combinaison, l’entrée est supprimée de la table 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 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.
Pour les sessions d’abonnés empilées, telles que PPP avec des VLAN configurés automatiquement, les deux noms d’utilisateur de la pile sont utilisés pour l’authentification et, par conséquent, ils sont tous deux comptabilisés dans la limite de session.
La limite configurée s’applique aux abonnés actifs existants, mais les sessions existantes ne sont pas supprimées 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 l’exemple d’une situation où cinq sessions sont actuellement actives pour une combinaison nom d’utilisateur/profil d’accès donnée lorsque vous configurez une limite de deux.
Le nombre de sessions actives est enregistré sous la forme de cinq dans l’entrée de la table des limites de session de la combinaison.
Un nouvel abonné avec 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).
Un abonné existant se déconnecte, ce qui réduit le nombre de sessions actives à quatre.
Un nouvel abonné avec 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).
Trois abonnés existants se déconnectent, ce qui réduit le nombre de sessions actives à une.
Un nouvel abonné avec 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 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 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 la CLI
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 des connexions multiples.
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 du nom d’utilisateur, car certains des caractères du nom d’utilisateur sont supprimés et supprimé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 l’instance logique system :routing (LS :RI) utilisée par l’abonné. Seul le système logique par défaut (principal) est pris en charge. Étant donné que le grossiste fait la différence entre plusieurs détaillants en les plaçant chacun dans un LS :RI différent, les noms d’utilisateur sont modifiés de manière appropriée pour chaque détaillant.
Vous pouvez sélectionner jusqu’à huit caractères comme délimiteurs pour marquer la limite entre les parties supprimé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 située à droite du délimiteur sélectionné est supprimée en même temps que le délimiteur. En configurant plusieurs délimiteurs, une structure de nom d’utilisateur donnée peut entraîner des noms d’utilisateur modifiés différents. Vous pouvez configurer la direction dans laquelle le nom d’origine est analysé pour déterminer quel délimiteur marque la limite. Par défaut, la direction d’analyse 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 d’analyse n’a pas d’importance. Dans les deux cas, le délimiteur unique est trouvé et example.com est ignoré. 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 d’analyse donne des noms d’utilisateur différents.
La direction d’analyse est de gauche à droite : le @ le plus à gauche est identifié comme le délimiteur et test@example.com est ignoré. Le nom d’utilisateur modifié est user1.
La direction d’analyse est de droite à gauche : le @ le plus à droite est identifié comme le délimiteur et example.com est ignoré. 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 d’analyse génère différents noms d’utilisateur.
La direction d’analyse est de gauche à droite : le @ est identifié comme le délimiteur et bldg1/example.com est ignoré. Le nom d’utilisateur modifié est user1.
La direction d’analyse est de droite à gauche : le / est identifié comme le délimiteur et example.com est ignoré. Le nom d’utilisateur modifié est user1@bldg1.
Vous pouvez configurer un profil d’accès d’abonné afin qu’une partie de chaque chaîne de connexion d’abonné soit supprimée et ensuite 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 initiées par RADIUS et les demandes de modification d’autorisation (CoA).
Avantages de la modification du nom d’utilisateur de l’abonné
Permet aux fournisseurs de services réseau wholesale de couche 2 de diriger facilement les abonnés vers le réseau d’entreprise de vente au détail approprié.
Voir aussi
Options de délai d’expiration de la session de l’abonné
Les options de délai d’expiration de session de l’abonné vous permettent de limiter l’accès de l’abonné 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 à la fois aux sessions d’abonnés tunnelisées par L2TP et aux sessions d’abonnés terminées par PPP. Pour les abonnés DHCP, le délai d’expiration de la session limite la durée du bail DHCP.
Pour configurer les attributs de délai d’expiration dans RADIUS, reportez-vous à la documentation de votre serveur RADIUS.
Pour configurer des limitations sur les sessions d’abonnés, configurez les options de session dans le profil client qui s’applique à l’abonné :
Résilier l’abonné à l’expiration du délai d’expiration de la session configurée, quelle que soit l’activité.
[edit access profile profile-name session-options] user@host# set client-session-timeout minutes
Arrêtez 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é.
[edit access profile profile-name session-options] user@host# set client-idle-timeout minutes
Résilier l’abonné lorsqu’il n’y a pas de trafic de données entrant pendant la durée du délai d’inactivité configuré ; Ignorez le trafic sortant.
[edit access profile profile-name session-options] user@host# set client-idle-timeout minutes user@host# set client-idle-timeout-ingress-only
Par exemple, pour configurer les options de délai d’expiration de session dans le acc-prof
profil client, en spécifiant un délai d’inactivité de 15 minutes, que seul le trafic entrant est surveillé et que la session expire après 120 minutes :
[edit] access { profile { acc-prof { session-options { client-idle-timeout 15; client-idle-timeout-ingress-only; client-session-timeout 120; } } } }
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 identifiants 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.
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 à cinq pour le profil d’accès isp-weg-4 :
[edit access profile isp-weg-4] user@host# set session-limit-per-username 5
Vous pouvez utiliser la commande pour afficher les show network-access aaa statistics session-limit-per-username
statistiques des sessions actives et des demandes bloquées.
Vous pouvez utiliser la clear network-access aaa statistics session-limit-per-username username
commande comme aide au débogage en effaçant les statistiques des requêtes bloquées pour l’un des cas suivants :
Pour tous les noms d’utilisateur de tous les profils d’accès.
Pour un nom d’utilisateur spécifique dans 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 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 d’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 du nom d’utilisateur, car certains des caractères du nom d’utilisateur sont supprimés et supprimé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 capacité peut s’avérer 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 abonné qui détermine également le contexte de l’abonné et de la session ; c’est-à-dire l’instance logique system :routing (LS :RI) utilisée par l’abonné. Seul le système logique par défaut (principal) est pris en charge. Étant donné que le grossiste fait la différence entre plusieurs détaillants en les plaçant chacun dans un LS :RI différent, les noms d’utilisateur sont modifiés de manière appropriée pour chaque détaillant.
Vous pouvez sélectionner jusqu’à huit caractères comme délimiteurs pour marquer la limite entre les parties supprimé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 située à droite du délimiteur sélectionné est supprimée en même temps que le délimiteur. En configurant plusieurs délimiteurs, une structure de nom d’utilisateur donnée peut entraîner des noms d’utilisateur modifiés différents. Vous pouvez configurer la direction dans laquelle le nom d’origine est analysé pour déterminer quel délimiteur marque la limite. Par défaut, la direction d’analyse est de gauche à droite.
Pour configurer la modification du nom d’utilisateur :
Dans l’exemple suivant, le profil d’options AAA, aaa1, 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élimiteur, @, soit trouvé. Le profil d’options AAA est appliqué aux abonnés PPP tunnelisés qui appartiennent au profil de groupe FD1.
[edit access aaa-options aaa1] user@host# access-profile entA user@host# aaa-context default:1 [edit access profile entA session-options strip-user-name] user@host# set delimiter @ user@host# set parse-direction left-to-right [edit access group-profile FD1 ppp] user@host# set ppp-options aaa-options aaa1
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 le example.com de chaîne sont ignorés, laissant un nom d’utilisateur modifié de user1. Notez que le résultat est le même si la direction d’analyse 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 le 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 @ se trouve en premier, car le nom est analysé de gauche à droite. Ce délimiteur et le test@example.com de chaîne sont ignorés, laissant user1 comme nom d’utilisateur modifié.
Que se passe-t-il lorsque la configuration définit une direction d’analyse différente ?
[edit access profile entA session-options strip-user-name] user@host# set delimiter @ user@host# set parse-direction right-to-left
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 ignoré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 de l’analyse en configurant plusieurs délimiteurs comme dans la configuration suivante, où vous spécifiez deux délimiteurs, @ et /.
[edit access profile entA session-options strip-user-name] user@host# set delimiter [@ /] user@host# set parse-direction left-to-right
Pour le nom d’utilisateur user1@bldg1/example.com, l’analyse de gauche à droite identifie d’abord le délimiteur @ et le nom d’utilisateur modifié est user1. En analysant de droite à gauche à la place, vous identifiez d’abord le délimiteur / et le supprimez avec la chaîne example.com, laissant un nom d’utilisateur modifié de user1@bldg1.

Voir aussi
Suppression des VLAN d’abonnés dynamiques 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 de la session, de l’inactivité de l’utilisateur ou des deux. Dans les configurations utilisant des VLAN abonnés créés dynamiquement, le délai d’inactivité est également :
Supprime les VLAN abonnés inactifs lorsque le seuil d’inactivité est atteint.
Supprime les VLAN dynamiques lorsqu’aucune session client n’a été créée (par exemple, dans le cas où 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 du client alors qu’aucune session client n’est créée sur le VLAN dynamique).
En règle générale, les délais d’expiration de session ne sont pas utilisés pour supprimer les VLAN 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 n’ont pas de protocole de couche supérieure permettant de déterminer à quel moment le VLAN est supprimé à l’aide de l’instruction remove-when-no-subscribers
, par exemple, lorsque le VLAN prend en charge l’IP sur Ethernet sans DHCP dans un modèle d’accès professionnel avec des adresses fixes.
Pour configurer l’attribut de délai d’inactivité dans RADIUS, reportez-vous à la documentation de votre serveur RADIUS.
Pour supprimer les VLAN d’abonné dynamiques inactifs :
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.