Commutation de tunnel L2TP pour réseaux multidomaines

Présentation de la commutation de tunnel L2TP

La commutation de tunnel L2TP, également connue sous le nom de multisaut L2TP, simplifie le déploiement d’un réseau L2TP sur plusieurs domaines. Un routeur situé entre un LAC et un LNS est configuré comme un commutateur de tunnel (LTS) L2TP (parfois appelé simplement commutateur de tunnel ou agrégateur de commutation de tunnel (TSA), comme illustré dans la Figure 1. Le LTS est configuré à la fois comme LNS et LAC. Lorsqu’un LAC distant envoie des paquets PPP encapsulés au LNS configuré sur le LTS, le LTS peut transférer ou rediriger les paquets via un autre tunnel vers un autre LNS au-delà du LTS. Le point d’arrêt logique de la session L2TP d’origine est basculé vers un autre point de terminaison.

Par exemple, dans le réseau illustré à la Figure 1, les paquets de l’abonné provisionné par le fournisseur de services A sont initialement ciblés sur le LNS configuré sur le LTS. Le LTS peut rediriger ces paquets vers LNS1.

Figure 1 : Topologie du réseau de commutation de tunnel L2TP Network diagram of L2TP setup showing Service Providers A and B connecting to LACs, L2TP Tunnel Switch, and LNSs with green PPPoE and blue L2TP arrows.

Network diagram of L2TP setup showing Service Providers A and B connecting to LACs, L2TP Tunnel Switch, and LNSs with green PPPoE and blue L2TP arrows.

La commutation de tunnel L2TP simplifie la configuration du réseau lorsque le domaine administratif d’un LAC est différent de celui du LNS souhaité. Par exemple :

Le LTS agit comme le LNS pour plusieurs LAC. Les LAC individuels n’ont pas besoin d’avoir le contrôle administratif ou la capacité requise pour identifier le LNS le plus approprié sur lequel mettre fin à leurs sessions. Le LTS remplit cette fonction et est centralisé dans le LTS.
Le LTS agit comme le LAC pour plusieurs LNS. Lorsqu’un nouveau LAC distant est ajouté au réseau d’un FAI, celui-ci n’a pas besoin de reconfigurer ses routeurs LNS pour accueillir le nouveau LAC, car ils se connectent au LAC sur le LTS.

Dans un réseau de vente en gros de couche 2, le grossiste peut utiliser la commutation de tunnel L2TP pour créer une configuration réseau plus plate et plus facile à gérer. Le grossiste regroupe les sessions de couche 2 d’un LAC destinées à différents FAI (et donc à différents LNS) sur un seul tunnel L2TP. Cette configuration permet d’utiliser une connexion de contrôle L2TP commune pour le LAC.

La figure 2 montre un exemple de commutation de tunnel L2TP pour les appels entrants avec la séquence d’événements suivante :

L’abonné ouvre une session PPP sur le LAC.
Le LAC crée le premier tunnel L2TP vers le LNS configuré sur le LTS et la première session L2TP pour transporter les paquets PPP encapsulés.
Lors de l’authentification de cette première session, le LTS détermine s’il faut retunneliser la session vers un LNS au-delà du LTS, en fonction de la présence ou de l’absence d’un profil de commutateur de tunnel configuré sur le LTS.

Le profil de commutateur de tunnel peut être un profil par défaut ou il peut être appliqué par le serveur RADIUS, une configuration de mappage de domaine ou une configuration de groupe de tunnel.
Si un profil de commutateur de tunnel est configuré, le LTS crée un deuxième tunnel (s’il n’existe pas déjà) vers le LNS au-delà du LTS spécifié dans le profil, puis crée la deuxième session dans ce tunnel.

Figure 2 : Commutation de tunnel L2TP pour les appels Network diagram showing a PPP user connecting via L2TP to a LAC, then tunneled to an LTS with LNS, illustrating tunnel switching to another LNS.

Network diagram showing a PPP user connecting via L2TP to a LAC, then tunneled to an LTS with LNS, illustrating tunnel switching to another LNS.

entrants

Application des profils de commutateur de tunnel
Arrêt des sessions à commutation de tunnel sur le LTS

Application des profils de commutateur de tunnel

Vous pouvez configurer un profil de commutateur de tunnel pour qu’il soit appliqué de plusieurs manières :

Par défaut, le profil s’applique globalement au trafic reçu de tous les LAC
Avec un mappage de domaine appliqué à une session d’abonné
Avec un groupe de tunnels appliqué à une session d’abonné
Dans la configuration de votre serveur RADIUS, renvoyée dans le VSA Tunnel Switch-Profile (26-91)

Vous pouvez configurer plusieurs de ces méthodes d’application. Lorsque plusieurs profils de commutateur de tunnel sont présents, l’ordre de priorité suivant détermine le profil utilisé par le LTS ; l’ordre est du plus élevé (RADIUS) au plus bas (profil par défaut) :

RADIUS VSA 26-91 > carte de domaine > tunnel groupe > profil de commutateur tunnel global

Le profil de commutateur de tunnel doit également faire référence à un profil de tunnel. Ce profil de tunnel spécifie les caractéristiques du second tunnel, vers lequel les paquets de l’abonné sont basculés.

Arrêt des sessions à commutation de tunnel sur le LTS

Les sessions à commutation de tunnel sont arrêtées sur le LTS lorsque l’une des situations suivantes se produit :

L’interface LAC ou LNS du LTS reçoit un message CDN (Call-Disconnect-Notify) (Tableau 1).

Tableau 1 : Cause du message CDN
Le message CDN est reçu le	Quand
Interface LAC	L’une des situations suivantes se produit : La deuxième session ne peut pas être établie. Le LNS distant met fin à la deuxième session.
Interface LNS	L’une des situations suivantes se produit : Le client PPPoE initie une déconnexion. Le LAC d’origine initie l’arrêt du tunnel

Les première et deuxième sessions sont toutes deux terminées, car le LTS relaie le CDN à l’interface qui ne l’a pas reçu. La cause de la déconnexion est la même pour les deux sessions.

L’interface LAC ou LNS du LTS reçoit un message Stop-Control-Connection-Notification (StopCCN) (Tableau 2).

Tableau 2 : Cause de l’arrêt du message CCN
Le message stopCCN est reçu le	Quand
Interface LAC	L’une des situations suivantes se produit : La deuxième session ne peut pas être établie. Le LNS distant termine le deuxième tunnel.
Interface LNS	Le LAC d’origine initie l’arrêt du tunnel.

Le LTS ne relaie pas le message StopCCN, car un tunnel donné peut contenir des sessions commutées et non commutées. Une autre raison dans un scénario de vente en gros est que le tunnel se terminant sur le LNS sur le LTS peut contenir des sessions de LAC de différents fournisseurs. Au lieu de cela, le LTS envoie un message CDN à l’interface qui n’a pas reçu le StopCCN pour mettre fin à la session de commutation de tunnel. Ce CDN relaie le code d’erreur contenu dans le StopCCN.

Une commande administrative clear est émise sur le LTS.

Le Tableau 3 répertorie les actions entreprises lorsqu’une commande administrative clear est émise sur le LTS.

Tableau 3 : mesures LAC, LNS et LTS prises pour les tunnels commutés en réponse à des commandes administratives claires
Commande	Mesure LAC ou LNS	Mesure LTS
`clear services l2tp destination`	Effacez la destination et tous les tunnels et sessions associés.	Pour chaque session commutée dans un tunnel vers la destination, effacez la session commutée mappée correspondante en lui envoyant un message CDN avec la cause définie sur Administratif.
`clear services l2tp destination all`	Effacez toutes les destinations, les tunnels et les sessions associés.	Aucune.
`clear services l2tp session`	Effacer la session.	Effacez la session commutée mappée correspondante pour cette session en lui envoyant un message CDN avec la cause définie sur Administratif.
`clear services l2tp session all`	Effacer toutes les sessions.	Aucune.
`clear services l2tp tunnel`	Nettoyer le tunnel et toutes ses sessions.	Pour chaque session commutée dans le tunnel, effacez la session commutée mappée correspondante en lui envoyant un message CDN avec la cause définie sur Administratif.
`clear services l2tp tunnel all`	Effacez tous les tunnels.	Aucune.

Actions de commutation de tunnel pour les AVP L2TP à la limite de commutation

Lorsque la commutation de tunnel L2TP redirige les paquets vers un autre LNS, elle effectue l’une des actions par défaut suivantes à la limite de commutation pour chaque AVP transporté dans les messages L2TP :

relay—L2TP transmet de manière transparente l’AVP dans le paquet commuté sans modification.
regenerate: L2TP ignore l’AVP reçu qui a été négocié par le premier tunnel et la première session. Il génère un nouvel AVP pour la deuxième session en fonction de la stratégie locale au niveau du LTS et envoie cet AVP dans le paquet commuté. La politique locale peut ou non utiliser la valeur de l’AVP reçue lors de la négociation pour la première session.

Le Tableau 4 répertorie l’action par défaut pour chaque AVP. Les AVP obligatoires sont toujours inclus dans les messages L2TP du LAC ; des AVP facultatifs peuvent être inclus dans les messages.

Vous pouvez éventuellement remplacer l’action par défaut effectuée à la limite de commutation pour le type de support AVP (18), le numéro appelant AVP (22) ou l’AVP d’informations de port Cisco NAS (100). Vous pouvez configurer l’un de ces trois AVP pour qu’il soit supprimé des paquets commutés ou régénéré, ou vous pouvez restaurer l’action de relais par défaut.

Remarque :

Les AVP L2TP dont les valeurs d’attribut sont masquées sont toujours régénérées à la limite de commutation. La valeur est décodée et envoyée en texte clair lorsque le paquet est transféré vers le LNS distant.

Tableau 4 : Mesure par défaut pour la gestion des AVP L2TP à la limite de commutation
Nom (numéro) AVP	AVP Type	L2TP Message Type	Mesure par défaut
ID de session attribué (14)	Obligatoire	CDN, ICRQ	Régénérer
ID de tunnel attribué (9)	Obligatoire	Le SCCRQ	Régénérer
Capacités du support (4)	En option	Le SCCRQ	Régénérer
Type de support (18)	En option	L’ICRQ	Relais
Numéro de série de la cote (15)	Obligatoire	L’ICRQ	Relais
Numéro appelé (21)	En option	L’ICRQ	Relais
Numéro d’appel (22)	En option	L’ICRQ	Relais
Défi (11)	En option	Le SCCRQ	Régénérer
Réponse au défi (13)	En option	Le SCCCN	Régénérer
Cisco NAS Port	En option	L’ICRQ	Relais
Capacité de basculement	En option	Le SCCRQ	Régénérer
Révision du firmware (6)	En option	Le SCCRQ	Régénérer
Capacités de cadrage (3)	Obligatoire	Le SCCRQ	Régénérer
Type de charpente (19)	Obligatoire	L’ICCN	Relais
Nom d’hôte (7)	Obligatoire	Le SCCRQ	Régénérer
Initial reçu LCP CONFREQ (26)	En option	L’ICCN	Relais Lorsque la renégociation LCP est activée avec l’instruction `lcp-negotiation` du profil client sur le LNS, l’AVP est régénérée plutôt que relayée.
Dernier reçu LCP CONFREQ (28)	En option	L’ICCN	Relais Lorsque la renégociation LCP est activée avec l’instruction `lcp-negotiation` du profil client sur le LNS, l’AVP est régénérée plutôt que relayée.
Dernier envoi LCP CONFREQ (27)	En option	L’ICCN	Relais Lorsque la renégociation LCP est activée avec l’instruction `lcp-negotiation` du profil client sur le LNS, l’AVP est régénérée plutôt que relayée.
Type de message (0)	Obligatoire	Tous	Régénérer
ID de canal physique (25)	En option	L’ICRQ	Régénérer
ID de groupe privé (37)	En option	L’ICCN	Relais
Version du protocole (2)	Obligatoire	Le SCCRQ	Régénérer
Défi Authen par procuration (31)	En option	L’ICCN	Relais Lorsque la renégociation LCP est activée avec l’instruction `lcp-negotiation` dans le profil client sur le LNS, l’authentification est également renégociée et l’AVP est régénéré plutôt que relayé.
ID d’authentification de proxy (32)	En option	L’ICCN	Relais Lorsque la renégociation LCP est activée avec l’instruction `lcp-negotiation` dans le profil client sur le LNS, l’authentification est également renégociée et l’AVP est régénéré plutôt que relayé.
Nom de l’autorité mandataire (30)	En option	L’ICCN	Relais Lorsque la renégociation LCP est activée avec l’instruction `lcp-negotiation` dans le profil client sur le LNS, l’authentification est également renégociée et l’AVP est régénéré plutôt que relayé.
Réponse d’Authen par procuration (33)	En option	L’ICCN	Relais Lorsque la renégociation LCP est activée avec l’instruction `lcp-negotiation` dans le profil client sur le LNS, l’authentification est également renégociée et l’AVP est régénéré plutôt que relayé.
Type de proxy (29)	En option	L’ICCN	Relais Lorsque la renégociation LCP est activée avec l’instruction `lcp-negotiation` dans le profil client sur le LNS, l’authentification est également renégociée et l’AVP est régénéré plutôt que relayé.
Taille de la fenêtre de réception (10)	En option	Le SCCRQ	Régénérer
Vitesse de connexion Rx (38)	En option	L’ICCN	Relais
Séquençage requis (39)	En option	L’ICCN	Régénérer
Sous-adresse (23)	En option	L’ICRQ	Relais
Bris d’égalité (5)	En option	Le SCCRQ	Régénérer
Récupération de tunnel	En option	Le SCCRQ	Régénérer
Vitesse de connexion Tx (24)	Obligatoire	L’ICCN	Relais
Nom du fournisseur (8)	En option	Le SCCRQ	Régénérer

Configuration de la commutation de tunnel L2TP

La commutation de tunnel L2TP permet à un routeur configuré en tant que LTS de transférer les paquets PPP transportés sur une session L2TP vers une deuxième session L2TP terminée sur un autre LNS. Pour configurer la commutation de tunnel L2TP, vous devez définir un profil de commutateur de tunnel, puis attribuer ce profil.

Vous pouvez configurer des profils de commutateur de tunnel pour toutes les sessions globales, toutes les sessions d’un groupe de tunnels, toutes les sessions d’un domaine ou dans votre configuration de serveur RADIUS afin qu’elles soient renvoyées dans le VSA de commutateur de tunnel RADIUS (26-91). L’ordre de priorité des profils de commutateur de tunnel provenant de diverses sources est le suivant :

RADIUS VSA 26-91 > carte de domaine > tunnel groupe > profil de commutateur tunnel global

Pour définir un profil de commutateur de tunnel L2TP :

Créez le profil.

(Facultatif) Remplacez les actions par défaut entreprises pour certains AVP L2TP à la limite de commutation.

Spécifiez le profil de tunnel qui définit le tunnel vers lequel le trafic d’abonné est basculé.
Remarque :
Cette étape n’est pas nécessaire pour un profil de commutateur de tunnel spécifié dans le VSA Tunnel Switch-Profile (26-91).
(Facultatif) Appliquez le profil en tant que profil global par défaut pour basculer les paquets de toutes les sessions entrantes à partir du LAC.
(Facultatif) Appliquez le profil dans le cadre d’un groupe de tunnels pour commuter les paquets de toutes les sessions du groupe de tunnels.
Remarque :
Le groupe de tunnels fait partie de la configuration LTS qui lui permet d’agir en tant que LNS pour les sessions d’origine à partir du LAC.

Un groupe de tunnels avec un profil de commutateur de tunnel doit également contenir un profil dynamique, car la commutation de tunnel ne prend en charge que les abonnés dynamiques.
(Facultatif) Appliquez le profil dans le cadre d’un mappage de domaine pour basculer les paquets de toutes les sessions associées au domaine.
Remarque :
Un mappage de domaine ne peut pas avoir à la fois un profil de commutateur de tunnel et un profil de tunnel. Vous devez supprimer l’un si vous ajoutez l’autre.
(Facultatif) Appliquez le profil à l’aide du VSA Tunnel-Switch-Profile [26–91] dans le message RADIUS Access-Accept renvoyé lors de l’authentification de la session du LAC. Reportez-vous à la documentation de votre serveur RADIUS pour déterminer comment configurer cette méthode.

Remarque :
Un profil de commutateur de tunnel spécifié par un serveur RADIUS dans le VSA de commutateur de tunnel (26-91) est prioritaire sur le profil de commutateur de tunnel spécifié dans la configuration de la CLI. Si le VSA de groupe de tunnels (26-64) est reçu en plus du VSA de profil de commutateur de tunnel (26-91), le VSA de profil de commutateur de tunnel (26-91) a la priorité sur le VSA de groupe de tunnels (26-64), ce qui garantit que les abonnés sont tunnel commutés plutôt que tunnelisés LAC.

Par exemple, considérez la configuration suivante. ce qui crée trois profils de commutation tunnel, l2tp-tunnel-switch-profile, lts-profile-groupA et lts-profile-example-com :

Voici un exemple de configuration LTS (commutation de tunnel de couche 2) pour les équipements MX Series :

Le profil l2tp-tunnel-switch-profile est appliqué comme valeur globale par défaut. Lorsque les paquets sont commutés selon ce profil, les valeurs du type porteur AVP (18) et du numéro appelant AVP (22) dans les paquets L2TP sont régénérées en fonction de la politique locale au niveau du commutateur de tunnel L2TP, puis envoyées avec les paquets. L’AVP (100) des informations sur les ports du NAS Cisco est tout simplement abandonnée. Enfin, l2tp-tunnel-profile1 fournit les caractéristiques de configuration du tunnel vers lequel le trafic est basculé.

Le profil de commutateur de tunnel lts-profile-groupA est appliqué au moyen d’un groupe de tunnels, groupA ; il spécifie un profil de tunnel différent, L2TP-tunnel-profile2, et ne remplace aucune action AVP. Le profil de commutateur de tunnel lts-profile-example.com est appliqué au moyen d’un mappage de domaine pour le domaine example.com ; il spécifie un profil de tunnel différent, L2TP-tunnel-profile3, et ne remplace aucune action AVP.

Définition de la taille de la fenêtre de réception L2TP

Vous pouvez configurer la taille de la fenêtre de réception L2TP pour un tunnel L2TP. La taille de la fenêtre de réception spécifie le nombre de paquets qu’un homologue peut envoyer avant d’attendre un accusé de réception du routeur.

Par défaut, la taille de la fenêtre de réception est définie sur quatre paquets. Si la taille de la fenêtre de réception est définie sur sa valeur par défaut, le routeur n’envoie pas la taille de la fenêtre de réception AVP, AVP 10, dans son premier paquet envoyé lors de la négociation du tunnel à son homologue.

Pour configurer la taille de la fenêtre de réception :

Définition du délai d’inactivité du tunnel L2TP

Vous pouvez configurer le LAC ou le LNS pour spécifier la durée d’activité d’un tunnel sans aucune session. Le minuteur d’inactivité démarre à la fin de la dernière session sur le tunnel. Lorsque le délai expire, le tunnel est déconnecté. Ce délai d’inactivité libère des ressources autrement consommées par des tunnels inactifs.

Si vous définissez la valeur du délai d’inactivité sur zéro, le tunnel est forcé de rester actif indéfiniment après la fin de la dernière session jusqu’à ce que l’une des conditions suivantes se produise :

C’est vous qui donnez la clear services l2tp tunnel commande.
L’homologue distant déconnecte le tunnel.

Bonne pratique :

Avant de revenir à une version antérieure de Junos OS qui ne prend pas en charge cette instruction, nous vous recommandons d’annuler explicitement la configuration de la fonctionnalité en l’incluant no idle-timeout au niveau de la [edit services l2tp tunnel] hiérarchie.

Pour définir le délai d’inactivité du tunnel :

Configurez le délai d’expiration.

Définition du délai d’expiration de destruction L2TP

Vous pouvez configurer le LAC ou le LNS pour spécifier combien de temps le routeur tente de maintenir les destinations, les tunnels et les sessions dynamiques après leur destruction. Ce délai d’expiration de destruction facilite le débogage et d’autres analyses en enregistrant les structures mémoire sous-jacentes après l’arrêt de la destination, du tunnel ou de la session. Une destination, un tunnel ou une session dynamique spécifique peut ne pas être maintenu pendant toute cette période si les ressources doivent être récupérées rapidement pour permettre l’établissement de nouveaux tunnels.

Bonne pratique :

Avant de revenir à une version antérieure de Junos OS qui ne prend pas en charge cette instruction, nous vous recommandons d’annuler explicitement la configuration de la fonctionnalité en l’incluant no destruct-timeout au niveau de la [edit services l2tp] hiérarchie.

Pour définir le délai d’expiration de la destruction L2TP :

Configurez le délai d’expiration.

Configuration du délai d’expiration du verrouillage de destination L2TP

Lorsque plusieurs ensembles de paramètres de tunnelisation sont disponibles, L2TP utilise un processus de sélection pour choisir le meilleur tunnel pour le trafic des abonnés. Dans le cadre de ce processus de sélection, L2TP bloque les destinations auxquelles il ne peut pas se connecter lorsqu’un abonné tente d’atteindre un domaine. L2TP place la destination sur la liste de verrouillage de destination et l’exclut de la prise en compte pendant une période configurable appelée délai de verrouillage de destination.

Par défaut, le délai d’expiration du verrouillage de destination est de 300 secondes (5 minutes). Vous pouvez configurer une valeur de 60 à 3600 secondes (1 minute à 1 heure). Lorsque le délai de verrouillage expire, L2TP suppose que la destination est maintenant disponible et l’inclut lors du processus de sélection du tunnel. La période de verrouillage de destination est une valeur globale et n’est pas configurable individuellement pour des destinations, des tunnels ou des groupes de tunnels particuliers.

Remarque :

En général, une destination verrouillée ne peut pas être utilisée tant que le délai de verrouillage n’a pas expiré. Toutefois, lorsque L2TP effectue le processus de sélection du tunnel, dans certaines circonstances, il efface le délai de verrouillage d’une destination verrouillée. Voir Sélection lorsque le basculement entre niveaux de préférence est configuré et Sélection lorsque le basculement à l’intérieur d’un niveau de préférence est configuré dans Vue d’ensemble de la sélection du tunnel LAC pour plus d’informations sur le processus de sélection.

Bonne pratique :

Configurez le délai d’expiration du verrouillage pour qu’il soit égal ou inférieur au délai d’expiration de destruction. Sinon, le délai de destruction expire avant le délai de verrouillage. Dans ce cas, la destination verrouillée est détruite et peut ensuite être remise en service avant l’expiration du délai de cadenassage, annulant ainsi l’efficacité du délai d’expiration du cadenas.

Pour configurer le délai d’expiration du verrouillage de destination :

Spécifiez la période en secondes.

La show services l2tp destination lockout commande affiche la liste de verrouillage de destination et, pour chaque destination, indique le temps restant avant l’expiration de son délai d’expiration. La show services l2tp destination detail commande indique pour chaque destination si elle est verrouillée et attend l’expiration du délai d’expiration ou non.

Suppression d’une destination L2TP de la liste de verrouillage des destinations

Lorsqu’un abonné au PPP tente de se connecter à un domaine, L2TP sélectionne un tunnel associé à une destination de ce domaine et tente d’accéder à la destination. Si la tentative de connexion échoue, L2TP place la destination sur la liste de verrouillage de destination. Les destinations de cette liste ne peuvent pas être prises en compte pour les connexions suivantes pendant une période configurable appelée délai de verrouillage de destination.

Vous pouvez émettre la request services l2tp destination unlock commande pour une destination particulière afin de la supprimer de la liste de verrouillage des destinations. Par conséquent, cette destination est immédiatement disponible lorsqu’un abonné se connecte au domaine associé.

Pour supprimer une destination de la liste de verrouillage des destinations :

Spécifiez le nom de la destination à déverrouiller.

Configuration du drain L2TP

À des fins administratives, vous pouvez définir l’état d’une destination ou d’un tunnel L2TP à drainer. Cela empêche la création de nouvelles sessions, de nouveaux tunnels et de nouvelles destinations au niveau L2TP LAC et LNS.

Vous pouvez configurer le drain L2TP au niveau global ou pour une destination ou un tunnel spécifique. Si la fonctionnalité est configurée au niveau L2TP global, aucune nouvelle destination, aucun nouveau tunnel ou nouvelle session ne peut être créé. Si la fonctionnalité est configurée pour une destination spécifique, aucun nouveau tunnel ou session ne peut être créé à cette destination. De même, si la fonctionnalité est configurée pour un tunnel spécifique, aucune nouvelle session ne peut être affectée à ce tunnel, mais de nouvelles destinations et de nouveaux tunnels peuvent être créés.

Pour empêcher la création de nouvelles sessions, destinations et tunnels pour L2TP :

Pour empêcher la création de nouveaux tunnels et sessions sur une destination particulière :

Pour empêcher la création de nouvelles sessions au niveau d’un tunnel spécifique :
Remarque :
Le tunnel name est le nom attribué localement au tunnel au format suivant : destination-name/tunnel-name ou tunnel-nameLorsque seul le tunnel-name est fourni, vous devez inclure l’instruction address ip-address permettant d’identifier la destination du tunnel par.

Lorsque cette fonctionnalité est configurée, la sortie de show services l2tp summaryla commande , show services l2tp destinationet show services l2tp tunnel affiche l’état de la session L2TP, de la destination et du tunnel sous la forme Drain.

Utilisation du même tunnel L2TP pour l’injection et la duplication de paquets IP

Vous pouvez configurer le même tunnel L2TP que celui utilisé pour la mise en miroir des stratégies sécurisée des abonnés pour la duplication des paquets. Les paquets dupliqués sont utilisés pour injecter du trafic vers le client ou vers le réseau. L’injection ou la transmission de paquets est prise en charge pour tous les modes d’accès d’abonné. Un seul tunnel L2TP est utilisé pour la transmission des paquets et la duplication des paquets. Un port ou une interface configuré pour la duplication de paquets d’un côté d’un tunnel L2TP est connecté à l’autre point de terminaison de tunnel. L’autre point de terminaison du tunnel peut envoyer des paquets IP via le tunnel L2TP vers le port ou l’interface configuré pour la duplication de paquets, et les paquets IP reçus à cette interface peuvent être soit transférés au client, soit envoyés comme s’ils avaient été reçus par le client.

Le point de terminaison de tunnel distant envoie un paquet de tunnel IP dont la charge utile contient une adresse MAC Ethernet. Si l’adresse MAC de destination du paquet de charge utile contient l’adresse MAC du routeur, le paquet Ethernet est envoyé dans le sens sortant vers le réseau, et il est traité et transféré comme s’il avait été reçu sur le port client. Si l’adresse MAC source du paquet de charge utile contient l’adresse MAC du routeur, le paquet Ethernet est transmis dans le sens sortant vers le port client. Si le tunnel ne contient pas le cookie de réception configuré, l’injection de paquets n’a pas lieu. Dans ce cas, tout paquet de tunnel reçu est compté et abandonné de la même manière que les paquets arrivant avec un mauvais cookie sont comptés et abandonnés.

Pour configurer le paquet à dupliquer et à envoyer vers le client ou le réseau (en fonction de l’adresse MAC dans la charge utile Ethernet), incluez l’instruction decapsulate l2tp output-interface interface-name cookie l2tpv3-cookie au niveau de la [edit firewall family family-name filter filter-name term term-name then] hiérarchie. Vous pouvez également configurer un compteur pour les paquets L2TP dupliqués ou décapsulés en incluant l’instruction count counter-name au niveau de la [edit firewall family family-name filter filter-name term term-name then] hiérarchie

SUR CETTE PAGE

Présentation de la commutation de tunnel L2TP

Application des profils de commutateur de tunnel

Arrêt des sessions à commutation de tunnel sur le LTS

Actions de commutation de tunnel pour les AVP L2TP à la limite de commutation

Configuration de la commutation de tunnel L2TP

Définition de la taille de la fenêtre de réception L2TP

Définition du délai d’inactivité du tunnel L2TP

Définition du délai d’expiration de destruction L2TP

Configuration du délai d’expiration du verrouillage de destination L2TP

Suppression d’une destination L2TP de la liste de verrouillage des destinations

Configuration du drain L2TP

Utilisation du même tunnel L2TP pour l’injection et la duplication de paquets IP

Documentation connexe