SUR CETTE PAGE
Instructions de configuration des tunnels logiques sur les routeurs MX Series
Instructions de configuration des tunnels logiques sur les routeurs ACX Series
Configuration d’un domaine de pont sur une interface physique de tunnel logique
Configuration de la bande passante recyclée pour l’interface physique du tunnel logique
Prise en charge des VPN de couche 3 sur les interfaces de tunnel logique
Configuration d’une interface dans le domaine VRF pour recevoir du trafic multicast
Configuration du ciblage par liaison unique pour les tunnels logiques redondants
Configuration du nombre minimal de liens actifs pour les tunnels logiques redondants
Connexion de systèmes logiques à l’aide d’interfaces de tunnel logique
Configuration des interfaces de tunnel logique
Les interfaces de tunnel logique (lt-) fournissent des services très différents selon le routeur hôte :
-
Sur les routeurs M Series, MX Series et T Series, les interfaces de tunnel logique vous permettent de connecter des systèmes logiques, des routeurs virtuels ou des instances VPN. Les routeurs M Series et T Series doivent être équipés d’un PIC de services de tunnel ou d’un module de services adaptatif (disponible uniquement sur les routeurs M7i). Les routeurs MX Series doivent être équipés d’un module MPC/MIC Trio. Pour plus d’informations sur la connexion de ces applications, reportez-vous à la bibliothèque de VPN Junos OS pour les périphériques de routage.
-
Sur les pare-feu SRX Series, l’interface de tunnel logique est utilisée pour interconnecter les systèmes logiques. Reportez-vous au Guide de l’utilisateur des systèmes logiques et des systèmes de location pour les équipements de sécurité pour plus d’informations sur l’utilisation de l’interface de tunnel logique sur le SRX Series.
Connexion de systèmes logiques
Pour connecter deux systèmes logiques, vous devez configurer une interface de tunnel logique sur les deux systèmes logiques. Vous configurez ensuite une relation d’homologue entre les interfaces du tunnel logique, créant ainsi une connexion point à point.
Pour configurer une connexion point à point entre deux systèmes logiques, configurez l’interface du tunnel logique en incluant l’instruction lt-fpc/pic/port suivante :
lt-fpc/pic/port {
unit logical-unit-number {
encapsulation encapsulation;
peer-unit unit-number; # peering logical system unit number
dlci dlci-number;
family (inet | inet6 | iso | mpls);
}
}
Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :
-
[edit interfaces] -
[edit logical-systems logical-system-name interfaces]
Lors de la configuration des interfaces de tunnel logique, notez les points suivants :
-
Vous pouvez configurer chaque interface de tunnel logique avec l’un des types d’encapsulation suivants : Ethernet, CCC (Ethernet circuit cross-connect), VPLS Ethernet, Frame Relay, Frame Relay CCC, VLAN, VLAN CCC ou VLAN VPLS.
-
Vous pouvez configurer la famille de protocoles IP, IPv6, ISO (Organisation internationale de normalisation) ou MPLS.
-
Ne reconfigurez pas une interface de tunnel logique qui est un point d’ancrage avec des périphériques pseudowire empilés au-dessus d’elle, sauf si vous désactivez d’abord tous les abonnés haut débit qui utilisent l’interface d’abonné pseudowire.
-
Les interfaces logiques d’appairage doivent appartenir à la même interface de tunnel logique dérivée du PIC des services de tunnel ou du module Adaptive Services.
-
Vous ne pouvez configurer qu’une seule unité homologue pour chaque interface logique. Par exemple, l’unité 0 ne peut pas être appairée à la fois avec l’unité 1 et l’unité 2.
-
Pour activer l’interface de tunnel logique, vous devez configurer au moins une instruction d’interface physique.
-
Les tunnels logiques ne sont pas pris en charge avec les PIC Adaptive Services, Multiservices ou Link Services (mais ils sont pris en charge sur le module Adaptive Services sur les routeurs M7i, comme indiqué ci-dessus).
-
Sur les routeurs M Series autres que le routeur M40e, les interfaces de tunnel logique nécessitent un concentrateur PIC flexible amélioré (FPC).
-
Sur les routeurs MX Series, les interfaces de tunnel logique nécessitent des modules MPC/MIC Trio. Ils ne nécessitent pas de PIC de services de tunnel dans le même système.
Voir aussi
Instructions de configuration des tunnels logiques sur les routeurs MX Series
Lorsque vous configurez un tunnel logique sur un routeur MX Series dont l’un des homologues est configuré en mode de couche 2, assurez-vous que le tunnel logique de couche 2 pair fait partie d’un domaine de pont ou d’une instance VPLS pour un flux de trafic bidirectionnel.
Pour configurer un tunnel logique avec encapsulation de pont, vous devez d’abord configurer le tunnel logique pour qu’il fasse partie du domaine de pont. L’exemple de configuration suivant vous permet de configurer un tunnel logique, lt-2/1/0.3 avec encapsulation de pont.
user@host# edit bridge-domains {
bd1 {
domain-type bridge;
vlan-id 1
}
}
user@host# edit chassis
lt-2/1/0 {
unit 3 {
description "MPLS port mirroring Bridge ingress interface";
encapsulation ethernet-bridge;
mtu 4500;
peer-unit 4;
family bridge {
interface-mode access;
vlan-id 1;
}
}
unit 4 {
description "MPLS Port mirroring L2/CCC egress interface";
encapsulation ethernet-ccc;
mtu 4500;
peer-unit 3;
family ccc {
filter {
input HighPriority;
}
}
}
}
Instructions de configuration des tunnels logiques sur les routeurs ACX Series
Respectez les instructions suivantes lors de la configuration des interfaces de tunnel logique (lt-) sur les routeurs ACX Series :
Vous pouvez utiliser une interface de tunnel logique pour connecter uniquement les domaines de pont et les pseudowires.
Les interfaces de tunnel logique ne peuvent pas interconnecter les liens suivants :
Pesudowire et une instance de routage (Pseudowire se terminant sur un VRF)
Deux instances de routage
VPLS et une instance de routage
Deux instances VPLS
Deux domaines de pont
Domaine de pont et instance VPLS
Un seul tunnel logique (interface physique) par type de bande passante (1 Gbit/s ou 10 Gbit/s) peut être configuré sur les routeurs ACX. Toutefois, vous pouvez spécifier jusqu’à deux interfaces de tunnel logique (l’une avec une bande passante de 1 Gbit/s et l’autre avec une bande passante de 10 Gbit/s) sur les routes ACX.
La bande passante garantie pour les tunnels logiques est de 1 Gbit/s et certaines plates-formes prennent en charge jusqu’à 10 Gbit/s de bande passante supplémentaire. Tous les services configurés à l’aide d’interfaces de tunnel logique partagent cette bande passante.
La bande passante configurée sur l’interface du tunnel logique est partagée entre le trafic en amont et en aval sur cette interface. La bande passante effective disponible pour le service est égale à la moitié de la bande passante configurée.
Plusieurs interfaces de tunnel logique pour permettre la configuration de services distincts sur chaque interface logique afin d’obtenir une bande passante accrue pour chaque interface individuellement ou le regroupement d’interfaces de tunnel logique individuelles n’est pas pris en charge.
Vous pouvez configurer le VLAN Ethernet, le CCC Ethernet, le pont VLAN sur les interfaces Ethernet et le VLAN sur les connexions croisées de circuit (CCC) en tant que types d’encapsulation sur les interfaces de tunnel logique. Les autres types d’encapsulation tels qu’Ethernet, VLAN, Ethernet VPLS ou VLAN VPLS ne sont pas pris en charge.
Lorsque l’encapsulation configurée sur les unités d’interface logique est l’un des types pris en charge, tel qu’un VLAN Ethernet ou un pont VLAN, vous pouvez activer uniquement les domaines de pont ou les protocoles CCC sur les interfaces de tunnel logique. Les autres familles d’adresses ou protocoles tels que IPv4, IPv6, MPLS ou OSPF ne sont pas pris en charge.
La configuration du classificateur, de la réécriture et du mécanisme de contrôle d’entrée est prise en charge sur les interfaces de tunnel logique. Les classificateurs fixes, basés sur BA et multichamps sont pris en charge sur les interfaces lt- au niveau de l’interface physique.
Les classificateurs BA basés sur 802.1p, 802.1ad, TOS et DSCP sont pris en charge. Les règles de remarquage peuvent être configurées au niveau du port sur l’interface LT. Les champs 802.1p, 802.1ad, TOS et DSCP du paquet peuvent être réécrits dans l’interface LT. Les mécanismes de contrôle d’entrée sont pris en charge.
Les mécanismes de contrôle de marquage tricolore simple à taux (srTCM) et de marquage tricolore à deux taux (trTCM) sont pris en charge. Les mécanismes de contrôle de sortie ne sont pas pris en charge.
Les classificateurs par défaut ne fonctionnent pas correctement lorsque les interfaces lt- sont configurées sur des PIC non-Ethernet.
La mise en file d’attente au niveau du port est prise en charge. Jusqu’à huit files d’attente par interface LT sont prises en charge. Ces huit files d’attente sont partagées entre le trafic amont et le trafic aval qui transitent par l’interface lt-. Si la bande passante configurée sur l’interface lt- n’est pas adéquate pour le trafic amont et descendant des services configurés sur l’interface, une défaillance se produit lors de la propagation du trafic, car plusieurs interfaces lt- ne sont pas prises en charge.
Huit classes de transfert (0 à 7) sont mappées aux huit files d’attente en fonction de la configuration globale du système. Le reste de la configuration du planificateur, la taille de la mémoire tampon, le taux de transmission, le taux de mise en forme, la priorité et les profils WRED ou drop peuvent être configurés sur les files d’attente de l’interface lt.
Les types de filtres de pare-feu suivants sont pris en charge sur les interfaces lt- :
Filtres au niveau de l’interface logique
Filtres de la famille Bridge
Filtres de la famille CCC
Toutes les configurations de pare-feu sont prises en charge. La limitation de mise à l’échelle de ces filtres est la même que celle des filtres de pare-feu existants.
OAM n’est pas pris en charge sur les interfaces lt-.
Comme pour les autres interfaces physiques, le nombre d’interfaces logiques pouvant être prises en charge sur les interfaces physiques de tunnel logique est de 30.
Lorsqu’un domaine de pont est configuré avec un ID VLAN (le domaine de pont a des VLAN normalisés), la différence de comportement entre les routeurs MX et ACX Series est que le routeur MX ne correspond pas à user-vlan-id dans le filtre de sortie, alors que le routeur ACX correspond à user-vlan-id spécifié dans le filtre de sortie.
Si l’interface de tunnel logique est créée à l’aide de PIC non Ethernet, le classificateur par défaut n’est pas lié à l’interface.
Pour créer des interfaces de tunnel logiques et la bande passante en gigabits par seconde à réserver aux services de tunnel, incluez l’instruction suivante tunnel-services bandwidth (1g | 10g) au niveau de la [edit chassis fpc slot-number pfe pfe-number core core-number channel channel-number] hiérarchie :
[edit interfaces]
lt-fpc/pic/port {
unit logical-unit-number {
encapsulation encapsulation;
peer-unit unit-number; # peering logical system unit number
dlci dlci-number;
family (inet | inet6 | iso | mpls);
}
}
Prise en charge ethernet-vpls et vlan-vpls encapsulation des routeurs ACX5048 et ACX5096. Ces encapsulations sont prises en charge uniquement sur l’interface de tunnel logique et sont nécessaires pour configurer les VPLS hiérarchiques.
Vous pouvez utiliser n’importe quel port physique inutilisé sur les routeurs ACX5048 et ACX5096 pour créer une interface de tunnel logique, comme indiqué ci-dessous :
user@host# edit chassis
fpc 0 {
pic 0 {
tunnel-services {
port port-number;
}
}
}
L’exemple de configuration suivant vous permet d’encapsuler vlan-ccc à l’aide de l’interface vlan-vpls LT dans les routeurs ACX5048 et ACX5096 :
user@host# edit interfaces
lt-0/0/1 {
unit 0 {
encapsulation vlan-ccc;
vlan-id 1;
peer-unit 1;
}
unit 1 {
encapsulation vlan-vpls;
vlan-id 1;
peer-unit 0;
}
}
Configuration de l’interface physique du tunnel logique et de l’interface du tunnel logique sur les routeurs ACX7K Series
À partir de Junos Evolved OS version 24.2R1, les routeurs ACX7K Series prennent en charge la configuration IFD (Logical Tunnel Physical Interface) pour les services de couche 2 (BD).
-
Prise en charge de l’interface physique du tunnel logique qui comprend :
-
Configuration au niveau de l’interface de tunnel logique
-
Prise en charge de l’assemblage de deux services disjoints via l’interface de tunnel logique
-
Prise en charge de SNMP sur l’interface de tunnel logique
-
-
Prise en charge de l’interface de tunnel logique (LT ifl) et du domaine de pont qui comprend :
-
Création d’une interface de tunnel logique, chaque unité d’interface de tunnel logique avec une
peer-unitconfiguration comme paramètre obligatoire. Si l’unité X est configurée unité Y en tant qu’unité homologue, alors l’unité Y doit avoir l’unité X en tantpeer-unitque . -
Prise en charge du pont VLAN d’encapsulation sur l’interface du tunnel logique
-
Prise en charge du pont Ethernet d’encapsulation sur l’interface de tunnel logique
-
Prise en charge des statistiques du récepteur et de l’émetteur sur l’interface du tunnel logique. Les statistiques du récepteur et de l’émetteur de l’interface de tunnel logique doivent fonctionner de la même manière que les autres statistiques d’interface logique.
-
Prise en charge du flooding de couche 2 sur l’interface de tunnel logique
-
Prise en charge de l’apprentissage MAC. Cette prise en charge inclut l’ajout d’un MAC statique sur l’interface du tunnel logique, l’apprentissage MAC dynamique sur l’interface du tunnel logique et la gestion de tous les événements et notifications MAC.
-
Configuration de l’interface physique du tunnel logique sur les routeurs ACX7K Series
Pour créer des interfaces de tunnel logiques et la bande passante en Gbits/s à réserver aux services de tunnel, incluez l’instruction tunnel-services bandwidth value au niveau de la [edit chassis fpc slot-number | feb slot slot-number pfe pfe-number core core-number channel channel-number] hiérarchie.
L’exemple de configuration suivant vous permet de configurer le tunnel logique sur des systèmes basés sur FPC :
user@host# edit chassis
fpc 0 {
pfe 0 {
core 0 {
channel 0 {
tunnel-services {
bandwidth 10g;
}
}
}
}
}
L’exemple de configuration suivant vous permet de configurer le tunnel logique sur les systèmes basés sur FEB :
user@host# edit chassis
feb slot 0 {
pfe 0 {
core 0 {
channel 0 {
tunnel-services {
bandwidth 10g;
}
}
}
}
}
Par exemple, pour créer lt-0/0/0:3, avec une bande passante de 10 Gbit/s, vous pouvez utiliser l’exemple de configuration suivant :
Créez une interface de tunnel logique et encapsulez l’interface logique pour une configuration de pontage de type fournisseur de services.
set chassis fpc 0 pfe 0 core 0 channel 3 tunnel-services bandwidth 10G set interfaces lt-0/0/0:3 flexible-vlan-tagging set interfaces lt-0/0/0:3 unit 0 peer-unit 1 encapsulation vlan-bridge vlan-id 100 set interfaces lt-0/0/0:3 unit 1 peer-unit 0 encapsulation vlan-bridge vlan-id 100
Configuration d’un domaine de pont sur une interface physique de tunnel logique
Sur les routeurs ACX7K, vous pouvez configurer une interface physique de tunnel logique (IFD) pour communiquer entre deux domaines de pont (BD). Pour cette interface physique de tunnel logique, vous pouvez créer des interfaces de tunnel logique et mapper les interfaces de tunnel logique à chaque domaine de service ou de pont. Désormais, le trafic peut être transféré d’un service à un autre à l’aide de ces interfaces de tunnel logiques. Vous pouvez également configurer la bande passante par interface de tunnel logique.
Encapsulez l’interface logique pour une configuration de pontage de type fournisseur de services.
[edit] user@host# set interfaces et-0/0/2 flexible-vlan-tagging user@host# set interfaces et-0/0/2 encapsulation flexible-ethernet-services user@host# set interfaces et-0/0/3 flexible-vlan-tagging user@host# set interfaces et-0/0/3 encapsulation flexible-ethernet-services user@host# set interfaces et-0/0/2 unit 0 encapsulation ethernet-bridge vlan-id 100 user@host# set interfaces et-0/0/3 unit 0 encapsulation ethernet-bridge vlan-id 100
Créez BD1 et associez une interface de tunnel logique.
[edit] user@host# set vlans bd1 interface et-0/0/3.0 user@host# set vlans bd1 interface et-0/0/2.0 user@host# set vlans bd1 interface lt-0/0/0:3.0
Encapsulez l’interface logique pour une configuration de pontage de type fournisseur de services.
[edit] user@host# set interfaces et-0/0/6 flexible-vlan-tagging user@host# set interfaces et-0/0/6 encapsulation flexible-ethernet-services user@host# set interfaces et-0/0/7 flexible-vlan-tagging user@host# set interfaces et-0/0/7 encapsulation flexible-ethernet-services user@host# set interfaces et-0/0/6 unit 0 encapsulation ethernet-bridge vlan-id 100 user@host# set interfaces et-0/0/7 unit 0 encapsulation ethernet-bridge vlan-id 100
Créez BD2 et associez une interface de tunnel logique.
[edit] user@host# set vlans bd2 vlan-id 100 user@host# set vlans bd2 interface et-0/0/7.0 user@host# set vlans bd2 interface et-0/0/6.0 user@host# set vlans bd2 interface lt-0/0/0:3.1
Configuration de la bande passante recyclée pour l’interface physique du tunnel logique
Sur les routeurs ACX7K series, les interfaces de tunnel logique utilisent les interfaces de recyclage internes pour faire recirculer le trafic entre deux services d’interconnexion.
Le mécanisme de recyclage a deux modes de fonctionnement :
-
Mode de bande passante recyclée par défaut
-
Mode de bande passante de recyclage configurable
Pour plus d’informations sur l’infrastructure de recyclage dans les plates-formes ACX7K series, reportez-vous à la section Gestion de la bande passante recyclée.
Par défaut, les interfaces de tunnel logique fonctionnent dans le mode par défaut. Pour activer le mode de configuration des interfaces de tunnel logique, recyclez l’application à l’aide de l’exemple de configuration suivant :
Configurez le pourcentage de la bande passante du calendrier pour l’application de tunnel logique.
[edit] user@host# set system packet-forwarding-options recycle-bandwidth-profiles prof1 tunnel-services 80
Dans cet exemple, vous réservez 80 % de la bande passante du calendrier pour l’application de tunnel logique. Dans ce cas, 80 % des 800 Gbit/s, soit 640 Gbit/s, sont réservés à l’application de tunnel logique.
Appliquez la bande passante configurée à l’application de tunnel logique.
[edit] user@host# set system packet-forwarding-options recycle-bandwidth profile prof1
Dans le mode par défaut, la bande passante du tunnel logique est partagée avec d’autres applications de recyclage en mode best effort. En mode de configuration, la somme totale de la bande passante de toutes les interfaces de tunnel logique est limitée à la bande passante totale de l'application de recyclage du tunnel logique. Si la somme de la bande passante configurée pour toutes les interfaces de tunnel logique est supérieure à la bande passante dérivée par l'application de recyclage de tunnel logique, la somme de la largeur de banwidth des interfaces de tunnel logique est limitée à la valeur de l'application de recyclage de tunnel logique.
Par exemple, configurez une bande passante de 10 Gbit/s pour le tunnle logique1 et de 100 Gbit/s pour le tunnel logique2. Le pourcentage d’application du tunnel logique est égal à 100 Gbit/s. La somme de la bande passante du tunnle logique1 et du tunnle logique2 sera de 100 Gbit/s et non de 110 Gbit/s. Dans ce cas, la bande passante de l’application de recyclage du tunnel logique est répartie dans le rapport de la bande passante de l’interface du tunnel logique individuel. En l’occurrence, il s’agit d’un ratio 1:10 de 100 Gbit/s.
Prise en charge des VPN de couche 3 sur les interfaces de tunnel logique
À partir de Junos OS Evolved version 24.1R1, nous prenons en charge le service VPN de couche 3 sur interface de tunnel logique sur les routeurs ACX7K Series. La fonctionnalité comprend :
-
VRF sur interface de tunnel logique
-
Interconnexion de services VPN de couche 3 et de services de couche 2 via une interface de tunnel logique
L’exemple de configuration suivant vous permet de configurer un VPN de couche 3 sur une interface de tunnel logique :
user@host# edit chassis {
lt-0/0/1:0 {
unit 0 {
vlan-id 10;
encapsulation vlan-bridge;
peer-unit 1;
}
unit 1 {
vlan-id 10;
family inet {
address 100.1.1.100/24;
}
family inet6 {
address 2001::1/128;
}
peer-unit 0;
}
routing-instances {
vpn100 {
instance-type vrf;
interface lt-0/0/1:0.1;
route-distinguisher <...>;
vrf-import vpn100-imp;
vrf-export vpn100-exp;
vrf-table-label;
}
policy-options {
policy-statement vpn100-exp {
term 1 {
from {
<...>;
}
then {
community add vpn100;
accept;
}
}
}
policy-statement vpn100-imp {
term 1 {
from {
<...>;
community vpn100;
}
then {
accept;
}
}
}
community vpn100 members <...>;
}
Exemple : Configuration de tunnels logiques
Configurez trois tunnels logiques :
[edit interfaces]
lt-4/2/0 {
description “Logical tunnel interface connects three logical systems”;
}
[edit logical-systems]
lr1 {
interfaces lt-4/2/0 {
unit 12 {
peer-unit 21; #Peering with lr2
encapsulation frame-relay;
dlci 612;
family inet;
}
unit 13 {
peer-unit 31; #Peering with lr3
encapsulation frame-relay-ccc;
dlci 613;
}
}
}
lr2 {
interfaces lt-4/2/0 {
unit 21 {
peer-unit 12; #Peering with lr1
encapsulation frame-relay-ccc;
dlci 612;
}
unit 23 {
peer-unit 32; #Peering with lr3
encapsulation frame-relay;
dlci 623;
}
}
}
lr3 {
interfaces lt-4/2/0 {
unit 31 {
peer-unit 13; #Peering with lr1
encapsulation frame-relay;
dlci 613;
family inet;
}
unit 32 {
peer-unit 23; #Peering with lr2
encapsulation frame-relay-ccc;
dlci 623;
}
}
}
Voir aussi
Configuration d’une interface dans le domaine VRF pour recevoir du trafic multicast
Vous pouvez configurer un routeur ACX Series pour recevoir du trafic multicast dans un domaine VRF. Dans une solution IPTV, les sources et les récepteurs IPTV peuvent être répartis sur différents points d’extrémité d’un réseau dans un domaine VRF. Pour recevoir le trafic multicast du côté du récepteur, il est nécessaire que le trafic multicast soit tunnelisé à travers le réseau pour atteindre l’appareil récepteur final ou l’abonné. Ce tunneling s’effectue généralement à l’aide de la technologie MVPN (Multicast Virtual Private Network).
Les routeurs ACX Series ne prennent pas en charge la technologie MVPN. Une autre méthode pour recevoir le trafic multicast dans le domaine VRF dans le routeur ACX Series consiste à associer une interface logique globale à une interface logique dans le domaine VRF. L’interface logique globale agit comme un proxy pour la réception du trafic multicast sur l’interface logique dans le domaine VRF. Pour associer une interface logique globale à une interface logique dans le domaine VRF, vous devez configurer une interface IRB dans un domaine global pour qu’elle agisse comme proxy pour l’interface logique dans le domaine VRF.
- Configuration d’une interface logique de proxy dans le domaine global
- Association de l’interface logique du proxy à une interface logique dans un domaine VRF
- Limitations
Configuration d’une interface logique de proxy dans le domaine global
Pour configurer une interface logique de proxy dans le domaine global, vous devez créer une interface de tunnel logique (lt-) et une interface IRB, puis associer l’interface IRB à un domaine de pont. Voici un exemple de configuration d’une interface logique de proxy dans le domaine global :
Créez une interface de tunnel logique (lt-).
[edit] user@host# set chassis aggregated-devices ethernet device-count 1 user@host# set chassis fpc 0 pic 0 tunnel-services bandwidth 1g user@host# set interfaces lt-0/0/10 unit 0 encapsulation vlan-bridge user@host# set interfaces lt-0/0/10 unit 0 vlan-id 101 user@host# set interfaces lt-0/0/10 unit 0 peer-unit 1 user@host# set interfaces lt-0/0/10 unit 1 encapsulation vlan-ccc user@host# set interfaces lt-0/0/10 unit 1 vlan-id 101 user@host# set interfaces lt-0/0/10 unit 1 peer-unit 0
Créez une interface IRB.
[edit] user@host# set interfaces irb unit 0 family inet address 192.168.1.2/24
Associez l’interface IRB à un domaine de pont.
[edit] user@host# set bridge-domains b1 vlan-id 101 user@host# set bridge-domains b1 interface lt-0/0/10.0 user@host# set bridge-domains b1 routing-interface irb.0
Association de l’interface logique du proxy à une interface logique dans un domaine VRF
Pour associer l’interface logique du proxy à une interface logique d’un domaine VRF, vous devez exécuter les commandes PFE suivantes :
test pfe acx vrf-mc-leak enable: active l’association de proxy.test pfe acx entry add VRF-logical-interface-name logical-tunnel-logical-interface-name IRB-logical-interface-name IRB-IP-address + 1: crée une association entre l’interface logique du proxy et l’interface logique d’un domaine VRF.test pfe acx vrf-mc-leak disable: désactive l’association de proxy.test pfe acx entry del VRF-logical-interface-name logical-tunnel-logical-interface-name IRB-logical-interface-name IRB-IP-address + 1: supprime l’association entre l’interface logique du proxy et l’interface logique d’un domaine VRF.show pfe vrf-mc-leak: affiche les entrées d’association entre l’interface logique du proxy et l’interface logique d’un domaine VRF.
Lorsque le routeur ou le PFE est redémarré, les associations de proxy des interfaces logiques sont supprimées et vous devez recréer les associations de proxy de l’interface logique.
Limitations
Les limitations suivantes doivent être prises en compte pour la réception de trafic multicast dans un domaine VRF :
Un maximum de 5 associations proxy d’interfaces logiques peuvent être configurées.
Le multicast VRF IPv6 n’est pas pris en charge.
L’interface AE en tant qu’interface VRF (demandant du trafic multicast) n’est pas prise en charge.
Le trafic multicast ne peut pas être transféré à partir de l’interface logique d’un domaine VRF si le routeur du premier saut est un routeur ACX.
Présentation des tunnels logiques redondants
Vous pouvez connecter deux équipements, par exemple un équipement orienté accès et un équipement orienté cur, via des tunnels logiques. Pour assurer la redondance des tunnels, vous pouvez créer et configurer plusieurs tunnels logiques physiques et les ajouter à un tunnel logique redondant virtuel.
Les tunnels logiques redondants sont pris en charge uniquement sur les routeurs MX Series avec MPC. À partir de Junos OS version 18.4R3, les tunnels logiques redondants sont pris en charge sur MX Series Virtual Chassis.
Par exemple, dans un réseau d’accès MPLS, vous pouvez configurer plusieurs pseudowires entre un nud d’accès et un routeur MX Series avec des MPC et les ajouter à un tunnel logique redondant. Vous pouvez ensuite ajouter plusieurs tunnels logiques au tunnel logique redondant. La Figure 1 illustre un tunnel logique redondant entre le nud d’accès et le routeur MX Series.
logiques redondants
Le tunnel logique redondant possède des interfaces logiques homologues à chaque extrémité, rlt0.0 et rlt0.1. Vous pouvez configurer les fonctionnalités de routeur sur ces interfaces pour le tunnel logique redondant et ses membres.
Chaque tunnel logique membre possède des interfaces logiques homologues. Dans la figure 1, lt-0/0/10.0 et lt-0/0/10.1 sont des pairs.
Le routeur MX Series effectue la recherche IP dans la table VRF (Layer VPN Routing and Forwarding) sur le routeur, là où se terminent les pseudowires regroupés dans des tunnels logiques.
- Configuration de tunnel logique redondante
- Ciblage par liaison unique
- Nombre minimum de liens actifs
- Détection des défaillances et basculement des tunnels logiques redondants
Configuration de tunnel logique redondante
Dans Junos OS versions 14.1R1 et antérieures, vous pouvez créer jusqu’à 16 tunnels logiques redondants, en fonction du nombre de moteurs de transfert de paquets et du nombre d’interfaces de bouclage sur chaque moteur de transfert de paquets sur votre équipement. À partir de Junos OS version 14.2 et pour les versions 13.3R3 et 14.1R2, la plage valide pour le nombre de périphériques est comprise entre 1 et 255.
Vous pouvez ajouter jusqu’à 32 tunnels logiques en tant que membres d’un tunnel logique redondant.
Lorsque vous ajoutez plus de deux membres au tunnel logique redondant, ils sont en mode actif. Par défaut, le trafic est équilibré en charge sur tous les membres du tunnel. Vous pouvez également configurer votre RLT pour le ciblage par liaison unique et spécifier un nombre minimum de liens actifs pour le RLT.
Lorsque vous n’ajoutez que deux membres au tunnel logique redondant, vous pouvez les configurer de l’une des manières suivantes :
-
Les deux membres en mode actif
-
Un membre en mode actif et l’autre en mode secondaire
Ciblage par liaison unique
Vous pouvez configurer votre ancre RLT pour utiliser le ciblage par liaison unique. Dans ce mode, tout le trafic circulant à travers votre interface pseudowire ou PWHT sera dirigé via un seul lien dans le bundle rlt . Si la liaison ciblée tombe en panne, tous les abonnés du RLT seront résiliés.
Nombre minimum de liens actifs
Dans ce mode, vous pouvez spécifier le nombre minimum de liaisons qui doivent être actives pour que l’interface RLT reste active. Si le nombre de liens actifs sur le RLT tombe en dessous du minimum, le RLT diminuera. Toutes les interfaces pseudowire et PWHT empilées sur le RLT tomberont également en panne et tous les abonnés seront résiliés.
Détection des défaillances et basculement des tunnels logiques redondants
Un tunnel logique échoue et est supprimé du groupe de tunnels logiques redondants, et le tunnel logique de sauvegarde devient actif en raison de l’un des événements suivants :
-
Une défaillance matérielle sur le module MPC se produit.
-
Une défaillance MPC se produit en raison d’un plantage du micro-noyau.
-
Le module MPC est arrêté administrativement et retiré du tunnel logique redondant.
-
Une panne de courant sur le module MPC se produit.
Vous pouvez réduire le temps nécessaire à la détection des défaillances et au basculement. Configurez l’instruction enhanced-ip au niveau de la hiérarchie pour activer la [edit chassis network-services] détection de vivacité du moteur de transfert de paquets.
Voir aussi
Configuration des tunnels logiques redondants
Utilisez des tunnels logiques redondants pour assurer la redondance des tunnels logiques entre deux équipements, par exemple un équipement orienté accès et un équipement orienté cur.
Lors de la configuration d’interfaces de tunnel logique redondantes, notez les points suivants :
À partir de Junos OS version 13.3, vous pouvez configurer des tunnels logiques redondants uniquement sur les routeurs MX Series avec MPC.
Dans Junos OS versions 14.1R1 et antérieures, vous pouvez créer jusqu’à 16 tunnels logiques redondants, en fonction du nombre de moteurs de transfert de paquets et du nombre d’interfaces de bouclage sur chaque moteur de transfert de paquets sur votre équipement. À partir de Junos OS version 14.2 et pour les versions 13.3R3 et 14.1R2, la plage valide pour le nombre de périphériques est comprise entre 1 et 255. La commande est illustrée ci-dessous.
set chassis redundancy-group interface-type redundant-logical-tunnel device-count [number];Vous pouvez ajouter jusqu’à 32 tunnels logiques en tant que membres.
Lorsqu’un tunnel logique avec une configuration existante rejoint un tunnel logique redondant, vous devez configurer le tunnel logique redondant avec les paramètres de la configuration existante.
Vous pouvez ajouter des tunnels logiques membres à un tunnel logique parent pour la redondance.
Lorsque vous ajoutez plusieurs tunnels logiques au tunnel logique redondant, les membres sont en mode actif par défaut.
Lorsque vous n’ajoutez que deux membres, vous pouvez les configurer de l’une des manières suivantes :
Les deux membres en mode actif
Un membre en mode actif et l’autre en mode secondaire
Pour configurer un tunnel logique redondant entre deux équipements :
Configuration du ciblage par liaison unique pour les tunnels logiques redondants
Utilisez le ciblage par liaison unique pour diriger tout le trafic d’un tunnel logique redondant vers une interface de tunnel logique spécifique.
single-targeted-link sous l’entrée targeted-options et spécifiez le lien de tunnel logique vers la cible.
[edit interfaces interface-name] user@host# set targeted-options single-targeted-link interface-name
Configuration du nombre minimal de liens actifs pour les tunnels logiques redondants
Vous pouvez utiliser l’option Minimum de liens actifs pour spécifier le nombre de liens de tunnel qui doivent être actifs pour que le tunnel logique redondant reste actif.
Lorsque le nombre minimum de liaisons actives est configuré, le tunnel logique redondant (RLT) tombe en panne si le nombre de liaisons actives est inférieur au nombre configuré. Lorsque le RLT tombe en panne, tout le trafic d’abonnés empilé sur le RLT est arrêté, y compris le trafic pseudowire et PWHT.
minimum-links. Cette option se trouve sous la redundancy-group hiérarchie.
[edit interfaces rlt-interface] user@host# set redundancy-group minimum-links number-of-links
Exemple : Configuration de tunnels logiques redondants
Cet exemple montre comment configurer des tunnels logiques redondants dans un réseau d’accès MPLS.
Exigences
Dans Junos OS version 13.3 ou ultérieure, vous pouvez configurer des tunnels logiques redondants uniquement sur les routeurs MX Series avec MPC.
Aperçu
Lorsqu’un tunnel logique avec une configuration existante rejoint un tunnel logique redondant, vous devez configurer le tunnel logique redondant avec les paramètres de la configuration existante.
Vous pouvez ajouter des tunnels logiques membres à un tunnel logique parent pour la redondance.
Sur les routeurs MX Series avec MPC, vous pouvez configurer des tunnels logiques redondants comme suit :
Dans Junos OS versions 14.1R1 et antérieures, vous pouvez créer jusqu’à 16 tunnels logiques redondants, en fonction du nombre de moteurs de transfert de paquets et du nombre d’interfaces de bouclage sur chaque moteur de transfert de paquets sur votre équipement. À partir de Junos OS version 14.2 et pour les versions 13.3R3 et 14.1R2, la plage valide pour le nombre de périphériques est comprise entre 1 et 255. La commande est illustrée ci-dessous.
set chassis redundancy-group interface-type redundant-logical-tunnel device-count [number];Vous pouvez ajouter jusqu’à 32 tunnels logiques en tant que membres.
Lorsque vous ajoutez plusieurs tunnels logiques à un tunnel logique redondant, les membres sont en mode actif par défaut.
Lorsque vous n’ajoutez que deux membres, vous pouvez les configurer de l’une des manières suivantes :
Les deux membres en mode actif
Un membre en mode actif et l’autre en mode secondaire
Topologie
La Figure 2 illustre un tunnel logique redondant entre le nud d’accès et le routeur MX Series dans un réseau d’accès MPLS.
logiques redondants
Le tunnel logique redondant possède des interfaces logiques homologues à chaque extrémité, rlt0.0 et rlt0.1. Vous pouvez configurer les fonctionnalités de routeur sur ces interfaces pour le tunnel logique redondant et ses membres.
Chaque tunnel logique membre possède des interfaces logiques homologues sur les équipements orientés accès et orientés vers le cur. Dans la figure 2, lt-0/0/10.0 et lt-0/0/10.1 sont des pairs.
Le routeur MX Series effectue la recherche IP dans la table VRF (Layer VPN Routing and Forwarding) sur le routeur, là où se terminent les pseudowires regroupés dans des tunnels logiques.
Configuration
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie.
set chassis redundancy-group interface-type redundant-logical-tunnel device-count 4 set chassis fpc 1 pic 0 tunnel-services bandwidth 1g set chassis fpc 2 pic 2 tunnel-services bandwidth 1g set interfaces rlt0 redundancy-group member-interface lt-1/0/10 set interfaces rlt0 redundancy-group member-interface lt-2/0/10 set interfaces rlt0 unit 0 description "Towards Layer 2 Circuit" set interfaces rlt0 unit 0 encapsulation vlan-ccc set interfaces rlt0 unit 0 vlan-id 600 set interfaces rlt0 unit 0 peer-unit 1 set interfaces rlt0 unit 0 family ccc set interfaces rlt0 unit 1 description "Towards Layer 3 VRF" set interfaces rlt0 unit 1 encapsulation vlan set interfaces rlt0 unit 1 vlan-id 600 set interfaces rlt0 unit 1 peer-unit 0 set interfaces rlt0 unit 1 family inet address 10.10.10.2/24 set protocols l2circuit neighbor 192.0.2.2 interface rlt0.0 virtual-circuit-id 100 set protocols l2circuit neighbor 192.0.2.2 interface rlt0.0 no-control-word set routing-instances pe-vrf instance-type vrf set routing-instances pe-vrf interface rlt0.1 set routing-instances pe-vrf route-distinguisher 65056:1 set routing-instances pe-vrf vrf-import VPN-A-Import set routing-instances pe-vrf vrf-export VPN-A-Export set routing-instances pe-vrf vrf-table-label set routing-instances pe-vrf protocols ospf export VPN-A-Import set routing-instances pe-vrf protocols ospf area 0.0.0.0 interface rlt0.1 set protocols mpls no-cspf set protocols mpls interface all set protocols ldp interface all set protocols bgp export local-routes set protocols bgp group internal type internal set protocols bgp group internal local-address 198.51.100.3 set protocols bgp group internal family inet any set protocols bgp group internal family inet-vpn unicast set protocols bgp group internal neighbor 203.0.113.4 set protocols ospf area 0.0.0.0 interface ge-5/3/8.0 set protocols ospf area 0.0.0.0 interface ge-5/2/5.0 set protocols ospf area 0.0.0.0 interface lo0.3 passive set policy-options policy-statement VPN-A-Export term a then community add VPN-A set policy-options policy-statement VPN-A-Export term a then accept set policy-options policy-statement VPN-A-Export term b then reject set policy-options policy-statement VPN-A-Import term a from protocol bgp set policy-options policy-statement VPN-A-Import term a from community VPN-A set policy-options policy-statement VPN-A-Import term a then accept set policy-options policy-statement VPN-A-Import term b then reject set policy-options policy-statement local-routes then accept set policy-options community VPN-A members target:100:100 set routing-options router-id 198.51.100.3 set routing-options autonomous-system 65056
Procédure
Procédure étape par étape
Dans cet exemple, tous les tunnels logiques sont en mode actif.
Créez le tunnel logique et les interfaces de tunnel logique redondantes.
[edit chassis] user@host# set redundancy-group interface-type redundant-logical-tunnel device-count 4 user@host# set fpc 1 pic 0 tunnel-services bandwidth 1g user@host# set fpc 2 pic 2 tunnel-services bandwidth 1g
Liez les tunnels logiques membres au tunnel logique redondant.
[edit interfaces] user@host# set rlt0 redundancy-group member-interface lt-1/0/10 user@host# set rlt0 redundancy-group member-interface lt-2/0/10
Configurez les interfaces de tunnel logique redondantes.
[edit interfaces] user@host# set rlt0 unit 0 description "Towards Layer 2 Circuit" user@host# set rlt0 unit 0 encapsulation vlan-ccc user@host# set rlt0 unit 0 vlan-id 600 user@host# set rlt0 unit 0 peer-unit 1 user@host# set rlt0 unit 0 family ccc user@host# set rlt0 unit 1 description "Towards Layer 3 VRF" user@host# set rlt0 unit 1 encapsulation vlan user@host# set rlt0 unit 1 vlan-id 600 user@host# set rlt0 unit 1 peer-unit 0 user@host# set rlt0 unit 1 family inet address 10.10.10.2/24
Connectez rlt0.0 à un circuit de couche 2.
[edit protocols] user@host# set l2circuit neighbor 192.0.2.2 interface rlt0.0 virtual-circuit-id 100 user@host# set l2circuit neighbor 192.0.2.2 interface rlt0.0 no-control-word
Ajoutez rlt0.1 à une instance VRF de couche 3.
[edit routing-instances] user@host# set pe-vrf instance-type vrf user@host# set pe-vrf interface rlt0.1 user@host# set pe-vrf route-distinguisher 65056:1 user@host# set pe-vrf vrf-import VPN-A-Import user@host# set pe-vrf vrf-export VPN-A-Export user@host# set pe-vrf vrf-table-label user@host# set pe-vrf protocols ospf export VPN-A-Import user@host# set pe-vrf protocols ospf area 0.0.0.0 interface rlt0.1
Configurez MPLS et LDP dans les pseudowires et le VPN de couche 3.
[edit protocols] user@host# set mpls no-cspf user@host# set mpls interface all user@host# set ldp interface all
Configurez BGP dans le VPN de couche 3.
[edit protocols] user@host# set bgp export local-routes user@host# set bgp group internal type internal user@host# set bgp group internal local-address 198.51.100.3 user@host# set bgp group internal family inet any user@host# set bgp group internal family inet-vpn unicast user@host# set bgp group internal neighbor 203.0.113.4
Configurez OSPF sur les interfaces orientées vers le cur et sur l’interface de bouclage local du routeur.
[edit protocols] user@host# set ospf area 0.0.0.0 interface ge-5/3/8.0 user@host# set ospf area 0.0.0.0 interface ge-5/2/5.0 user@host# set ospf area 0.0.0.0 interface lo0.3 passive
Définissez les options de stratégie pour BGP.
[edit policy-options] user@host# set policy-statement VPN-A-Export term a then community add VPN-A user@host# set policy-statement VPN-A-Export term a then accept user@host# set policy-statement VPN-A-Export term b then reject user@host# set policy-statement VPN-A-Import term a from protocol bgp user@host# set policy-statement VPN-A-Import term a from community VPN-A user@host# set policy-statement VPN-A-Import term a then accept user@host# set policy-statement VPN-A-Import term b then reject user@host# set policy-statement local-routes then accept user@host# set community VPN-A members target:100:100
Définissez l’ID du routeur et le numéro du système autonome (AS).
[edit routing-options] user@host# set router-id 198.51.100.3 user@host# set autonomous-system 65056
Résultats
En mode configuration, confirmez votre configuration en entrant les commandes suivantes :
show chassisshow interfacesshow policy-optionsshow protocolsshow routing-instancesshow routing-options
Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@host# show chassis
redundancy-group {
interface-type {
redundant-logical-tunnel {
device-count 4;
}
}
}
fpc 1 {
pic 0 {
tunnel-services {
bandwidth 1g;
}
}
}
fpc 1 {
pic 2 {
tunnel-services {
bandwidth 1g;
}
}
}
user@host# show interfaces rlt0
redundancy-group {
member-interface lt-1/0/10;
member-interface lt-2/0/10;
}
unit 0 {
description "Towards Layer 2 Circuit";
encapsulation vlan-ccc;
vlan-id 600;
peer-unit 1;
family ccc;
}
unit 1 {
description "Towards Layer 3 VRF";
encapsulation vlan;
vlan-id 600;
peer-unit 0;
family inet {
address 10.10.10.2/24;
}
}
user@host# show protocols l2circuit
neighbor 192.0.2.2 {
interface rlt0.0 {
virtual-circuit-id 100;
no-control-word;
}
}
user@host# show protocols
mpls {
no-cspf;
interface all;
}
bgp {
export local-routes;
group internal {
type internal;
local-address 198.51.100.3;
family inet {
any;
}
family inet-vpn {
unicast;
}
neighbor 203.0.113.4;
}
}
ospf {
area 0.0.0.0 {
interface ge-5/3/8.0;
interface ge-5/2/5.0;
interface lo0.3 {
passive;
}
}
}
ldp {
interface all;
}
l2circuit {
neighbor 192.0.2.2 {
interface rlt0.0 {
virtual-circuit-id 100;
no-control-word;
}
}
}
user@host# routing-instances
pe-vrf {
instance-type vrf;
interface rlt0.1;
route-distinguisher 65056:1;
vrf-import VPN-A-Import;
vrf-export VPN-A-Export;
vrf-table-label;
protocols {
ospf {
export VPN-A-Import;
area 0.0.0.0 {
interface rlt0.1;
}
}
}
}
user@host# policy-options
policy-statement VPN-A-Export {
term a {
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
policy-statement VPN-A-Import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement local-routes {
then accept;
}
community VPN-A members target:100:100;
user@host# routing-options router-id 198.51.100.3; autonomous-system 65056;
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de la configuration redondante du tunnel logique
- Vérification du circuit de couche 2
- Vérification des voisins OSPF
- Vérification du groupe BGP
- Vérification des routes BGP dans la table de routage
Vérification de la configuration redondante du tunnel logique
But
Vérifiez que le tunnel logique redondant avec les interfaces de tunnel logique enfant est créé avec les encapsulations appropriées.
Action
user@host# run show interfaces terse | match rlt0 lt-1/0/10.0 up up container--> rlt0.0 lt-1/0/10.1 up up container--> rlt0.1 lt-2/0/10.0 up up container--> rlt0.0 lt-2/0/10.1 up up container--> rlt0.1 rlt0 up up rlt0.0 up up ccc rlt0.1 up up inet 10.10.10.2/24
Vérification du circuit de couche 2
But
Vérifiez que le circuit de couche 2 est opérationnel.
Action
user@host# run show l2circuit connections
Layer-2 Circuit Connections:
Legend for connection status (St)
EI -- encapsulation invalid NP -- interface h/w not present
MM -- mtu mismatch Dn -- down
EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down
CM -- control-word mismatch Up -- operational
VM -- vlan id mismatch CF -- Call admission control failure
OL -- no outgoing label IB -- TDM incompatible bitrate
NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration
BK -- Backup Connection ST -- Standby Connection
CB -- rcvd cell-bundle size bad SP -- Static Pseudowire
LD -- local site signaled down RS -- remote site standby
RD -- remote site signaled down HS -- Hot-standby Connection
XX -- unknown
Legend for interface status
Up -- operational
Dn -- down
Neighbor: 192.0.2.2
Interface Type St Time last up # Up trans
rlt0.0(vc 100) rmt Up Aug 8 00:28:04 2013 1
Remote PE: 192.0.2.2, Negotiated control-word: No
Incoming label: 299776, Outgoing label: 299776
Negotiated PW status TLV: No
Local interface: rlt0.0, Status: Up, Encapsulation: VLAN
Vérification des voisins OSPF
But
Vérifiez que les routeurs sont adjacents et capables d’échanger des données OSPF.
Action
user@host# run show ospf neighbor Address Interface State ID Pri Dead 198.168.30.2 ge-5/2/5.0 Full 203.0.113.4 128 38 198.168.20.1 ge-5/3/8.0 Full 192.0.2.2 128 38
Vérification du groupe BGP
But
Vérifiez que le groupe BGP est créé.
Action
user@host# run show bgp group internal
Group Type: Internal AS: 65056 Local AS: 65056
Name: internal Index: 0 Flags: <Export Eval>
Export: [ local-routes ]
Holdtime: 0
Total peers: 1 Established: 1
203.0.113.4+179
inet.0: 1/6/3/0
inet.2: 0/0/0/0
bgp.l3vpn.0: 2/2/2/0
pe-vrf.inet.0: 2/2/2/0
Vérification des routes BGP dans la table de routage
But
Vérifiez que les routes BGP figurent dans la table de routage pe-vrf.inet.0.
Action
user@host# run show route protocol bgp table pe-vrf.inet.0
pe-vrf.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
198.168.50.0/24 *[BGP/170] 01:18:14, localpref 100, from 203.0.113.4
AS path: I, validation-state: unverified
> to 198.168.30.2 via ge-5/2/5.0, Push 16
198.168.51.0/24 *[BGP/170] 01:18:14, MED 2, localpref 100, from 203.0.113.4
AS path: I, validation-state: unverified
> to 198.168.30.2 via ge-5/2/5.0, Push 16
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plate-forme 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.