Tunnelisation LAC L2TP pour les abonnés

Sélection lorsque le basculement entre les niveaux de préférence est configuré

Lorsqu’un utilisateur tente de se connecter à un domaine dans une configuration par défaut, c’est-à-dire lorsque le basculement à l’intérieur d’un niveau de préférence et l’équilibrage de charge ne sont pas configurés, le LAC recherche les destinations valides vers le domaine demandé, en commençant par le niveau de préférence de tunnel le plus élevé. Si aucune destination valide n’est trouvée ou si la tentative de connexion à une destination échoue, le LAC descend au niveau inférieur suivant pour poursuivre la recherche. Le processus de recherche est le même pour tous les niveaux, sauf pour le plus faible :

1. La recherche commence par identifier les tunnels avec des destinations valides au niveau de préférence parmi tous les tunnels spécifiés dans le profil de tunnel du domaine.

2. Toutes les destinations verrouillées et valides sont placées dans la liste DestinationsLockedNotContacted. Aucune tentative n’est faite pour contacter l’une de ces destinations.

3. Parmi les destinations valides déverrouillées, le LAC en sélectionne une au hasard et tente de se connecter par le biais du tunnel associé ; si le tunnel n’a pas de sessions en cours, le LAC doit établir le tunnel.

   Remarque :

   La sélection aléatoire est le comportement par défaut. Le comportement est différent lorsque l’équilibrage de charge pondéré ou l’équilibrage de charge égal à destination est configuré. Voir Sélection lors de la répartition de la charge de session entre plusieurs LNS pour plus d’informations sur l’équilibrage de charge.

   • Si la tentative réussit, le LAC signale la connexion réussie au client PPP. Le BAC efface également toutes les destinations de la liste DestinationsLockedNotContacted.

   • Si le LAC ne reçoit pas de réponse, il retente la tentative jusqu’au nombre maximum de nouvelles tentatives. Si le LAC épuise les nouvelles tentatives sans recevoir de réponse, la tentative est considérée comme infructueuse et le LAC marque la destination comme inaccessible en verrouillant la destination. Il place la destination sur la liste de verrouillage et démarre le minuteur de verrouillage de destination.

4. Ce que le BAC fera ensuite dépend du niveau de préférence actuel.

   • S’il ne s’agit pas du niveau de préférence le plus bas, le BAC passe au niveau de préférence inférieur suivant et poursuit le processus de recherche.

   • S’il s’agit du niveau de préférence le plus bas et que la liste DestinationsLockedNotContacted n’est pas vide, le LAC déverrouille toutes les destinations de la liste DestinationsLockedNotContacted et revient au niveau de préférence le plus élevé et redémarre le processus de recherche.

   • S’il s’agit du niveau de préférence le plus bas et que la liste DestinationsLockedNotContacted est vide, ce qui signifie que toutes les destinations valides ont été tentées, le LAC signale un échec de connexion au client PPP.

5. Lorsque les destinations valides d’un niveau sont toutes verrouillées, ce que le LAC fait ensuite dépend du niveau de préférence actuel.

   • S’il ne s’agit pas du niveau de préférence le plus bas, le BAC passe au niveau de préférence inférieur suivant et poursuit le processus de recherche.

   • S’il s’agit du niveau de préférence le plus bas, le LAC sélectionne la destination verrouillée et valide avec le temps de verrouillage restant le plus court. Il efface le délai de verrouillage et tente de se connecter à la destination et d’établir une session.

     • Si la tentative réussit, le LAC signale la connexion réussie au client PPP.

     • Si la tentative échoue et que la liste DestinationsLockedNotContacted est vide, ce qui signifie que toutes les destinations valides ont été tentées, le LAC signale un échec de connexion au client PPP.

     • Si la tentative échoue et que la liste DestinationsLockedNotContacted n’est pas vide, le LAC déverrouille toutes les destinations de la liste DestinationsLockedNotContacted, revient au niveau de préférence le plus élevé et redémarre le processus de recherche.

6. Lorsqu’aucune destination valide n’est présente, ce que le LAC fait ensuite dépend du niveau de préférence actuel.

   • S’il ne s’agit pas du niveau de préférence le plus bas, le BAC passe au niveau de préférence inférieur suivant et poursuit le processus de recherche.

   • S’il s’agit du niveau de préférence le plus bas et que la liste DestinationsLockedNotContacted est vide, ce qui signifie que toutes les destinations valides ont été tentées, le LAC signale un échec de connexion au client PPP.

   • S’il s’agit du niveau de préférence le plus bas et que la liste DestinationsLockedNotContacted n’est pas vide, la LAC déverrouille toutes les destinations de la liste DestinationsLockedNotContacted, revient au niveau de préférence le plus élevé et redémarre le processus.

7. Le processus de recherche et de basculement passe d’un niveau à l’autre jusqu’à ce qu’une session soit établie ou que toutes les destinations valides aient été tentées (aucune destination ne figure dans la liste DestinationsLockedNotContacted) et que la connexion échoue.

La figure 1 illustre les conditions et les points de décision possibles qui déterminent le choix d’une destination et du tunnel correspondant pour le cas par défaut, où le basculement se produit entre les niveaux de préférence de tunnel.

Figure 1 : Processus de sélection de la destination et du tunnel avec basculement entre les niveaux de préférence

Par exemple, supposons que le profil tunnel inclut les tunnels suivants, chacun avec une destination valide :

• Préférence 0, Tunnel 1, 192.168.10.10

• Préférence 1, Tunnel 2, 192.168.22.22

• Préférence 1, Tunnel 3, 192.168.33.33

• Préférence 2, Tunnel 4, 192.168.44.44

Le basculement dans les préférences et l’équilibrage de charge ne sont pas configurés.

Lorsqu’un utilisateur PPP tente de se connecter au domaine, le LAC agit comme suit :

1. Au niveau de préférence le plus élevé, 0, le LAC sélectionne le tunnel 1, car il s’agit du seul tunnel du niveau avec une destination valide. Le LAC tente d’atteindre 192.168.10.10.

2. Cette tentative de connexion échoue, le LAC verrouille donc 192.168.10.10. Il n’est pas pris en compte à nouveau lors de cette tentative de connexion et ne peut être pris en compte pour aucune tentative de connexion tant que le délai de verrouillage de destination n’a pas expiré.

3. Le LAC passe au niveau suivant, le niveau de préférence 1, pour atteindre une destination pour le domaine. Le LAC sélectionne au hasard entre 192.168.22.22 par le tunnel 2 et 192.168.33.33 par le tunnel 3. Il sélectionne 192.168.22.22 et tente de se connecter via le tunnel 2.

4. La tentative de connexion à 192.168.22.22 échoue, de sorte que le LAC verrouille 192.168.22.22. Il n’est pas pris en compte à nouveau lors de cette tentative de connexion et ne peut être pris en compte pour aucune tentative de connexion tant que le délai de verrouillage de destination n’a pas expiré.

   Remarque :

   Même si le tunnel 3 a une destination valide déverrouillée, le LAC ne peut pas maintenant sélectionner ce tunnel pour atteindre 192.168.33.33, car le LAC ne peut faire qu’une seule tentative pour atteindre une destination valide chaque fois qu’il recherche dans un niveau où la méthode de basculement se situe entre deux niveaux de préférence.

5. Le LAC tombe au niveau final (le plus bas) dans cet exemple, le niveau de préférence 2. Le LAC sélectionne le tunnel 4 car c’est le seul tunnel du niveau avec une destination valide. Le LAC tente de joindre 192.168.44.44.

6. La tentative de connexion à 192.168.44.44 échoue également, de sorte que le LAC verrouille 192.168.44.44. Il n’est pas pris en compte à nouveau lors de cette tentative de connexion et ne peut être pris en compte pour aucune tentative de connexion tant que le délai de verrouillage de destination n’a pas expiré.

7. Étant donné qu’il s’agit du niveau le plus bas et que la liste DestinationsLockedNotContacted est vide, le LAC rejette la demande de connexion du client PPP.

   Les destinations 192.168.10.10, 192.168.22.22 et 192.168.44.44 ont été verrouillées, mais n’ont pas été ajoutées à la liste DestinationsLockedNotContacted, car le BAC les a verrouillées après avoir tenté de se connecter. La destination 192.168.33.33 n’a pas été contactée, mais n’a pas été ajoutée à la liste DestinationsLockedNotContacted car elle n’est pas verrouillée.

8. Le client tente à nouveau de se reconnecter et le LAC répète le processus de sélection du tunnel, en recommençant au niveau de préférence 0 pour vérifier la présence d’une destination non verrouillée et valide, puis en passant d’un niveau à l’autre si nécessaire.

9. Au niveau de préférence 0, 192.168.10.10 est la seule destination valide et est toujours verrouillée, de sorte que le LAC ne peut pas tenter de se connecter à la destination. Le LAC ajoute 192.168.10.10 à la liste DestinationsLockedNotContacted, puis passe au niveau de préférence 1.

   Remarque :

   N’oubliez pas que le minuteur de verrouillage de destination s’applique globalement, de sorte qu’il persiste sur plusieurs connexions d’abonnés. La liste DestinationsLockedNotContacted s’applique uniquement à une connexion d’abonné donnée et ne persiste pas. Même si BAC a communiqué avec le 192.168.10.10 au sujet de cet abonné, c’était lors d’une tentative de connexion précédente. Lors de cette tentative de connexion, il ne peut pas contacter la destination en raison du verrouillage et place par conséquent la destination dans la liste DestinationsLockedNotContacted.

10. Au niveau de préférence 1, 192.168.22.22 est toujours verrouillé, donc le LAC ajoute 192.168.22.22 à la liste DestinationsLockedNotContacted. 192.168.33.33 est toujours disponible. Le LAC tente de se connecter à 192.168.33.33 par le tunnel 3.

11. Cette tentative de connexion échoue, le LAC verrouille donc 192.168.33.33. Il n’est pas pris en compte à nouveau lors de cette tentative de connexion et ne peut être pris en compte pour aucune tentative de connexion tant que le délai de verrouillage de destination n’a pas expiré. Le LAC tombe au niveau de préférence 2.

12. 192.168.44.44 est toujours verrouillé, donc le LAC ajoute 192.168.44.44 à la liste DestinationsLockedNotContacted.

13. Il s’agit du niveau de préférence le plus bas, mais cette fois, la liste DestinationsLockedNotContacted n’est pas vide ; Il contient 192.168.10.10, 192.168.22.22 et 192.168.44.44. Le LAC déverrouille toutes les destinations de la liste DestinationsLockedNotContacted, puis revient au niveau de préférence le plus élevé.

14. Au niveau de préférence 0, le LAC tente de se connecter à 192.168.10.10 car il a été déverrouillé. Le LAC établit la session et signale la connexion réussie au client PPP.

Bien que le BAC ne tente pas de communiquer avec une destination qui est verrouillée, il y a un cas particulier où le BAC a atteint le niveau de préférence le plus bas. Le niveau doit avoir plus d’une destination valide et toutes doivent être verrouillées. Par exemple, supposons que le profil tunnel inclut les tunnels suivants, chacun avec une destination valide :

• Préférence 0, Tunnel 1, 192.168.10.10

• Préférence 1, Tunnel 2, 192.168.22.22. La destination est verrouillée avec le minuteur de verrouillage actuellement à 245 secondes.

• Préférence 1, Tunnel 3, 192.168.33.33. La destination est verrouillée avec le minuteur de verrouillage actuellement à 180 secondes.

Le basculement dans les préférences et l’équilibrage de charge ne sont pas configurés.

Lorsqu’un utilisateur PPP tente de se connecter au domaine, le LAC agit comme suit :

1. Au niveau de préférence le plus élevé, 0, le LAC sélectionne le tunnel 1, car il s’agit du seul tunnel du niveau avec une destination valide. Le LAC tente d’atteindre 192.168.10.10.

2. Cette tentative de connexion échoue, le LAC verrouille donc 192.168.10.10. Il n’est pas pris en compte à nouveau lors de cette tentative de connexion et ne peut être pris en compte pour aucune tentative de connexion tant que le délai de verrouillage de destination n’a pas expiré.

3. Le LAC passe au niveau suivant, le niveau de préférence 1, pour atteindre une destination pour le domaine. Les deux destinations valides à ce niveau, 192.168.22.22 et 192.168.33.33, sont verrouillées.

4. Le LAC ajoute les deux destinations à la liste DestinationsLockedNotContacted.

5. Comme il s’agit du niveau de préférence le plus bas, le LAC détermine quelle destination a un temps de verrouillage restant le plus court. Il sélectionne 192.168.33.33 car il a un temps de verrouillage restant plus court (180 secondes) que 192.168.22.22 (245 secondes). Le LAC déverrouille 192.168.33.33 et tente de se connecter via le tunnel 3. Par conséquent, le BAC retire également 192.168.33.33 de la liste DestinationsLockedNotContacted.

6. La tentative de connexion réussit et une session est établie à 192.168.33.33. Le LAC signale une connexion réussie au client PPP.

Sélection lorsque le basculement à l’intérieur d’un niveau de préférence est configuré

Lorsque vous configurez le basculement à l’intérieur d’un niveau de préférence, le processus de sélection de la destination et du tunnel est le même que pour la configuration par défaut, à une exception près : le LAC n’est pas limité à une seule tentative de connexion à un niveau de préférence.

Lorsque le LAC tente de se connecter à une destination valide et déverrouillée sans succès, il verrouille cette destination, mais ne passe pas immédiatement au niveau inférieur suivant. Au lieu de cela, si une autre destination valide et déverrouillée est disponible au même niveau de préférence, le LAC tente de se connecter à cette destination.

Si le LAC ne se connecte pas, il continue d’essayer d’atteindre une destination dans ce niveau de préférence jusqu’à ce qu’il ne reste plus de destinations valides déverrouillées à tenter. À ce moment-là, le LAC descend pour rechercher au niveau de préférence inférieur suivant. À chaque niveau, le BAC recherche et tente de se connecter à une destination valide jusqu’à ce qu’aucune destination valide non verrouillée ne soit disponible.

Si le LAC tombe au niveau de préférence le plus bas et ne trouve aucune destination valide et déverrouillée, le comportement dépend de la liste DestinationsLockedNotContacted :

• Si la liste DestinationsLockedNotContacted n’est pas vide, la LAC déverrouille toutes les destinations de la liste DestinationsLockedNotContacted et revient au niveau de préférence le plus élevé et redémarre le processus de recherche.

• Si DestinationsLockedNotContacted est vide, ce qui signifie que toutes les destinations valides ont été tentées, le LAC signale un échec de connexion au client PPP.

Par exemple, supposons que le profil tunnel spécifie les tunnels et les destinations suivants. L’équilibrage de charge n’est pas configuré. Toutes les destinations sont valables ; tous sont débloqués sauf 192.168.3.3. Les niveaux de préférence pour les tunnels sont attribués comme suit :

• Préférence 0, Tunnel 1, 192.168.1.1, déverrouillé

• Préférence 0, Tunnel 2, 192.168.2.2, déverrouillé

• Préférence 0, Tunnel 3, 192.168.3.3, minuterie de verrouillage 100 secondes

• Préférence 1, Tunnel 4, 192.168.4.4, déverrouillé

• Préférence 1, Tunnel 5, 192.168.5.5, déverrouillé

Dans cet exemple, lorsqu’un utilisateur PPP tente de se connecter au domaine, le LAC agit comme suit :

1. Le LAC sélectionne de manière aléatoire entre les deux destinations déverrouillées et valides au niveau de préférence 0, 192.168.1.1 via le tunnel 1 et 192.168.2.2 via le tunnel 2. Il choisit 192.168.2.2 et tente de se connecter via le tunnel 2.

2. La tentative de connexion à 192.168.2.2 échoue, de sorte que le LAC verrouille 192.168.2.2. Il n’est pas pris en compte à nouveau lors de cette tentative de connexion et ne peut être pris en compte pour aucune tentative de connexion tant que le délai de verrouillage de destination n’a pas expiré.

3. Le LAC tente ensuite de se connecter à 192.168.1.1 via le tunnel 1 au niveau de préférence 0.

4. La tentative de connexion à 192.168.1.1 échoue, de sorte que le LAC verrouille 192.168.1.1. Il n’est pas pris en compte à nouveau lors de cette tentative de connexion et ne peut être pris en compte pour aucune tentative de connexion tant que le délai de verrouillage de destination n’a pas expiré.

5. 192.168.3.3 à travers le tunnel 3 est la seule destination valide restante au niveau de préférence 0, mais elle est verrouillée. Le BAC ajoute 192.168.3.3 à la liste DestinationsLockedNotContacted. BAC n’a pas ajouté 192.168.1.1 et 192.168.2.2 à la liste DestinationsLockedNotContacted, car il les a verrouillés après avoir tenté de les contacter.

6. Comme le niveau 0 n’a plus de destinations valides déverrouillées, le LAC passe au niveau suivant, le niveau de préférence 1, pour atteindre une destination pour le domaine.

7. Au niveau de préférence 1, le LAC sélectionne au hasard 192.168.4.4 et tente de se connecter via le tunnel 4.

8. La tentative de connexion à 192.168.4.4 échoue, de sorte que le LAC verrouille 192.168.4.4. Il n’est pas pris en compte à nouveau lors de cette tentative de connexion et ne peut être pris en compte pour aucune tentative de connexion tant que le délai de verrouillage de destination n’a pas expiré.

9. Le LAC tente ensuite de se connecter à 192.168.5.5 via le tunnel 5 au niveau de préférence 1.

10. La tentative de connexion à 192.168.5.5 échoue, de sorte que le LAC verrouille 192.168.5.5. Il n’est pas pris en compte à nouveau lors de cette tentative de connexion et ne peut être pris en compte pour aucune tentative de connexion tant que le délai de verrouillage de destination n’a pas expiré. Le niveau 1 n’a plus de destinations valides et débloquées. Étant donné que la liste DestinationsLockedNotContacted n’est pas vide, le LAC déverrouille toutes les destinations de la liste (dans ce cas, 192.168.3.3) et revient au niveau de préférence le plus élevé, 0.

11. 192.168.3.3 est maintenant la seule destination déverrouillée au niveau de préférence 0, donc le LAC tente de s’y connecter via le tunnel 3.

12. La tentative de connexion à 192.168.3.3 échoue, de sorte que le LAC verrouille 192.168.3.3. Il n’est pas pris en compte à nouveau lors de cette tentative de connexion et ne peut être pris en compte pour aucune tentative de connexion tant que le délai de verrouillage de destination n’a pas expiré.

13. Parce que le niveau 0 n’a plus de destinations valides déverrouillées, le LAC passe au niveau suivant, le niveau de préférence 1.

14. Le niveau de préférence 1 n’a pas de destinations valides déverrouillées. Le champ DestinationsLockedNotContacted est vide, car le BAC a contacté toutes les destinations valides aux deux niveaux de préférence. Le LAC rejette la demande de connexion du client PPP.

Sélection lors de la répartition de la charge de session entre plusieurs LNS

Plusieurs profils de tunnel peuvent être configurés sur le LAC ; Certains tunnels peuvent partager des destinations. Lorsque le LAC tunnelise la session d’un abonné PPP au LNS, un tunnel doit être sélectionné pour la session d’abonné. Le processus de sélection des tunnels choisit le tunnel ayant la préférence la plus élevée et ayant une destination accessible. Par défaut, le LAC sélectionne aléatoirement un tunnel parmi plusieurs tunnels répondant aux mêmes critères. Vous pouvez également configurer l’équilibrage de charge pour permettre différents choix de sélection. Les deux méthodes d’équilibrage de charge affectent les tunnels et les destinations sélectionnés par le LAC, mais le processus de sélection et de basculement reste le même.

• Équilibrage de charge pondéré
• Équilibrage de charge à destination égale

Scénario 1 : Limite de châssis

Dans le tableau 1, le nombre actuel de sessions L2TP est de 10 000 et la limite de sessions est configurée à 10 000 à tous les niveaux. Lorsqu’une nouvelle session est demandée, la première vérification au niveau du châssis échoue, car le nombre de sessions en cours correspond à la limite configurée. Aucune autre vérification n’est effectuée aux autres niveaux et la demande de session est rejetée. Aucune nouvelle session n’est autorisée à quelque niveau que ce soit tant que le nombre de sessions actuel n’est pas inférieur à 10 000.

Scénario 2 : Limite de tunnel

Dans le Tableau 2, le nombre actuel de sessions L2TP est de 2000. Lorsqu’une nouvelle session est demandée, la première vérification au niveau du châssis réussit, car la limite configurée autorise jusqu’à 10 000 sessions sur le châssis, mais seulement 2 000 sessions sont actuellement actives. La vérification suivante, au niveau tunnel, échoue, car le nombre de sessions actuel correspond à la limite configurée tunnel à la limite de 2000 pour tunnel A.

Aucune autre vérification n’est effectuée aux autres niveaux et la demande de session est rejetée.

Aucune nouvelle session n’est autorisée sur le tunnel A tant que son nombre actuel de sessions n’est pas inférieur à 2000 et que la vérification de session ne peut pas passer. Si cela se produit, les contrôles de l’autre niveau réussissent dans ce scénario car leurs limites configurées sont supérieures à leur nombre actuel.

La limite de sessions de 2000 s’applique à tous les tunnels ; En d’autres termes, chaque tunnel actif a une limite indépendante de 2 000 sessions. La défaillance d’un tunnel n’a aucun effet sur les autres tunnels. Une demande de session sur un autre tunnel passe, tant que le nombre de sessions actuel pour ce tunnel est inférieur à 2000.

Scénario 3 : Limite de groupe de tunnels

Dans le tableau 3, le nombre actuel de sessions L2TP est de 2000. Lorsqu’une nouvelle session est demandée, la première vérification au niveau du châssis réussit, car la limite configurée autorise jusqu’à 10 000 sessions sur le châssis, mais seulement 2 000 sessions sont actuellement actives. La deuxième vérification, au niveau du tunnel, passe également pour la même raison. La vérification suivante, au niveau du groupe de tunnels pour le groupe de tunnels B, échoue, car le nombre de sessions actuel pour le groupe de tunnels B correspond à la limite configurée du groupe de tunnels de 2000.

Aucune autre vérification n’est effectuée aux autres niveaux et la demande de session est rejetée.

Aucune nouvelle session n’est autorisée sur le groupe de tunnels B tant que le nombre de sessions actuel n’est pas inférieur à 2000 et que la vérification de session n’est pas acceptée. Si cela se produit, les contrôles de l’autre niveau peuvent passer car leurs limites configurées sont supérieures à leurs nombres actuels.

Pour les groupes de tunnels, la limite de sessions est configurée par groupe ; En d’autres termes, vous ne pouvez pas spécifier une limite unique qui s’applique à tous les groupes de tunnels. La défaillance d’un groupe de tunnels n’a aucun effet sur les autres groupes de tunnels. Dans ce scénario, une demande de session sur un autre groupe de tunnels est transmise si le nombre de sessions en cours pour ce groupe est inférieur à la limite de sessions configurée.

Scénario 4 : limite de groupe de session

Dans le tableau 4, le nombre actuel de sessions L2TP est de 6000. Lorsqu’une nouvelle session est demandée, la vérification passe pour le châssis, le tunnel et le groupe de tunnels, car la limite configurée pour chacun autorise jusqu’à 10 000 sessions, mais seulement 6 000 sessions sont actuellement actives. La vérification au niveau du groupe de limite de session échoue, car le nombre de sessions actuel pour le groupe de limite de session slg1 correspond à la limite configurée de 6000.

Aucune autre vérification n’est effectuée au niveau restant et la demande de session est rejetée.

Aucune nouvelle session n’est autorisée pour les clients du groupe de limite de session slg1 tant que le nombre de sessions actuel du groupe n’est pas inférieur à 6000 et que la vérification de session peut réussir. Si cela se produit, la vérification de niveau restante peut passer car sa limite configurée est supérieure à son nombre actuel.

Vous pouvez reconfigurer un groupe de limite de session en supprimant ou en ajoutant des clients sans affecter les sessions en cours. La reconfiguration affecte le nombre de sessions disponibles à établir pour le groupe de clients.

• Si vous supprimez un client, le nombre de nouvelles sessions qui peuvent être établies augmente du nombre de sessions actuelles de ce client.

• Si vous ajoutez un client, le nombre de nouvelles sessions pouvant être établies est réduit du nombre de sessions actuelles de ce client. Le nouveau total de sessions en cours pour les clients existants plus le nouveau client peut dépasser la limite configurée pour le groupe de limite de session. Dans ce cas, aucune session n’est abandonnée, mais aucune nouvelle session ne peut être établie tant que le nombre de sessions ne tombe pas en dessous de la limite de groupe configurée.

Pour approfondir cette question, considérez la séquence d’événements suivante :

1. Le groupe de limite de sessions slg1 a deux clients, ent1-serviceA avec un nombre de sessions actuel de 3500 et ent1-serviceB avec un nombre de sessions actuel de 0. Le groupe slg1 étant limité à 6 000 sessions, vous ne pouvez pas ajouter plus de 2 500 sessions pour ces clients :

   6000 - 3500 = 2500

2. Ensuite, 1000 sessions sont connectées pour le client ent1-service B. Désormais, pas plus de 1500 sessions peuvent être ajoutées pour ces clients :

   6 000 - (3 500 + 1 000) = 1 500

3. Ensuite, supposons que vous supprimiez le client ent1-serviceA du groupe session-limit. La capacité des sessions de groupe passe à 5000 sessions :

   6000 - 1000 = 5000

4. Enfin, vous ajoutez un nouveau client, ent1-serviceC, au groupe session-limit. Ce nouveau client compte actuellement 8000 sessions actives. Dans ce cas, le groupe session-limit compte désormais 9000 sessions :

   1000 + 8000 = 9000

   Aucune session n’est abandonnée même si la limite maximale de sessions pour le groupe, 6000, est dépassée. Aucune nouvelle session ne peut être ajoutée tant que le nombre de sessions n’est pas passé de 9 000 à moins de 6 000.

Scénario 5 : Limite de clients individuels

Dans le Tableau 5, la vérification de session passe pour le châssis, le tunnel et le groupe de tunnels, car leurs limites configurées sont supérieures à leur nombre de sessions actuel. Le client, ent1-serviceA, n’appartient pas à un groupe de limitation de session. La vérification de limite échoue pour le client car son nombre de sessions actuel correspond à la limite configurée de 6000.

Aucune nouvelle session n’est autorisée pour ce client tant que son nombre de sessions actuel n’est pas inférieur à 6000 et que la vérification de session peut réussir. La défaillance d’un client indépendant n’a aucun effet sur les autres clients. Dans ce scénario, une demande de session pour tout autre client indépendant est transmise si le nombre de sessions en cours pour ce client est inférieur à sa limite de session configurée.

La limite de session que vous définissez pour un client individuel (qui ne fait pas partie d’un groupe de limite de session) s’applique par groupe de tunnel. Plusieurs LAC avec le même nom d’hôte source, mais des adresses IP sources différentes, sont traités comme le même client.

Supposons que vous ayez trois LAC, A, B et C. Tous les trois ont le même nom d’hôte source, ce-lac. LAC A et LAC B établissent des sessions avec un LNS via l’adresse de passerelle associée au groupe de tunnels 1. LAC C établit les sessions via une passerelle différente associée au groupe de tunnels 2. Les LAC ayant le même nom d’hôte, la configuration du client est la même pour les trois. Toutefois, la limite de session client s’applique différemment aux LAC en raison des groupes de tunnels.

Supposons que la limite de sessions client soit de 100. Étant donné que LAC A et LAC B créent tous deux des sessions dans le groupe de tunnels 1, ils doivent partager la limite de clients. Cela signifie que le nombre total de sessions autorisées pour LAC A et LAC B combinés est de 100.

LAC C crée des sessions dans un autre groupe de tunnels, 2. Étant donné que la limite de sessions client s’applique par groupe de tunnels, LAC C a droit à 100 sessions, quel que soit le nombre de sessions déjà établies par LAC A et LAC B.