SUR CETTE PAGE
Actions de commutation de tunnel pour les AVP L2TP à la limite de commutation
Configuration du délai d’expiration du verrouillage de destination L2TP
Suppression d’une destination L2TP de la liste de verrouillage des destinations
Utilisation du même tunnel L2TP pour l’injection et la duplication de paquets IP
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.

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 :
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 à 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 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.
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.

- Application des profils de commutateurs de tunnel
- Clôture des sessions de commutation de tunnels sur le LTS
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) :
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.
Commander |
Action LAC ou LNS |
LTS Action |
---|---|---|
|
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. |
|
Effacez toutes les destinations ainsi que tous les tunnels et sessions associés. |
Aucun. |
|
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. |
|
Effacez toutes les sessions. |
Aucun. |
|
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. |
|
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.
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.
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 |
Dernière réception LCP CONFREQ (28) |
Optionnel |
L’ICCN |
Relais Lorsque la renégociation LCP est activée avec l’instruction |
Dernier envoi LCP CONFREQ (27) |
Optionnel |
L’ICCN |
Relais Lorsque la renégociation LCP est activée avec l’instruction |
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 |
ID d’authentification proxy (32) |
Optionnel |
L’ICCN |
Relais Lorsque la renégociation LCP est activée avec l’instruction |
Nom d’authentification du proxy (30) |
Optionnel |
L’ICCN |
Relais Lorsque la renégociation LCP est activée avec l’instruction |
Réponse d’authentification par procuration (33) |
Optionnel |
L’ICCN |
Relais Lorsque la renégociation LCP est activée avec l’instruction |
Type d’authentification de proxy (29) |
Optionnel |
L’ICCN |
Relais Lorsque la renégociation LCP est activée avec l’instruction |
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 :
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 :
[edit access tunnel-switch-profile l2tp-tunnel-switch-profile] user@host# set avp bearer-type regenerate user@host# set avp calling-number regenerate user@host# set avp cisco-nas-port-info drop user@host# set tunnel-profile l2tp-tunnel-profile1 [edit access tunnel-switch-profile lts-profile-groupA] user@host# set tunnel-profile l2tp-tunnel-profile2 [edit access tunnel-switch-profile lts-profile-example.com] user@host# set tunnel-profile l2tp-tunnel-profile3 [edit services l2tp] user@host1# set tunnel-switch-profile l2tp-tunnel-switch-profile user@host1# set tunnel-group groupA tunnel-switch-profile lts-profile-groupA [edit access domain] user@host1# set map example.com tunnel-switch-profile lts-profile-example.com
Voici l’exemple de configuration LTS (Commutation de tunnel de couche 2) pour les équipements MX Series :
set services l2tp tunnel-group TG1 l2tp-access-profile DEFAULT set services l2tp tunnel-group TG1 aaa-access-profile aaa-access-profile set services l2tp tunnel-group TG1 hello-interval 0 set services l2tp tunnel-group TG1 local-gateway address 192.1.1.1 set services l2tp tunnel-group TG1 local-gateway gateway-name default set services l2tp tunnel-group TG1 service-interface si-0/0/0 set services l2tp tunnel-group TG1 dynamic-profile lns-profile set chassis fpc 0 pic 0 inline-services bandwidth 10g set chassis network-services enhanced-ip set dynamic-profiles lns-profile routing-instances "$junos-routing-instance" interface "$junos-interface-name" set dynamic-profiles lns-profile interfaces "$junos-interface-ifd-name" unit "$junos-interface-unit" ppp-options chap set dynamic-profiles lns-profile interfaces "$junos-interface-ifd-name" unit "$junos-interface-unit" ppp-options pap set dynamic-profiles lns-profile interfaces "$junos-interface-ifd-name" unit "$junos-interface-unit" family inet unnumbered-address "$junos-loopback-interface" set dynamic-profiles lns-profile interfaces "$junos-interface-ifd-name" unit "$junos-interface-unit" family inet6 unnumbered-address "$junos-loopback-interface" set access profile DEFAULT client default l2tp aaa-access-profile aaa-access-profile set access profile DEFAULT client default l2tp shared-secret "$9$i.T3AtOREyApIcSrLX" set access profile DEFAULT client default l2tp dynamic-profile lns-profile set access profile DEFAULT client default user-group-profile l2tp-access-group-profile set access group-profile l2tp-access-group-profile ppp idle-timeout 200 set access group-profile l2tp-access-group-profile ppp ppp-options pap set access group-profile l2tp-access-group-profile ppp ppp-options chap set access group-profile l2tp-access-group-profile ppp keepalive 0 set access tunnel-profile lac-profile tunnel 1 preference 1 set access tunnel-profile lac-profile tunnel 1 identification 1 set access tunnel-profile lac-profile tunnel 1 remote-gateway address 192.1.2.1 set access tunnel-profile lac-profile tunnel 1 remote-gateway gateway-name default set access tunnel-profile lac-profile tunnel 1 source-gateway address 192.1.2.5 set access tunnel-profile lac-profile tunnel 1 source-gateway gateway-name default set access tunnel-profile lac-profile tunnel 1 secret "$9$u9CE0BEleW-dsp07Vb2GUCtu" set access tunnel-switch-profile tsp-profile tunnel-profile lac-profile set access domain map yogeshn.com tunnel-switch-profile tsp-profile …
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 :
[edit services l2tp tunnel] user@host# set rx-window-size packets
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.
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.
[edit services l2tp tunnel] user@host# set idle-timeout seconds
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.
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.
[edit services l2tp] user@host# set destruct-timeout seconds
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.
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 .
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.
[edit services l2tp destination] user@host# set lockout-timeout seconds
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.
user@host> request services l2tp destination unlock destination-name
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.
Lorsque cette fonctionnalité est configurée, la commande , show services l2tp summary
show services l2tp destination
show 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