Tunnels basés sur le saut suivant 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-over-UDP dynamique pour prendre en charge le prochain saut composite de tunnel. Il fournit également des informations sur la configuration du transfert de chemin inversé pour se protéger contre l’usurpation d’identité.
Exemple : configuration de tunnels GRE dynamiques basés sur le saut suivant
Cet exemple montre comment configurer un tunnel GRE (Generic Routing Encapsulation) 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 périphérique, y compris l’interface de bouclage.
-
Configurez l’ID du routeur et le numéro de système autonome de l’appareil.
Établissez une session BGP interne (IBGP) avec le périphérique PE distant.
Établissez un appairage OSPF entre les appareils.
Aperçu
À partir de Junos OS version 16.2, un tunnel GRE (Generic Routing Encapsulation) dynamique prend en charge la création d’un prochain saut composite de tunnel 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 une interface et c’est le mode par défaut pour la création de tunnels dynamiques. Sur un tunnel dynamique basé sur une interface, le nombre de tunnels pouvant être configurés sur un périphérique dépend du nombre total d’interfaces prises en charge sur le périphérique. Le tunnel GRE dynamique basé sur le saut suivant supprime la dépendance aux 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 de mise à l’échelle pour le nombre de tunnels dynamiques qui peuvent être créés sur un appareil.
À partir de Junos OS version 17.1, sur les routeurs MX Series équipés de MPC et de MIC, la limite d’évolutivité des tunnels GRE dynamiques basés sur le saut suivant est augmentée. L’augmentation des valeurs de mise à l’échelle profite aux réseaux de centres de données, où un routeur de passerelle est nécessaire pour communiquer avec un certain nombre de serveurs sur une infrastructure IP ; par exemple dans Contrail Networking.
À un moment donné, le tunnel dynamique basé sur le saut suivant ou le tunnel GRE dynamique basé sur l’interface par défaut peut exister sur un périphérique. 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 moment 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 fonction de tunnel dynamique existante nécessite une configuration statique complète. Actuellement, les informations de tunnel reçues des appareils homologues dans les itinéraires annoncés sont ignorées. À partir de Junos OS version 17.4R1, 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 est utilisée pour spécifier les types de tunnel, publier les informations de tunnel côté expéditeur, 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çue.
Les encapsulations de tunnels multiples sont prises en charge par BGP. Lors de la réception de plusieurs capacités, le tunnel dynamique basé sur le saut suivant est créé en fonction de la stratégie BGP configurée et des préférences de tunnel. La préférence de tunnel doit être cohérente entre les deux extrémités du tunnel pour que le tunnel soit mis en place. Par défaut, le tunnel MPLS-over-UDP (MPLSoUDP) est préféré aux tunnels GRE. Si une configuration de tunnel dynamique existe, elle est prioritaire sur la communauté de tunnel reçue.
Lorsque vous configurez 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 du saut suivant 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 des tunnels IP pris 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.
La création dynamique de tunnels GRE basée sur de nouveaux sauts suivants IPv6 mappés IPv4 est prise en charge avec cette fonctionnalité.
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 de 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écouverte de l’unité de transmission maximale de chemin
Caractéristique clé GRE
Exploitation, administration et maintenance GRE (OAM) pour les messages persistants GRE.
Topologie
La figure 1 illustre un scénario VPN de couche 3 sur des tunnels GRE dynamiques. Les équipements de périphérie client (CE), CE1 et CE2, se connectent aux équipements de périphérie du fournisseur (PE), PE1 et PE2, respectivement. Les périphériques PE sont connectés à un périphérique fournisseur (périphérique P1) et une session BGP interne (IBGP) interconnecte les deux périphériques PE. Deux tunnels GRE dynamiques sont configurés entre les équipements PE. Le tunnel dynamique entre le périphérique PE1 et le périphérique PE2 est basé sur le mode tunnel du saut suivant, et le tunnel dynamique entre le périphérique PE2 et le périphérique 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 tunnel CNH est créé pour les sauts suivants de protocole dans la table de routage inet.3. Cette route de tunnel IP est retirée uniquement lorsque la configuration de tunnel dynamique est supprimée.
Les attributs CNH du tunnel sont les suivants :
-
Lorsque le CNH VPN de couche 3 est désactivé : adresse source/destination, chaîne d’encapsulation et étiquette VPN.
-
Lorsque l’allocation d’étiquettes VPN CNH et VPN par préfixe de couche 3 est activée : adresse source, adresse de destination et chaîne d’encapsulation.
-
Lorsque le CNH VPN de couche 3 est activé et que l’allocation d’étiquettes VPN par préfixe est désactivée : adresse source, adresse de destination et chaîne d’encapsulation. Dans ce cas, l’itinéraire est ajouté à l’autre table d’instance de routage et de transfert virtuel avec un itinéraire secondaire.
-
-
Les périphériques PE sont interconnectés à l’aide d’une session IBGP. Le tronçon suivant IBGP vers un voisin BGP distant est le protocole suivant hop, 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 tunnel composite saut suivant, des sauts suivants indirects avec transfert des sauts suivants sont créés.
-
Le tunnel CNH est utilisé pour transférer les sauts suivants des sauts suivants indirects.
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 à la configuration de votre réseau, copiez et collez-les dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit du 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, voir Utilisation de l’éditeur CLI en mode Configuration du Guide de l’utilisateur de l’interface de ligne de commande.
Pour configurer Device PE1 :
Configurez les interfaces de périphérique, 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 du périphérique PE1 avec l’appareil 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 du routeur et le numéro de système autonome pour le périphérique 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 périphériques 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 Device 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 de tunnel GRE dynamique basée sur le saut suivant sur le périphérique PE1.
[edit routing-options] user@PE1# set dynamic-tunnels gre next-hop-based-tunnel
Configurez les paramètres de tunnel GRE dynamique du périphérique PE1 vers le périphérique 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 le périphérique 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 le périphérique 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 de configuration, confirmez votre configuration en entrant les show interfacescommandes , , show routing-optionsshow protocolset show routing-instances . Si la sortie n’affiche pas la configuration voulue, 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, entrez commit à partir du mode de configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de la connexion entre les périphériques PE
- Vérifier les routes de tunnel dynamiques sur l’équipement PE1
- Vérifier les itinéraires dynamiques du tunnel sur l’équipement PE2
- Vérification que les itinéraires ont l’indicateur de saut suivant indirect attendu
Vérification de la connexion entre les périphériques PE
But
Vérifiez l’état de l’appairage BGP entre le périphérique PE1 et le périphérique PE2, ainsi que les routes BGP reçues du périphérique PE2.
Action
À partir du mode opérationnel, exécutez les show bgp summary commandes et 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
Sens
Dans la première sortie, l’état de session BGP est , ce qui signifie que la session est
Establterminée et que les périphériques PE sont appairés.Dans la deuxième sortie, le périphérique PE1 a appris deux routes BGP à partir du périphérique PE2.
Vérifier les routes de tunnel dynamiques sur l’équipement PE1
But
Vérifiez les itinéraires dans la table de routage inet.3 et les informations de la base de données de tunnel dynamique sur le périphérique PE1.
Action
À partir du mode opérationnel, exécutez les show route table inet.3 commandes et 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
Sens
Dans la première sortie, étant donné que le périphérique PE1 est configuré avec le tunnel GRE dynamique basé sur le saut suivant, un itinéraire composite de tunnel est créé pour l’entrée de route de la table de routage inet.3.
Dans la deuxième sortie, le tunnel GRE dynamique créé entre le périphérique PE1 et le périphérique 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 dynamiques du tunnel sur l’équipement PE2
But
Vérifiez les itinéraires dans la table de routage inet.3 et les informations de la base de données de tunnel dynamique sur le périphérique PE2.
Action
À partir du mode opérationnel, exécutez les show route table inet.3 commandes et 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
Sens
Dans la première sortie, étant donné que le périphérique 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 le périphérique PE2 et le périphérique PE1 est actif et le nom d’interface nouvellement créé lui est attribué.
Vérification que les itinéraires ont l’indicateur de saut suivant indirect attendu
But
Vérifiez que Device PE1 et Device PE2 sont configurés pour maintenir la liaison du saut suivant indirect au transfert sur la table de transfert du moteur de transfert de paquets.
Action
En mode opérationnel, exécutez la show krt indirect-next-hop commande sur Device PE1 et Device 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
Sens
Dans la première sortie, le périphérique PE1 dispose d’un tunnel GRE dynamique basé sur le saut suivant vers le périphérique 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, voir :
Commandes de dépannage
Problème
La configuration de tunnel GRE dynamique basée sur le saut suivant ne prend pas effet.
Solution
Pour dépanner la configuration du tunnel GRE basé sur le saut suivant, utilisez les commandes suivantes traceoptions au niveau de la hiérarchie des [edit routing-options dynamic-tunnels] instructions :
traceoptions file file-nametraceoptions file size file-sizetraceoptions 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-over-UDP basés sur le saut suivant
Cet exemple montre comment configurer un tunnel MPLS-over-UDP dynamique qui inclut un prochain saut composite de tunnel. La fonctionnalité MPLS-over-UDP offre un avantage d’évolutivité sur le nombre de tunnels IP pris en charge sur un appareil.
À partir de Junos OS version 18.3R1, 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 prochain saut composite de tunnel, un saut suivant indirect et un saut suivant de transfert sont créés pour résoudre la route de destination du tunnel. Vous pouvez également utiliser le contrôle de stratégie pour résoudre le tunnel dynamique sur des préfixes sélectionnés 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 PE (Provider Edge).
Avant de commencer :
-
Configurez les interfaces de périphérique, y compris l’interface de bouclage.
-
Configurez l’ID du routeur et le numéro de système automatique de l’appareil.
-
Établissez une session BGP interne (IBGP) avec le périphérique PE distant.
-
Établissez un appairage OSPF entre les appareils.
Aperçu
À partir de Junos OS version 16.2, un tunnel UDP dynamique prend en charge la création d’un tunnel composite suivant pour chaque tunnel UDP configuré. Ces tunnels UDP dynamiques basés sur le saut suivant sont appelés tunnels MPLS-over-UDP. Les tunnels composites suivant sont activés par défaut pour les tunnels MPLS-over-UDP.
Les tunnels MPLS sur UDP peuvent être bidirectionnels ou unidirectionnels.
-
Bidirectionnel : lorsque les équipements PE sont connectés via des tunnels MPLS-over-UDP dans les deux sens, on parle de tunnel MPLS-over-UDP bidirectionnel.
-
Unidirectionnel : lorsque deux équipements PE sont connectés sur un tunnel MPLS-over-UDP dans un sens et sur MPLS/IGP dans l’autre sens, on parle de tunnel MPLS-over-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 fournissent une connectivité l’un à l’autre sur deux réseaux disjoints. Étant donné qu’il n’existe pas de tunnel MPLS-over-UDP unidirectionnel, vous devez configurer une décapsulation MPLS-over-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 QFX10000 avec des tunnels MPLS-over-UDP unidirectionnels, vous devez configurer le périphérique PE distant avec un filtre d’entrée pour les paquets MPLS-over-UDP et une action pour décapsuler les en-têtes IP et UDP pour transférer les paquets dans le sens inverse du tunnel.
Par exemple, sur le périphérique PE distant, le périphérique PE2, la configuration suivante est requise pour les tunnels MPLS-over-UDP unidirectionnels :
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-over-UDP. Le terme udp_decap désigne le filtre d’entrée permettant d’accepter des paquets UDP sur l’interface orientée cœur du périphérique PE2, puis de décaprimer les paquets MPLS sur UDP vers des paquets MPLS over IP pour transfert.
Vous pouvez utiliser les commandes existantes du mode de fonctionnement du pare-feu, par exemple show firewall filter pour afficher la décapsulation MPLS-over-UDP basée sur des 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-over-UDP unidirectionnels :
-
Seule l’adresse IPv4 est prise en charge comme en-tête externe. La décapsulation MPLS-over-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 Junos OS version 17.1, sur les routeurs MX Series équipés de MPC et de MIC, la limite d’évolutivité des tunnels MPLS sur UDP est augmentée.
À partir de Junos version 19.2R1, sur les routeurs MX Series équipés de MPC et de MIC, l'architecture CSC (carrier support) de l'opérateur peut être déployée avec des tunnels MPLS sur UDP transportant le trafic MPLS sur des tunnels UDP IPv4 dynamiques établis entre les équipements PE de l'opérateur. Grâce à cette amélioration, l’avantage d’évolutivité fourni par les tunnels MPLS sur UDP est encore accru. La prise en charge CSC avec le tunnel MPLS-over-UDP n’est pas prise en charge pour le tunnel IPv6 UDP.
La fonction de tunnel dynamique existante nécessite une configuration statique complète. Actuellement, les informations de tunnel reçues des appareils homologues dans les itinéraires annoncés sont ignorées. À partir de Junos OS version 17.4R1, sur les routeurs MX Series, les tunnels MPLS-over-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 est utilisée pour spécifier les types de tunnel, publier les informations de tunnel côté expéditeur, 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çue.
Les encapsulations de tunnels multiples sont prises en charge par BGP. Lors de la réception de plusieurs capacités, le tunnel dynamique basé sur le saut suivant est créé en fonction de la stratégie BGP configurée et des préférences de tunnel. La préférence de tunnel doit être cohérente entre les deux extrémités du tunnel pour que le tunnel soit mis en place. Par défaut, le tunnel MPLS-over-UDP est préféré aux tunnels GRE. Si une configuration de tunnel dynamique existe, elle est prioritaire sur la communauté de tunnel reçue.
Lorsque vous configurez un tunnel MPLS-over-UDP dynamique basé sur le saut suivant, tenez compte des considérations suivantes :
-
Une session IBGP doit être configurée entre les périphériques 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 des tunnels IP pris en charge dans chaque mode.
-
Le fait d’avoir à la fois des types d’encapsulation de tunnel dynamique GRE et UDP basés sur le saut suivant pour la même destination de tunnel entraîne un échec de validation.
-
Pour les tunnels MPLS-over-UDP unidirectionnels, vous devez configurer explicitement la décapsulation MPLS-over-UDP basée sur des filtres sur le périphérique PE distant pour que les paquets soient transférés.
-
Le basculement GRES (Graceful Routing Engine Switchover) est pris en charge avec MPLS-over-UDP, et les indicateurs de type tunnel MPLS-over-UDP sont compatibles ISSU et NSR unifiés.
-
Les tunnels MPLS-over-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 basés sur les nouveaux sauts suivants IPv6 mappés IPv4.
-
Les tunnels MPLS-over-UDP sont pris en charge en interopérabilité avec contrail, dans lequel les tunnels MPLS-over-UDP sont créés à partir du contrail vRouter vers une passerelle MX. Pour ce faire, la communauté suivante doit être annoncée sur le trajet entre le routeur MX Series et le vRouter contrail :
[edit policy-options community] udp members 0x030c:64512:13;
À un moment donné, un seul type de tunnel est pris en charge sur la contrail vRouter : tunnels GRE dynamiques basés sur le saut suivant, tunnels MPLS sur UDP ou VXLAN.
-
Les fonctionnalités suivantes ne sont pas prises en charge avec la configuration de tunnel MPLS-over-UDP dynamique basée sur le saut suivant :
-
Maillage automatique RSVP
-
Configuration de tunnel GRE et UDP IPV6 simple
-
Systèmes logiques
-
Topologie
La figure 2 illustre un scénario VPN de couche 3 sur des tunnels MPLS-over-UDP dynamiques. Les équipements de périphérie client (CE), CE1 et CE2, se connectent aux équipements de périphérie du fournisseur (PE), PE1 et PE2, respectivement. Les périphériques PE sont connectés à un périphérique fournisseur (périphérique P1) et une session BGP interne (IBGP) interconnecte les deux périphériques PE. Un tunnel MPL-over-UDP bidirectionnel dynamique basé sur le saut suivant est configuré entre les équipements PE.
Le tunnel MPLS-over-UDP est géré comme suit :
-
Une fois qu’un tunnel MPLS-over-UDP est configuré, une route de masque de destination de tunnel avec un saut suivant composite de tunnel est créée pour le tunnel dans la table de routage inet.3. Cette route de tunnel IP est retirée uniquement lorsque la configuration de tunnel dynamique est supprimée.
Les attributs du saut suivant composite du tunnel sont les suivants :
-
Lorsque le prochain saut composite VPN de couche 3 est désactivé : adresse source et de destination, chaîne d’encapsulation et étiquette VPN.
-
Lorsque l’allocation d’étiquettes VPN composite de couche 3 est activée : adresse source, adresse de destination et chaîne d’encapsulation.
-
Lorsque le saut suivant composite VPN de couche 3 est activé et que l’allocation d’étiquettes VPN par préfixe est désactivée : adresse source, adresse de destination et chaîne d’encapsulation. Dans ce cas, l’itinéraire est ajouté à l’autre table d’instance de routage et de transfert virtuel avec un itinéraire secondaire.
-
-
Les périphériques PE sont interconnectés à l’aide d’une session IBGP. Le tronçon suivant IBGP vers un voisin BGP distant est le protocole suivant hop, qui est résolu à l’aide de la route de masque de tunnel avec le saut suivant du tunnel.
-
Une fois le prochain saut du protocole résolu sur le tunnel composite saut suivant, des sauts suivants indirects avec transfert des sauts suivants sont créés.
-
Le saut suivant composite tunnel est utilisé pour transférer les sauts suivants des sauts suivants indirects.
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 à la configuration de votre réseau, copiez et collez-les dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit du 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, voir Utilisation de l’éditeur CLI en mode Configuration du Guide de l’utilisateur de l’interface de ligne de commande.
Pour configurer Device PE1 :
-
Configurez les interfaces de périphérique, 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 du périphérique PE1 avec l’appareil 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 le périphérique 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-over-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 inet-import 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 périphériques 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 Device 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 de tunnel GRE dynamique basée sur le saut suivant sur le périphérique 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-over-UDP.
[edit routing-options] user@PE1# set dynamic-tunnels gre next-hop-based-tunnel
-
Configurez les paramètres du tunnel MPLS-over-UDP du périphérique PE1 au périphérique 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 le périphérique 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 le périphérique 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 de configuration, confirmez votre configuration en entrant les show interfacescommandes , , show routing-optionsshow protocolset show routing-instances . Si la sortie n’affiche pas la configuration voulue, 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, entrez commit à partir du mode de configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de la connexion entre les périphériques PE
- Vérifier les routes de tunnel dynamiques sur l’équipement PE1
- Vérifier les itinéraires dynamiques du tunnel sur l’équipement PE2
- Vérification que les itinéraires ont l’indicateur de saut suivant indirect attendu
Vérification de la connexion entre les périphériques PE
But
Vérifiez l’état de l’appairage BGP entre le périphérique PE1 et le périphérique PE2, ainsi que les routes BGP reçues du périphérique PE2.
Action
À partir du mode opérationnel, exécutez les show bgp summary commandes et 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
Sens
-
Dans la première sortie, l’état de session BGP est , ce qui signifie que la session est
Establterminée et que les périphériques PE sont appairés. -
Dans la deuxième sortie, le périphérique PE1 a appris une route BGP à partir du périphérique PE2.
Vérifier les routes de tunnel dynamiques sur l’équipement PE1
But
Vérifiez les itinéraires dans la table de routage inet.3 et les informations de la base de données de tunnel dynamique sur le périphérique 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
Sens
-
Dans la première sortie, étant donné que le périphérique PE1 est configuré avec le tunnel MPLS-over-UDP, une route composite de tunnel est créée pour l’entrée de route de la table de routage inet.3.
-
Dans les sorties restantes, le tunnel MPLS-over-UDP est affiché avec le type d’encapsulation du tunnel, les paramètres du saut suivant du tunnel et l’état du tunnel.
Vérifier les itinéraires dynamiques du tunnel sur l’équipement PE2
But
Vérifiez les itinéraires dans la table de routage inet.3 et les informations de la base de données de tunnel dynamique sur le périphérique PE2.
Action
À partir du mode opérationnel, exécutez les commandes , et les show route table inet.3show dynamic-tunnels database terse commandes.
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
Sens
Les sorties indiquent la création du tunnel MPLS-over-UDP et l’ID du saut suivant affecté comme interface de saut suivant, similaire à Device PE1.
Vérification que les itinéraires ont l’indicateur de saut suivant indirect attendu
But
Vérifiez que Device PE1 et Device PE2 sont configurés pour maintenir la liaison du saut suivant indirect au transfert sur la table de transfert du moteur de transfert de paquets.
Action
En mode opérationnel, exécutez la show krt indirect-next-hop commande sur Device PE1 et Device 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
Sens
Les résultats montrent qu’un tunnel MPLS-over-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, voir :
Commandes de dépannage
Problème
La configuration de tunnel MPLS-over-UDP dynamique basée sur le saut suivant ne prend pas effet.
Solution
Pour dépanner la configuration du tunnel MPLS-over-UDP basé sur le saut suivant, utilisez les commandes suivantes traceroute au niveau de 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;
}
Vue d’ensemble de la protection anti-usurpation pour les tunnels dynamiques basés sur le saut suivant
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 est l’injection de trafic dans un VPN client arbitraire à partir d’un serveur compromis via le routeur de passerelle. Dans de tels cas, les contrôles anti-usurpation d’identité sur les tunnels IP garantissent que seules les sources légitimes injectent du trafic dans les centres de données à partir de leurs tunnels IP désignés.
Les tunnels IP dynamiques basés sur le saut suivant créent un tunnel composite suivant pour chaque tunnel dynamique créé sur l’appareil. Étant donné que les tunnels dynamiques basés sur le saut suivant suppriment la dépendance aux interfaces physiques pour chaque nouveau tunnel dynamique configuré, la configuration des tunnels dynamiques basés sur le saut suivant offre un avantage de mise à l’échelle par rapport au nombre de tunnels dynamiques pouvant être créés sur un périphérique. À partir de Junos OS version 17.1, des capacités anti-usurpation d’identité pour les tunnels IP dynamiques basés sur le saut suivant sont fournies pour les tunnels dynamiques basés sur le saut suivant. Grâce à 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.
L’anti-usurpation est implémentée à l’aide de contrôles de transfert de chemin inverse dans le moteur de transfert de paquets. Les contrôles sont mis en œuvre pour le trafic passant par le tunnel jusqu’à l’instance de routage. Actuellement, lorsque le routeur de passerelle reçoit du trafic d’un tunnel, seule la destination est recherchée et le paquet est transféré en conséquence. Lorsque la protection anti-usurpation est activée, le routeur de passerelle effectue également une recherche d’adresse source de l’en-tête IP du paquet d’encapsulation dans le VPN, en plus de la recherche de destination du tunnel. Cela garantit que les sources légitimes injectent du trafic via leurs tunnels IP désignés. Par conséquent, la protection anti-usurpation garantit que le trafic du tunnel provient d’une source légitime sur les tunnels désignés.
La figure 3 illustre un exemple de topologie avec les exigences de protection anti-usurpation d’identité.
Dans cet exemple, le routeur de passerelle est le routeur G. Le routeur G dispose de deux VPN : vert et bleu. Les deux serveurs, le serveur A et le serveur B, peuvent accéder aux 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 VRF (Virtual Routing and Forwarding) pour les VPN verts et bleus, chacune contenant 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.
La vérification réussit pour le transfert de chemin inversé lorsque :
Un paquet provient d’une source légitime sur son tunnel 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 permet au paquet de passer et de le transmettre à 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 multirésident 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 anti-usurpation d’identité des VPN de couche 3 n’est pas activée par défaut. Pour activer l’anti-usurpation des tunnels dynamiques basés sur le saut suivant, 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 est appliquée à l’instance de routage VRF uniquement. Le mode par défaut est défini sur , où le paquet provenant d’une source sur strictun tunnel non désigné ne réussit pas la vérification. Le ip-tunnel-rpf-check mode peut être défini sur loose, où la vérification du transfert du 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 du 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 pour les tunnels dynamiques basés sur le saut suivant :
La protection anti-usurpation d’identité ne peut être activée que pour les tunnels IPv4 et le trafic de données IPv4. Les capacités anti-usurpation ne sont pas prises en charge sur les tunnels IPv6 et le trafic de données IPv6.
L’anti-usurpation pour les tunnels dynamiques basés sur le saut suivant permet de détecter et d’empêcher une machine virtuelle compromise (vérification du chemin inverse de la source interne), mais pas un serveur compromis qui usurpe des étiquettes.
Les tunnels IP basés sur le saut suivant peuvent prendre naissance et se terminer sur une table de routage inet.0.
La protection anti-usurpation d’identité est efficace lorsque l’instance de routage VRF possède des interfaces de commutation d’étiquettes (LSI) (à l’aide des interfaces )
vrf-table-labelou de tunnel virtuel (VT). Avecper-next-hopl’étiquette sur l’instance de routage VRF, la protection anti-usurpation n’est pas prise en charge.Le s’applique
rpf fail-filteruniquement au paquet IP interne.L’activation des contrôles 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 avec la protection anti-usurpation activée pour l’instance de routage VRF est légèrement supérieure à l’utilisation des tunnels dynamiques basés sur le saut suivant sans la protection anti-usurpation activée.
La protection anti-usurpation d’identité nécessite des vérifications supplémentaires de l’adresse IP source, ce qui a un impact minimal sur les performances du réseau.
Le basculement GRES (Graceful Routing Engine Switchover) et la mise à niveau logicielle en service (ISSU) sont pris en charge avec une protection anti-usurpation.
Exemple : configuration de la protection anti-usurpation d’identité pour les tunnels dynamiques basés sur le saut suivant
Cet exemple montre comment configurer les contrôles de transfert de chemin inverse pour l’instance de routage et transfert virtuel (VRF) afin d’activer la protection anti-usurpation des tunnels dynamiques basés sur le saut suivant. Les vérifications permettent de s’assurer que les sources légitimes injectent du trafic via leurs tunnels IP 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écute 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 du routeur et attribuez un numéro de système autonome au routeur.
Établissez une session BGP interne (IBGP) 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 saut suivant entre les deux routeurs.
Configurez une instance de routage VRF pour chaque connexion routeur-hôte.
Aperçu
À partir de Junos OS version 17.1, des capacités anti-usurpation sont ajoutées aux tunnels IP dynamiques basés sur le saut suivant, où des contrôles sont mis en œuvre pour le trafic passant par le 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 du trafic d’un tunnel, seule la recherche d’adresse de destination est effectuée avant le transfert. Avec la protection anti-usurpation d’identité, le routeur de passerelle effectue une recherche d’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 leurs 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 anti-usurpation d’identité. Pour transmettre le trafic provenant de tunnels non désignés, la vérification du transfert de chemin inverse est activée en mode perdant. Pour le trafic provenant de sources inexistantes, la vérification du transfert de chemin inverse échoue pour les modes strict et lâche.
L’anti-usurpation d’identité est pris en charge sur les instances de routage VRF. Pour activer l’anti-usurpation des 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 anti-usurpation d’identité. Les routeurs R0, R1 et R2 sont chacun connectés aux hôtes Host0, Host1 et Host2, respectivement. Deux tunnels dynamiques génériques basés sur le saut suivant basé sur l’encapsulation de routage (GRE), le tunnel 1 et le tunnel 2, connectent le routeur R0 aux routeurs R1 et R2, respectivement. L’instance de routage VRF s’exécute entre chaque routeur et ses périphériques hôtes connectés.
Par exemple, trois paquets (paquets A, B et C) sont reçus sur le routeur 0 du routeur R2 via le tunnel GRE dynamique basé sur le saut suivant (tunnel 2). L’adresse IP source de ces paquets est 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: étant donné que la source provient d’un tunnel désigné (tunnel 2), le paquet A réussit 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 dessiné, le paquet B échoue par défaut à la vérification du transfert de chemin inverse en mode strict. Si le mode loose est activé, le transfert du paquet B est autorisé.
Packet C: la source étant une source de tunnel inexistante, le paquet C échoue à la vérification du transfert du chemin inverse et le paquet n’est pas transféré.
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 à la configuration de votre réseau, copiez et collez-les dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit du 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, voir Utilisation de l’éditeur CLI en mode Configuration du 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 du 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 de tunnel GRE dynamique 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 et de transfert virtuel (VRF) sur le routeur R0 et affectez l’interface de connexion à 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 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 de configuration, confirmez votre configuration en entrant les show interfacescommandes , , show routing-optionsshow protocolset show routing-options . Si la sortie n’affiche pas la configuration voulue, 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 anti-usurpation d’identité
Vérification de la configuration de base
But
Vérifiez l’état de l’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 et 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
Sens
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 commandes , et les show route table inet.3show dynamic-tunnels database terse commandes.
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
Sens
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 anti-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 le show krt table VPN1.inet.0 detailfichier .
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
Sens
La vérification du transfert de chemin inverse configurée 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 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.