Tunnels basés sur les sauts suivants pour les VPN de couche 3
Cette rubrique décrit la configuration d’un tunnel GRE (Generic Routing Encapsulation) dynamique et d’un tunnel MPLS sur UDP dynamique pour la prise en charge du saut suivant composite de tunnel. Il fournit également des informations sur la configuration du transfert de chemin inverse pour vous protéger contre l’usurpation d’identité.
Configurer des tunnels dynamiques MPLS sur GRE basés sur des sauts suivants
Les tunnels MPLS-sur-GRE basés sur le saut suivant créent un saut suivant composite de tunnel, un saut suivant indirect et un saut suivant de transfert pour résoudre un itinéraire de destination de tunnel. Vous pouvez configurer des tunnels MPLS sur GRE basés sur les sauts suivants, ainsi que la décapsulation des tunnels basée sur des filtres de pare-feu.
Sur ACX Series, à partir de Junos OS Evolved version 24.2R1, vous pouvez configurer un tunnel GRE dynamique basé sur les sauts suivants en incluant l’instruction gre next-hop-based-tunnel dans la hiérarchie [edit routing-options dynamic-tunnels].
Vous pouvez configurer la décapsulation basée sur les filtres de pare-feu MPLS-sur-GRE en incluant l’instruction gre au niveau de la hiérarchie [edit firewall family family-name filter filter-name term term-name then decapsulate]. Seule l’action de décapsulation est prise en charge dans la règle de filtre de pare-feu. La décapsulation basée sur les filtres de pare-feu MPLS sur GRE n’est prise en charge que pour les inets de la famille.
Vous pouvez récupérer les statistiques du tunnel d’encapsulation en configurant un intervalle spécifique à l’aide de l’instruction interval au niveau de la hiérarchie [edit routing-options dynamic-tunnels statistics]. Vous pouvez également utiliser la show dynamic-tunnels database statistics commande pour afficher les statistiques.
- Configurer l’encapsulation pour un tunnel dynamique de saut suivant
- Configurer les filtres de pare-feu pour la décapsulation
- Activation des statistiques d’encapsulation
- Limitations
Configurer l’encapsulation pour un tunnel dynamique de saut suivant
Pour configurer l’encapsulation pour le tunnel de saut suivant dynamique, vous devez inclure l’instruction gre next-hop-based-tunnel au niveau de la hiérarchie [edit routing-options dynamic-tunnels].
Voici un exemple de configuration pour l’encapsulation MPLS sur GRE :
[edit]
protocols {
bgp {
group IBGP {
type internal;
local-address 192.168.19.190;
family inet {
unicast;
}
}
neighbor 192.168.20.11;
}
}
routing-options {
dynamic-tunnels {
gre full-resolved-next-hop-based-tunnel;
gre next-hop-based-tunnel;
test_tunnel {
source-address 192.168.19.190;
gre;
destination-networks {
192.168.20.0/24 preference 4;
}
}
}
}
Configurer les filtres de pare-feu pour la décapsulation
Dans la configuration suivante, nous faisons correspondre le protocole SIP, DIP aux paquets de tunnel. Le filtre de pare-feu doit être mappé à l’instance de routage par défaut.
Avec cette action, PFE programme le routeur pour qu’il enlève les en-têtes de tunnel et poursuive le traitement en fonction de l’en-tête interne.
forwarding-options {
family inet {
filter {
input f1;
}
}
}
firewall {
family inet {
filter f1 {
term t1 {
from {
source-address {
192.168.9.190/32;
}
destination-address {
10.255.10.11/32;
} }
then {
decapsulate {
gre;
}
}
}
term t2 {
then accept;
}
}
}
}
Activation des statistiques d’encapsulation
Le PFE a la capacité de fournir les statistiques d’encapsulation au niveau d’un paquet et d’un nombre d’octets. La valeur du nombre d’octets inclut l’en-tête d’encapsulation. Par défaut, les statistiques ne sont pas activées pour l’encapsulation du tunnel, car les compteurs utilisés pour les statistiques sont une ressource partagée. Par conséquent, vous devez activer l’allocation de compteur en configurant l’instruction encap-stats-enable CLI.
Pour activer les statistiques d’encapsulation, configurez l’interface de ligne de commande suivante :
user@host# set system packet-forwarding-options tunnel encap-stats-enable
Limitations
Voici les limitations lors de la configuration des tunnels dynamiques MPLS sur GRE basés sur le saut suivant sur ACX Series :
-
La propagation TTL pour le tunnel dynamique basé sur le saut suivant n’est pas prise en charge.
-
La classe de service et la MTU ne sont pas prises en charge.
-
La découverte MTU de chemin pour l’encapsulation IPv4 et IPv6 n’est pas prise en charge, car le cache de flux n’est pas conservé pour le paquet encapsulé au nœud d’origine du tunnel.
-
La protection contre l’usurpation d’identité lors de la décapsulation du tunnel pour l’adresse IP source interne n’est pas prise en charge.
-
Dans une règle de filtre de pare-feu, uniquement
decapsulate mpls-in-udpetdecapsulate greest pris en charge pour la décapsulation de tunnel. Les autres règles de filtre de pare-feu sur l’interface principale entrante ne sont pas prises en charge en raison de la limitation du chemin de données. -
La règle de décapsulation du filtre de pare-feu prend uniquement en charge le VRF par défaut.
-
Les statistiques de tunnel par composite de tunnel au niveau du saut suivant ne sont pas prises en charge.
-
L’attribution des compteurs statistiques se fait selon le principe du premier arrivé, premier servi (FCFS). Lors d’un redémarrage du système ou d’un redémarrage evo-pefmand, certains compteurs peuvent avoir une valeur différente de zéro après le redémarrage et les compteurs peuvent ne pas s’incrémenter.
-
Le masque de préfixe /32 pour IPv4 et /128 pour IPv6 n’est pris en charge que dans les règles de filtrage basées sur la décapsulation. La liste des préfixes de filtre de pare-feu dans les règles de filtrage basées sur la décapsulation n’est pas prise en charge.
-
Le balisage VLAN flexible n’est pas pris en charge.
-
Le tunnel GRE dynamique next-hop basé sur l’interface n’est pas pris en charge.
-
L’instruction
set chassis loopback-dynamic-tunnelde configuration ne s’applique pas à la plate-forme ACX, car l’encapsulation et la décapsulation de tunnel au débit de ligne sont prises en charge. -
Le cœur IPv6 n’est pas pris en charge.
Exemple : configuration de tunnels GRE dynamiques basés sur le saut suivant
Cet exemple montre comment configurer un tunnel d’encapsulation de routage générique (GRE) dynamique qui inclut un prochain saut composite de tunnel (CNH) au lieu d’un saut suivant d’interface. Le tunnel GRE dynamique basé sur le saut suivant présente un avantage d’évolutivité par rapport aux tunnels GRE dynamiques basés sur l’interface.
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
-
Cinq routeurs MX Series avec MPC et MIC.
-
Junos OS version 16.2 ou ultérieure s’exécutant sur les routeurs PE.
Avant de commencer :
-
Configurez les interfaces de l’appareil, y compris l’interface de bouclage.
-
Configurez l’ID de routeur et le numéro du système autonome de l’appareil.
-
Établissez une session BGP interne (IBGP) avec l’équipement PE distant.
-
Établissez un appairage OSPF entre les appareils.
Aperçu
À partir de la version 16.2 de Junos OS, un tunnel GRE (Generic Generic Routing Encapsulation) dynamique prend en charge la création d’un saut suivant composite pour chaque tunnel GRE configuré.
Par défaut, pour chaque nouveau tunnel GRE dynamique configuré, une interface de tunnel logique correspondante est créée. C’est ce qu’on appelle un tunnel dynamique basé sur l’interface et c’est le mode par défaut pour créer des tunnels dynamiques. Dans le cas d’un tunnel dynamique basé sur une interface, le nombre de tunnels pouvant être configurés sur un équipement dépend du nombre total d’interfaces prises en charge sur l’appareil. Le tunnel GRE dynamique basé sur le saut suivant supprime la dépendance vis-à-vis des interfaces physiques, et l’encapsulation du tunnel GRE est implémentée en tant qu’instruction de saut suivant sans créer d’interface de tunnel logique. Cela offre un avantage d’évolutivité pour le nombre de tunnels dynamiques qui peuvent être créés sur un appareil.
À partir de la version 17.1 de Junos OS, sur les routeurs MX Series avec MPC et MIC, la limite de mise à l’échelle des tunnels GRE dynamiques basés sur le saut suivant est augmentée. Ces valeurs d’évolutivité accrues profitent aux réseaux de datacenters, où un routeur de passerelle doit communiquer avec un certain nombre de serveurs via une infrastructure IP ; par exemple, dans Contrail Networking.
À un moment donné, un tunnel dynamique basé sur le saut suivant ou un tunnel GRE dynamique basé sur l’interface par défaut peut exister sur un équipement. Le passage d’un mode tunnel à un autre supprime les tunnels existants et crée de nouveaux tunnels dans le nouveau mode tunnel en fonction des limites de mise à l’échelle prises en charge. De même, à un instant donné, pour la même destination de tunnel, le type d’encapsulation de tunnel basé sur le saut suivant peut être GRE ou UDP.
Pour activer le tunnel GRE dynamique basé sur le saut suivant, incluez l’instruction next-hop-based-tunnel au niveau de la [edit routing-options dynamic-tunnels gre] hiérarchie.
La fonctionnalité de tunnel dynamique existante nécessite une configuration statique complète. Actuellement, les informations de tunnel reçues des périphériques homologues dans les routes annoncées sont ignorées. À partir de la version 17.4R1 de Junos OS, sur les routeurs MX Series, les tunnels GRE dynamiques basés sur le saut suivant sont signalés à l’aide de la communauté étendue d’encapsulation BGP. La stratégie d’exportation BGP permet de spécifier les types de tunnel, d’annoncer les informations de tunnel côté expéditeur et d’analyser et transmettre les informations de tunnel côté récepteur. Un tunnel est créé en fonction de la communauté de tunnel de type reçu.
BGP prend en charge plusieurs encapsulations de tunnel. En cas de fonctionnalité multiple, le tunnel dynamique basé sur le saut suivant est créé en fonction de la stratégie BGP configurée et de la préférence de tunnel. La préférence de tunnel doit être cohérente aux deux extrémités du tunnel pour que le tunnel soit mis en place. Par défaut, le tunnel MPLS sur UDP (MPLSoUDP) est préféré aux tunnels GRE. S’il existe une configuration de tunnel dynamique, elle est prioritaire sur la communauté de tunnels reçus.
Lors de la configuration d’un tunnel GRE dynamique basé sur le saut suivant, tenez compte des considérations suivantes :
-
La création de tunnels dynamiques est déclenchée dans le processus de résolution des sauts suivants du protocole IBGP.
-
Le passage du mode tunnel basé sur le saut suivant au mode tunnel basé sur l’interface (et vice versa) est autorisé, ce qui peut avoir un impact sur les performances du réseau en termes de valeurs de mise à l’échelle du tunnel IP prises en charge dans chaque mode.
-
Le tunnel de maillage automatique RSVP n’est pas pris en charge avec la configuration de tunnel dynamique basée sur le saut suivant.
-
Cette fonctionnalité prend en charge la création dynamique de tunnels GRE basés sur de nouveaux sauts suivants IPv4-mappés IPv6.
-
Les fonctionnalités suivantes ne sont pas prises en charge avec la configuration de tunnel GRE dynamique basée sur le saut suivant :
-
Maillage automatique RSVP
-
Systèmes logiques
-
Collecte des statistiques de trafic par tunnel côté expéditeur (MX Series)
-
Application de la QoS, telle que le contrôle et la mise en forme, à l’interface du tunnel.
-
Détection de l’unité de transmission maximale du chemin
-
Fonctionnalité clé de GRE
-
Exploitation, administration et maintenance GRE (OAM) pour les messages keepalive GRE.
-
Topologie
La figure 1 illustre un scénario de VPN de couche 3 sur des tunnels GRE dynamiques. Les appareils de périphérie client (CE), CE1 et CE2, se connectent aux appareils de périphérie du fournisseur (PE), PE1 et PE2, respectivement. Les équipements PE sont connectés à un équipement fournisseur (équipement P1) et une session BGP interne (IBGP) interconnecte les deux équipements PE. Deux tunnels GRE dynamiques sont configurés entre les équipements PE. Le tunnel dynamique de l’équipement PE1 à l’équipement PE2 est basé sur le mode de tunnel de saut suivant, et le tunnel dynamique de l’équipement PE2 vers l’équipement PE1 est basé sur le mode tunnel d’interface.
GRE dynamiques
Le tunnel GRE dynamique basé sur le saut suivant est géré comme suit :
-
Une fois qu’un tunnel GRE dynamique basé sur le saut suivant est configuré, un itinéraire de masque de destination de tunnel avec un CNH de tunnel est créé pour les sauts suivants de protocole dans la table de routage inet.3. Cette route de tunnel IP n’est retirée que lorsque la configuration dynamique du tunnel est supprimée.
Les attributs CNH du tunnel sont les suivants :
-
Lorsque le CNH VPN de couche 3 est désactivé : adresse source et de destination, chaîne d’encapsulation et étiquette VPN.
-
Lorsque le CNH VPN de couche 3 et l’attribution d’étiquettes VPN par préfixe sont activés : adresse source, adresse de destination et chaîne d’encapsulation.
-
Lorsque le CNH VPN de couche 3 est activé et que l’attribution d’étiquettes VPN par préfixe est désactivée : adresse source, adresse de destination et chaîne d’encapsulation. Dans ce cas, la route est ajoutée à l’autre table d’instance de routage et de transfert virtuel avec une route secondaire.
-
-
Les appareils PE sont interconnectés à l’aide d’une session IBGP. Le saut suivant de la route IBGP vers un voisin BGP distant est le saut suivant du protocole, qui est résolu à l’aide de la route de masque de tunnel avec le saut suivant du tunnel.
-
Une fois le saut suivant résolu sur le saut suivant composite du tunnel, des sauts suivants indirects avec transfert de sauts suivants sont créés.
-
Le tunnel CNH est utilisé pour transférer les sauts suivants des sauts indirects suivants.
Configuration
Configuration rapide de la CLI
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 à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
CE1
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/8
set interfaces lo0 unit 0 family inet address 10.127.0.1/8
set routing-options router-id 10.127.0.1
set routing-options autonomous-system 65200
set protocols bgp group ce1-pe1 export export-loopback-direct
set protocols bgp group ce1-pe1 peer-as 65100
set protocols bgp group ce1-pe1 neighbor 10.0.0.2
set policy-options policy-statement export-loopback-direct term term-1 from interface lo0.0
set policy-options policy-statement export-loopback-direct term term-1 from route-filter 10.127.0.1/8 exact
set policy-options policy-statement export-loopback-direct term term-1 then accept
CE2
set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.2/24
set interfaces lo0 unit 0 family inet address 10.127.0.5/32
set routing-options router-id 10.127.0.5
set routing-options autonomous-system 65200
set protocols bgp group ce1-pe1 export export-loopback-direct
set protocols bgp group ce1-pe1 peer-as 65100
set protocols bgp group ce1-pe1 neighbor 203.0.113.1
set policy-options policy-statement export-loopback-direct term term-1 from interface lo0.0
set policy-options policy-statement export-loopback-direct term term-1 from route-filter 10.127.0.5/8 exact
set policy-options policy-statement export-loopback-direct term term-1 then accept
PE1
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.2/8
set interfaces ge-0/0/1 unit 0 family inet address 192.0.2.1/24
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.127.0.2/32
set routing-options static route 10.33.0.0/16 next-hop 192.0.2.2
set routing-options router-id 10.127.0.2
set routing-options autonomous-system 65100
set routing-options dynamic-tunnels gre next-hop-based-tunnel
set routing-options dynamic-tunnels gre-dyn-tunnel-to-pe2 source-address 10.127.0.2
set routing-options dynamic-tunnels gre-dyn-tunnel-to-pe2 gre
set routing-options dynamic-tunnels gre-dyn-tunnel-to-pe2 destination-networks 10.127.0.0/16
set protocols bgp group IBGP type internal
set protocols bgp group IBGP local-address 10.127.0.2
set protocols bgp group IBGP family inet-vpn unicast
set protocols bgp group IBGP neighbor 10.127.0.4
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set routing-instances L3VPN-Over-GRE-PE1 instance-type vrf
set routing-instances L3VPN-Over-GRE-PE1 interface ge-0/0/0.0
set routing-instances L3VPN-Over-GRE-PE1 route-distinguisher 10.127.0.2:1
set routing-instances L3VPN-Over-GRE-PE1 vrf-target target:600:1
set routing-instances L3VPN-Over-GRE-PE1 protocols bgp group pe1-ce1 peer-as 65200
set routing-instances L3VPN-Over-GRE-PE1 protocols bgp group pe1-ce1 neighbor 10.0.0.1 as-override
P1
set interfaces ge-0/0/0 unit 0 family inet address 192.0.2.2/24
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces ge-0/0/1 unit 0 family inet address 198.51.100.1/24
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.127.0.3/32
set routing-options router-id 10.127.0.3
set routing-options autonomous-system 65100
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
PE2
set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.1/24
set interfaces ge-0/0/1 unit 0 family inet address 198.51.100.2/24
set interfaces lo0 unit 0 family inet address 10.127.0.4/32
set routing-options nonstop-routing
set routing-options router-id 10.127.0.4
set routing-options autonomous-system 65100
set routing-options dynamic-tunnels gre-dyn-tunnel-to-pe1 source-address 10.127.0.4
set routing-options dynamic-tunnels gre-dyn-tunnel-to-pe1 gre
set routing-options dynamic-tunnels gre-dyn-tunnel-to-pe1 destination-networks 10.127.0.0/16
set protocols bgp group IBGP type internal
set protocols bgp group IBGP local-address 10.127.0.4
set protocols bgp group IBGP family inet-vpn unicast
set protocols bgp group IBGP neighbor 10.127.0.2
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set routing-instances L3VPN-Over-GRE-PE2 instance-type vrf
set routing-instances L3VPN-Over-GRE-PE2 interface ge-0/0/0.0
set routing-instances L3VPN-Over-GRE-PE2 route-distinguisher 10.127.0.4:1
set routing-instances L3VPN-Over-GRE-PE2 vrf-target target:600:1
set routing-instances L3VPN-Over-GRE-PE2 protocols bgp group ebgp peer-as 65200
set routing-instances L3VPN-Over-GRE-PE2 protocols bgp group ebgp neighbor 203.0.113.2 as-override
Procédure
Procédure étape par étape
L’exemple suivant nécessite que vous naviguiez à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.
Pour configurer l’équipement PE1 :
-
Configurez les interfaces de l’appareil, y compris l’interface de bouclage de l’appareil.
[edit interfaces] user@PE1# set ge-0/0/0 unit 0 family inet address 10.0.0.2/8 user@PE1# set ge-0/0/1 unit 0 family inet address 192.0.2.1/24 user@PE1# set ge-0/0/1 unit 0 family mpls user@PE1# set lo0 unit 0 family inet address 10.127.0.2/8/32 -
Configurez un itinéraire statique pour les itinéraires à partir de l’équipement PE1 avec l’équipement P1 comme destination du saut suivant.
[edit routing-options] user@PE1# set static route 172.16.0.0/16 next-hop 192.0.2.2 -
Configurez l’ID de routeur et le numéro du système autonome pour l’appareil PE1.
[edit routing-options] user@PE1# set router-id 10.127.0.2 user@PE1# set autonomous-system 65100 -
Configurez l’appairage IBGP entre les équipements PE.
[edit protocols] user@PE1# set bgp group IBGP type internal user@PE1# set bgp group IBGP local-address 10.127.0.2 user@PE1# set bgp group IBGP family inet-vpn unicast user@PE1# set bgp group IBGP neighbor 10.127.0.4 -
Configurez OSPF sur toutes les interfaces de l’équipement PE1, à l’exception de l’interface de gestion.
[edit protocols] user@PE1# set ospf area 0.0.0.0 interface ge-0/0/1.0 user@PE1# set ospf area 0.0.0.0 interface lo0.0 passive -
Activez la configuration dynamique du tunnel GRE basée sur le saut suivant sur l’équipement PE1.
[edit routing-options] user@PE1# set dynamic-tunnels gre next-hop-based-tunnel -
Configurez les paramètres dynamiques du tunnel GRE de l’équipement PE1 vers l’équipement PE2.
[edit routing-options] user@PE1# set dynamic-tunnels gre-dyn-tunnel-to-pe2 source-address 10.127.0.2 user@PE1# set dynamic-tunnels gre-dyn-tunnel-to-pe2 gre user@PE1# set dynamic-tunnels gre-dyn-tunnel-to-pe2 destination-networks 10.127.0.0/16 -
Exportez la stratégie d’équilibrage de charge vers la table de transfert.
[edit routing-options] user@PE1# set forwarding-table export pplb -
Configurez une instance de routage VRF sur l’équipement PE1 et d’autres paramètres d’instance de routage.
[edit routing-instances] user@PE1# set L3VPN-Over-GRE-PE1 instance-type vrf user@PE1# set L3VPN-Over-GRE-PE1 interface ge-0/0/0.0 user@PE1# set L3VPN-Over-GRE-PE1 route-distinguisher 10.127.0.2:1 user@PE1# set L3VPN-Over-GRE-PE1 vrf-target target:600:1 -
Activez BGP dans la configuration de l’instance de routage pour l’appairage avec l’appareil CE1.
[edit routing-instances] user@PE1# set L3VPN-Over-GRE-PE1 protocols bgp group pe1-ce1 peer-as 65200 user@PE1# set L3VPN-Over-GRE-PE1 protocols bgp group pe1-ce1 neighbor 10.0.0.1 as-override
Résultats
À partir du mode configuration, confirmez votre configuration en entrant les show interfacescommandes , show routing-options, show protocolset show routing-instances . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@PE1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.0.0.2/8;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 192.0.2.1/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.127.0.2/32;
}
}
}
user@PE1# show routing-options
static {
route 172.16.0.0/16 next-hop 192.0.2.2;
}
router-id 10.127.0.2;
autonomous-system 65100;
dynamic-tunnels {
gre next-hop-based-tunnel;
gre-dyn-tunnel-to-pe2 {
source-address 10.127.0.2;
gre;
destination-networks {
10.127.0.0/16;
}
}
}
user@PE1# show protocols
bgp {
group IBGP {
type internal;
local-address 127.0.0.2;
family inet-vpn {
unicast;
}
neighbor 127.0.0.4;
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/1.0;
interface lo0.0 {
passive;
}
}
}
user@PE1# show routing-instances
L3VPN-Over-GRE-PE1 {
instance-type vrf;
interface ge-0/0/0.0;
route-distinguisher 127.0.0.2:1;
vrf-target target:600:1;
protocols {
bgp {
group pe1-ce1 {
peer-as 200;
neighbor 10.0.0.1 {
as-override;
}
}
}
}
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de la connexion entre les appareils PE
- Vérifier les itinéraires de tunnel dynamiques sur l’équipement PE1
- Vérifier les itinéraires de tunnel dynamiques sur l’équipement PE2
- Vérification de la présence de l’indicateur de prochain saut indirect attendu sur les routes
Vérification de la connexion entre les appareils PE
But
Vérifiez l’état d’appairage BGP entre l’équipement PE1 et l’équipement PE2, ainsi que les routes BGP reçues de l’équipement PE2.
Action
À partir du mode opérationnel, exécutez les show bgp summary commandes and show route receive-protocol bgp ip-address table bgp.l3vpn.0 .
user@PE1> show bgp summary
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
bgp.l3vpn.0
2 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
127.0.0.4 100 139 136 0 0 58:23 Establ
bgp.l3vpn.0: 2/2/2/0
L3VPN-Over-GRE-PE1.inet.0: 2/2/2/0
10.0.0.1 200 135 136 0 0 58:53 Establ
L3VPN-Over-GRE-PE1.inet.0: 1/1/1/0
user@PE1> show route receive-protocol bgp 10.127.0.4 table bgp.l3vpn.0 bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 10.127.0.4:1:127.0.0.5/8 * 127.0.0.4 65100 65200 I 10.127.0.4:1:203.0.113.0/24 * 127.0.0.4 65100 I
Signification
-
Dans la première sortie, l’état de session BGP est
Establ, ce qui signifie que la session est active et que les périphériques PE sont appairés. -
Dans la deuxième sortie, l’équipement PE1 a appris deux routes BGP à partir de l’équipement PE2.
Vérifier les itinéraires de tunnel dynamiques sur l’équipement PE1
But
Vérifiez les routes dans la table de routage inet.3 et les informations de la base de données de tunnel dynamique sur l’équipement PE1.
Action
À partir du mode opérationnel, exécutez les show route table inet.3 commandes and show dynamic-tunnels database terse .
user@PE1> show route table inet.3
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.127.0.0/8 *[Tunnel/300] 01:01:45
Tunnel
10.127.0.4/8 *[Tunnel/300] 00:10:24
Tunnel Composite
user@PE1> show dynamic-tunnels database terse
Table: inet.3
Destination-network: 10.127.0.0/8
Destination Source Next-hop Type Status
10.127.0.4/8 10.127.0.2 0xb395e70 nhid 612 gre Up
Signification
-
Dans la première sortie, étant donné que l’équipement PE1 est configuré avec le tunnel GRE dynamique basé sur le saut suivant, une route composite de tunnel est créée pour l’entrée de route de la table de routage inet.3.
-
Dans la deuxième sortie, le tunnel GRE dynamique créé entre l’équipement PE1 et l’équipement PE2 est actif et un ID de saut suivant lui est attribué au lieu d’une interface de saut suivant.
Vérifier les itinéraires de tunnel dynamiques sur l’équipement PE2
But
Vérifiez les routes dans la table de routage inet.3 et les informations de la base de données du tunnel dynamique sur l’équipement PE2.
Action
À partir du mode opérationnel, exécutez les show route table inet.3 commandes and show dynamic-tunnels database terse .
user@PE2> show route table inet.3
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.127.0.0/8 *[Tunnel/300] 01:06:52
Tunnel
10.127.0.2/8 *[Tunnel/300] 01:04:45
> via gr-0/1/0.32769
user@PE1> show dynamic-tunnels database terse Table: inet.3 Destination-network: 127.0.0.0/8 Destination Source Next-hop Type 10. 10.127.0.2/8 10.127.0.4 gr-0/1/0.32769 gre Up
Signification
-
Dans la première sortie, étant donné que l’appareil PE2 a la configuration de tunnel GRE dynamique basée sur l’interface par défaut, une nouvelle interface est créée pour l’entrée de route de la table de routage inet.3.
-
Dans la deuxième sortie, le tunnel GRE dynamique créé entre l’équipement PE2 et l’équipement PE1 est actif et le nom d’interface nouvellement créé lui est attribué.
Vérification de la présence de l’indicateur de prochain saut indirect attendu sur les routes
But
Vérifiez que les périphériques PE1 et PE2 sont configurés pour maintenir la liaison de saut suivant indirect vers le transfert suivant sur la table de transfert du moteur de transfert de paquets.
Action
À partir du mode opérationnel, exécutez la commande sur l’appareil PE1 et l’appareil show krt indirect-next-hop PE2.
user@PE1> show krt indirect-next-hop
Indirect Nexthop:
Index: 1048574 Protocol next-hop address: 10.127.0.4
RIB Table: bgp.l3vpn.0
Label: Push 299792
Policy Version: 1 References: 2
Locks: 3 0xb2ab630
Flags: 0x0
INH Session ID: 0x0
INH Version ID: 0
Ref RIB Table: unknown
Tunnel type: GRE, Reference count: 3, nhid: 612
Destination address: 10.127.0.4, Source address: 10.127.0.2
Tunnel id: 1, VPN Label: Push 299792, TTL action: prop-ttl
IGP FRR Interesting proto count : 2
Chain IGP FRR Node Num : 1
IGP Resolver node(hex) : 0xb3c6d9c
IGP Route handle(hex) : 0xb1ad230 IGP rt_entry protocol : Tunnel
IGP Actual Route handle(hex) : 0x0 IGP Actual rt_entry protocol : Any
user@PE2> show krt indirect-next-hop
Indirect Nexthop:
Index: 1048574 Protocol next-hop address: 10.127.0.2
RIB Table: bgp.l3vpn.0
Label: Push 299792
Policy Version: 2 References: 2
Locks: 3 0xb2ab630
Flags: 0x2
INH Session ID: 0x145
INH Version ID: 0
Ref RIB Table: unknown
Next hop: via gr-0/1/0.32769
Label operation: Push 299792
Label TTL action: prop-ttl
Load balance label: Label 299792: None;
Label element ptr: 0xb395d40
Label parent element ptr: 0x0
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 0x144
IGP FRR Interesting proto count : 2
Chain IGP FRR Node Num : 1
IGP Resolver node(hex) : 0xb3d36e8
IGP Route handle(hex) : 0xb1af060 IGP rt_entry protocol : Tunnel
IGP Actual Route handle(hex) : 0x0 IGP Actual rt_entry protocol : Any
Signification
-
Dans la première sortie, l’équipement PE1 dispose d’un tunnel GRE dynamique basé sur le saut suivant vers l’équipement PE2.
-
Dans la deuxième sortie, le périphérique PE2 dispose d’un tunnel GRE dynamique basé sur une interface vers le périphérique PE1.
Dépannage
Pour dépanner les tunnels dynamiques basés sur le saut suivant, reportez-vous à :
Commandes de dépannage
Problème
La configuration dynamique du tunnel GRE basée sur le saut suivant n’est pas prise en compte.
Solution
Pour dépanner la configuration du tunnel GRE basée sur le saut suivant, utilisez les commandes suivantes traceoptions dans la [edit routing-options dynamic-tunnels] hiérarchie des instructions :
-
traceoptions file file-name -
traceoptions file size file-size -
traceoptions flag all
Par exemple:
[edit routing-options dynamic-tunnels]
traceoptions {
file gre_dyn_pe1.wri size 4294967295;
flag all;
}
Exemple : configuration de tunnels dynamiques MPLS sur UDP basés sur le saut suivant
Cet exemple montre comment configurer un tunnel MPLS sur UDP dynamique qui inclut un saut suivant composite de tunnel. La fonctionnalité MPLS sur UDP offre un avantage d’évolutivité sur le nombre de tunnels IP pris en charge sur un périphérique.
À partir de la version 18.3R1 de Junos OS, les tunnels MPLS sur UDP sont pris en charge sur les routeurs PTX Series et les commutateurs QFX Series. Pour chaque tunnel dynamique configuré sur un routeur PTX ou un commutateur QFX, un saut suivant composite de tunnel, un saut suivant indirect et un prochain saut de transfert sont créés pour résoudre l’itinéraire de destination du tunnel. Vous pouvez également utiliser le contrôle de stratégie pour résoudre le tunnel dynamique sur certains préfixes en incluant l’instruction de configuration forwarding-rib au niveau de la [edit routing-options dynamic-tunnels] hiérarchie.
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
-
Cinq routeurs MX Series avec MPC et MIC.
-
Junos OS version 16.2 ou ultérieure s’exécutant sur les routeurs Provider Edge (PE).
Avant de commencer :
-
Configurez les interfaces de l’appareil, y compris l’interface de bouclage.
-
Configurez l’ID de routeur et le numéro système autonome de l’appareil.
-
Établissez une session BGP interne (IBGP) avec l’équipement PE distant.
-
Établissez un appairage OSPF entre les appareils.
Aperçu
À partir de la version 16.2 de Junos OS, un tunnel UDP dynamique prend en charge la création d’un saut suivant composite pour chaque tunnel UDP configuré. Ces tunnels UDP dynamiques basés sur le saut suivant sont appelés tunnels MPLS-sur-UDP. Les sauts suivants composites de tunnel sont activés par défaut pour les tunnels MPLS sur UDP.
Les tunnels MPLS sur UDP peuvent être bidirectionnels ou unidirectionnels.
-
Bidirectionnel : lorsque les périphériques PE sont connectés via des tunnels MPLS sur UDP dans les deux sens, on parle de tunnel MPLS sur UDP bidirectionnel.
-
Unidirectionnel : lorsque deux périphériques PE sont connectés via un tunnel MPLS-sur-UDP dans un sens, et sur MPLS/IGP dans l’autre sens, on parle de tunnel MPLS-sur-UDP unidirectionnel.
Les tunnels MPLS sur UDP unidirectionnels sont utilisés dans les scénarios de migration ou dans les cas où deux équipements PE se connectent mutuellement sur deux réseaux disjoints. Étant donné qu’il n’existe pas de tunnel dans le sens inverse pour les tunnels MPLS sur UDP unidirectionnels, vous devez configurer une décapsulation MPLS sur UDP basée sur un filtre sur le périphérique PE distant pour transférer le trafic.
À partir de Junos OS version 18.2R1, sur les routeurs PTX Series et les QFX10000 avec des tunnels MPLS sur UDP unidirectionnels, vous devez configurer le périphérique PE distant avec un filtre d’entrée pour les paquets MPLS sur UDP et une action de décapsulation des en-têtes IP et UDP pour le transfert des paquets dans le sens inverse du tunnel.
Par exemple, sur l’équipement PE2 distant, la configuration suivante est requise pour les tunnels unidirectionnels MPLS sur UDP :
PE2
[edit firewall filter] user@host# set Decap_Filter term udp_decap from protocol udp user@host# set Decap_Filter term udp_decap from destination-port 6635 user@host# set Decap_Filter term udp_decap then count UDP_PKTS user@host# set Decap_Filter term udp_decap then decapsulate mpls-in-udp user@host# set Decap_Filter term def then count def_pkt user@host# set Decap_Filter term def then accept
Dans l’exemple de configuration ci-dessus, Decap_Filter est le nom du filtre de pare-feu utilisé pour la décapsulation MPLS-sur-UDP. Il s’agit udp_decap du filtre d’entrée permettant d’accepter les paquets UDP sur l’interface centrale de l’équipement PE2, puis de décapsuler les paquets MPLS-sur-UDP en paquets MPLS-sur-IP pour le transfert.
Vous pouvez utiliser les commandes existantes du mode opérationnel du pare-feu, par exemple show firewall filter pour afficher la décapsulation MPLS sur UDP basée sur les filtres.
Par exemple:
user@host >show firewall filter Decap_Filter Filter: Decap_Filter Counters: Name Bytes Packets UDP_PKTS 16744 149 def_pkt 13049 136
Pour les tunnels MPLS sur UDP unidirectionnels :
-
Seule l’adresse IPv4 est prise en charge en tant qu’en-tête externe. La décapsulation MPLS sur UDP basée sur un filtre ne prend pas en charge l’adresse IPv6 dans l’en-tête externe.
-
Seule l’instance de routage par défaut est prise en charge après la décapsulation.
À partir de la version 17.1 de Junos OS, la limite d’évolutivité des tunnels MPLS sur UDP est augmentée sur les routeurs MX Series avec MPC et MIC.
À partir de la version 19.2R1 de Junos, sur les routeurs MX Series avec MPC et MIC, l'architecture CSC (Carrier Supporting Carrier Supporting Carrier) peut être déployée avec des tunnels MPLS sur UDP acheminant le trafic MPLS sur des tunnels UDP IPv4 dynamiques établis entre les périphériques PE de l'opérateur de support. Avec cette amélioration, l’avantage de mise à l’échelle fourni par les tunnels MPLS sur UDP est encore accru. La prise en charge CSC avec le tunnel MPLS sur UDP n’est pas prise en charge pour le tunnel UDP IPv6.
La fonctionnalité de tunnel dynamique existante nécessite une configuration statique complète. Actuellement, les informations de tunnel reçues des périphériques homologues dans les routes annoncées sont ignorées. À partir de la version 17.4R1 de Junos OS, sur les routeurs MX Series, les tunnels MPLS sur UDP dynamiques basés sur le saut suivant sont signalés à l’aide de la communauté étendue d’encapsulation BGP. La stratégie d’exportation BGP permet de spécifier les types de tunnel, d’annoncer les informations de tunnel côté expéditeur et d’analyser et transmettre les informations de tunnel côté récepteur. Un tunnel est créé en fonction de la communauté de tunnel de type reçu.
BGP prend en charge plusieurs encapsulations de tunnel. En cas de fonctionnalité multiple, le tunnel dynamique basé sur le saut suivant est créé en fonction de la stratégie BGP configurée et de la préférence de tunnel. La préférence de tunnel doit être cohérente aux deux extrémités du tunnel pour que le tunnel soit mis en place. Par défaut, le tunnel MPLS sur UDP est préféré aux tunnels GRE. S’il existe une configuration de tunnel dynamique, elle est prioritaire sur la communauté de tunnels reçus.
Lors de la configuration d’un tunnel MPLS sur UDP dynamique basé sur le saut suivant, tenez compte des considérations suivantes :
-
Une session IBGP doit être configurée entre les équipements PE.
-
Un basculement entre les encapsulations de tunnel dynamiques basées sur le saut suivant (UDP et GRE) est autorisé, ce qui peut avoir un impact sur les performances du réseau en termes de valeurs de mise à l’échelle du tunnel IP prises en charge dans chaque mode.
-
Le fait d’avoir des types d’encapsulation de tunnel dynamiques basés sur les sauts suivants GRE et UDP pour la même destination de tunnel entraîne un échec de validation.
-
Pour les tunnels unidirectionnels MPLS-sur-UDP, vous devez explicitement configurer la décapsulation MPLS-sur-UDP basée sur un filtre sur le périphérique PE distant pour les paquets à transférer.
-
Le basculement GRES (Graceful Moteur de routage) est pris en charge avec MPLS-sur-UDP, et les indicateurs de type de tunnel MPLS-sur-UDP sont unifiés conformes aux normes ISSU et NSR.
-
Les tunnels MPLS sur UDP sont pris en charge sur Virtual MX (vMX) en mode Lite.
-
Les tunnels MPLS sur UDP prennent en charge la création de tunnels GRE dynamiques en fonction des nouveaux sauts suivants IPv6 mappés IPv4.
-
Les tunnels MPLS-sur-UDP sont pris en charge dans le cadre de l’interopérabilité avec Contrail, dans lequel les tunnels MPLS-sur-UDP sont créés à partir du routeur virtuel contrail vers une passerelle MX. Pour ce faire, la communauté suivante doit être annoncée dans le routage entre le routeur MX Series et le routeur virtuel contrail :
[edit policy-options community] udp members 0x030c:64512:13;
À un moment donné, un seul type de tunnel est pris en charge sur le vRouter contrail : les tunnels GRE dynamiques basés sur le saut suivant, les tunnels MPLS sur UDP ou VXLAN.
-
Les fonctionnalités suivantes ne sont pas prises en charge avec la configuration de tunnel MPLS sur UDP dynamique basée sur le saut suivant :
-
Maillage automatique RSVP
-
Configuration simple de tunnel IPV6 GRE et UDP
-
Systèmes logiques
-
Topologie
La figure 2 illustre un scénario de VPN de couche 3 sur des tunnels MPLS sur UDP dynamiques. Les appareils de périphérie client (CE), CE1 et CE2, se connectent aux appareils de périphérie du fournisseur (PE), PE1 et PE2, respectivement. Les équipements PE sont connectés à un équipement fournisseur (équipement P1) et une session BGP interne (IBGP) interconnecte les deux équipements PE. Un tunnel MPL sur UDP bidirectionnel dynamique basé sur le prochain saut est configuré entre les périphériques PE.
MPLS sur UDP dynamiques
Le tunnel MPLS sur UDP est géré comme suit :
-
Une fois qu’un tunnel MPLS sur UDP est configuré, un itinéraire de masque de destination de tunnel avec un saut suivant composite de tunnel est créé pour le tunnel dans la table de routage inet.3. Cette route de tunnel IP n’est retirée que lorsque la configuration dynamique du tunnel est supprimée.
Les attributs de saut suivant composites de tunnel sont les suivants :
-
Lorsque le saut suivant composite VPN de couche 3 est désactivé : adresse source et de destination, chaîne d’encapsulation et étiquette VPN.
-
Lorsque le saut suivant composite VPN de couche 3 et l’attribution d’étiquettes VPN par préfixe sont activés : adresse source, adresse de destination et chaîne d’encapsulation.
-
Lorsque le saut suivant composite VPN de couche 3 est activé et que l’attribution d’étiquettes VPN par préfixe est désactivée : adresse source, adresse de destination et chaîne d’encapsulation. Dans ce cas, la route est ajoutée à l’autre table d’instance de routage et de transfert virtuel avec une route secondaire.
-
-
Les appareils PE sont interconnectés à l’aide d’une session IBGP. Le saut suivant de la route IBGP vers un voisin BGP distant est le saut suivant du protocole, qui est résolu à l’aide de la route de masque de tunnel avec le saut suivant du tunnel.
-
Une fois que le saut suivant de protocole est résolu sur le saut suivant composite du tunnel, des sauts suivants indirects avec transfert de sauts suivants sont créés.
-
Le saut suivant composite du tunnel est utilisé pour transférer les sauts suivants des sauts suivants indirects.
Configuration
Configuration rapide de la CLI
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 à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
CE1
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/8 set interfaces lo0 unit 0 family inet address 10.127.0.1/32 set routing-options router-id 10.127.0.1 set routing-options autonomous-system 65200 set protocols bgp group ce1-pe1 export export-loopback-direct set protocols bgp group ce1-pe1 peer-as 100 set protocols bgp group ce1-pe1 neighbor 10.0.0.2 set policy-options policy-statement export-loopback-direct term term-1 from interface lo0.0 set policy-options policy-statement export-loopback-direct term term-1 from route-filter 10.127.0.1/32 exact set policy-options policy-statement export-loopback-direct term term-1 then accept
CE2
set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.2/24 set interfaces lo0 unit 0 family inet address 10.127.0.5/32 set routing-options router-id 10.127.0.5 set routing-options autonomous-system 65200 set protocols bgp group ce1-pe1 export export-loopback-direct set protocols bgp group ce1-pe1 peer-as 65100 set protocols bgp group ce1-pe1 neighbor 203.0.113.1 set policy-options policy-statement export-loopback-direct term term-1 from interface lo0.0 set policy-options policy-statement export-loopback-direct term term-1 from route-filter 10.127.0.5/32 exact set policy-options policy-statement export-loopback-direct term term-1 then accept
PE1
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.2/8 set interfaces ge-0/0/1 unit 0 family inet address 192.0.2.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.127.0.2/32 set routing-options static route 10.33.0/16 next-hop 192.0.2.2 set routing-options router-id 10.127.0.2 set routing-options autonomous-system 65100 set routing-options forwarding-table export pplb set routing-options dynamic-tunnels gre next-hop-based-tunnel set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe2 source-address 10.127.0.2 set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe2 udp set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe2 destination-networks 10.127.0.0/24 set protocols bgp group IBGP type internal set protocols bgp group IBGP local-address 10.127.0.2 set protocols bgp group IBGP family inet-vpn unicast set protocols bgp group IBGP neighbor 10.127.0.4 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set routing-instances MPLS-over-UDP-PE1 instance-type vrf set routing-instances MPLS-over-UDP-PE1 interface ge-0/0/0.0 set routing-instances MPLS-over-UDP-PE1 route-distinguisher 10.127.0.2:1 set routing-instances MPLS-over-UDP-PE1 vrf-target target:600:1 set routing-instances MPLS-over-UDP-PE1 protocols bgp group pe1-ce1 peer-as 65200 set routing-instances MPLS-over-UDP-PE1 protocols bgp group pe1-ce1 neighbor 10.0.0.1 as-override
P1
set interfaces ge-0/0/0 unit 0 family inet address 192.0.2.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 198.51.100.1/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.127.0.3/32 set routing-options router-id 10.127.0.3 set routing-options autonomous-system 65100 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive
PE2
set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.1/24 set interfaces ge-0/0/1 unit 0 family inet address 198.51.100.2/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.127.0.4/8 set routing-options nonstop-routing set routing-options router-id 10.127.0.4 set routing-options autonomous-system 65100 set routing-options forwarding-table export pplb set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe1 source-address 10.127.0.4 set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe1 udp set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe1 destination-networks 10.127.0.0/24 set protocols bgp group IBGP type internal set protocols bgp group IBGP local-address 10.127.0.4 set protocols bgp group IBGP family inet-vpn unicast set protocols bgp group IBGP neighbor 10.127.0.2 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set routing-instances MPLS-over-UDP-PE2 instance-type vrf set routing-instances MPLS-over-UDP-PE2 interface ge-0/0/0.0 set routing-instances MPLS-over-UDP-PE2 route-distinguisher 10.127.0.4:1 set routing-instances MPLS-over-UDP-PE2 vrf-target target:600:1 set routing-instances MPLS-over-UDP-PE2 protocols bgp group ebgp peer-as 65200 set routing-instances MPLS-over-UDP-PE2 protocols bgp group ebgp neighbor 203.0.113.2 as-override
Procédure
Procédure étape par étape
L’exemple suivant nécessite que vous naviguiez à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.
Pour configurer l’équipement PE1 :
-
Configurez les interfaces de l’appareil, y compris l’interface de bouclage de l’appareil.
[edit interfaces] user@PE1# set ge-0/0/0 unit 0 family inet address 10.0.0.2/8 user@PE1# set ge-0/0/1 unit 0 family inet address 192.0.2.1/24 user@PE1# set ge-0/0/1 unit 0 family mpls user@PE1# set lo0 unit 0 family inet address 10.127.0.2/8
-
Configurez un itinéraire statique pour les itinéraires à partir de l’équipement PE1 avec l’équipement P1 comme destination du saut suivant.
[edit routing-options] user@PE1# set static route 10.33.0.0/16 next-hop 192.0.2.2
-
Configurez l’ID de routeur et le numéro de système autonome pour l’équipement PE1.
[edit routing-options] user@PE1# set router-id 10.127.0.2 user@PE1# set autonomous-system 65100
-
(PTX Series uniquement) Configurez le contrôle des stratégies pour résoudre le routage de tunnel dynamique MPLS-sur-UDP sur certains préfixes.
[edit routing-options dynamic-tunnels] user@PTX-PE1# set forwarding-rib inet.0 inet-import dynamic-tunnel-fwd-route-import
-
(PTX Series uniquement) Configurez la stratégie d’importation d’inet pour résoudre les itinéraires de destination de tunnel dynamiques sur .
[edit policy-options] user@PTX-PE1# set policy-statement dynamic-tunnel-fwd-route-import term 1 from route-filter 10.127.0.4/32 exact user@PTX-PE1# set policy-statement dynamic-tunnel-fwd-route-import term 1 then accept user@PTX-PE1# set policy-options policy-statement dynamic-tunnel-fwd-route-import then reject
-
Configurez l’appairage IBGP entre les équipements PE.
[edit protocols] user@PE1# set bgp group IBGP type internal user@PE1# set bgp group IBGP local-address 10.127.0.2 user@PE1# set bgp group IBGP family inet-vpn unicast user@PE1# set bgp group IBGP neighbor 10.127.0.4
-
Configurez OSPF sur toutes les interfaces de l’équipement PE1, à l’exception de l’interface de gestion.
[edit protocols] user@PE1# set ospf area 0.0.0.0 interface ge-0/0/1.0 user@PE1# set ospf area 0.0.0.0 interface lo0.0 passive
-
Activez la configuration dynamique du tunnel GRE basée sur le saut suivant sur l’équipement PE1.
Note:Cette étape est uniquement nécessaire pour illustrer la différence d’implémentation entre les tunnels GRE dynamiques basés sur le saut suivant et les tunnels MPLS sur UDP.
[edit routing-options] user@PE1# set dynamic-tunnels gre next-hop-based-tunnel
-
Configurez les paramètres du tunnel MPLS-sur-UDP de l’équipement PE1 vers l’équipement PE2.
[edit routing-options] user@PE1# set dynamic-tunnels udp-dyn-tunnel-to-pe2 source-address 10.127.0.2 user@PE1# set dynamic-tunnels udp-dyn-tunnel-to-pe2 udp user@PE1# set dynamic-tunnels udp-dyn-tunnel-to-pe2 destination-networks 10.127.0.0/24
-
Configurez une instance de routage VRF sur l’équipement PE1 et d’autres paramètres d’instance de routage.
[edit routing-instances] user@PE1# set MPLS-over-UDP-PE1 instance-type vrf user@PE1# set MPLS-over-UDP-PE1 interface ge-0/0/0.0 user@PE1# set MPLS-over-UDP-PE1 route-distinguisher 10.127.0.2:1 user@PE1# set MPLS-over-UDP-PE1 vrf-target target:600:1
-
Activez BGP dans la configuration de l’instance de routage pour l’appairage avec l’appareil CE1.
[edit routing-instances] user@PE1# set MPLS-over-UDP-PE1 protocols bgp group pe1-ce1 peer-as 65200 user@PE1# set MPLS-over-UDP-PE1 protocols bgp group pe1-ce1 neighbor 10.0.0.1 as-override
Résultats
À partir du mode configuration, confirmez votre configuration en entrant les show interfacescommandes , show routing-options, show protocolset show routing-instances . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@PE1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.0.0.2/8;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 192.0.2.1/24;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.127.0.2/32;
}
}
}
user@PE1# show routing-options
static {
route 10.33.0.0/16 next-hop 192.0.2.2;
}
router-id 10.127.0.2;
autonomous-system 65100;
forwarding-table {
export pplb;
}
dynamic-tunnels {
gre next-hop-based-tunnel;
udp-dyn-tunnel-to-pe2 {
source-address 10.127.0.2;
udp;
destination-networks {
10.127.0.0/24;
}
}
}
user@PE1# show protocols
bgp {
group IBGP {
type internal;
local-address 10.127.0.2;
family inet-vpn {
unicast;
}
neighbor 10.127.0.4;
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/1.0;
interface lo0.0 {
passive;
}
}
}
user@PE1# show routing-instances
MPLS-over-UDP-PE1 {
instance-type vrf;
interface ge-0/0/0.0;
route-distinguisher 10.127.0.2:1;
vrf-target target:600:1;
protocols {
bgp {
group pe1-ce1 {
peer-as 65200;
neighbor 10.0.0.1 {
as-override;
}
}
}
}
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de la connexion entre les appareils PE
- Vérifier les itinéraires de tunnel dynamiques sur l’équipement PE1
- Vérifier les itinéraires de tunnel dynamiques sur l’équipement PE2
- Vérification de la présence de l’indicateur de prochain saut indirect attendu sur les routes
Vérification de la connexion entre les appareils PE
But
Vérifiez l’état d’appairage BGP entre l’équipement PE1 et l’équipement PE2, ainsi que les routes BGP reçues de l’équipement PE2.
Action
À partir du mode opérationnel, exécutez les show bgp summary commandes and show route receive-protocol bgp ip-address table bgp.l3vpn.0 .
user@PE1> show bgp summary
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
bgp.l3vpn.0
2 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.127.0.4 65100 139 136 0 0 58:23 Establ
bgp.l3vpn.0: 2/2/2/0
MPLS-over-UDP-PE1.inet.0: 2/2/2/0
10.10.0.1 65200 135 136 0 0 58:53 Establ
MPLS-over-UDP-PE1.inet.0: 1/1/1/0
user@PE1> show route receive-protocol bgp 10.127.0.4 table bgp.l3vpn.0 bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 10.127.0.4:1:127.0.0.5/8 * 10.127.0.4 65100 65200 I
Signification
-
Dans la première sortie, l’état de session BGP est
Establ, ce qui signifie que la session est active et que les périphériques PE sont appairés. -
Dans la deuxième sortie, l’équipement PE1 a appris une route BGP à partir de l’équipement PE2.
Vérifier les itinéraires de tunnel dynamiques sur l’équipement PE1
But
Vérifiez les routes dans la table de routage inet.3 et les informations de la base de données de tunnel dynamique sur l’équipement PE1.
Action
À partir du mode opérationnel, exécutez les show route table inet.3commandes , show dynamic-tunnels database terse, show dynamic-tunnels databaseet show dynamic-tunnels database summary .
user@PE1> show route table inet.3
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.127.0.0/24 *[Tunnel/300] 00:21:18
Tunnel
127.0.0.4/8 *[Tunnel/300] 00:21:18
Tunnel Composite
user@PE1> show dynamic-tunnels database terse Table: inet.3 Destination-network: 10.127.0.0/24 Destination Source Next-hop Type Status 10.127.0.4/8 10.127.0.2 0xb395b10 nhid 613 udp Up
user@PE1> show dynamic-tunnels database
Table: inet.3
. . .
Tunnel to: 10.127.0.4/32
Reference count: 2
Next-hop type: UDP
Source address: 10.127.0.2 Tunnel Id: 2
Next hop: tunnel-composite, 0xb395b10, nhid 613
VPN Label: Push 299776 Reference count: 3
Traffic Statistics: Packets 0, Bytes 0
State: Up
user@PE1> show dynamic-tunnels database summary Dynamic Tunnels, Total 1 displayed GRE Tunnel: Active Tunnel Mode, Next Hop Base IFL Based, Total 0 displayed, Up 0, Down 0 Nexthop Based, Total 0 displayed, Up 0, Down 0 RSVP Tunnel: Total 0 displayed UDP Tunnel: Total 1 displayed, Up 1, Down 0
Signification
-
Dans la première sortie, étant donné que l’équipement PE1 est configuré avec le tunnel MPLS-sur-UDP, une route composite de tunnel est créée pour l’entrée de route de la table de routage inet.3.
-
Dans les autres sorties, le tunnel MPLS-sur-UDP s’affiche avec le type d’encapsulation du tunnel, les paramètres du prochain saut du tunnel et l’état du tunnel.
Vérifier les itinéraires de tunnel dynamiques sur l’équipement PE2
But
Vérifiez les routes dans la table de routage inet.3 et les informations de la base de données du tunnel dynamique sur l’équipement PE2.
Action
À partir du mode opérationnel, exécutez les show route table inet.3commandes , puis .show dynamic-tunnels database terse
user@PE2> show route table inet.3
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.127.0.0/24 *[Tunnel/300] 00:39:31
Tunnel
10.127.0.2/32 *[Tunnel/300] 00:24:53
Tunnel Composite
user@PE1> show dynamic-tunnels database terse Table: inet.3 Destination-network: 127.0.0.0/8 Destination Source Next-hop Type Status 10.127.0.2/32 10.127.0.4 0xb395450 nhid 615 udp Up
Signification
Les sorties montrent la création du tunnel MPLS sur UDP et l’ID de saut suivant attribué en tant qu’interface de saut suivant, similaire à l’équipement PE1.
Vérification de la présence de l’indicateur de prochain saut indirect attendu sur les routes
But
Vérifiez que les périphériques PE1 et PE2 sont configurés pour maintenir la liaison de saut suivant indirect vers le transfert suivant sur la table de transfert du moteur de transfert de paquets.
Action
À partir du mode opérationnel, exécutez la commande sur l’appareil PE1 et l’appareil show krt indirect-next-hop PE2.
user@PE1> show krt indirect-next-hop
Indirect Nexthop:
Index: 1048574 Protocol next-hop address: 10.127.0.4
RIB Table: bgp.l3vpn.0
Label: Push 299776
Policy Version: 1 References: 1
Locks: 3 0xb2ab630
Flags: 0x0
INH Session ID: 0x0
INH Version ID: 0
Ref RIB Table: unknown
Tunnel type: UDP, Reference count: 3, nhid: 613
Destination address: 10.127.0.4, Source address: 10.127.0.2
Tunnel id: 2, VPN Label: Push 299776, TTL action: prop-ttl
IGP FRR Interesting proto count : 1
Chain IGP FRR Node Num : 1
IGP Resolver node(hex) : 0xb3c70dc
IGP Route handle(hex) : 0xb1ae688 IGP rt_entry protocol : Tunnel
IGP Actual Route handle(hex) : 0x0 IGP Actual rt_entry protocol : Any
user@PE2> show krt indirect-next-hop
Indirect Nexthop:
Index: 1048575 Protocol next-hop address: 10.127.0.2
RIB Table: bgp.l3vpn.0
Label: Push 299776
Policy Version: 1 References: 2
Locks: 3 0xb2ab740
Flags: 0x0
INH Session ID: 0x0
INH Version ID: 0
Ref RIB Table: unknown
Tunnel type: UDP, Reference count: 3, nhid: 615
Destination address: 10.127.0.2, Source address: 10.127.0.4
Tunnel id: 1, VPN Label: Push 299776, TTL action: prop-ttl
IGP FRR Interesting proto count : 2
Chain IGP FRR Node Num : 1
IGP Resolver node(hex) : 0xb3d3a28
IGP Route handle(hex) : 0xb1ae634 IGP rt_entry protocol : Tunnel
IGP Actual Route handle(hex) : 0x0 IGP Actual rt_entry protocol : Any
Signification
Les sorties montrent qu’un tunnel MPLS-sur-UDP dynamique basé sur le saut suivant est créé entre les périphériques PE.
Dépannage
Pour dépanner les tunnels dynamiques basés sur le saut suivant, reportez-vous à :
Commandes de dépannage
Problème
La configuration dynamique du tunnel MPLS sur UDP basée sur le saut suivant n’est pas prise en compte.
Solution
Pour dépanner la configuration du tunnel MPLS-sur-UDP basé sur le saut suivant, utilisez les commandes suivantes traceroute dans la [edit routing-options dynamic-tunnels] hiérarchie des instructions :
-
traceoptions file file-name -
traceoptions file size file-size -
traceoptions flag all
Par exemple:
[edit routing-options dynamic-tunnels]
traceoptions {
file udp_dyn_pe1.wri size 4294967295;
flag all;
}
Présentation de la protection contre l’usurpation d’identité pour les tunnels dynamiques basés sur les sauts suivants
Avec l’augmentation du déploiement de tunnels IP à grande échelle dans les centres de données, il est nécessaire d’ajouter des mesures de sécurité permettant aux utilisateurs de limiter le trafic malveillant provenant de machines virtuelles (VM) compromises. Une attaque possible consiste à injecter du trafic dans un VPN client arbitraire à partir d’un serveur compromis via le routeur de passerelle. Dans ce cas, les contrôles anti-usurpation d’identité sur les tunnels IP permettent de s’assurer que seules les sources légitimes injectent du trafic dans les centres de données à partir des tunnels IP qui leur ont été désignés.
Les tunnels IP dynamiques basés sur les sauts suivants créent un saut suivant composite pour chaque tunnel dynamique créé sur l’équipement. Étant donné que les tunnels dynamiques basés sur les sauts suivants suppriment la dépendance vis-à-vis des interfaces physiques pour chaque nouveau tunnel dynamique configuré, la configuration de tunnels dynamiques basés sur les sauts suivants offre un avantage d’évolutivité par rapport au nombre de tunnels dynamiques pouvant être créés sur un appareil. À partir de la version 17.1 de Junos OS, des fonctionnalités anti-usurpation sont prévues pour les tunnels dynamiques basés sur le saut suivant. Avec cette amélioration, une mesure de sécurité est mise en œuvre pour empêcher l’injection de trafic dans un VPN client arbitraire à partir d’un serveur compromis via le routeur de passerelle.
La lutte contre l’usurpation d’identité est mise en œuvre à l’aide de vérifications de transfert de chemin inverse dans le moteur de transfert de paquets. Les contrôles sont mis en œuvre pour le trafic entrant dans le tunnel vers l’instance de routage. Actuellement, lorsque le routeur de passerelle reçoit le trafic d’un tunnel, seule la recherche de destination est effectuée et le paquet est transféré en conséquence. Lorsque la protection contre l’usurpation d’identité est activée, le routeur de passerelle effectue également une recherche de l’adresse source de l’en-tête IP du paquet d’encapsulation dans le VPN, en plus de la recherche de la destination du tunnel. Cela permet de s’assurer que les sources légitimes injectent du trafic via les tunnels IP qu’elles ont désignés. Par conséquent, la protection contre l’usurpation d’identité garantit que le trafic provient d’une source légitime sur les tunnels désignés.
La figure 3 illustre un exemple de topologie avec les exigences en matière de protection contre l’usurpation d’identité.
Dans cet exemple, le routeur de passerelle est le routeur G. Le routeur G dispose de deux VPN : le vert et le bleu. Les deux serveurs, le serveur A et le serveur B, peuvent atteindre les VPN vert et bleu sur le routeur G via les tunnels dynamiques T1 et T2 basés sur le saut suivant, respectivement. Plusieurs hôtes et machines virtuelles (P, Q, R, S et T) connectés aux serveurs peuvent accéder aux VPN via le routeur de passerelle, le routeur G. Le routeur G contient les tables de routage et de transfert virtuels (VRF) pour les VPN verts et bleus, chacune remplie avec les informations d’accessibilité des machines virtuelles dans ces VPN.
Par exemple, dans VPN Green, le routeur G utilise le tunnel T1 pour atteindre l’hôte P, le tunnel T2 pour atteindre les hôtes R et S, et l’équilibrage de charge est effectué entre les tunnels T1 et T2 pour atteindre l’hôte multirésident Q. Dans VPN Blue, le routeur G utilise le tunnel T1 pour atteindre les hôtes P et R, et le tunnel T2 pour atteindre les hôtes Q et T.
Le contrôle passe pour le transfert de chemin inverse dans les cas suivants :
Un paquet provient d’une source légitime sur le tunnel qui lui a été désigné.
L’hôte P dans VPN Green envoie un paquet à l’hôte X en utilisant le tunnel T1. Étant donné que le routeur G peut atteindre l’hôte P via le tunnel T1, il autorise le passage du paquet et le transmet à l’hôte X.
Un paquet provient d’une source multirésidente sur ses tunnels désignés.
L’hôte Q dans VPN Green est multihébergé sur les serveurs A et B et peut atteindre le routeur G via les tunnels T1 et T2. L’hôte Q envoie un paquet à l’hôte Y en utilisant le tunnel T1 et un paquet à l’hôte X en utilisant le tunnel T2. Étant donné que le routeur G peut atteindre l’hôte Q via les tunnels T1 et T2, il permet aux paquets de passer et de les transmettre aux hôtes Y et X, respectivement.
La protection contre l’usurpation d’identité n’est pas activée par défaut sur les VPN de couche 3. Pour activer la protection contre l’usurpation d’identité dans les tunnels dynamiques basés sur les sauts suivants, incluez l’instruction ip-tunnel-rpf-check au niveau de la [edit routing-instances routing-instance-name routing-options forwarding-table] hiérarchie. La vérification du transfert de chemin inverse s’applique uniquement à l’instance de routage VRF. Le mode par défaut est défini sur strict, où le paquet provenant d’une source sur un tunnel non désigné ne passe pas la vérification. Le ip-tunnel-rpf-check mode peut être défini sur loose, où la vérification du transfert de chemin inverse échoue lorsque le paquet provient d’une source inexistante. Un filtre de pare-feu facultatif peut être configuré sous l’instruction ip-tunnel-rpf-check pour compter et consigner les paquets qui ont échoué à la vérification du transfert de chemin inverse.
L’exemple de sortie suivant montre une configuration anti-usurpation d’identité :
[edit routing-instances routing-instance-name routing-options forwarding-table]
ip-tunnel-rpf-check {
mode loose;
fail-filter filter-name;
}
Tenez compte des instructions suivantes lors de la configuration de la protection anti-usurpation d’identité pour les tunnels dynamiques basés sur le saut suivant :
La protection contre l’usurpation d’identité ne peut être activée que pour les tunnels IPv4 et le trafic de données IPv4. Les fonctionnalités anti-usurpation d’identité ne sont pas prises en charge sur les tunnels IPv6 et le trafic de données IPv6.
La protection contre l’usurpation d’identité des tunnels dynamiques basés sur les sauts suivants permet de détecter et d’empêcher la compromission d’une machine virtuelle (vérification du transfert de chemin inverse de la source interne), mais pas celle d’un serveur compromis victime d’usurpation d’étiquettes.
Les tunnels IP basés sur le saut suivant peuvent commencer et se terminer sur une table de routage inet.0.
La protection contre l’usurpation d’identité est efficace lorsque l’instance de routage VRF possède des interfaces à commutation d’étiquettes (LSI) (à l’aide de ) ou des
vrf-table-labelinterfaces de tunnel virtuel (VT). Avecper-next-hopl’étiquette sur l’instance de routage VRF, la protection contre l’usurpation d’identité n’est pas prise en charge.Le
rpf fail-filterne s’applique qu’au paquet IP interne.L’activation des vérifications anti-usurpation n’affecte pas la limite de mise à l’échelle des tunnels dynamiques basés sur le saut suivant sur un appareil.
L’utilisation des ressources système pour laquelle la protection anti-usurpation d’identité est activée pour l’instance de routage VRF est légèrement supérieure à l’utilisation de tunnels dynamiques basés sur le saut suivant sans la protection anti-usurpation d’identité activée.
La protection contre l’usurpation d’identité nécessite des vérifications supplémentaires des adresses IP sources, ce qui a un impact minimal sur les performances du réseau.
GRES (Graceful moteur de routage Switchover) et ISSU (In-Service Software Upgrade) sont protégés contre l’usurpation d’identité.
Exemple : configuration de la protection anti-usurpation d’identité pour les tunnels dynamiques basés sur les sauts suivants
Cet exemple montre comment configurer les vérifications de transfert de chemin inverse pour l’instance de routage VRF (Virtual Routing and Forwarding) afin d’activer la protection contre l’usurpation d’identité pour les tunnels dynamiques basés sur les sauts suivants. Les vérifications permettent de s’assurer que les sources légitimes injectent du trafic via les tunnels IP qui leur ont été désignés.
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
Trois routeurs MX Series avec MIC, chacun connecté à un équipement hôte.
Junos OS version 17.1 ou ultérieure s’exécutant sur un ou tous les routeurs.
Avant de commencer :
Activez la configuration des services de tunnel sur le concentrateur PIC flexible.
Configurez les interfaces du routeur.
Configurez l’ID de routeur et attribuez un numéro de système autonome au routeur.
Établissez une session BGP (IBGP) interne avec les points de terminaison du tunnel.
Configurez RSVP sur tous les routeurs.
Configurez OSPF ou tout autre protocole de passerelle intérieure sur tous les routeurs.
Configurez deux tunnels IP dynamiques basés sur le prochain saut entre les deux routeurs.
Configurez une instance de routage VRF pour chaque connexion routeur-hôte.
Aperçu
À partir de la version 17.1 de Junos OS, des fonctionnalités anti-usurpation sont ajoutées aux tunnels IP dynamiques basés sur le saut suivant, pour lesquelles des vérifications sont mises en œuvre pour le trafic provenant du tunnel vers l’instance de routage à l’aide du transfert de chemin inverse dans le moteur de transfert de paquets.
Actuellement, lorsque le routeur de passerelle reçoit le trafic d’un tunnel, seule la recherche de l’adresse de destination est effectuée avant le transfert. Grâce à la protection contre l’usurpation d’identité, le routeur de passerelle recherche l’adresse source de l’en-tête IP du paquet d’encapsulation dans le VPN pour s’assurer que les sources légitimes injectent du trafic via les tunnels IP désignés. C’est ce qu’on appelle le mode strict et c’est le comportement par défaut de la protection contre l’usurpation d’identité. Pour transmettre le trafic à partir de tunnels non désignés, la vérification du transfert de chemin inverse est activée en mode perdant. Pour le trafic reçu de sources inexistantes, la vérification du transfert de chemin inverse échoue pour les modes strict et lâche.
La protection contre l’usurpation d’identité est prise en charge sur les instances de routage VRF. Pour activer la protection contre l’usurpation d’identité dans les tunnels dynamiques, incluez l’instruction ip-tunnel-rpf-check au niveau de la [edit routing-instances routing-instance-name routing-options forwarding-table] hiérarchie.
Topologie
La figure 4 illustre un exemple de topologie de réseau dotée d’une protection contre l’usurpation d’identité. Les routeurs R0, R1 et R2 sont chacun connectés aux hôtes Host0, Host1 et Host2, respectivement. Deux tunnels dynamiques basés sur l’encapsulation de routage générique (GRE), le tunnel 1 et le tunnel 2, connectent respectivement le routeur R0 aux routeurs R1 et R2. L’instance de routage VRF est en cours d’exécution entre chaque routeur et ses équipements hôtes connectés.
Prenons l’exemple de trois paquets (paquets A, B et C) reçus sur le routeur 0 à partir du routeur R2 via le tunnel GRE dynamique basé sur le saut suivant (tunnel 2). Les adresses IP sources de ces paquets sont 172.17.0.2 (paquet A), 172.18.0.2 (paquet B) et 172.20.0.2 (paquet C).
L’adresse IP source des paquets A et B appartient respectivement à l’hôte 2 et à l’hôte 1. Le paquet C est un tunnel source inexistant. Dans cet exemple, le tunnel désigné est le tunnel 2 et le tunnel non désigné est le tunnel 1. Par conséquent, les paquets sont traités comme suit :
Packet A: la source provenant d’un tunnel désigné (tunnel 2), le paquet A passe le contrôle de transfert du chemin inverse et est traité pour être transféré via le tunnel 2.
Packet B: étant donné que la source provient du tunnel 1, qui est un tunnel non défini, par défaut, le paquet B échoue à la vérification du transfert de chemin inverse en mode strict. Si le mode lâche est activé, le paquet B est autorisé pour le transfert.
Packet C: la source étant une source de tunnel inexistante, le paquet C échoue à la vérification du transfert de chemin inverse et le paquet n’est pas transféré.
Configuration
Configuration rapide de la CLI
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 à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
Routeur R0
set interfaces ge-0/0/0 unit 0 family inet address 192.0.2.1/24 set interfaces ge-0/0/1 unit 0 family inet address 198.51.100.1/24 set interfaces ge-0/0/2 vlan-tagging set interfaces ge-0/0/2 unit 0 vlan-id 1 set interfaces ge-0/0/2 unit 0 family inet address 172.16.0.1/16 set interfaces lo0 unit 0 family inet address 10.1.1.1/32 set routing-options router-id 10.1.1.1 set routing-options autonomous-system 100 set routing-options dynamic-tunnels gre next-hop-based-tunnel set routing-options dynamic-tunnels T1 source-address 192.0.2.1 set routing-options dynamic-tunnels T1 gre set routing-options dynamic-tunnels T1 destination-networks 192.0.2.0/24 set routing-options dynamic-tunnels T2 source-address 198.51.100.1 set routing-options dynamic-tunnels T2 gre set routing-options dynamic-tunnels T2 destination-networks 198.51.100.0/24 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols bgp group IBGP type internal set protocols bgp group IBGP local-address 10.1.1.1 set protocols bgp group IBGP family inet-vpn unicast set protocols bgp group IBGP neighbor 20.1.1.1 set protocols bgp group IBGP neighbor 30.1.1.1 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface all set routing-instances VPN1 instance-type vrf set routing-instances VPN1 interface ge-0/0/2.0 set routing-instances VPN1 route-distinguisher 100:100 set routing-instances VPN1 vrf-target target:100:1 set routing-instances VPN1 vrf-table-label set routing-instances VPN1 routing-options forwarding-table ip-tunnel-rpf-check mode strict set routing-instances VPN1 protocols bgp group External type external set routing-instances VPN1 protocols bgp group External family inet unicast set routing-instances VPN1 protocols bgp group External peer-as 200 set routing-instances VPN1 protocols bgp group External neighbor 172.16.0.1
Routeur R1
set interfaces ge-0/0/0 unit 0 family inet address 192.0.2.2/24 set interfaces ge-0/0/1 vlan-tagging set interfaces ge-0/0/1 unit 0 vlan-id 2 set interfaces ge-0/0/1 unit 0 family inet address 172.18.0.1/16 set interfaces lo0 unit 0 family inet address 20.1.1.1/32 set routing-options router-id 20.1.1.1 set routing-options autonomous-system 100 set routing-options dynamic-tunnels gre next-hop-based-tunnel set routing-options dynamic-tunnels T1 source-address 192.0.2.2 set routing-options dynamic-tunnels T1 gre set routing-options dynamic-tunnels T1 destination-networks 192.0.2.0/24 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols bgp group IBGP type internal set protocols bgp group IBGP local-address 20.1.1.1 set protocols bgp group IBGP family inet-vpn unicast set protocols bgp group IBGP neighbor 30.1.1.1 set protocols bgp group IBGP neighbor 10.1.1.1 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface all set routing-instances VPN2 instance-type vrf set routing-instances VPN2 interface ge-0/0/1.0 set routing-instances VPN2 route-distinguisher 100:200 set routing-instances VPN2 vrf-target target:200:1 set routing-instances VPN2 vrf-table-label
R2
set interfaces ge-0/0/1 unit 0 family inet address 198.51.100.2/24 set interfaces ge-0/0/2 vlan-tagging set interfaces ge-0/0/2 unit 0 vlan-id 3 set interfaces ge-0/0/2 unit 0 family inet address 172.17.0.1/16 set interfaces lo0 unit 0 family inet address 30.1.1.1/32 set routing-options router-id 30.1.1.1 set routing-options autonomous-system 100 set routing-options dynamic-tunnels gre next-hop-based-tunnel set routing-options dynamic-tunnels T2 source-address 198.51.100.2 set routing-options dynamic-tunnels T2 gre set routing-options dynamic-tunnels T2 destination-networks 198.51.100.0/24 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols bgp group IBGP type internal set protocols bgp group IBGP local-address 30.1.1.1 set protocols bgp group IBGP family inet-vpn unicast set protocols bgp group IBGP neighbor 20.1.1.1 set protocols bgp group IBGP neighbor 10.1.1.1 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface all set routing-instances VPN3 instance-type vrf set routing-instances VPN3 interface ge-0/0/2.0 set routing-instances VPN3 route-distinguisher 100:300 set routing-instances VPN3 vrf-target target:300:1 set routing-instances VPN3 vrf-table-label
Procédure
Procédure étape par étape
L’exemple suivant nécessite que vous naviguiez à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, reportez-vous à la section Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.
Pour configurer le routeur R0 :
Configurez les interfaces du routeur R0, y compris l’interface de bouclage.
[edit interfaces] user@R0# set ge-0/0/0 unit 0 family inet address 192.0.2.1/24 user@R0# set ge-0/0/1 unit 0 family inet address 198.51.100.1/24 user@R0# set ge-0/0/2 vlan-tagging user@R0# set ge-0/0/2 unit 0 vlan-id 1 user@R0# set ge-0/0/2 unit 0 family inet address 172.16.0.1/16 user@R0# set lo0 unit 0 family inet address 10.1.1.1/32
Attribuez l’ID de routeur et le numéro de système autonome au routeur R0.
[edit routing-options] user@R0# set router-id 10.1.1.1 user@R0# set autonomous-system 100
Configurez l’appairage IBGP entre les routeurs.
[edit protocols] user@R0# set bgp group IBGP type internal user@R0# set bgp group IBGP local-address 10.1.1.1 user@R0# set bgp group IBGP family inet-vpn unicast user@R0# set bgp group IBGP neighbor 20.1.1.1 user@R0# set bgp group IBGP neighbor 30.1.1.1
Configurez OSPF sur toutes les interfaces du routeur R0, à l’exception de l’interface de gestion.
[edit protocols] user@R0# set ospf traffic-engineering user@R0# set ospf area 0.0.0.0 interface lo0.0 passive user@R0# set ospf area 0.0.0.0 interface all
Configurez RSVP sur toutes les interfaces du routeur R0, à l’exception de l’interface de gestion.
[edit protocols] user@R0# set rsvp interface all user@R0# set rsvp interface fxp0.0 disable
Activez la configuration dynamique du tunnel GRE basée sur le saut suivant sur le routeur R0.
[edit routing-options] user@R0# set dynamic-tunnels gre next-hop-based-tunnel
Configurez les paramètres dynamiques du tunnel GRE du routeur R0 au routeur R1.
[edit routing-options] user@R0# set dynamic-tunnels T1 source-address 192.0.2.1 user@R0# set dynamic-tunnels T1 gre user@R0# set dynamic-tunnels T1 destination-networks 192.0.2.0/24
Configurez les paramètres dynamiques du tunnel GRE du routeur R0 au routeur R2.
[edit routing-options] user@R0# set dynamic-tunnels T2 source-address 198.51.100.1 user@R0# set dynamic-tunnels T2 gre user@R0# set dynamic-tunnels T2 destination-networks 198.51.100.0/24
Configurez une instance de routage VRF (Virtual Routing and Forwarding) sur le routeur R0 et affectez l’interface se connectant à l’hôte 1 à l’instance VRF.
[edit routing-instances] user@R0# set VPN1 instance-type vrf user@R0# set VPN1 route-distinguisher 100:100 user@R0# set VPN1 vrf-target target:100:1 user@R0# set VPN1 vrf-table-label user@R0# set VPN1 interface ge-0/0/2.0
Configurez une session BGP externe avec l’hôte 1 pour l’instance de routage VRF.
[edit routing-instances] user@R0# set VPN1 protocols bgp group External type external user@R0# set VPN1 protocols bgp group External family inet unicast user@R0# set VPN1 protocols bgp group External peer-as 200 user@R0# set VPN1 protocols bgp group External neighbor 172.16.0.1
Configurez la protection anti-usurpation d’identité pour l’instance de routage VRF sur le routeur R0. Cela permet de vérifier le transfert de chemin inverse pour les tunnels dynamiques basés sur le saut suivant, T1 et T2, sur le routeur 0.
[edit routing-instances] user@R0# set VPN1 routing-options forwarding-table ip-tunnel-rpf-check mode strict
Résultats
À partir du mode configuration, confirmez votre configuration en entrant les show interfacescommandes , show routing-options, show protocolset show 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@R0# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 192.0.2.1/24;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 198.51.100.1/24;
}
}
}
ge-0/0/2 {
vlan-tagging;
unit 0 {
vlan-id 1;
family inet {
address 172.16.0.1/16;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.1.1.1/32;
}
}
}
user@R0# show routing-options
router-id 10.1.1.1;
autonomous-system 100;
dynamic-tunnels {
gre next-hop-based-tunnel;
T1 {
source-address 192.0.2.1;
gre;
destination-networks {
192.0.2.0/24;
}
}
T2 {
source-address 198.51.100.1;
gre;
destination-networks {
198.51.100.0/24;
}
}
}
user@R0# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
bgp {
group IBGP {
type internal;
local-address 10.1.1.1;
family inet-vpn {
unicast;
}
neighbor 20.1.1.1;
neighbor 30.1.1.1;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface all;
}
}
user@R0# show routing-instances
VPN1 {
instance-type vrf;
interface ge-0/0/2.0;
route-distinguisher 100:100;
vrf-target target:100:1;
vrf-table-label;
routing-options {
forwarding-table {
ip-tunnel-rpf-check {
mode strict;
}
}
}
protocols {
bgp {
group External {
type external;
family inet {
unicast;
}
peer-as 200;
neighbor 172.16.0.1;
}
}
}
}
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de la configuration de base
- Vérification de la configuration dynamique du tunnel
- Vérification de la configuration de la protection contre l’usurpation d’identité
Vérification de la configuration de base
But
Vérifiez l’état d’appairage OSPF et BGP entre le routeur R0 et les routeurs R1 et R2.
Action
À partir du mode opérationnel, exécutez les show ospf neighbor commandes and show bgp summary.
user@R0> show ospf neighbor
Address Interface State ID Pri Dead
192.0.2.2 ge-0/0/0.0 Full 20.1.1.1 128 32
198.51.100.2 ge-0/0/1.0 Full 30.1.1.1 128 32
user@R0> show bgp summary
Groups: 2 Peers: 3 Down peers: 1
Table Tot Paths Act Paths Suppressed History Damp State Pending
bgp.l3vpn.0
0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
20.1.1.1 100 182 178 0 0 1:20:27 Establ
bgp.l3vpn.0: 0/0/0/0
30.1.1.1 100 230 225 0 0 1:41:51 Establ
bgp.l3vpn.0: 0/0/0/0
172.16.0.1 200 0 0 0 0 1:42:08 Establ
Signification
Les sessions OSPF et BGP sont opérationnelles entre les routeurs R0, R1 et R2.
Vérification de la configuration dynamique du tunnel
But
Vérifiez l’état des tunnels GRE dynamiques basés sur le saut suivant entre le routeur R0 et les routeurs R1 et R2.
Action
À partir du mode opérationnel, exécutez les show route table inet.3commandes , puis .show dynamic-tunnels database terse
user@R0> show route table inet.3
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.0/24 *[Tunnel/300] 01:47:57
Tunnel
192.0.2.2/24 *[Tunnel/300] 01:47:57
Tunnel Composite
198.51.100.0/24 *[Tunnel/300] 01:47:57
Tunnel
198.51.100.2/24 *[Tunnel/300] 01:47:57
Tunnel Composite
user@R0> show dynamic-tunnels database terse Table: inet.3 Destination-network: 192.0.2.0/24 Destination Source Next-hop Type Status 192.0.2.2/24 192.0.2.1 0xb395e70 nhid 612 gre Up Destination-network: 198.51.100.0/24 Destination Source Next-hop Type Status 198.51.100.2 198.51.100.1 0xb395e70 nhid 612 gre Up
Signification
Les deux tunnels GRE dynamiques basés sur le saut suivant, le tunnel 1 et le tunnel 2, sont opérationnels.
Vérification de la configuration de la protection contre l’usurpation d’identité
But
Vérifiez que la vérification du transfert de chemin inverse a été activée sur l’instance de routage VRF sur le routeur R0.
Action
À partir du mode opérationnel, exécutez la show krt table VPN1.inet.0 detailcommande .
user@R0> show krt table VPN1.inet.0 detail
KRT tables:
VPN1.inet.0 : GF: 1 krt-index: 8 ID: 0 kernel-id: 8
flags: (null)
tunnel rpf config data : enable, strict, filter [0], 0x2
tunnel rpf tlv data : enable, strict, filter [0], 0x4
unicast reverse path: disabled
fast-reroute-priority: 0
Permanent NextHops
Multicast : 0 Broadcast : 0
Receive : 0 Discard : 0
Multicast Discard: 0 Reject : 0
Local : 0 Deny : 0
Table : 0
Signification
La vérification configurée du transfert de chemin inverse est activée sur l’instance de routage VRF en mode strict.
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.