Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Commutation de tunnel L2TP pour les réseaux multi-domaines

Présentation de la commutation de tunnel L2TP

La commutation de tunnel L2TP, également connue sous le nom de sauts multiples L2TP, simplifie le déploiement d’un réseau L2TP sur plusieurs domaines. Un routeur situé entre un LAC et un LNS est configuré en tant que commutateur de tunnel L2TP (LTS), parfois simplement appelé commutateur de tunnel ou agrégateur de commutation de tunnel (TSA), comme illustré sur la Figure 1. Le LTS est configuré à la fois comme un LNS et un 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 de terminaison logique de la session L2TP d’origine est basculé vers un autre point de terminaison.

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

Figure 1 : topologie L2TP Tunnel Switching Network Topology du réseau de commutation de tunnel L2TP

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

  • Le LTS agit comme le LNS pour plusieurs LAC. Il n’est pas nécessaire que les LAC disposent du contrôle administratif ou des capacités nécessaires pour identifier le LNS le plus approprié pour mettre fin à leurs sessions. Le LTS remplit cette fonction est centralisée dans le LTS.

  • Le LTS fait office de 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 s’adapter au 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 de 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 :

  1. L’abonné ouvre une session PPP sur le LAC.

  2. Le LAC crée le premier tunnel L2TP vers le LNS configuré sur le LTS et la première session L2TP à transporter les paquets PPP encapsulés.

  3. 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 non d’un profil de commutateur de tunnel configuré sur le LTS.

    Il peut s’agir d’un profil par défaut, d’une configuration de mappage de domaine ou d’un groupe de tunnels.

  4. 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, comme spécifié dans le profil, et crée la deuxième session dans ce tunnel.

Figure 2 : commutation de tunnel L2TP pour les appels L2TP Tunnel Switching for Incoming Calls entrants

Application des profils de commutateurs de tunnel

Vous pouvez configurer un profil de commutateur de tunnel pour qu’il s’applique de plusieurs manières :

  • En tant que profil par défaut appliqué 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 profil de commutateur de tunnel VSA (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éfinit le profil utilisé par le LTS ; l’ordre est du plus élevé (RADIUS) au plus bas (profil par défaut) :

  1. Carte de domaine RADIUS VSA 26-91 > > groupe de tunnels > profil global du commutateur de tunnel

Le profil du 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 abonnés sont basculés.

Clôture des sessions de commutation de tunnels sur le LTS

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

  • L’interface LAC ou LNS sur le 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 la terminaison du tunnel

    La première et la deuxième session sont 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 du message StopCCN

    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 la terminaison du tunnel.

    Le LTS ne relaie pas le message StopCCN, car un tunnel donné peut contenir à la fois des sessions commutées et non commutées. Dans un scénario de vente en gros, une autre raison est que l’extrémité du tunnel sur le LNS sur le LTS peut contenir des sessions provenant 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 transporté dans le StopCCN.

  • Une commande administrative clear est émise sur le LTS.

Le tableau 3 répertorie les mesures prises lorsqu’une commande administrative clear est émise sur le LTS.

Tableau 3 : Actions LAC, LNS et LTS effectuées pour les tunnels commutés en réponse à des commandes administratives d’effacement

Commander

Action LAC ou LNS

LTS Action

clear services l2tp destination

Effacez la destination, ainsi que 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 dont la cause est définie sur Administrative.

clear services l2tp destination all

Effacez toutes les destinations ainsi que tous les tunnels et sessions associés.

Aucun.

clear services l2tp session

Effacez la session.

Effacez la session commutée mappée correspondante pour cette session en lui envoyant un message CDN dont la cause est définie sur Administrative.

clear services l2tp session all

Effacez toutes les sessions.

Aucun.

clear services l2tp tunnel

Effacez 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 dont la cause est définie sur Administrative.

clear services l2tp tunnel all

Effacez tous les tunnels.

Aucun.

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 réseau LNS, elle effectue l’une des actions par défaut suivantes au niveau de la limite de commutation pour chaque AVP transporté dans les messages L2TP :

  • relay—L2TP transfère de manière transparente l’AVP dans le paquet commuté sans aucune 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 stratégie 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 BAC ; Des AVP facultatifs peuvent être inclus dans les messages.

Vous pouvez éventuellement remplacer l’action par défaut effectuée au niveau de la limite de commutation pour le type de support AVP (18), la cote AVP (22) ou Cisco NAS Port Info AVP (100). Vous pouvez configurer n’importe lequel 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.

Note:

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

Tableau 4 : action par défaut pour la gestion des AVP L2TP au niveau de la limite de commutation

Nom AVP (numéro)

Type d’AVP

L2TP Message Type

Action par défaut

ID de session attribué (14)

Obligatoire

CDN, ICRQ

Régénérer

ID de tunnel attribué (9)

Obligatoire

La SCCRQ

Régénérer

Capacités du porteur (4)

Optionnel

La SCCRQ

Régénérer

Type de porteur (18)

Optionnel

L’ICRQ

Relais

Appeler le numéro de série (15)

Obligatoire

L’ICRQ

Relais

Numéro d’appel (21)

Optionnel

L’ICRQ

Relais

Cote (22)

Optionnel

L’ICRQ

Relais

Défi (11)

Optionnel

La SCCRQ

Régénérer

Réponse au défi (13)

Optionnel

Le SCCCN

Régénérer

Cisco NAS Port

Optionnel

L’ICRQ

Relais

Capacité de basculement

Optionnel

La SCCRQ

Régénérer

Révision du firmware (6)

Optionnel

La SCCRQ

Régénérer

Capacités d’encadrement (3)

Obligatoire

La SCCRQ

Régénérer

Type d’encadrement (19)

Obligatoire

L’ICCN

Relais

Nom d’hôte (7)

Obligatoire

La SCCRQ

Régénérer

Initiale reçue LCP CONFREQ (26)

Optionnel

L’ICCN

Relais

Lorsque la renégociation LCP est activée avec l’instruction lcp-negotiation dans le profil client sur le LNS, l’AVP est régénéré plutôt que relayé.

Dernière réception LCP CONFREQ (28)

Optionnel

L’ICCN

Relais

Lorsque la renégociation LCP est activée avec l’instruction lcp-negotiation dans le profil client sur le LNS, l’AVP est régénéré plutôt que relayé.

Dernier envoi LCP CONFREQ (27)

Optionnel

L’ICCN

Relais

Lorsque la renégociation LCP est activée avec l’instruction lcp-negotiation dans le profil client sur le LNS, l’AVP est régénéré plutôt que relayé.

Type de message (0)

Obligatoire

Tout

Régénérer

ID de canal physique (25)

Optionnel

L’ICRQ

Régénérer

ID de groupe privé (37)

Optionnel

L’ICCN

Relais

Version du protocole (2)

Obligatoire

La SCCRQ

Régénérer

Défi Authen par procuration (31)

Optionnel

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 proxy (32)

Optionnel

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 d’authentification du proxy (30)

Optionnel

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’authentification par procuration (33)

Optionnel

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 d’authentification de proxy (29)

Optionnel

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)

Optionnel

La SCCRQ

Régénérer

Vitesse de connexion Rx (38)

Optionnel

L’ICCN

Relais

Séquençage requis (39)

Optionnel

L’ICCN

Régénérer

Sous-adresse (23)

Optionnel

L’ICRQ

Relais

Bris d’égalité (5)

Optionnel

La SCCRQ

Régénérer

Récupération de tunnel

Optionnel

La SCCRQ

Régénérer

Vitesse de connexion Tx (24)

Obligatoire

L’ICCN

Relais

Nom du fournisseur (8)

Optionnel

La 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 seconde 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 affecter ce profil.

Vous pouvez configurer des profils de commutateur de tunnel pour toutes les sessions globalement, toutes les sessions d’un groupe de tunnels, toutes les sessions d’un domaine ou dans la configuration de votre serveur RADIUS à renvoyer dans le profil de commutateur de tunnel RADIUS VSA (26-91). L’ordre de priorité des profils de commutateurs de tunnel provenant de différentes sources est le suivant :

  • Carte de domaine RADIUS VSA 26-91 > > groupe de tunnels > profil global du commutateur de tunnel

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

  1. Créez le profil.
  2. (Facultatif) Remplacez les actions par défaut effectuées pour certains AVP L2TP au niveau de la limite de commutation.
  3. Spécifiez le profil de tunnel qui définit le tunnel vers lequel le trafic abonné est basculé.
    Note:

    Cette étape n’est pas nécessaire pour un profil de commutateur de tunnel spécifié dans le profil de commutateur de tunnel VSA (26-91).

  4. (Facultatif) Appliquez le profil en tant que profil global par défaut aux paquets de commutation de toutes les sessions entrantes du LAC.
  5. (Facultatif) Appliquez le profil dans le cadre d’un groupe de tunnels pour commuter les paquets de toutes les sessions du groupe de tunnels.
    Note:

    Le groupe de tunnels fait partie de la configuration LTS qui lui permet d’agir en tant que LNS pour les sessions d’origine 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.

  6. (Facultatif) Appliquez le profil dans le cadre d’une carte de domaine pour commuter les paquets de toutes les sessions associées au domaine.
    Note:

    Une carte 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.

  7. (Facultatif) Appliquez le profil à l’aide du Tunnel-Switch-Profile VSA [26–91] dans le message RADIUS Access-Accept renvoyé lorsque la session du LAC est authentifiée. Reportez-vous à la documentation de votre serveur RADIUS pour déterminer comment configurer cette méthode.
    Note:

    Un profil de commutateur de tunnel spécifié par un serveur RADIUS dans le profil de commutateur de tunnel VSA (26-91) est prioritaire sur le profil de commutateur de tunnel spécifié dans la configuration de l’interface de ligne de commande. 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) est prioritaire sur le VSA de groupe de tunnels (26-64), ce qui garantit que les abonnés sont commutés via un tunnel plutôt qu’un tunnel.

Prenons l’exemple de la configuration suivante. ce qui crée trois profils de commutateur de tunnel, l2tp-tunnel-switch-profile, lts-profile-groupA et lts-profile-example-com :

Voici l’exemple de configuration LTS (Commutation de tunnel de couche 2) pour les équipements MX Series :

Le profil l2tp-tunnel-switch-profile est appliqué par défaut. Lorsque les paquets sont commutés en fonction de ce profil, les valeurs du type de support AVP (18) et de la cote AVP (22) dans les paquets L2TP sont régénérées en fonction de la stratégie locale au niveau du commutateur de tunnel L2TP, puis envoyées avec les paquets. L’AVP (100) d’informations sur le port NAS Cisco (100) est simplement abandonné. 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 il ne remplace aucune action AVP. Le profil du commutateur de tunnel lts-profile-example.com est appliqué au moyen d’une carte 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 de 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 pendant laquelle un tunnel sans aucune session reste actif. Le minuteur d’inactivité démarre lorsque la dernière session du tunnel est terminée. Lorsque le minuteur expire, le tunnel est déconnecté. Ce délai d’inactivité libère des ressources qui seraient autrement consommées par les 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 situations suivantes se produise :

  • Vous émettez la clear services l2tp tunnel commande.

  • L’homologue distant déconnecte le tunnel.

Bonne pratique :

Avant de rétrograder vers une version de Junos OS qui ne prend pas en charge cette instruction, nous vous recommandons de déconfigurer explicitement la fonctionnalité en incluant l’instruction 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 la durée pendant laquelle le routeur tente de maintenir les destinations, tunnels et sessions dynamiques après leur destruction. Ce délai d’expiration facilite le débogage et d’autres analyses en enregistrant les structures de mémoire sous-jacentes après la fin de la destination, du tunnel ou de la session. Une destination, un tunnel ou une session dynamique spécifique peut ne pas être conservé pendant toute cette période si les ressources doivent être récupérées de manière anticipée pour permettre l’établissement de nouveaux tunnels.

Bonne pratique :

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

Pour définir le délai d’expiration de 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 verrouille 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 exclut la destination 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 comprise entre 60 et 3600 secondes (de 1 minute à 1 heure). À l’expiration du délai de verrouillage, L2TP suppose que la destination est désormais disponible et l’inclut lors de la 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.

Note:

En général, une destination verrouillée ne peut pas être utilisée tant que le minuteur de verrouillage n’a pas expiré. Toutefois, lorsque L2TP effectue le processus de sélection du tunnel, dans certaines circonstances, il efface le temporisateur de verrouillage pour une destination verrouillée. Pour plus d’informations sur le processus de sélection, reportez-vous aux sections Sélection lorsque le basculement entre les 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 Présentation de la sélection de tunnel LAC .

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. Dans le cas contraire, le délai d’expiration de destruction expire avant le délai d’expiration du verrouillage. Dans ce cas, la destination verrouillée est détruite et peut être remise en service avant l’expiration du délai de verrouillage, annulant ainsi l’efficacité du délai de verrouillage.

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 des verrouillages 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 verrouillée.

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

Lorsqu’un abonné PPP tente de se connecter à un domaine, L2TP sélectionne un tunnel associé à une destination dans ce domaine et tente d’accéder à la destination. Si la tentative de connexion échoue, L2TP place la destination sur la liste de verrouillage des destinations. Les destinations de cette liste ne peuvent pas être prises en compte pour les connexions ultérieures pendant une période configurable appelée délai d’expiration du verrouillage de la 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, procédez comme suit :

  • 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 L2TP ou d’un tunnel à drainer. Cela empêche la création de nouvelles sessions, de nouveaux tunnels et de nouvelles destinations au niveau du LAC L2TP et du 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 nouvelle 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 sessions, de destinations et de tunnels pour L2TP :
  • Pour empêcher la création de nouveaux tunnels et sessions à une destination particulière :
  • Pour empêcher la création de nouvelles sessions dans un tunnel spécifique :
    Note:

    Le tunnel name est le nom attribué localement au tunnel dans le format suivant : destination-name/tunnel-name ou tunnel-nameLorsque seul le est tunnel-name fourni, vous devez inclure l’instruction address ip-address pour identifier la destination du tunnel par.

Lorsque cette fonctionnalité est configurée, la commande , show services l2tp summaryshow services l2tp destinationshow services l2tp tunnel et affiche l’état de la session, de la destination et du tunnel L2TP 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 sécurisée des stratégies abonnés afin de dupliquer les 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 des abonnés. Un seul tunnel L2TP est utilisé à la fois 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 du 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 du tunnel distant envoie un paquet de tunnel IP contenant une adresse MAC Ethernet dans la charge utile. 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, puis 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 la direction sortante vers le port client. Si le tunnel ne contient pas le cookie de réception configuré, l’injection de paquets ne se produit pas. Dans ce cas, tout paquet de tunnel reçu est compté et abandonné de la même manière que les paquets qui arrivent avec un cookie erroné 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