SUR CETTE PAGE
Configuration d’un LNS L2TP avec des interfaces de service en ligne
Application d’attributs PPP à des abonnés LNS L2TP par interface de service en ligne
Application d’attributs PPP aux abonnés LNS L2TP avec un profil de groupe d’utilisateurs
Configuration d’un pool d’attribution d’adresses pour LNS L2TP avec des services en ligne
Configuration d’une interface de service en ligne pour LNS L2TP
Configuration des options de l’interface logique des services en ligne LNS
Configuration de la redondance dynamique LNS 1:1 sur les interfaces de service en ligne agrégées
Vérification de la redondance 1:1 de l’interface de service en ligne agrégée LNS
Limites de session L2TP et équilibrage de charge pour les interfaces de service
Application de services à une session L2TP sans utiliser RADIUS
Configuration d’un pool d’interfaces de services en ligne pour les sessions LNS dynamiques
Configuration d’un profil dynamique pour les sessions LNS dynamiques
Interfaces de service en ligne LNS L2TP
Configuration d’un LNS L2TP avec des interfaces de service en ligne
La licence de fonctionnalités LNS L2TP doit être installée avant de commencer la configuration. Sinon, un message d’avertissement s’affiche lorsque la configuration est validée.
Pour configurer un LNS L2TP avec des interfaces de service en ligne :
Vous devez également configurer le CoS pour les sessions LNS. Pour plus d’informations, voir Configuration de Dynamic CoS pour un service LNS Inline L2TP.
Application d’attributs PPP à des abonnés LNS L2TP par interface de service en ligne
Vous pouvez configurer les attributs PPP qui sont appliqués par le LNS sur l’interface de service en ligne (si) aux abonnés PPP tunnelisés à partir du LAC. Étant donné que vous configurez les attributs par interface plutôt qu’avec un profil de groupe d’utilisateurs, les attributs des abonnés peuvent être modifiés avec une granularité plus fine. Cette configuration correspond à celle utilisée pour les abonnés PPPoE résiliés.
Pour configurer les attributs PPP pour les interfaces si créées dynamiquement :
Pour configurer les attributs PPP pour les interfaces si créées de manière statique :
Spécifiez l’interface de service logique en ligne.
[edit interfaces si-slot/pic/port] user@host# edit unit logical-unit-number
Configurez l’intervalle entre les messages keepalive PPP pour le tunnel L2TP se terminant sur le LNS.
[edit interfaces si-slot/pic/port unit logical-unit-number] user@host# set keepalives interval seconds
Configurez le nombre de paquets keepalive qu’une destination ne doit pas recevoir avant que le réseau ne coupe une liaison.
[edit interfaces si-slot/pic/port unit logical-unit-number] user@host# set keepalives down-count number
Remarque :Cette
keepalives up-countoption n’est généralement pas utilisée pour la gestion des abonnés.Configurez les méthodes d’authentification PPP qui s’appliquent aux abonnés PPP tunnelisés au niveau du LNS.
[edit interfaces si-slot/pic/port unit logical-unit-number] user@host# set ppp-options chap user@host# set ppp-options pap
Configurez le routeur pour inviter le Customer Premises Equipment (CPE) à négocier les adresses DNS primaire et secondaire lors de la négociation IPCP pour les abonnés PPP tunnelisés au LNS.
[edit interfaces si-slot/pic/port unit logical-unit-number] user@host# set ppp-options ipcp-suggest-dns-option
Bien que toutes les autres instructions subordonnées à ppp-options, y compris celles subordonnées à chap et pap— soient prises en charge, elles ne sont généralement pas utilisées pour la gestion des abonnés. Nous vous recommandons de conserver ces autres instructions à leurs valeurs par défaut.
Vous pouvez également configurer les attributs PPP avec un profil de groupe d’utilisateurs qui applique les attributs à tous les abonnés avec ce profil sur un client BAC. Voir Application d’attributs PPP aux abonnés LNS L2TP avec un profil de groupe d’utilisateurs pour plus d’informations. Lorsque vous configurez les attributs PPP pour les abonnés LNS L2TP à la fois sur l’interface si et dans les profils de groupe d’utilisateurs, la configuration de l’interface de service en ligne est prioritaire sur la configuration du profil de groupe d’utilisateurs.
Lorsque les options PPP sont configurées à la fois dans un profil de groupe et un profil dynamique, la configuration du profil dynamique est totalement prioritaire sur le profil de groupe lorsque le profil dynamique inclut une ou plusieurs des options PPP qui peuvent être configurées dans le profil de groupe. La préséance complète signifie qu’il n’y a pas de fusion des options entre les profils. Le profil de groupe est appliqué à l’abonné uniquement lorsque le profil dynamique n’inclut aucune option PPP disponible dans le profil de groupe.
Application d’attributs PPP aux abonnés LNS L2TP avec un profil de groupe d’utilisateurs
Vous pouvez configurer un profil de groupe d’utilisateurs qui permet au LNS d’appliquer des attributs PPP aux abonnés PPP tunnelisés à partir du LAC. Le profil de groupe d’utilisateurs est associé aux clients (LAC) dans le profil d’accès L2TP. Par conséquent, tous les abonnés traités par un client donné partagent les mêmes attributs PPP.
Pour configurer un profil de groupe d’utilisateurs :
Vous pouvez également configurer les attributs PPP pour chaque interface. Pour plus d’informations, reportez-vous à la section Application d’attributs PPP à des abonnés LNS L2TP par interface de service en ligne . Lorsque vous configurez les attributs PPP pour les abonnés LNS L2TP à la fois sur l’interface si et dans les profils de groupe d’utilisateurs, la configuration de l’interface de service en ligne est prioritaire sur la configuration du profil de groupe d’utilisateurs.
Lorsque les options PPP sont configurées à la fois dans un profil de groupe et un profil dynamique, la configuration du profil dynamique est totalement prioritaire sur le profil de groupe lorsque le profil dynamique inclut une ou plusieurs des options PPP qui peuvent être configurées dans le profil de groupe. La préséance complète signifie qu’il n’y a pas de fusion des options entre les profils. Le profil de groupe est appliqué à l’abonné uniquement lorsque le profil dynamique n’inclut aucune option PPP disponible dans le profil de groupe.
Configuration d’un profil d’accès L2TP sur le LNS
Les profils d’accès définissent comment valider les connexions L2TP (Layer 2 Tunneling Protocol) et les demandes de session. Dans chaque profil d’accès L2TP, vous configurez un ou plusieurs clients (LAC). Les caractéristiques client sont utilisées pour authentifier les LAC avec des mots de passe correspondants et pour établir les attributs du tunnel client et de la session. Vous pouvez configurer plusieurs profils d’accès et plusieurs clients dans chaque profil.
Pour configurer un profil d’accès L2TP :
Configuration d’un profil d’accès local AAA sur le LNS
Pour certains tunnels LNS, vous pouvez remplacer le profil d’accès configuré sur l’instance de routage qui héberge le tunnel avec une configuration de serveur RADIUS particulière. Vous pouvez configurer un profil d’accès local pour ce faire. Vous pouvez ensuite utiliser l’instruction aaa-access-profile pour appliquer le profil d’accès local à un groupe de tunnels ou à un client BAC.
Un profil d’accès local appliqué à un client remplace un profil d’accès local appliqué à un groupe de tunnels, qui à son tour remplace le profil d’accès de l’instance de routage.
Pour configurer un profil d’accès local AAA :
Configuration d’un pool d’attribution d’adresses pour LNS L2TP avec des services en ligne
Vous pouvez configurer des pools d’adresses qui peuvent être affectés dynamiquement aux abonnés PPP tunnelisés. Les pools doivent être locaux à l’instance de routage sur laquelle l’abonné apparaît. Les pools configurés sont fournis dans les attributs RADIUS Framed-Pool et Framed-IPv6-Pool. Les pools sont facultatifs lorsque Framed-IP-Address est envoyé par RADIUS.
Pour configurer un pool d’attribution d’adresses, vous devez spécifier le nom du pool et configurer les adresses du pool.
Vous pouvez éventuellement configurer plusieurs plages nommées, ou sous-ensembles, d’adresses dans un pool d’attribution d’adresses. Lors de l’attribution dynamique d’adresses, un client peut se voir attribuer une adresse d’une plage nommée spécifique. Pour créer une plage nommée, vous spécifiez un nom pour la plage et définissez la plage d’adresses.
Assurez-vous d’utiliser l’instruction de pools d’affectation d’adresses (address-assignment) plutôt que l’instruction de pools d’adresses (address-pool).
Pour plus d’informations sur les pools d’attribution d’adresses, consultez Vue d’ensemble des pools d’attribution d’adresses et Vue d’ensemble de la configuration des pools d’attribution d’adresses.
Pour configurer un pool d’attribution d’adresses IPv4 pour L2TP LNS :
Par exemple, pour configurer un pool d’attribution d’adresses IPv4 :
[edit access] user@host# edit address-assignment pool lns-v4-pool family inet [edit access address-assignment pool lns-v4-pool family inet] user@host# set network 192.168.1.1/16 [edit access address-assignment pool lns-v4-pool family inet] user@host# set range lns-v4-pool-range low 192.168.1.1 high 192.168.255.255
Pour configurer un pool d’attribution d’adresses IPv6 pour LNS L2TP :
Configurez le nom du pool et spécifiez la famille IPv6.
[edit access] user@host# edit address-assignment pool pool-name family inet6
Configurez le préfixe de réseau IPv6 pour le pool d’adresses. La spécification du préfixe est requise lorsque vous configurez un pool d’attribution d’adresses IPv6.
[edit access address-assignment pool pool-name family inet6] user@host# set prefix ipv6-prefix
Configurez le nom de la plage et définissez-la. Vous pouvez définir la plage en fonction des limites inférieure et supérieure des préfixes de la plage, ou en fonction de la longueur des préfixes de la plage.
[edit access address-assignment pool pool-name family inet6] user@host# set range range-name low lower-limit high upper-limit
Par exemple, pour configurer un pool d’attribution d’adresses IPv6 :
[edit access] user@host# edit address-assignment pool lns-v6-pool family inet6 [edit access address-assignment pool lns-v6-pool family inet6] user@host# set prefix 2001:DB8::/32 [edit access address-assignment pool lns-v6-pool family inet6] user@host# set range lns-v6-pool-range low 2001:DB8:1::/48 high 2001:DB8::ffff::/48
Configuration de l’interface homologue LNS L2TP
L’interface homologue connecte le LNS au cloud, vers les LAC, afin que les paquets IP puissent être échangés entre les points de terminaison du tunnel. MPLS et Ethernet agrégé peuvent également être utilisés pour atteindre les LAC.
Sur les routeurs MX Series, vous devez configurer l’interface homologue sur une MPC.
Pour configurer l’interface homologue LNS :
Activation des interfaces de service en ligne
L’interface de service en ligne est une interface physique virtuelle qui réside sur le moteur de transfert de paquets. Cette si interface, appelée interface d’ancrage , permet de fournir des services L2TP sans PIC de services spéciaux. L’interface de service en ligne est prise en charge uniquement par les MPC des routeurs MX Series. Quatre interfaces de service en ligne sont configurables par emplacement de châssis occupé par MPC.
Sur les routeurs MX80 et MX104, vous ne pouvez configurer que quatre interfaces physiques de services en ligne comme interfaces d’ancrage pour les sessions LNS L2TP : si-1/0/0, si-1/1/0, si-1/2/0 et si-1/3/0. Vous ne pouvez pas configurer si-0/0/0 à cette fin sur les routeurs MX80 et MX104.
Bien que la plage de valeurs de bande passante soit comprise entre 1 Gbit/s et 400 Gbit/s, vous ne pouvez pas configurer la bande passante en chiffres absolus tels que 12 345 878 000 Bps. Vous devez utiliser les options disponibles dans l’instruction CLI :
1g10gpar100gincréments de 10 Gbit/s :10g,20g, ,70g90g40g50g60g80g30g100g100gpar400gincréments de 100 Gbit/s :100g,200g,300g,400g
La bande passante maximale disponible varie d’un MPC à l’autre, comme indiqué dans le Tableau 1. Un message de journal système est généré lorsque vous configurez une bande passante supérieure à celle prise en charge par la MPC.
MPC |
Bande passante maximale prise en charge |
|---|---|
| MPC2E NG, MPC2E NG Q, |
80 Gbit/s |
MPC3E NG, MPC3E NG Q |
130 Gbit/s |
MPC3 100GE et 40GE et MIC |
40 Gbit/s |
MPC4E |
130 Gbit/s |
MPC5E |
130 Gbit/s |
MPC6E |
130 Gbit/s |
MPC7E |
240 Gbit/s |
MPC8E |
240 Gbit/s 400 Gbit/s en mode mis à niveau de 1,6 Tbit/s |
MPC9E |
400 Gbit/s |
Pour activer les interfaces de service en ligne :
Configuration d’une interface de service en ligne pour LNS L2TP
L’interface de service en ligne est une interface de service physique virtuelle qui réside sur le moteur de transfert de paquets. Cette si interface, appelée interface d’ancrage , permet de fournir des services L2TP sans PIC de services spéciaux. L’interface de service en ligne est prise en charge uniquement par les MPC des routeurs MX Series. Quatre interfaces de service en ligne sont configurables par emplacement de châssis occupé par MPC.
Vous pouvez maximiser le nombre de sessions qui peuvent être mises en forme dans une interface de service en définissant le nombre maximal de niveaux hiérarchiques sur deux. Dans ce cas, chaque session LNS utilise un nœud L3 dans la hiérarchie du planificateur pour la mise en forme.
Si vous ne spécifiez pas le nombre de niveaux (deux est la seule option), le nombre de sessions LNS qui peuvent être mises en forme sur l’interface de service est limité au nombre de nœuds L2, soit 4 096 sessions. Des sessions supplémentaires sont toujours proposées, mais elles ne sont pas façonnées.
Pour configurer une interface de service en ligne :
Configuration des options de l’interface logique des services en ligne LNS
Vous devez spécifier des caractéristiques :dial-options pour chacune des interfaces logiques de services en ligne que vous configurez pour le LNS. Sur les routeurs MX Series, LNS ne prend en charge qu’une seule session par interface logique. Vous devez donc la configurer en tant qu’interface dedicated . Cette option n’est shared pas prise en charge. (LNS sur les supports dedicated et shared options des routeurs M Series.) Vous configurez également un nom d’identification pour l’interface logique qui correspond au nom que vous spécifiez dans le profil d’accès.
Vous devez spécifier la famille d’adresses inet pour chaque interface logique statique ou dans le profil dynamique pour les interfaces LNS dynamiques. Bien que la CLI accepte l’une ou l’autre inet inet6 des interfaces logiques statiques, l’abonné ne peut pas se connecter correctement si la famille inet d’adresses n’est pas configurée.
Pour une configuration dynamique de l’interface, consultez Configuration d’un profil dynamique pour les sessions LNS dynamiques.
Pour configurer les options de l’interface logique statique :
Présentation de la redondance à états LNS 1:1
Par défaut, lorsqu’une interface d’ancrage de service en ligne (si) tombe en panne (par exemple, lorsque la carte hébergeant l’interface tombe en panne ou redémarre), le trafic d’abonnés L2TP est perdu. Lorsque le temporisateur PPP keepalive du tunnel expire par la suite, le plan de contrôle tombe en panne et le client PPP est déconnecté. Par conséquent, le client doit alors se reconnecter.
Vous pouvez éviter les pertes de trafic dans ces circonstances en configurant une offre groupée d’interfaces de service en ligne agrégées (asi) pour fournir une redondance dynamique 1:1, également appelée redondance de secours à chaud ou de sauvegarde active. L’offre se compose d’une paire d’interfaces physiques si, la liaison membre principale (active) et la liaison membre secondaire (de secours ou de secours). Ces interfaces doivent être configurées sur différents MPC ; La redondance n’est pas réalisable si vous configurez l’interface principale et l’interface secondaire sur la même MPC, car les deux interfaces membres tombent en panne si la carte tombe en panne.
Lorsque les abonnés se connectent et que la redondance 1:1 est configurée, la session L2TP est établie sur une interface logique virtuelle (asi.0x) sous-jacente sur l’interface physique asi0. Les interfaces logiques d’abonné individuelles sont créées sur l’interface sous-jacente au format asiX.logical-unit-number. En cas de panne ou de redémarrage sur la MPC hébergeant l’interface de liaison du membre principal, la session reste active. Tout le trafic de données destiné à cette session L2TP est automatiquement déplacé vers l’interface de liaison de membre secondaire de l’autre MPC.
Configuration de la redondance dynamique LNS 1:1 sur les interfaces de service en ligne agrégées
Vous pouvez créer un bundle d’interfaces de service en ligne agrégées (asi) pour fournir une redondance dynamique LNS 1:1 pour les interfaces d’ancrage de service en ligne (si). L’offre groupée associe deux interfaces qui résident sur des MPC différentes en tant que liaisons principales et secondaires. Les sessions LNS sont ensuite établies sur une interface logique virtuelle, asiX.logical-unit-number. Le basculement de session LNS se produit lorsque l’interface d’ancrage principale tombe en panne ou que la carte est redémarrée à l’aide de la request chassis fpc restart commande. Lorsque cela se produit, la liaison secondaire (sur un autre MPC) devient active et tout le trafic de données LNS destiné à la session est automatiquement déplacé vers l’interface secondaire. La session d’abonné reste active sur l’interfaceX virtuelle.logical-unit-number Aucune statistique de trafic n’est perdue. Lorsque ce redondance n’est pas configuré, abonné trafic est perdu, les keepalives expirent et le client PPP est déconnecté et doit se reconnecter.
Avant de commencer, vous devez procéder comme suit :
Vérifiez que la gestion améliorée des abonnés est activée.
Créez des interfaces de service en ligne sur différents MPC à agréger dans l’offre groupée.
Voir Activation d’interfaces de service en ligne et Configuration d’une interface de service en ligne pour LNS L2TP.
Si vous utilisez des pools d’interfaces de service, définissez-les.
Suivez ces instructions :
Vous devez effectuer une configuration
unit 0 family inetpour chaque offre groupée, sinon la session ne sera pas établie.L’interface principale (active) et l’interface secondaire (de secours) doivent se trouver sur des MPC différents.
La bande passante configurée au niveau de la
[edit chassis fpc slot pic number inline-services bandwidth]hiérarchie doit être la même pour les deux liaisons membres.Une interface si configurée en tant que membre d’un bundle d’interfaces de service en ligne agrégées ne peut pas être configurée en tant que membre d’un autre bundle.
Une interface si configurée en tant que membre d’un bundle d’interfaces de service en ligne agrégées ne peut pas non plus être utilisée pour une fonction qui n’est pas liée à des services agrégés ; par exemple, il ne peut pas être utilisé pour le réassemblage IP en ligne.
Lorsque vous configurez une interface si en tant que membre d’un bundle de services en ligne agrégés, vous ne pouvez plus configurer cette interface si indépendamment. Vous ne pouvez configurer que le bundle parent ; La configuration du bundle est appliquée immédiatement à toutes les interfaces membres.
Pour configurer la redondance dynamique 1:1 LNS :
L’exemple de configuration suivant crée le bundle asi0 avec des liens de membre sur les MPC dans les emplacements 1 et 2, puis affecte le bundle pour fournir une redondance pour les sessions L2TP sur le groupe de tunnels tg1 :
[edit interfaces asi0] user@host# set aggregated-inline-services-options primary-interface si-1/0/0 user@host# set aggregated-inline-services-options secondary-interface si-2/0/0 user@host# set unit 0 family inet [edit chassis fpc 1 pic 0 inline-services] user@host# set bandwidth 10g [edit chassis fpc 2 pic 0 inline-services] user@host# set bandwidth 10g [edit services l2tp tunnel-group tg1] user@host# set service-interface asi0
Vérification de la redondance 1:1 de l’interface de service en ligne agrégée LNS
Objet
Consultez des informations sur les offres groupées d’interfaces de service en ligne, les liens de membres individuels et l’état de la redondance.
Mesures à prendre
Pour afficher des informations récapitulatives sur une offre groupée d’interfaces de service en ligne agrégées :
user@host> show interfaces asi0 terse Interface Admin Link Proto Local Remote asi0 up up asi0.0 up up inet
Pour afficher des informations détaillées sur une offre groupée d’interfaces de service en ligne agrégées :
user@host> show interfaces asi0 extensive Physical interface: asi0, Enabled, Physical link is Up Interface index: 223, SNMP ifIndex: 734, Generation: 226 Type: Adaptive-Services, Link-level type: Adaptive-Services, MTU: 9192, Clocking: Unspecified, Speed: 20000mbps Device flags : Present Running Interface flags: Point-To-Point SNMP-Traps Internal: 0x4000 Link type : Full-Duplex Link flags : None Physical info : Unspecified Hold-times : Up 0 ms, Down 0 ms Current address: Unspecified, Hardware address: Unspecified Alternate link address: Unspecified Last flapped : 2014-01-20 23:35:02 PST (00:03:25 ago) Statistics last cleared: Never Traffic statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 IPv6 transit statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Input errors: Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Giants: 0, Policed discards: 0, Resource errors: 0 Output errors: Carrier transitions: 0, Errors: 0, Drops: 0, MTU errors: 0, Resource errors: 0 Logical interface asi0.0 (Index 356) (SNMP ifIndex 52241) (Generation 165) Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Adaptive-Services Traffic statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Local statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Transit statistics: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Protocol inet, MTU: 9192, Generation: 198, Route table: 0 Flags: Sendbcast-pkt-to-rePour afficher des informations sur une interface membre individuelle dans un bundle d’interfaces de service en ligne agrégées :
user@host> show interfaces si-1/0/0 Physical interface: si-1/0/0, Enabled, Physical link is Up Interface index: 165, SNMP ifIndex: 630 Type: Adaptive-Services, Link-level type: Adaptive-Services, MTU: 9192, Speed: 10000mbps Device flags : Present Running Interface flags: Point-To-Point SNMP-Traps Internal: 0x4000 Link type : Full-Duplex Link flags : None Last flapped : Never Input rate : 0 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface si-1/0/0.0 (Index 357) (SNMP ifIndex 52229) Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Adaptive-Services Input packets : 0 Output packets: 0 Protocol asi, AS bundle: asi0.0 Flags: Function2Pour afficher l’état de la redondance des offres groupées d’interfaces de service en ligne agrégées :
user@host> show interfaces redundancy Interface State Last change Primary Secondary Current status asi0 On secondary 1d 23:56 si-1/0/0 si-2/0/0 primary down asi1 On primary 10:10:27 si-3/0/0 si-4/0/0 secondary down ae0 On primary 00:00:02 ge-1/0/0 ge-3/0/1 backup down ae2 On primary 00:00:01 ge-2/0/0 ge-4/0/1 both up
Cet exemple de sortie montre que les interfaces Ethernet agrégées et les interfaces de service agrégées en ligne sont configurées pour la redondance. Pour afficher un seul des bundles d’interfaces de service en ligne agrégées :
user@host> show interfaces redundancy asi0 Interface State Last change Primary Secondary Current status asi0 On secondary 1d 23:56 si-1/0/0 si-2/0/0 primary down
Pour afficher des informations détaillées sur toutes les interfaces de redondance configurées :
user@host> show interfaces redundancy detail Redundancy interfaces detail Interface : asi0 State : On primary Last change : 00:00:36 Primary : si-1/0/0 Secondary : si-3/0/0 Current status: both up Interface : ae0 State : On primary Last change : 00:01:30 Primary : ge-1/0/0 Secondary : ge-3/0/1 Current status : backup down
Limites de session L2TP et équilibrage de charge pour les interfaces de service
Le LNS équilibre la charge des sessions d’abonnés sur les interfaces de service disponibles dans un pool d’appareils en fonction du nombre de sessions actuellement actives sur les interfaces. Vous pouvez configurer une limite maximale par interface de service (si) et par interface de service agrégée (asi). Dans le cas des interfaces asi, vous ne pouvez pas configurer de limite pour les interfaces membres si individuelles du lot.
- Limites de session sur les interfaces de service
- Équilibrage de charge de session entre les interfaces de service
Limites de session sur les interfaces de service
Lorsqu’une demande de session L2TP est lancée pour une interface de service, le LNS vérifie le nombre de sessions actives sur cette interface par rapport au nombre maximal de sessions autorisées pour l’interface de service individuelle ou l’interface de service agrégée. Le LNS détermine si le nombre de sessions en cours (affiché par la show services l2tp summary commande) est inférieur à la limite configurée. Lorsque c’est le cas ou qu’aucune limite n’est configurée, la vérification passe et la session peut être établie. Si le nombre de sessions en cours est égal à la limite configurée, le LNS rejette la demande de session. Aucune requête ultérieure ne peut être acceptée sur cette interface tant que le nombre de requêtes actives n’est pas inférieur au maximum configuré. Lorsqu’une demande de session est rejetée pour une interface si ou asi, le LNS renvoie un message CDN avec le code de résultat défini sur 2 et le code d’erreur défini sur 4.
Par exemple, supposons qu’une interface de service unique soit configurée dans le groupe de tunnels. Le nombre actuel de sessions L2TP est de 1500, avec une limite configurée de 2000 sessions. Lorsqu’une nouvelle session est demandée, la vérification de limite est acceptée et la demande de session est acceptée.
Interface utilisateur |
Limite de session configurée |
Nombre de sessions actuel |
Résultat de la vérification des limites de session |
|---|---|---|---|
si-0/0/0 |
2000 |
1500 |
Réussite |
La vérification de limite continue de passer et les demandes de session sont acceptées jusqu’à ce que 500 demandes aient été acceptées, ce qui porte le nombre de sessions actuel à 2000, ce qui correspond au maximum configuré. La vérification de la limite de session échoue pour toutes les demandes suivantes et toutes les demandes sont rejetées jusqu’à ce que le nombre de sessions actuel sur l’interface tombe en dessous de 2000, de sorte que la vérification de limite puisse passer.
Interface utilisateur |
Limite de session configurée |
Nombre de sessions actuel |
Résultat de la vérification des limites de session |
|---|---|---|---|
si-0/0/0 |
2000 |
2000 |
Échec |
Lorsque la limite de session est fixée à zéro pour une interface, aucune demande de session ne peut être acceptée. S’il s’agit de la seule interface du groupe de tunnels, toutes les demandes de session du groupe sont rejetées jusqu’à ce que la limite de session passe de zéro ou qu’une autre interface de service soit ajoutée au groupe de tunnels.
Lorsqu’une interface de service dans un pool d’appareils de service a atteint la limite maximale configurée ou que la limite configurée est nulle, le LNS ignore cette interface lorsqu’une demande de session est effectuée et sélectionne une autre interface dans le pool pour vérifier la limite de session. Cela continue jusqu’à ce qu’une interface réussisse et que la session soit acceptée ou qu’aucune autre interface ne reste dans le pool à sélectionner.
Équilibrage de charge de session entre les interfaces de service
Le comportement de distribution de la charge de session dans un pool d’appareils de service a changé dans Junos OS version 16.2. Lorsqu’un nombre de sessions d’une interface de service est inférieur à celui d’une autre interface du pool et que les deux interfaces sont inférieures à leur limite maximale de sessions, les sessions suivantes sont distribuées à l’interface ayant moins de sessions.
Dans les versions antérieures, les sessions étaient distribuées de manière strictement circulaire, quel que soit le nombre de sessions. L’ancien comportement peut entraîner une distribution inégale des sessions lorsque le moteur de transfert de paquets est redémarré ou qu’une interface de service tombe en panne puis se rétablit.
Prenons un exemple dans le scénario suivant utilisant l’ancien comportement de distribution Round Robin pour un pool avec deux interfaces de service :
Deux cents sessions sont réparties uniformément sur les deux interfaces de service.
SI-0/0/0 compte 100 sessions.
SI-1/0/0 compte 100 sessions.
L’interface si-1/0/0 redémarre. À son retour, les sessions initiales ne sont terminées que sur si-0/0/0.
SI-0/0/0 compte 100 sessions.
SI-1/0/0 a 0 sessions.
Comme les sessions précédemment sur si-1/0/0 se reconnectent, elles sont réparties de manière égale sur les deux interfaces de service. Lorsque les 100 sessions sont sauvegardées, la distribution est considérablement déséquilibrée.
SI-0/0/0 compte 150 sessions.
SI-1/0/0 comporte 50 sessions.
Après 100 nouvelles sessions connectées, si-0/0/0 atteint sa limite maximale. Les sessions suivantes ne sont acceptées que le si-1/0/0.
SI-0/0/0 compte 200 sessions.
SI-1/0/0 compte 100 sessions.
Après 100 sessions supplémentaires connectées, si-1/0/0 atteint sa limite maximale. Aucune autre session ne peut être acceptée tant que le nombre de sessions n’est pas inférieur à 200 pour l’une des interfaces.
SI-0/0/0 compte 200 sessions.
SI-1/0/0 compte 200 sessions.
Considérons maintenant le même scénario en utilisant le comportement de répartition de charge actuel en fonction du nombre de sessions jointes. Le pool d’appareils possède à nouveau deux interfaces de service, chacune avec une limite maximale configurée de 200 sessions :
Deux cents sessions sont réparties uniformément sur les deux interfaces de service.
SI-0/0/0 compte 100 sessions.
SI-1/0/0 compte 100 sessions.
L’interface si-1/0/0 redémarre. Lorsqu’il revient, les sessions ne sont initialement disponibles que sur si-0/0/0.
SI-0/0/0 compte 100 sessions.
SI-1/0/0 a 0 sessions.
Lorsque les sessions précédemment sur si-1/0/0 se reconnectent, elles sont distribuées en fonction de la charge de session sur chaque interface. Étant donné que les deux interfaces sont en dessous de leur limite maximale et que si-1/0/0 a moins de sessions que si-0/0/0, les sessions sont initialement distribuées uniquement à si-1/0/0.
Après 1 nouvelle session :
SI-0/0/0 compte 100 sessions.
SI-1/0/0 a 1 session.
Après 10 nouvelles sessions :
SI-0/0/0 compte 100 sessions.
SI-1/0/0 a 10 sessions.
Après 100 nouvelles sessions :
SI-0/0/0 compte 100 sessions.
SI-1/0/0 compte 100 sessions.
Comme les deux interfaces ont maintenant le même nombre de sessions, la session suivante (#101) est distribuée de manière aléatoire entre les deux interfaces. La session suivante (#102) va à l’interface avec le nombre de sessions le plus faible. Cela rend les interfaces à nouveau égales, de sorte que la session suivante (#103) est distribuée de manière aléatoire. Ce schéma se répète jusqu’à la limite maximale de 200 sessions pour les deux interfaces.
SI-0/0/0 compte 200 sessions.
SI-1/0/0 compte 200 sessions.
Aucune autre session ne peut être acceptée sur l’une ou l’autre interface tant que le nombre de sessions ne passe pas sous la barre des 200 sur l’une des interfaces.
Le comportement d’équilibrage de charge est le même pour les interfaces de service agrégées. Une interface asi est sélectionnée dans un pool en fonction du nombre de sessions actuel pour l’interface asi. Lorsque ce nombre est inférieur au nombre maximum, le LNS vérifie le nombre de sessions actuel pour l’interface si active dans le bundle asi. Lorsque ce nombre est inférieur au nombre maximum, la session peut être établie sur l’interface asi.
Dans un pool d’appareils mixtes qui comporte à la fois des interfaces de service et des interfaces de service agrégées, les sessions sont distribuées à l’interface, asi ou si, qui a le nombre de sessions le plus faible. Lorsque le nombre de sessions d’une interface, quel que soit son type, atteint sa limite, elle ne peut plus accepter de sessions tant que le nombre ne passe pas en dessous du maximum.
Vous pouvez utiliser la configuration de limite de session pour atteindre une limite de session sur des moteurs de transfert de paquets particuliers. Supposons que vous souhaitiez une limite de 100 sessions sur un PFE0 qui comporte deux interfaces de service. Vous pouvez définir la limite maximale sur chaque interface sur 50, ou toute autre combinaison dont la somme est égale à 100 pour établir la limite PFE0.
Exemple : Configuration d’un LNS L2TP
Cet exemple montre comment configurer un LNS L2TP sur un routeur MX Series pour fournir des points de terminaison de tunnel pour un LAC L2TP de votre réseau. Cette configuration inclut un profil dynamique pour les abonnés à double pile.
Exigences
Cet exemple de LNS L2TP nécessite les matériels et logiciels suivants :
Plate-forme de routage universelle MX Series 5G
Un ou plusieurs MPC
Junos OS version 11.4 ou ultérieure
Aucune configuration spéciale au-delà de l’initialisation de l’appareil n’est requise avant de pouvoir configurer cette fonctionnalité.
Vous devez configurer certains attributs RADIUS standard et Juniper Networks VSA dans la liste de retour d’attributs sur le serveur AAA associé au LNS pour que cet exemple fonctionne. Le Tableau 2 répertorie les attributs avec leur paramètre d’ordre et leurs valeurs requis. Nous vous recommandons d’utiliser le dictionnaire RADIUS Juniper Networks le plus récent, disponible dans la zone Téléchargements de la page Gestion des abonnés Junos OS à l’adresse https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/subscriber-access/index.html.
Nom VSA [numéro] |
Commande |
Valeur |
|---|---|---|
Type de paramètre CoS [26–108] |
1 |
T01 Multiplay |
Type de paramètre CoS [26–108] |
2 |
T02 10m |
Type de paramètre CoS [26–108] |
3 |
T08 -36 |
Type de paramètre CoS [26–108] |
4 |
Mode cellulaire T07 |
Framed-IPv6-Pool [100] |
0 |
jnpr_ipv6_pool |
Piscine encadrée [88] |
0 |
jnpr_pool |
nom de la stratégie de sortie [26-11] |
0 |
classifier |
nom de la stratégie entrante [26-10] |
0 |
classifier |
Routeur virtuel [26-1] |
0 |
par défaut |
Vue d’ensemble
Le LNS utilise des profils de groupes d’utilisateurs pour appliquer des attributs PPP aux abonnés PPP qui sont tunnelisés à partir du LAC. Les LAC du réseau sont des clients du LNS. Les clients sont associés à des profils de groupes d’utilisateurs dans le profil d’accès L2TP configuré sur le LNS. Dans cet exemple, le profil ce-l2tp-group-profile de groupe d’utilisateurs spécifie les attributs PPP suivants :
Intervalle de 30 secondes entre l’arrivée des messages keepalive PPP pour les tunnels L2TP du LAC client et leur arrivée sur le LNS.
Intervalle de 200 secondes qui définit la durée pendant laquelle la session d’abonné PPP peut être inactive avant d’être considérée comme ayant expiré.
PAP et CHAP sont les méthodes d’authentification PPP qui s’appliquent aux abonnés PPP tunnelisés au LNS.
Le profil ce-l2tp-profile d’accès L2TP définit un ensemble de paramètres L2TP pour chaque LAC client. Dans cet exemple, le profil ce-l2tp-group-profile de groupe d’utilisateurs est associé à la fois aux clients lac1 et lac2à . Les deux clients sont configurés pour que le LNS renégocie le protocole de contrôle de liaison (LCP) avec le client PPP plutôt que d’accepter les paramètres LCP prénégociés que les LAC transmettent au LNS. La renégociation du LCP entraîne également une renégociation de l’authentification par le LNS ; La méthode d’authentification est spécifiée dans le profil du groupe d’utilisateurs. Le nombre maximal de sessions autorisées par tunnel est défini sur 1000 pour lac1 et 4000 pour lac2. Un mot de passe différent est configuré pour chaque LAC.
Un profil d’accès AAA local, aaa-profile, vous permet de remplacer le profil d’accès AAA global, de sorte que vous pouvez spécifier un ordre d’authentification, un serveur RADIUS que vous souhaitez utiliser pour L2TP et un mot de passe pour le serveur.
Dans cet exemple, un pool d’adresses définit une plage d’adresses IP que le LNS alloue aux sessions PPP tunnelisées. Cet exemple définit des plages d’adresses IPv4 et IPv6.
Deux interfaces de service en ligne sont activées sur le MPC situé dans l’emplacement 5 du routeur. Pour chaque interface, 10 Gbit/s de bande passante sont réservés au trafic de tunnel sur le PFE associé à l’interface. Ces interfaces d’ancrage servent d’interface physique sous-jacente. Pour activer la prise en charge des files d’attente CoS sur les interfaces de service en ligne logiques individuelles, vous devez configurer à la fois l’encapsulation des services (generic-services) et la prise en charge de la planification hiérarchique sur les ancres. La famille d’adresses IPv4 est configurée pour les deux interfaces d’ancrage. Les deux interfaces d’ancrage sont spécifiées dans le pool de périphériques de lns_p1 service. Le LNS peut équilibrer les charges de trafic entre les deux interfaces d’ancrage lorsque le groupe de tunnels inclut le pool.
Cet exemple utilise le profil dyn-lns-profile2 dynamique pour spécifier les caractéristiques des sessions L2TP qui sont créées ou affectées dynamiquement lorsqu’un abonné est tunnelisé vers le LNS. Pour de nombreuses caractéristiques, une variable prédéfinie est définie ; les variables sont remplacées dynamiquement par les valeurs appropriées lorsqu’un abonné est tunnelisé vers le LNS.
L’interface à laquelle le client PPP tunnelisé se connecte ($junos-interface-name) est créée dynamiquement dans l’instance de routage ($junos-routing-instance) affectée à l’abonné. Les options de routage pour les routes d’accès incluent l’adresse du prochain saut de la route ($junos-framed-route-nexthop), la métrique ($junos-framed-route-cost) et la préférence ($junos-framed-route-distance). Pour les routes internes à l’accès, une variable d’adresse IP dynamique ($junos-subscriber-ip-address) est définie.
Les interfaces de service logiques en ligne sont définies par le nom d’une interface d’ancrage configurée ($junos-interface-ifd-name) et un numéro d’unité logique ($junos-interface-unit). Le profil attribue l2tp-encapuslation comme identifiant l’interface logique et spécifie que chaque interface ne peut être utilisée que pour une seule session à la fois.
L’adresse IPv4 est définie sur une valeur renvoyée par le serveur AAA. Pour le trafic IPv4, un filtre $junos-input-filter de pare-feu d’entrée et un filtre $junos-output-filter de pare-feu de sortie sont attachés à l’interface. La variable de bouclage ($junos-loopback-interface) dérive une adresse IP d’une interface de bouclage (lo) configurée dans l’instance de routage et l’utilise dans la négociation IPCP comme adresse de serveur PPP. Comme il s’agit d’une configuration à double pile, la famille d’adresses IPv6 est également définie, avec les adresses fournies par la $junos-ipv6-address variable.
La $junos-ipv6-address variable est utilisée car le protocole Router Advertisement Protocol est également configuré. Cette variable permet à AAA d’allouer la première adresse du préfixe à réserver comme adresse locale pour l’interface. La configuration minimale du protocole de publication de routeur dans le profil dynamique spécifie les $junos-interface-name variables et $junos-ipv6-ndra-prefix à affecter dynamiquement une valeur de préfixe dans les annonces de routeur de découverte de voisins IPv6.
Le profil dynamique inclut également la classe de configuration de service appliquée au trafic du tunnel. Le profil de contrôle du trafic (tc-profile) inclut des variables pour la carte du planificateur ($junos-cos-scheduler-map), le taux de mise en forme ($junos-cos-shaping-rate), la comptabilité des frais généraux ($junos-cos-shaping-mode) et l’ajustement des $junos-cos-byte-adjustoctets ). Le profil dynamique applique la configuration CoS, y compris la classe de transfert, le profil de contrôle du trafic de sortie et les règles de réécriture, aux interfaces de service dynamiques.
La tg-dynamic configuration de groupe de tunnels spécifie le profil ce-l2tp-profiled’accès , le profil aaa-profileAAA local et le profil dyn-lns-profile2 dynamique qui sont utilisés pour créer dynamiquement des sessions LNS et définir les caractéristiques des sessions. Le lns_p1 pool d’équipements de service associe un pool d’interfaces de service au groupe pour permettre au LNS d’équilibrer le trafic entre les interfaces. L’adresse 203.0.113.2 de passerelle locale correspond à l’adresse de passerelle distante configurée sur le réseau LAC. Le nom ce-lns de la passerelle locale correspond au nom de la passerelle distante configurée sur le lac des accès.
Cet exemple ne montre pas tous les choix de configuration possibles.
La configuration
Procédure
Configuration rapide de la CLI
Pour configurer rapidement un LNS L2TP, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, puis copiez et collez les commandes dans la CLI.
[edit] edit access group-profile ce-l2tp-group-profile set ppp idle-timeout 200 set ppp ppp-options pap set ppp ppp-options chap set ppp keepalive 30 top edit access profile ce-l2tp-profile set client lac1 l2tp maximum-sessions-per-tunnel 1000 set client lac1 l2tp interface-id l2tp-encapsulation-1 set client lac1 l2tp lcp-renegotiation set client lac1 l2tp shared-secret "lac1-$ABC123" set client lac1 user-group-profile ce-l2tp-group-profile set client lac2 l2tp maximum-sessions-per-tunnel 4000 set client lac2 l2tp interface-id l2tp-encap-2 set client lac2 l2tp lcp-renegotiation set client lac2 l2tp shared-secret "lac2-$ABC123" set client lac2 user-group-profile ce-l2tp-group-profile top edit access profile aaa-profile set authentication-order radius set radius authentication-server 198.51.100.193 set radius-server 198.51.100.193 secret "$ABC123” top edit access address-assignment pool client-pool1 family inet set network 192.168.1.1/16 set range lns-v4-pool-range low 192.168.1.1 set range lns-v4-pool-range high 192.168.255.255 top edit access address-assignment pool client-ipv6-pool2 family inet6 set prefix 2001:DB8::/32 set range lns-v6-pool-range low 2001:DB8:1::/48 set range lns-v6-pool-range high 2001:DB8:ffff::/48 top set interfaces ge-5/0/1 unit 11 vlan-id 11 set interfaces ge-5/0/1 unit 11 family inet address 203.0.113.2/24 set interfaces lo0 unit 0 family inet address 127.0.0.1/32 top set chassis fpc 5 pic 0 inline-services bandwidth 10g set chassis fpc 5 pic 2 inline-services bandwidth 10g top edit interfaces si-5/0/0 set hierarchical-scheduler maximum-hierarchy-levels 2 set encapsulation generic-services set unit 0 family inet top edit interfaces si-5/2/0 set hierarchical-scheduler maximum-hierarchy-levels 2 set encapsulation generic-services set unit 0 family inet top set services service-device-pools pool lns_p1 interface si-5/0/0 set services service-device-pools pool lns_p1 interface si-5/2/0 top edit dynamic-profiles dyn-lns-profile2 routing-instances $junos-routing-instance set interface $junos-interface-name edit routing-options access route $junos-framed-route-ip-address-prefix set next-hop $junos-framed-route-nexthop set metric $junos-framed-route-cost set preference $junos-framed-route-distance up 2 edit access-internal route $junos-subscriber-ip-address set qualified-next-hop $junos-interface-name up 5 edit interfaces $junos-interface-ifd-name unit $junos-interface-unit set dial-options l2tp-interface-id l2tp-encapsulation set dial-options dedicated set family inet filter input $junos-input-filter set family inet filter output $junos-output-filter set family inet unnumbered-address $junos-loopback-interface set family inet6 address $junos-ipv6-address set family inet6 filter input $junos-input-ipv6-filter set family inet6 filter output $junos-output-ipv6-filter up 3 edit protocols router-advertisement set interface $junos-interface-name prefix $junos-ipv6-ndra-prefix top [edit class-of-service] edit rewrite-rules dscp rewriteDSCP forwarding-class expedited-forwarding set loss-priority high code-point af11 set loss-priority high code-point af12 top edit dynamic-profiles dyn-lns-profile2 class-of-service traffic-control-profiles tc-profile set scheduler-map $junos-cos-scheduler-map set shaping-rate $junos-cos-shaping-rate set overhead-accounting $junos-cos-shaping-mode set overhead-accounting bytes $junos-cos-byte-adjust up edit interfaces $junos-interface-ifd-name unit $junos-interface-unit set forwarding-class expedited-forwarding set output-traffic-control-profile tc-profile set rewrite-rules dscp rewriteDSCP edit interfaces si-5/0/0 set output-control-profile-remaining tc-profile top set services l2tp tunnel-group tg-dynamic l2tp-access-profile ce-l2tp-profile set services l2tp tunnel-group tg-dynamic aaa-access-profile aaa-profile set services l2tp tunnel-group tg-dynamic local-gateway address 203.0.113.2 set services l2tp tunnel-group tg-dynamic local-gateway gateway-name ce-lns set services l2tp tunnel-group tg-dynamic service-device-pool lns_p1 set services l2tp tunnel-group tg-dynamic dynamic-profile dyn-lns-profile2
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la procédure à suivre, consultez Utilisation de l’éditeur CLI en mode configuration.
Pour configurer un LNS L2TP avec des interfaces de service en ligne :
Configurez un profil de groupe d’utilisateurs qui définit la configuration PPP pour les abonnés au tunnel.
[edit access] user@host# edit group-profile ce-l2tp-group-profile [edit access group-profile ce-l2tp-group-profile] user@host# set ppp keepalive 30 user@host# set ppp idle-timeout 200 user@host# set ppp ppp-options chap user@host# set ppp ppp-options pap
Configurez un profil d’accès L2TP qui définit les paramètres L2TP pour chaque LAC client. Cela inclut l’association d’un profil de groupe d’utilisateurs au client et la spécification de l’identifiant de l’interface logique des services en ligne qui représente une session L2TP sur le LNS.
[edit access profile ce-l2tp-profile client lac1] user@host# set l2tp interface-id l2tp-encapsulation user@host# set l2tp maximum-sessions-per-tunnel 1000 user@host# set l2tp shared-secret "lac1-$ABC123" user@host# set l2tp lcp-renegotiation user@host# set user-group-profile ce-l2tp-group-profile [edit access profile ce-l2tp-profile client lac2] user@host# set l2tp interface-id interface-id user@host# set l2tp maximum-sessions-per-tunnel 4000 user@host# set l2tp shared-secret "lac2-$ABC123" user@host# set l2tp lcp-renegotiation user@host# set user-group-profile ce-l2tp-group-profile
Remarque :S’il
user-group-profileest modifié ou supprimé, les abonnés LNS existants qui utilisaient cette configuration client du protocole de tunnelisation de couche 2 tombent en panne.Configurez un profil d’accès AAA pour remplacer le profil d’accès global pour l’ordre des méthodes d’authentification AAA et des attributs de serveur.
[edit access profile aaa-profile] user@host# set authentication-order radius user@host# set radius authentication-server 198.51.100.193 user@host# set radius-server 198.51.100.193 secret "$ABC123”
Configurez les pools d’attribution d’adresses IPv4 et IPv6 pour allouer des adresses aux clients (LAC).
[edit access address-assignment pool client-pool1 family inet] user@host# set network 192.168.1.1/16 user@host# set range lns-v4-pool-range low 192.168.1.1 high 192.168.255.255 [edit access address-assignment pool client-ipv6-pool2 family inet6] user@host# set prefix 2001:DB8::/32 user@host# set range lns-v6-pool-range low 2001:DB8:1::/48 user@host# set range lns-v6-pool-range high 2001:DB8:ffff::/48
Configurez l’interface homologue pour terminer le tunnel et l’adresse IPCP côté serveur PPP (adresse de bouclage).
[edit interfaces ge-5/0/1 user@host# set vlan-tagging user@host# set unit 11 [edit interfaces ge-5/0/1.11 user@host# set vlan-id 11 user@host# set family inet address 10.1.1.2/24 [edit interfaces lo0] user@host# set unit 0 family inet address 127.0.0.1/32
Activez les interfaces de service en ligne sur une MPC.
[edit chassis fpc 5] user@host# set pic 0 inline-services bandwidth 10g user@host# set pic 2 inline-services bandwidth 10g
Configurez les interfaces de service d’ancrage avec l’encapsulation des services, la planification hiérarchique et la famille d’adresses.
[edit interfaces si-5/0/0] user@host# set hierarchical-scheduler maximum hierarchy-levels 2 user@host# set encapsulation generic-services user@host# set unit 0 family inet [edit interfaces si-5/2/0] user@host# set hierarchical-scheduler maximum hierarchy-levels 2 user@host# set encapsulation generic-services user@host# set unit 0 family inet
Configurez un pool d’interfaces de service pour les sessions LNS dynamiques.
[edit services service-device-pools pool lns_p1] user@host# set interface si-5/0/0 user@host# set interface si-5/2/0
Configurez un profil dynamique qui crée dynamiquement des interfaces logiques L2TP pour les abonnés à double pile.
[edit dynamic-profiles dyn-lns-profile2] user@host# edit routing-instances $junos-routing-instance user@host# set interface $junos-interface-name [edit dynamic-profiles dyn-lns-profile2 routing-instances “$junos-routing-instance”] user@host# edit routing-options access route $junos-framed-route-ip-address-prefix [edit dynamic-profiles dyn-lns-profile2 routing-instances “$junos-routing-instance” routing-options access route “$junos-framed-route-ip-address-prefix”] user@host# set next-hop $junos-framed-route-nexthop user@host# set metric $junos-framed-route-cost user@host# set preference $junos-framed-route-distance [edit dynamic-profiles dyn-lns-profile2 routing-instances “$junos-routing-instance” routing-options access-internal] user@host# set route $junos-subscriber-ip-address qualified-next-hop $junos-interface-name [edit dynamic-profiles dyn-lns-profile2 interfaces “$junos-interface-ifd-name” unit “$junos-interface-unit”] user@host# set dial-options l2tp-interface-id l2tp-encapsulation user@host# set dial-options dedicated user@host# set family inet unnumbered-address $junos-loopback-interface user@host# set family inet filter input $junos-input-filter user@host# set family inet filter output $junos-output-filter user@host# set family inet6 address $junos-ipv6-address set family inet6 filter input $junos-input-ipv6-filter set family inet6 filter output $junos-output-ipv6-filter [edit dynamic-profiles dyn-lns-profile2 protocols router-advertisement] user@host# set interface $junos-interface-name prefix $junos-ipv6-ndra-prefix
Configurez les règles de mise en forme, de planification et de réécriture, et appliquez-les dans le profil dynamique au trafic du tunnel.
[edit class-of-service] user@host# edit rewrite-rules dscp rewriteDSCP forwarding-class expedited-forwarding user@host# set loss-priority high code-point af11 user@host# set loss-priority high code-point af12 [edit dynamic-profiles dyn-lns-profile2 class-of-service traffic-control-profiles tc-profile] user@host# set scheduler-map $junos-cos-scheduler-map user@host# set shaping-rate $junos-cos-shaping-rate user@host# set overhead-accounting $junos-cos-shaping-mode user@host# set overhead-accounting bytes $junos-cos-byte-adjust [edit dynamic-profiles dyn-lns-profile2 class-of-service interfaces “$junos-interface-ifd-name” unit "$junos-interface-unit"] user@host# set forwarding-class expedited-forwarding user@host# set output-traffic-control-profile tc-profile user@host# set rewrite-rules dscp rewriteDSCP [edit class-of-service interfaces si-5/0/0] user@host# set output-traffic-control-profile-remaining tc-profile
Configurez le groupe de tunnels L2TP pour activer des sessions LNS dynamiques en utilisant le pool d’interfaces de service en ligne pour activer l’équilibrage de charge.
[edit services l2tp tunnel-group tg-dynamic] user@host# set l2tp-access-profile ce-l2tp-profile user@host# set local-gateway address 10.1.1.2 user@host# set local-gateway gateway-name ce-lns user@host# set aaa-access-profile aaa-profile user@host# set dynamic-profile dyn-lns-profile2 user@host# set service-device-pool lns_p1
Résultats
En mode configuration, confirmez la configuration du profil d’accès, du profil de groupe, du profil AAA et des pools d’attribution d’adresses en entrant la show access commande. Confirmez la configuration des services en ligne en entrant la show chassis commande. Confirmez la configuration de l’interface en entrant la show interfaces commande. Confirmez la configuration du profil dynamique en entrant la show dynamic-profiles commande. Confirmez la configuration du groupe de tunnels en entrant la show services l2tp commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@host# show access
group-profile ce-l2tp-group-profile {
ppp {
idle-timeout 200;
ppp-options {
pap;
chap;
}
keepalive 30;
}
}
profile ce-l2tp-profile {
client lac1 {
l2tp {
maximum-sessions-per-tunnel 1000;
interface-id l2tp-encapsulation-1;
lcp-renegotiation;
shared-secret "lac1-$ABC123"; ## SECRET-DATA
}
user-group-profile ce-l2tp-group-profile;
}
client lac2 {
l2tp {
maximum-sessions-per-tunnel 4000;
interface-id l2tp-encap-2;
lcp-renegotiation;
shared-secret "lac2-$ABC123"; ## SECRET-DATA
}
user-group-profile ce-l2tp-group-profile;
}
}
profile aaa-profile {
authentication-order radius;
radius-server {
198.51.100.193 secret "$ABC123"; ## SECRET-DATA
}
}
address-assignment {
pool client-pool1 {
family inet {
network 192.168.1.1/16;
range lns-v4-pool-range {
low 192.168.1.1;
high 192.168.255.255;
}
}
}
pool client-ipv6-pool2 {
family inet6 {
prefix 2001:DB8::/32;
range lns-v6-pool-range {
low 2001:DB8:1::/48;
high 2001:DB8:ffff::/48;
}
}
}
}
[edit]
user@host# show chassis
fpc 5 {
pic 0 {
inline-services {
bandwidth 10g;
}
}
pic 2 {
inline-services {
bandwidth 10g;
}
}
}
[edit]
user@host# show interfaces
ge-5/0/1 {
vlan-tagging;;
unit 11 {
vlan-id 11;
family inet {
address 203.0.113.2/24;
}
}
}
si-5/0/0 {
hierarchical-scheduler maximum-hierarchy-levels 2;
encapsulation generic-services;
unit 0 {
family inet;
}
}
si-5/2/0 {
hierarchical-scheduler maximum-hierarchy-levels 2;
encapsulation generic-services;
unit 0 {
family inet;
}
}
lo0 {
unit 0 {
family inet {
address 127.0.0.1/32;
}
}
}
[edit]
user@host# show dynamic-profiles
dyn-lns-profile2 {
routing-instances {
"$junos-routing-instance" {
interface "$junos-interface-name";
routing-options {
access {
route $junos-framed-route-ip-address-prefix {
next-hop "$junos-framed-route-nexthop";
metric "$junos-framed-route-cost";
preference "$junos-framed-route-distance";
}
}
access-internal {
route $junos-subscriber-ip-address {
qualified-next-hop "$junos-interface-name";
}
}
}
}
}
interfaces {
"$junos-interface-ifd-name" {
unit "$junos-interface-unit" {
dial-options {
l2tp-interface-id l2tp-encapsulation;
dedicated;
}
family inet {
filter {
input "$junos-input-filter";
output "$junos-output-filter";
}
unnumbered-address "$junos-loopback-interface";
}
family inet6 {
address $junos-ipv6-address;
input $junos-input-ipv6-filter;
output $junos-output-ipv6-filter;
}
}
}
}
protocols {
router-advertisement {
interface "$junos-interface-name" {
prefix $junos-ipv6-ndra-prefix;
}
}
}
class-of-service {
rewrite-rules {
dscp rewriteDSCP {
forwarding-class expedited-forwarding {
loss-priority high code-point af11
loss-priority high code-point af12
}
}
}
traffic-control-profiles {
tc-profile {
scheduler-map "$junos-cos-scheduler-map";
shaping-rate "$junos-cos-shaping-rate";
overhead-accounting "$junos-cos-shaping-mode" bytes "$junos-cos-byte-adjust";
}
}
interfaces {
"$junos-interface-ifd-name" {
unit "$junos-interface-unit" {
forwarding-class expedited-forwarding;
output-traffic-control-profile tc-profile;
rewrite-rules {
dscp rewriteDSCP;
}
}
}
}
}
}
[edit]
user@host# show services l2tp
tunnel-group tg-dynamic {
l2tp-access-profile ce-l2tp-profile;
aaa-access-profile aaa-profile;
local-gateway {
address 203.0.113.2;
gateway-name ce-lns;
}
service-device-pool lns_p1;
dynamic-profile dyn-lns-profile2;
}
Lorsque vous avez terminé de configurer l’appareil, entrez en commit mode configuration.
Configuration d’un groupe de tunnels L2TP pour les sessions LNS avec des interfaces de services en ligne
Le groupe de tunnels L2TP spécifie les attributs qui s’appliquent aux tunnels L2TP et aux sessions d’un groupe de clients BAC. Ces attributs incluent le profil d’accès utilisé pour valider les demandes de connexion L2TP adressées au LNS sur l’adresse de passerelle locale, un profil d’accès local qui remplace le profil d’accès global, le minuteur keepalive et si la valeur IP ToS est reflétée.
Si vous supprimez un groupe de tunnels, toutes les sessions L2TP de ce groupe de tunnels sont terminées. Si vous modifiez la valeur des local-gateway-addressinstructions , service-device-poolou service-interface , toutes les sessions L2TP utilisant ces paramètres sont terminées. Si vous modifiez ou supprimez d’autres instructions au niveau de la [edit services l2tp tunnel-group name] hiérarchie, les nouveaux tunnels que vous établissez utilisent les valeurs mises à jour, mais les tunnels et les sessions existants ne sont pas affectés.
Pour configurer le groupe de tunnels LNS :
Application de services à une session L2TP sans utiliser RADIUS
Les services sont appliqués aux sessions L2TP pour l’activation ou modifiés ultérieurement par les attributs spécifiques au fournisseur (VSA) du serveur RADIUS ou dans les demandes de changement d’autorisation (CoA) RADIUS. À partir de la version 18.1R1 de Junos OS, vous pouvez appliquer des services aux sessions L2TP au moyen de profils de service dynamiques sans impliquer RADIUS. Dans les environnements multifournisseurs, les clients peuvent utiliser uniquement des attributs RADIUS standard pour simplifier la gestion en évitant l’utilisation de VSA de plusieurs fournisseurs. Cependant, cela complique l’application des services aux sessions L2TP, car les VSA sont généralement tenus d’appliquer des services. L’activation dynamique locale du profil de service vous permet d’éviter ce problème. Vous pouvez également utiliser l’activation du profil de service local pour fournir des services par défaut lorsque les serveurs RADIUS sont en panne.
Vous pouvez appliquer des services à tous les abonnés d’un groupe de tunnels ou à tous les abonnés utilisant un lac particulier. Vous pouvez configurer un maximum de 12 services par groupe de tunnels ou nom d’hôte BAC.
Après avoir configuré un ou plusieurs profils de service dynamiques qui définissent des services, vous les appliquez dans le groupe de tunnels ou dans la configuration de profil d’accès d’un client LAC en spécifiant les noms des profils de service. Vous pouvez lister plusieurs profils à activer, séparés par une esperluette (&). Vous pouvez également spécifier des paramètres à utiliser par le profil de service qui peuvent remplacer les valeurs configurées dans le profil lui-même, tels qu’un taux de mise en forme en aval pour un service CoS.
La liste des services configurée localement (via les profils de service) sert d’autorisation locale qui est appliquée par authd lors de l’activation de la session client. Cette liste de services est soumise à la même validation et au même traitement que les services provenant d’autorités externes, telles que RADIUS. Ces services sont présentés lors de la connexion de l’abonné.
Vous pouvez toujours utiliser des VSA RADIUS ou des demandes CoA de concert avec les profils de service. Si les services proviennent d’une autorité externe en tant qu’autorisation lors de l’authentification ou pendant le provisionnement (activation) de la session de l’abonné, les services de l’autorité externe ont la priorité absolue sur ceux de la configuration locale. Si un service appliqué avec RADIUS est identique à un service appliqué avec un profil de service dans la CLI, mais avec des paramètres différents, le service RADIUS est appliqué avec un nouvel ID de session et est prioritaire sur le profil de service précédent.
Vous pouvez émettre des commandes pour désactiver ou réactiver tout service que vous avez précédemment activé pour un groupe de tunnels ou un LAC.
Définissez les profils de service dynamiques que vous souhaitez appliquer ultérieurement à un groupe de tunnels ou à un LAC.
Pour appliquer des profils de service à tous les abonnés d’un groupe de tunnels :
Spécifiez un ou plusieurs profils de service et tous les paramètres à transmettre aux services.
[edit services l2tp tunnel-group group-name] user@host# set service-profile profile-name(parameter)&profile-name
Pour appliquer des profils de service à tous les abonnés d’une LAC donnée :
Spécifiez un ou plusieurs profils de service et tous les paramètres à transmettre aux services.
[edit access profile profile-name client client-name l2tp] user@host# set service-profile profile-name(parameter)&profile-name
Remarque :Lorsque des profils de service sont configurés pour un client LAC et pour un groupe de tunnels qui utilise ce client, seul le profil de service client LAC est appliqué. Elle remplace la configuration du groupe de tunnels. Par exemple, dans la configuration suivante, le groupe de tunnels tg-LAC-3 utilise le client LAC LAC-3, de sorte que la configuration LAC3 remplace la configuration du groupe de tunnels. Par conséquent, seul le service cos-A3 est activé pour les abonnés du groupe de tunnels, plutôt que pour Cos2 et fw1. Le taux de mise en forme passé pour le service est de 24 Mbit/s.
[edit] user@host# set services l2tp tunnel-group tg-LAC-3 service-profile cos2(31000000)&fw1 user@host# set access profile prof-lac client LAC-3 l2tp service-profile cos-A3(24000000)
Vous pouvez désactiver tout service appliqué à une session d’abonné en exécutant la commande suivante :
user@host> request network-access aaa subscriber delete session-id subscriber-session-id service-profile profile-name
Vous pouvez réactiver n’importe quel service appliqué à une session d’abonné en exécutant la commande suivante :
user@host> request network-access aaa subscriber add session-id subscriber-session-id service-profile profile-name
Pour afficher les sessions de services pour toutes les sessions d’abonné actuelles, utilisez la show subscribers extensive commande or show network-access aaa subscribers session-id id-number detail .
Pour comprendre le fonctionnement d’une application de service local, les exemples suivants illustrent les différentes possibilités de configuration. Tout d’abord, considérez les configurations de profil de service dynamique suivantes, Cos2 et FW1 :
dynamic-profiles {
cos2 {
variables {
shaping-rate default-value 10m;
shaping-rate-in default-value 10m;
data-in-filter uid;
data-in-policer uid;
}
interfaces {
"$junos-interface-ifd-name" {
unit "$junos-interface-unit" {
family inet;
}
}
}
class-of-service {
traffic-control-profiles {
TrafficShaper {
scheduler-map a;
shaping-rate "$shaping-rate";
}
}
interfaces {
"$junos-interface-ifd-name" {
unit "$junos-interface-unit" {
output-traffic-control-profile TrafficShaper;
}
}
}
}
}
|
dynamic-profiles {
fw1 {
variables {
v6input default-value v6ingress;
v6output default-value v6egress;
input default-value upstrm-filter;
output default-value dwnstrm-filter;
}
interfaces {
"$junos-interface-ifd-name" {
unit "$junos-interface-unit" {
family inet;
}
}
}
}
}
L’affirmation suivante s’applique aux deux services à tous les abonnés du groupe de tunnels tg1 ; une valeur de paramètre de 31 Mbit/s est transmise au service cos2 :
[edit] user@host# set services l2tp tunnel-group tg1 service-profile cos2(31000000)&fw1
Dans le profil de service cos2, la vitesse de mise en forme est fournie par une variable définie par l’utilisateur avec une valeur par défaut de 10 m, ou 1 Mbit/s. Une fois la session L2TP terminée, cos2 et fw1 sont activés avec des ID de session de service de 34 et 35, respectivement.
user@host1> show subscribers extensive
...
Service Session ID: 34
Service Session Name: cos2
State: Active
Family: inet
Service Activation time: 2018-02-15 15:44:16 IST
Service Session ID: 35
Service Session Name: fw1
State: Active
Family: inet
Service Activation time: 2018-02-15 15:44:16 IST
Dynamic configuration:
input: upstrm-filter
output: dwnstrm-filter
v6input: v6ingress
v6output: v6egress
Le paramètre passé à cos2 est utilisé comme valeur pour $shaping-rate ; par conséquent, la vitesse de mise en forme du service est ajustée de la valeur par défaut de 10 Mbit/s à 31 Mbit/s, comme indiqué dans la sortie de commande suivante. Bien que la sortie indique que l’application de réglage est RADIUS CoA, l’ajustement est une conséquence du paramètre transmis au profil de service. Cette opération utilise le même cadre interne qu’un CoA et est déclarée comme telle.
user@host1> show class-of-service interface si-1/0/0.3221225492
Logical interface: si-1/0/0.3221225492, Index: 3221225492
Object Name Type Index
Traffic-control-profile subscriber-tcp-2 Output 23571
Scheduler-map a Output 4294967354
Classifier dscp-ipv6-compatibility dscp-ipv6 9
Classifier ipprec-compatibility ip 13
Adjusting application: RADIUS CoA
Adjustment type: absolute
configured-shaping-rate: 31000000
adjustment-value: 31000000
Adjustment overhead-accounting mode: frame mode
Adjustment overhead bytes: 0
Adjustment target: node
Adjustment priority: 1
À présent, le service cos2 est désactivé de la CLI pour la session 27 de l’abonné.
user@host1> request network-access aaa subscriber delete service-profile cos2 session-id 27 Successful completion
La sortie suivante montre que cos2 a disparu, ne laissant que fw1 comme service actif.
user@host1> show subscribers extensive
Type: L2TP
User Name: user@example.com
IP Address: 192.0.2.103
IP Netmask: 255.255.255.255
Logical System: default
Routing Instance: default
Interface: si-1/0/0.3221225492
Interface type: Dynamic
Underlying Interface: si-1/0/0.3221225492
Dynamic Profile Name: dyn-lns-profile
State: Active
Radius Accounting ID: 27
Session ID: 27
PFE Flow ID: 42
Login Time: 2017-08-30 07:29:39 IST
Service Sessions: 1
IP Address Pool: ipv4_pool
Accounting interval: 600
Frame/cell mode: Frame
Overhead accounting bytes: -38
Calculated downstream data rate: 1000000 kbps
Adjusted downstream data rate: 1000000 kbps
Service Session ID: 35
Service Session Name: fw1
State: Active
Family: inet
Service Activation time: 2018-02-15 15:44:16 IST
Dynamic configuration:
input: upstrm-filter
output: dwnstrm-filter
v6input: v6ingress
v6output: v6egress
La commande suivante réactive cos2 pour la session d’abonné 27.
user@host1> request network-access aaa subscriber add service-profile cos2 session-id 27 Successful completion
Le service cos2 réactivé a un nouvel ID de session de service de 36.
user@host1> show subscribers extensive
...
Service Session ID: 35
Service Session Name: fw1
State: Active
Family: inet
Service Activation time: 2018-02-15 15:44:16 IST
Dynamic configuration:
input: upstrm-filter
output: dwnstrm-filter
v6input: v6ingress
v6output: v6egress
Service Session ID: 36
Service Session Name: cos2
State: Active
Family: inet
Service Activation time: 2018-02-15 15:58:23 IST
Le service cos2 réactivé utilise le taux de mise en forme par défaut, 10 Mbit/s, du profil de service.
user@host1> show class-of-service interface si-1/0/0.3221225492
Logical interface: si-1/0/0.3221225492, Index: 3221225492
Object Name Type Index
Traffic-control-profile subscriber-tcp-2 Output 23571
Scheduler-map a Output 4294967354
Classifier dscp-ipv6-compatibility dscp-ipv6 9
Classifier ipprec-compatibility ip 13
Adjusting application: RADIUS CoA
Adjustment type: absolute
configured-shaping-rate: 10000000
adjustment-value: 10000000
Adjustment overhead-accounting mode: frame mode
Adjustment overhead bytes: 0
Adjustment target: node
Adjustment priority: 1
Ensuite, une demande de CoA RADIUS est reçue, qui inclut le VSA d’activation du service (26-65). Le VSA spécifie et active le service et spécifie une modification du taux de mise en forme de cos2 de 10 Mbit/s par défaut à 12 Mbit/s. La session de service cos2 36 apparaît toujours dans la sortie, mais est remplacée par la nouvelle session de service initiée par le CoA, 49.
user@host1> show subscribers extensive
...
Service Session ID: 35
Service Session Name: fw1
State: Active
Family: inet
Service Activation time: 2018-02-15 15:44:16 IST
Dynamic configuration:
input: upstrm-filter
output: dwnstrm-filter
v6input: v6ingress
v6output: v6egress
Service Session ID: 36
Service Session Name: cos2
State: Active
Family: inet
Service Activation time: 2018-02-15 15:58:23 IST
Service Session ID: 49
Service Session Name: cos2
State: Active
Family: inet
Service Activation time: 2018-02-15 16:25:04 IST
Dynamic configuration:
shaping-rate: 12000000
shaping-rate-in: 10m
user@host1> show class-of-service interface si-1/0/0.3221225492
Logical interface: si-1/0/0.3221225492, Index: 3221225492
Object Name Type Index
Traffic-control-profile subscriber-tcp-2 Output 23571
Scheduler-map a Output 4294967354
Classifier dscp-ipv6-compatibility dscp-ipv6 9
Classifier ipprec-compatibility ip 13
Adjusting application: RADIUS CoA
Adjustment type: absolute
configured-shaping-rate: 12000000
adjustment-value: 12000000
Adjustment overhead-accounting mode: frame mode
Adjustment overhead bytes: 0
Adjustment target: node
Adjustment priority: 1
Lorsqu’un service est appliqué à la fois par la configuration CLI et par un VSA RADIUS (26-65), mais avec des paramètres différents, la configuration RADIUS remplace la configuration CLI. Dans l’exemple suivant, la configuration CLI applique le profil de service cos2 avec une valeur de 31 Mbit/s pour le taux de mise en forme.
[edit] user@host# set services l2tp tunnel-group tg1 service-profile cos2(31000000)
L’activation du service de message d’accès-acceptation RADIUS VSA (26-65) applique cos2 avec une valeur de 21 Mbit/s pour le taux de mise en forme.
l2tp@l2tp.com User-Password := "bras"
Auth-Type = Local,
Service-Type = Framed-User,
Framed-Protocol = PPP,
ERX-Service-Activate:1 += 'cos2(21000000)',
La configuration CLI active la session de service 22 avec un taux de mise en forme de 31 Mbit/s. Le VSA RADIUS active la session de service 23 avec un taux de mise en forme de 21 Mbit/s.
user@host1> show subscribers extensive
...
Service Session ID: 22
Service Session Name: cos2
State: Active
Family: inet
Service Activation time: 2018-02-16 08:22:03 IST
Dynamic configuration:
shaping-rate: 31000000
shaping-rate-in: 10m
Service Session ID: 23
Service Session Name: cos2
State: Active
Family: inet
Service Activation time: 2018-02-16 08:22:03 IST
Dynamic configuration:
shaping-rate: 21000000
shaping-rate-in: 10m
user@host1> show class-of-service interface si-1/0/0.3221225492
Logical interface: si-1/0/0.3221225492, Index: 3221225492
Object Name Type Index
Traffic-control-profile subscriber-tcp-2 Output 23571
Scheduler-map a Output 4294967354
Classifier dscp-ipv6-compatibility dscp-ipv6 9
Classifier ipprec-compatibility ip 13
Adjusting application: RADIUS CoA
Adjustment type: absolute
configured-shaping-rate: 21000000
adjustment-value: 21000000
Adjustment overhead-accounting mode: frame mode
Adjustment overhead bytes: 0
Adjustment target: node
Adjustment priority: 1
Configuration d’un pool d’interfaces de services en ligne pour les sessions LNS dynamiques
Vous pouvez créer un pool d’interfaces de service en ligne, également appelé pool d’équipements de service, pour permettre l’équilibrage de charge du trafic L2TP entre les interfaces. Le pool est pris en charge pour les configurations LNS dynamiques, où il fournit un ensemble d’interfaces logiques qui peuvent être créées dynamiquement et allouées aux sessions L2TP sur le LNS. Le pool est affecté à un groupe de tunnels LNS. L2TP conserve l’état de chaque interface de service en ligne et utilise une méthode de tourniquet pour répartir uniformément la charge entre les interfaces disponibles lorsque de nouvelles demandes de session sont acceptées.
L’équilibrage de charge n’est disponible que pour les interfaces d’abonné créées dynamiquement.
Les sessions LNS ancrées sur une MPC ne sont pas affectées par une défaillance de MIC tant qu’il existe un autre chemin vers les LAC homologues. Si le MPC hébergeant l’interface homologue tombe en panne et qu’il n’y a pas de chemin vers les LAC homologues, la défaillance déclenche l’arrêt et le nettoyage de toutes les sessions sur le MPC.
Si le MPC ancrant les sessions LNS lui-même échoue, le moteur de routage ne déplace pas les sessions vers un autre emplacement et toutes les sessions sont immédiatement terminées. De nouvelles sessions peuvent apparaître sur une autre interface disponible lorsque le client tente une nouvelle tentative.
Pour configurer le pool d’appareils de service :
Configuration d’un profil dynamique pour les sessions LNS dynamiques
Vous pouvez configurer L2TP pour attribuer dynamiquement des interfaces de service en ligne aux tunnels L2TP. Vous devez définir un ou plusieurs profils dynamiques et affecter un profil à chaque groupe de tunnels. Le LNS prend en charge les sessions IPv4 uniquement, IPv6 uniquement et IPv4/IPv6 à double pile.
Pour configurer le profil dynamique L2TP :
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.