Dépannage des VPN de couche 3
Diagnostiquer les problèmes courants liés aux VPN de couche 3
Problème
Description
Pour résoudre les problèmes liés à la configuration du VPN de couche 3, commencez par une extrémité du VPN (le routeur CE local) et suivez les itinéraires jusqu’à l’autre extrémité du VPN (le routeur CE distant).
Solution
Les étapes de dépannage suivantes devraient vous aider à diagnostiquer les problèmes courants :
Si vous avez configuré un protocole de routage entre les routeurs PE (Provider Edge) local et CE, vérifiez que l’appairage et la contiguïté sont pleinement opérationnels. Dans ce cas, veillez à spécifier le nom de l’instance de routage. Par exemple, pour vérifier les contiguïtés OSPF, entrez la
show ospf neighbor instance routing-instance-namecommande sur le routeur PE.Si l’appairage et la contiguïté ne sont pas entièrement opérationnels, vérifiez la configuration du protocole de routage sur le routeur CE et vérifiez la configuration du protocole de routage pour l’instance de routage VPN associée sur le routeur PE.
Vérifiez que les routeurs CE et PE locaux peuvent envoyer un ping l’un à l’autre.
Pour vérifier que le routeur CE local peut envoyer un ping à l’interface VPN sur le routeur PE local, utilisez une
pingcommande au format suivant, en spécifiant l’adresse IP ou le nom du routeur PE :user@host> ping (ip-address | host-name)
Pour vérifier que le routeur PE local peut envoyer une requête ping au routeur CE, utilisez une
pingcommande au format suivant, spécifiant l’adresse IP ou le nom du routeur CE, le nom de l’interface utilisée pour le VPN et l’adresse IP source (l’adresse locale) dans les paquets de demande d’écho sortants :user@host> ping ip-address interface interface local echo-address
Souvent, l’appairage ou la contiguïté entre les routeurs CE locaux et PE locaux doit se produire avant qu’une
pingcommande réussisse. Pour vérifier qu’une liaison est opérationnelle dans un environnement de laboratoire, supprimez l’interface du VRF (VPN routing and forwarding) en supprimant l’instructioninterfacedu niveau hiérarchique et en[edit routing-instance routing-instance-name]validant à nouveau la configuration. Cela supprime l’interface du VPN. Ensuite, essayez à nouveau la ping commande. Si la commande réussit, reconfigurez l’interface dans le VPN et vérifiez à nouveau la configuration du protocole de routage sur les routeurs CE et PE locaux.Sur le routeur PE local, vérifiez que les routes du routeur CE local se trouvent dans la table VRF (routing-instance-name.inet.0) :
user@host> show route table routing-instance-name.inet.0 <detail>
L’exemple suivant illustre les entrées de la table de routage. Ici, l’adresse de bouclage du routeur CE est
10.255.14.155/32et le protocole de routage entre les routeurs PE et CE est BGP. L’entrée ressemble à n’importe quelle annonce BGP ordinaire.10.255.14.155/32 (1 entry, 1 announced) *BGP Preference: 170/-101 Nexthop: 192.168.197.141 via fe-1/0/0.0, selected State: <Active Ext> Peer AS: 1 Age: 45:46 Task: BGP_1.192.168.197.141+179 Announcement bits (2): 0-BGP.0.0.0.0+179 1-KRT AS path: 1 I Localpref: 100 Router ID: 10.255.14.155Si les routes du routeur CE local ne sont pas présentes dans la table de routage VRF, vérifiez que le routeur CE annonce les routes vers le routeur PE. Si un routage statique est utilisé entre les routeurs CE et PE, assurez-vous que les routes statiques appropriées sont configurées.
Sur un routeur PE distant, vérifiez que les routes du routeur CE local sont présentes dans la table de routage bgp.l3vpn.0 :
user@host> show route table bgp.l3vpn.0 extensive 10.255.14.175:3:10.255.14.155/32 (1 entry, 0 announced) *BGP Preference: 170/-101 Route Distinguisher: 10.255.14.175:3 Source: 10.255.14.175 Nexthop: 192.168.192.1 via fe-1/1/2.0, selected label-switched-path vpn07-vpn05 Push 100004, Push 100005(top) State: <Active Int Ext> Local AS: 69 Peer AS: 69 Age: 15:27 Metric2: 338 Task: BGP_69.10.255.14.175+179 AS path: 1 I Communities: target:69:100 BGP next hop: 10.255.14.175 Localpref: 100 Router ID: 10.255.14.175 Secondary tables: VPN-A.inet.0La sortie de la
show route table bgp.l3vpn.0 extensivecommande contient les informations suivantes spécifiques au VPN :Dans le nom du préfixe (la première ligne de la sortie), le séparateur de route est ajouté au préfixe de route du routeur CE local. Le séparateur de route étant unique sur Internet, la concaténation du séparateur de route et du préfixe IP fournit des entrées de routage VPN-IP version 4 (IPv4) uniques.
Le
Route Distinguisherchamp répertorie la route distincte de l’adresse VPN-IPv4.Le
label-switched-pathchamp indique le nom du chemin de commutation d’étiquettes (LSP) utilisé pour transporter le trafic VPN.Le
Pushchamp montre les deux étiquettes transportées dans le paquet VPN-IPv4. La première étiquette est l’étiquette interne, qui est l’étiquette VPN qui a été attribuée par le routeur PE. La deuxième étiquette est l’étiquette extérieure, qui est une étiquette RSVP.Le
Communitieschamp répertorie la communauté cible.Le
Secondary tableschamp répertorie les autres tables de routage sur ce routeur dans lesquelles cette route a été installée.
Si les routes du routeur CE local ne sont pas présentes dans la table de routage bgp.l3vpn.0 sur le routeur PE distant, procédez comme suit :
Vérifiez le filtre d’importation VRF sur le routeur PE distant, qui est configuré dans l’instruction
vrf-import. (Sur le routeur PE local, vérifiez le filtre d’exportation VRF, qui est configuré avec l’instructionvrf-export.)Vérifiez qu’il existe un chemin LSP ou LDP opérationnel entre les routeurs PE. Pour ce faire, vérifiez que les adresses de saut suivant IBGP se trouvent dans la table inet.3.
Vérifiez que la session IBGP entre les routeurs PE est établie et configurée correctement.
Vérifiez les itinéraires « cachés », ce qui signifie généralement que les itinéraires n’ont pas été étiquetés correctement. Pour ce faire, utilisez la
show route table bgp.l3vpn.0 hiddencommande.Vérifiez que l’étiquette interne correspond à l’étiquette VPN interne attribuée par le routeur PE local. Pour ce faire, utilisez la
show route table mplscommande.
L’exemple suivant montre la sortie de cette commande sur le routeur PE distant. Ici, l’étiquette intérieure est
100004.... Push 100004, Push 10005 (top)
L’exemple suivant montre la sortie de cette commande sur le routeur PE local, qui montre que l’étiquette interne de
100004correspond à l’étiquette interne sur le routeur PE distant :... 100004 *[VPN/7] 06:56:25, metric 1 > to 192.168.197.141 via fe-1/0/0.0, Pop
Sur le routeur PE distant, vérifiez que les routes du routeur CE local sont présentes dans la table VRF (routing-instance-name.inet.0) :
user@host> show route table routing-instance-name.inet.0 detail 10.255.14.155/32 (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 10.255.14.175:3 Source: 10.255.14.175 Nexthop: 192.168.192.1 via fe-1/1/2.0, selected label-switched-path vpn07-vpn05 Push 100004, Push 100005(top) State: <Secondary Active Int Ext> Local AS: 69 Peer AS: 69 Age: 1:16:22 Metric2: 338 Task: BGP_69.10.255.14.175+179 Announcement bits (2): 1-KRT 2-VPN-A-RIP AS path: 1 I Communities: target:69:100 BGP next hop: 10.255.14.175 Localpref: 100 Router ID: 10.255.14.175 Primary Routing Table bgp.l3vpn.0Dans cette table de routage, le séparateur de route n’est plus ajouté au préfixe. La dernière ligne,
Primary Routing Table, répertorie la table à partir de laquelle cet itinéraire a été appris.Si les routes ne sont pas présentes dans cette table de routage, mais qu’elles étaient présentes dans la table de routage bgp.l3vpn.0 sur le routeur CE local, il est possible qu’elles n’aient pas passé la stratégie d’importation VRF sur le routeur PE distant.
Si une route VPN-IPv4 ne correspond à aucune
vrf-importstratégie, elle n’apparaît pas du tout dans la table bgp.l3vpn et n’est donc pas présente dans la table VRF. Si cela se produit, cela peut indiquer que sur le routeur PE, vous avez configuré une autrevrf-importinstruction sur un autre VPN (avec une cible commune) et que les routes apparaissent dans la table bgp.l3vpn.0, mais qu’elles sont importées dans le mauvais VPN.Sur le routeur CE distant, vérifiez que les routes du routeur CE local sont présentes dans la table de routage (inet.0) :
user@host> show route
Si les routes ne sont pas présentes, vérifiez la configuration du protocole de routage entre les routeurs PE et CE distants, et assurez-vous que les pairs et les proximités (ou routes statiques) entre les routeurs PE et CE sont corrects.
Si vous déterminez que les routes provenant du routeur CE local sont correctes, vérifiez les routes provenant du routeur CE distant en répétant cette procédure.
Exemple : Dépannage des VPN de couche 3
Cet exemple montre comment utiliser la ping commande pour vérifier l’accessibilité de différents routeurs dans une topologie VPN, et comment utiliser la traceroute commande pour vérifier le chemin que les paquets empruntent entre les routeurs VPN.
- Exigences
- Aperçu
- Envoi d’un ping au routeur CE à partir d’un autre routeur CE
- Envoi d’un ping aux routeurs PE et CE distants à partir du routeur CE local
- Envoi d’un ping à un routeur CE à partir d’une interface multi-accès
- Envoi d’un ping aux routeurs PE directement connectés à partir des routeurs CE
- Envoi d’un ping aux routeurs CE directement connectés à partir des routeurs PE
- Envoi d’une requête ping au routeur CE distant à partir du routeur PE local
- Dépannage des routes annoncées de manière incohérente à partir d’interfaces Gigabit Ethernet
Exigences
Cet exemple utilise les composants matériels et logiciels suivants :
-
Routeurs M Series
-
Junos OS version 10.0R1 et ultérieures
Aperçu
Topologie
La topologie illustrée dans la Figure 1 illustre le réseau utilisé dans cet exemple pour illustrer comment utiliser les commandes ping et traceroute pour tester la connectivité entre les routeurs participant à un VPN de couche 3.
Envoi d’un ping au routeur CE à partir d’un autre routeur CE
Procédure
Procédure étape par étape
Ce qui suit décrit comment utiliser le ping et traceroute les commandes pour dépanner les topologies VPN de couche 3. Vous pouvez envoyer une requête ping d’un routeur CE à l’autre en spécifiant l’adresse de bouclage de l’autre routeur CE comme adresse IP dans la ping commande. Cette ping commande réussit si les adresses de bouclage ont été annoncées par les routeurs CE à leurs routeurs PE directement connectés. Le succès de ces ping commandes signifie également que le routeur CE1 peut envoyer un ping à tous les périphériques réseau au-delà du routeur CE2, et vice versa. La figure 1 illustre la topologie référencée dans les étapes suivantes :
-
Routeur ping CE2 (VPN5) à partir du routeur CE1 (VPN4) :
user@vpn4> ping 10.255.10.5 local 10.255.10.4 count 3 PING 10.255.10.5 (10.255.10.5): 56 data bytes 64 bytes from 10.255.10.5: icmp_seq=0 ttl=253 time=1.086 ms 64 bytes from 10.255.10.5: icmp_seq=1 ttl=253 time=0.998 ms 64 bytes from 10.255.10.5: icmp_seq=2 ttl=253 time=1.140 ms --- 10.255.10.5 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.998/1.075/1.140/0.059 ms
-
Pour déterminer le chemin entre l’interface de bouclage du routeur CE1 et l’interface de bouclage du routeur CE2, utilisez la
traceroutecommande :user@vpn4> traceroute 10.255.10.5 source 10.255.10.4 traceroute to 10.255.10.5 (10.255.10.5) from 10.255.10.4, 30 hops max, 40 byte packets 1 vpn1-fe-110.isp-core.net (192.168.192.1) 0.680 ms 0.491 ms 0.456 ms 2 vpn2-t3-001.isp-core.net (192.168.192.110) 0.857 ms 0.766 ms 0.754 ms MPLS Label=100005 CoS=0 TTL=1 S=1 3 vpn5.isp-core.net (10.255.10.5) 0.825 ms 0.886 ms 0.732 ms -
Lorsque vous utilisez la
traceroutecommande pour examiner le chemin utilisé par un VPN de couche 3, les routeurs du fournisseur (P) dans le réseau du fournisseur de services ne sont pas affichés. Comme indiqué ci-dessus, le passage du routeur VPN1 au routeur VPN2 s’affiche sous la forme d’un saut unique. Le routeur P (VPN3) illustré à la Figure 1 n’est pas affiché. -
Routeur ping CE1 (VPN4) à partir du routeur CE2 (VPN5) :
user@vpn5> ping 10.255.10.4 local 10.255.10.5 count 3 PING 10.255.10.4 (10.255.10.4): 56 data bytes 64 bytes from 10.255.10.4: icmp_seq=0 ttl=253 time=1.042 ms 64 bytes from 10.255.10.4: icmp_seq=1 ttl=253 time=0.998 ms 64 bytes from 10.255.10.4: icmp_seq=2 ttl=253 time=0.954 ms --- 10.255.10.4 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.954/0.998/1.042/0.036 ms
-
Pour déterminer le chemin entre le routeur CE2 et le routeur CE1, utilisez la
traceroutecommande suivante :user@vpn5> traceroute 10.255.10.4 source 10.255.10.5 traceroute to 10.255.10.4 (10.255.10.4) from 10.255.10.5, 30 hops max, 40 byte packets 1 vpn-08-t3-003.isp-core.net (192.168.193.2) 0.686 ms 0.519 ms 0.548 ms 2 vpn1-so-100.isp-core.net (192.168.192.100) 0.918 ms 0.869 ms 0.859 ms MPLS Label=100021 CoS=0 TTL=1 S=1 3 vpn4.isp-core.net (10.255.10.4) 0.878 ms 0.760 ms 0.739 ms
Envoi d’un ping aux routeurs PE et CE distants à partir du routeur CE local
Procédure
Procédure étape par étape
À partir du routeur CE local, vous pouvez envoyer une requête ping aux interfaces VPN sur les routeurs PE et CE distants, qui sont des interfaces point à point. La figure 1 illustre la topologie référencée dans les exemples suivants :
-
Envoyez un ping au routeur CE2 à partir du routeur CE1.
user@vpn4> ping 192.168.193.5 local 10.255.10.4 count 3 PING 192.168.193.5 (192.168.193.5): 56 data bytes 64 bytes from 192.168.193.5: icmp_seq=0 ttl=253 time=1.040 ms 64 bytes from 192.168.193.5: icmp_seq=1 ttl=253 time=0.891 ms 64 bytes from 192.168.193.5: icmp_seq=2 ttl=253 time=0.944 ms --- 192.168.193.5 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.891/0.958/1.040/0.062 ms
-
Pour déterminer le chemin entre l’interface de bouclage du routeur CE1 et l’interface directement connectée du routeur CE2, utilisez la
traceroutecommande :user@vpn4> traceroute 192.168.193.5 source 10.255.10.4 traceroute to 192.168.193.5 (192.168.193.5) from 10.255.10.4, 30 hops max, 40 byte packets 1 vpn1-fe-110.isp-core.net (192.168.192.1) 0.669 ms 0.508 ms 0.457 ms 2 vpn2-t3-001.isp-core.net (192.168.192.110) 0.851 ms 0.769 ms 0.750 ms MPLS Label=100000 CoS=0 TTL=1 S=1 3 vpn5-t3-003.isp-core.net (192.168.193.5) 0.829 ms 0.838 ms 0.731 ms -
Ping Router PE2 (VPN2) à partir du routeur CE1 (VPN4). Dans ce cas, les paquets provenant du routeur CE1 vont au routeur PE2, puis au routeur CE2, et de nouveau au routeur PE2 avant que le routeur PE2 ne puisse répondre aux demandes ICMP (Internet Control Message Protocol). Vous pouvez le vérifier à l’aide de la
traceroutecommande.user@vpn4> ping 192.168.193.2 local 10.255.10.4 count 3 PING 192.168.193.2 (192.168.193.2): 56 data bytes 64 bytes from 192.168.193.2: icmp_seq=0 ttl=254 time=1.080 ms 64 bytes from 192.168.193.2: icmp_seq=1 ttl=254 time=0.967 ms 64 bytes from 192.168.193.2: icmp_seq=2 ttl=254 time=0.983 ms --- 192.168.193.2 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.967/1.010/1.080/0.050 ms
-
Pour déterminer le chemin entre le routeur CE1 et le routeur PE2, utilisez la
traceroutecommande :user@vpn4> traceroute 192.168.193.2 source 10.255.10.4 traceroute to 192.168.193.2 (192.168.193.2) from 10.255.10.4, 30 hops max, 40 byte packets 1 vpn1-fe-110.isp-core.net (192.168.192.1) 0.690 ms 0.490 ms 0.458 ms 2 vpn2-t3-003.isp-core.net (192.168.193.2) 0.846 ms 0.768 ms 0.749 ms MPLS Label=100000 CoS=0 TTL=1 S=1 3 vpn5-t3-003.isp-core.net (192.168.193.5) 0.643 ms 0.703 ms 0.600 ms 4 vpn-08-t3-003.isp-core.net (192.168.193.2) 0.810 ms 0.739 ms 0.729 ms
Envoi d’un ping à un routeur CE à partir d’une interface multi-accès
Procédure
Procédure étape par étape
Vous ne pouvez pas envoyer de ping d’un routeur CE à l’autre si l’interface VPN est une interface multi-accès, telle que l’interface fe-1/1/2.0 du routeur CE1. Pour envoyer une requête ping au routeur CE1 à partir du routeur CE2, vous devez soit inclure l’instruction vrf-table-label au niveau de la hiérarchie sur le routeur PE1, soit configurer une route statique sur le [edit routing-instances routing-instance-name] routeur PE1 vers l’interface VPN du routeur CE1. Si vous incluez l’instruction vrf-table-label ping à un routeur, vous ne pouvez pas configurer de route statique.
-
Si vous configurez une route statique sur le routeur PE1 vers l’interface VPN du routeur CE1, son prochain saut doit pointer vers le routeur CE1 (au niveau de la hiérarchie), et cette route doit être annoncée du routeur PE1 vers le
[edit routing-instance routing-instance-name]routeur PE2 comme indiqué dans la configuration suivante :[edit] routing-instances { direct-multipoint { instance-type vrf; interface fe-1/1/0.0; route-distinguisher 69:1; vrf-import direct-import; vrf-export direct-export; routing-options { static { route 192.168.192.4/32 next-hop 192.168.192.4; } } protocols { bgp { group to-vpn4 { peer-as 1; neighbor 192.168.192.4; } } } } policy-options { policy-statement direct-export { term a { from protocol bgp; then { community add direct-comm; accept; } } term b { from { protocol static; route-filter 192.168.192.4/32 exact; } then { community add direct-comm; accept; } } term d { then reject; } } } } -
Vous pouvez maintenant envoyer un ping au routeur CE1 à partir du routeur CE2 :
user@vpn5> ping 192.168.192.4 local 10.255.10.5 count 3 PING 192.168.192.4 (192.168.192.4): 56 data bytes 64 bytes from 192.168.192.4: icmp_seq=0 ttl=253 time=1.092 ms 64 bytes from 192.168.192.4: icmp_seq=1 ttl=253 time=1.019 ms 64 bytes from 192.168.192.4: icmp_seq=2 ttl=253 time=1.031 ms --- 192.168.192.4 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.019/1.047/1.092/0.032 ms
-
Pour déterminer le chemin entre ces deux interfaces, utilisez la
traceroutecommande :user@vpn5> traceroute 192.168.192.4 source 10.255.10.5 traceroute to 192.168.192.4 (192.168.192.4) from 10.255.10.5, 30 hops max, 40 byte packets 1 vpn-08-t3003.isp-core.net (192.168.193.2) 0.678 ms 0.549 ms 0.494 ms 2 vpn1-so-100.isp-core.net (192.168.192.100) 0.873 ms 0.847 ms 0.844 ms MPLS Label=100021 CoS=0 TTL=1 S=1 3 vpn4-fe-112.isp-core.net (192.168.192.4) 0.825 ms 0.743 ms 0.764 ms
Envoi d’un ping aux routeurs PE directement connectés à partir des routeurs CE
Procédure
Procédure étape par étape
À partir des interfaces de bouclage sur les routeurs CE, vous pouvez envoyer un ping à l’interface VPN sur le routeur PE directement connecté. La figure 1 illustre la topologie référencée dans cette procédure :
-
À partir de l’interface de bouclage sur le routeur CE1 (VPN4), envoyez une requête ping à l’interface VPN,
fe-1/1/0.0, sur le routeur PE1 :user@vpn4> ping 192.168.192.1 local 10.255.10.4 count 3 PING 192.168.192.1 (192.168.192.1): 56 data bytes 64 bytes from 192.168.192.1: icmp_seq=0 ttl=255 time=0.885 ms 64 bytes from 192.168.192.1: icmp_seq=1 ttl=255 time=0.757 ms 64 bytes from 192.168.192.1: icmp_seq=2 ttl=255 time=0.734 ms --- 192.168.192.1 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.734/0.792/0.885/0.066 ms
-
À partir de l’interface de bouclage sur le routeur CE2 (VPN5), envoyez une requête ping à l’interface VPN,
t3-0/0/3.0, sur le routeur PE2 :user@vpn5> ping 192.168.193.2 local 10.255.10.5 count 3 PING 192.168.193.2 (192.168.193.2): 56 data bytes 64 bytes from 192.168.193.2: icmp_seq=0 ttl=255 time=0.998 ms 64 bytes from 192.168.193.2: icmp_seq=1 ttl=255 time=0.834 ms 64 bytes from 192.168.193.2: icmp_seq=2 ttl=255 time=0.819 ms --- 192.168.193.2 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.819/0.884/0.998/0.081 ms
-
À partir de l’interface de bouclage sur le routeur CE2 (VPN5), envoyez une requête ping à l’interface VPN,
t3-0/0/3.0, sur le routeur PE2 :user@vpn5> ping 192.168.193.2 local 10.255.10.5 count 3 PING 192.168.193.2 (192.168.193.2): 56 data bytes 64 bytes from 192.168.193.2: icmp_seq=0 ttl=255 time=0.998 ms 64 bytes from 192.168.193.2: icmp_seq=1 ttl=255 time=0.834 ms 64 bytes from 192.168.193.2: icmp_seq=2 ttl=255 time=0.819 ms --- 192.168.193.2 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.819/0.884/0.998/0.081 ms
-
Pour déterminer le chemin entre l’interface de bouclage du routeur CE2 et les interfaces VPN du routeur PE2, utilisez la
traceroutecommande :user@vpn5> traceroute 192.168.193.2 source 10.255.10.5 traceroute to 192.168.193.2 (192.168.193.2) from 10.255.10.5, 30 hops max, 40 byte packets 1 vpn-08-t3003.isp-core.net (192.168.193.2) 0.852 ms 0.670 ms 0.656 ms
Envoi d’un ping aux routeurs CE directement connectés à partir des routeurs PE
Procédure
Procédure étape par étape
À partir des interfaces VPN et loopback des routeurs PE, vous pouvez envoyer un ping à l’interface VPN sur le routeur CE directement connecté. La figure 1 illustre la topologie référencée dans cette procédure :
-
À partir de l’interface VPN du routeur PE (routeur PE1), vous pouvez envoyer un ping à l’interface VPN ou à l’interface de bouclage sur le routeur CE directement connecté (routeur CE1).
À partir de l’interface VPN sur le routeur PE1 (VPN1), envoyez une requête ping à l’interface VPN,
fe-1/1/0.0, sur le routeur CE1 :user@vpn1> ping 192.168.192.4 interface fe-1/1/0.0 local 192.168.192.1 count 3 PING 192.168.192.4 (192.168.192.4): 56 data bytes 64 bytes from 192.168.192.4: icmp_seq=0 ttl=255 time=0.866 ms 64 bytes from 192.168.192.4: icmp_seq=1 ttl=255 time=0.728 ms 64 bytes from 192.168.192.4: icmp_seq=2 ttl=255 time=0.753 ms --- 192.168.192.4 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.728/0.782/0.866/0.060 ms
-
À partir de l’interface VPN sur le routeur PE1 (VPN1), envoyez une requête ping à l’interface de bouclage,
10.255.10.4, sur le routeur CE1 :user@vpn1> ping 10.255.10.4 interface fe-1/1/0.0 local 192.168.192.1 count 3 PING 10.255.10.4 (10.255.10.4): 56 data bytes 64 bytes from 10.255.10.4: icmp_seq=0 ttl=255 time=0.838 ms 64 bytes from 10.255.10.4: icmp_seq=1 ttl=255 time=0.760 ms 64 bytes from 10.255.10.4: icmp_seq=2 ttl=255 time=0.771 ms --- 10.255.10.4 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.760/0.790/0.838/0.034 ms
-
Pour déterminer le chemin d’accès entre l’interface VPN du routeur PE1 et les interfaces VPN et de bouclage du routeur CE1, respectivement, utilisez les commandes suivantes
traceroute:user@vpn1> traceroute 10.255.10.4 interface fe-1/1/0.0 source 192.168.192.1 traceroute to 10.255.10.4 (10.255.10.4) from 192.168.192.1, 30 hops max, 40 byte packets 1 vpn4.isp-core.net (10.255.10.4) 0.842 ms 0.659 ms 0.621 ms user@vpn1> traceroute 192.168.192.4 interface fe-1/1/0.0 source 192.168.192.1 traceroute to 192.168.192.4 (192.168.192.4) from 192.168.192.1, 30 hops max, 40 byte packets 1 vpn4-fe-112.isp-core.net (192.168.192.4) 0.810 ms 0.662 ms 0.640 ms
-
À partir de l’interface VPN sur le routeur PE2 (VPN2), pingez l’interface VPN,
t3-0/0/3.0, sur le routeur CE2 :user@vpn2> ping 192.168.193.5 interface t3-0/0/3.0 local 192.168.193.2 count 3 PING 192.168.193.5 (192.168.193.5): 56 data bytes 64 bytes from 192.168.193.5: icmp_seq=0 ttl=255 time=0.852 ms 64 bytes from 192.168.193.5: icmp_seq=1 ttl=255 time=0.909 ms 64 bytes from 192.168.193.5: icmp_seq=2 ttl=255 time=0.793 ms --- 192.168.193.5 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.793/0.851/0.909/0.047 ms
-
À partir de l’interface VPN sur le routeur PE2 (VPN2), envoyez une requête ping à l’interface de bouclage,
10.255.10.5, sur le routeur CE2 :user@vpn2> ping 10.255.10.5 interface t3-0/0/3.0 local 192.168.193.2 count 3 PING 10.255.10.5 (10.255.10.5): 56 data bytes 64 bytes from 10.255.10.5: icmp_seq=0 ttl=255 time=0.914 ms 64 bytes from 10.255.10.5: icmp_seq=1 ttl=255 time=0.888 ms 64 bytes from 10.255.10.5: icmp_seq=2 ttl=255 time=1.066 ms --- 10.255.10.5 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.888/0.956/1.066/0.079 ms
-
Pour déterminer le chemin entre l’interface VPN du routeur PE2 et les interfaces VPN et de bouclage du routeur CE2, respectivement, utilisez les commandes suivantes
traceroute:user@vpn2> traceroute 10.255.10.5 interface t3-0/0/3.0 source 192.168.193.2 traceroute to 10.255.10.5 (10.255.10.5) from 192.168.193.2, 30 hops max, 40 byte packets 1 vpn5.isp-core.net (10.255.10.5) 1.009 ms 0.677 ms 0.633 ms user@vpn2> traceroute 192.168.193.5 interface t3-0/0/3.0 source 192.168.193.2 traceroute to 192.168.193.5 (192.168.193.5) from 192.168.193.2, 30 hops max, 40 byte packets 1 vpn5-t3-003.isp-core.net (192.168.193.5) 0.974 ms 0.665 ms 0.619 ms
Envoi d’une requête ping au routeur CE distant à partir du routeur PE local
Procédure
Procédure étape par étape
La procédure suivante s’applique uniquement aux VPN de couche 3. Pour envoyer une requête ping à un routeur CE distant à partir d’un routeur PE local dans un VPN de couche 3, vous devez configurer les interfaces suivantes :
-
Configurez une unité logique pour l’interface de bouclage.
Pour configurer une unité logique supplémentaire sur l’interface de bouclage du routeur PE, configurez l’instruction
unitau niveau de la[edit interfaces lo0]hiérarchie :[edit interfaces] lo0 { unit number { family inet { address address; } } } -
Configurez l’interface de bouclage pour l’instance de routage VPN de couche 3 sur le routeur PE local. Vous pouvez associer une interface de bouclage logique à chaque instance de routage VPN de couche 3, ce qui vous permet d’envoyer une requête ping à une instance de routage spécifique sur un routeur.
Spécifiez l’interface de bouclage que vous avez configurée à l’étape 1 à l’aide de l’instruction
interfaceau niveau de la[edit routing-instances routing-instance-name]hiérarchie :[edit routing-instances routing-instance-name] interface interface-name;
Le
interface-nameest l’unité logique de l’interface de bouclage (par exemple,lo0.1). -
À partir de l’interface VPN sur le routeur PE, vous pouvez maintenant envoyer un ping à l’unité logique sur l’interface de bouclage sur le routeur CE distant :
user@host> ping interface interface hostPermet
interfacede spécifier la nouvelle unité logique sur l’interface de bouclage (par exemple,lo0.1). Pour plus d’informations sur l’utilisation de laping interfacecommande, reportez-vous au Guide de référence des commandes Junos Interfaces.
Dépannage des routes annoncées de manière incohérente à partir d’interfaces Gigabit Ethernet
Procédure
Procédure étape par étape
Pour les routes directes sur un réseau local dans un VPN de couche 3, Junos OS tente de localiser un routeur CE qui peut être désigné comme le saut suivant. Si cela n’est pas possible, les routes annoncées à partir des interfaces Gigabit Ethernet sont abandonnées.
Dans de tels cas :
-
Utilisez l’instruction
staticau niveau de la[edit routing-options]hiérarchie ou[edit logical-systems logical-system-name routing-options]dans l’instance de routage VRF vers un routeur CE sur le sous-réseau LAN, en configurant le routeur CE comme saut suivant. Tout le trafic vers des destinations directes sur ce réseau local sera dirigé vers le routeur CE. Vous pouvez ajouter deux routes statiques à deux routeurs CE sur le LAN pour la redondance. -
Configurez l’instruction
vrf-table-labelau niveau de la[edit routing-instances routing-instance-name]hiérarchie pour mapper l’étiquette interne d’un paquet à une table de routage VRF spécifique. Cela permet d’examiner l’en-tête IP encapsulé pour forcer les recherches IP sur l’instance de routage VRF pour l’ensemble du trafic.Note:L’instruction
vrf-table-labeln’est pas disponible pour toutes les interfaces orientées vers le cœur ; par exemple, les interfaces canalisées ne sont pas prises en charge. Pour plus d’informations sur la prise en charge de l’instruction sur lesvrf-table-labelinterfaces Ethernet et SONET/SDH, reportez-vous à la section Filtrage des paquets dans les VPN de couche 3 en fonction des en-têtes IP.
Exemple : Diagnostic de problèmes réseau liés aux VPN de couche 3 en désactivant la décrémentation TTL
Cet exemple montre comment désactiver la décrémentation TTL dans une seule instance de routage VRF dans un scénario VPN de couche 3.
Exigences
Avant de commencer :
-
Configurez les interfaces du routeur. Reportez-vous au Guide de configuration des interfaces réseau.
Aperçu
Pour diagnostiquer les problèmes réseau liés aux VPN, il peut être utile de désactiver la décrémentation de la durée de vie normale (TTL). L’en-tête IP inclut un champ TTL qui sert de compteur de sauts. À chaque saut routé, le TTL est décrémenté d’une unité ; si la durée de vie atteint zéro avant que le paquet n’atteigne sa destination, le paquet est ignoré et (éventuellement) un message de dépassement de la durée de vie ICMP est envoyé à la source. Les étiquettes MPLS disposent également d’un champ TTL. Les routeurs MPLS copient la durée de vie d’un paquet IP lorsqu’il entre dans un chemin de commutation d’étiquettes (LSP). Un paquet IP avec un TTL de 27 reçoit une étiquette MPLS avec un TTL de 27. Junos OS décrémente la TTL MPLS d’un paquet encapsulé MPLS à la place de la TTL IP, à chaque saut de commutation d’étiquettes. Étant donné que le TTL MPLS est copié (ou propagé) à partir du TTL IP, un traceroute répertorie tous les sauts du chemin, qu’ils soient routés ou affectés à une commutation d’étiquette. Lorsque le paquet quitte le LSP, le TTL MPLS décrémenté est repropagé dans le champ TTL IP.
Par défaut, la propagation TTL est activée. La déclaration globale no-propagate-ttl désactive la propagation TTL au niveau du routeur et affecte tous les LSP signalés par RSVP ou LDP. Lorsqu’un routeur agit en tant que routeur entrant pour un LSP et que la configuration du routeur inclut l’instruction no-propagate-ttl , le routeur envoie un en-tête MPLS avec une valeur TTL de 255, quelle que soit la TTL du paquet IP. Lorsqu’un routeur fait office d’avant-dernier routeur, il insère l’en-tête MPLS sans propager le TTL MPLS dans le paquet IP. Ainsi, la valeur TTL du paquet IP est conservée, quel que soit le nombre de sauts du LSP.
Au lieu de configurer le comportement de propagation TTL au niveau du routeur, vous pouvez configurer le comportement des routes dans une instance de routage VRF. Cet exemple montre comment désactiver la propagation TTL pour les routes dans une seule instance de routage VRF plutôt qu’au niveau du routeur global.
La configuration par VRF prévaut sur la configuration globale du routeur. Si vous désactivez la propagation TTL sur le routeur et que vous activez explicitement la propagation TTL pour une seule instance de routage VRF, la propagation TTL est active pour cette instance de routage. Pour activer explicitement la propagation TTL sur une instance de routage VRF, incluez l’instruction vrf-propagate-ttl dans l’instance de routage.
Lorsque vous modifiez le comportement de propagation TTL, les anciens sauts suivants des routes VRF sont supprimés de la table de routage inet.3 et de nouveaux sauts suivants sont ajoutés.
Il vous suffit de configurer l’instruction vrf-propagate-ttl or no-vrf-propagate-ttl sur les routeurs entrants.
Diagramme de topologie
La figure 2 illustre la topologie utilisée dans cet exemple. Les routeurs PE1 et PE2 disposent de deux VPN---VPN-A et VPN-B. Les appareils CE1 et CE4 appartiennent au VPN-A. Les appareils CE2 et CE5 appartiennent au VPN-B. Dans cet exemple, la propagation TTL du routeur PE1 est désactivée sur le VPN-A, mais pas sur le VPN-B. La propagation TTL est désactivée pour les paquets reçus par PE1 sur l’interface connectée à CE1. Cet exemple montre la configuration sur le routeur PE1. Il n’est pas nécessaire d’inclure l’instruction no-vrf-propagate-ttl sur le routeur de sortie (PE2).
unique
Configuration
Procédure
Configuration rapide de la CLI
Pour désactiver rapidement la propagation TTL dans une instance de routage VRF, copiez les commandes suivantes et collez-les dans l’interface de ligne de commande.
[edit]
set interfaces lo0 unit 0 family inet address 10.255.179.45/32 primary
set protocols mpls interface all
set protocols bgp group ibgp type internal
set protocols bgp group ibgp local-address 10.255.179.45
set protocols bgp group ibgp family inet-vpn unicast
set protocols bgp group ibgp neighbor 10.255.179.71
set protocols ospf area 0.0.0.0 interface fe-1/1/2.0
set protocols ospf area 0.0.0.0 interface fxp0.0 disable
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ldp interface all
set policy-options policy-statement VPN-A-export term a from protocol ospf
set policy-options policy-statement VPN-A-export term a from interface ge-1/2/0.0
set policy-options policy-statement VPN-A-export term a then community add VPN-A
set policy-options policy-statement VPN-A-export term a then accept
set policy-options policy-statement VPN-A-export term b then reject
set policy-options policy-statement VPN-A-import term a from protocol bgp
set policy-options policy-statement VPN-A-import term a from community VPN-A
set policy-options policy-statement VPN-A-import term a then accept
set policy-options policy-statement VPN-A-import term b then reject
set policy-options policy-statement VPN-B-export term a from protocol static
set policy-options policy-statement VPN-B-export term a then community add VPN-B
set policy-options policy-statement VPN-B-export term a then accept
set policy-options policy-statement VPN-B-export term b then reject
set policy-options policy-statement VPN-B-import term a from protocol bgp
set policy-options policy-statement VPN-B-import term a from community VPN-B
set policy-options policy-statement VPN-B-import term a then accept
set policy-options policy-statement VPN-B-import term b then reject
set policy-options policy-statement bgp-to-ospf from protocol bgp
set policy-options policy-statement bgp-to-ospf then accept
set policy-options community VPN-A members target:1:100
set policy-options community VPN-B members target:1:200
set routing-instances VPN-A instance-type vrf
set routing-instances VPN-A interface ge-1/2/0.0
set routing-instances VPN-A route-distinguisher 10.255.179.45:100
set routing-instances VPN-A interface ge-1/2/0.0
set routing-instances VPN-A no-vrf-propagate-ttl
set routing-instances VPN-A vrf-import VPN-A-import
set routing-instances VPN-A vrf-export VPN-A-export
set routing-instances VPN-A protocols ospf export bgp-to-ospf
set routing-instances VPN-A protocols ospf area 0.0.0.0 interface ge-1/2/0.0
set routing-instances VPN-B instance-type vrf
set routing-instances VPN-B interface so-0/1/0.0
set routing-instances VPN-B route-distinguisher 10.255.179.45:300
set routing-instances VPN-B vrf-import VPN-B-import
set routing-instances VPN-B vrf-export VPN-B-export
set routing-instances VPN-B routing-options static route 10.255.179.15/32 next-hop so-0/1/0.0
set routing-options autonomous-system 1
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à 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 Configuration.
Pour configurer une carte de flux :
-
Configurez l’interface de bouclage.
[edit] user@PE1# edit interfaces [edit interfaces] user@PE1# set lo0 unit 0 family inet address 10.255.179.45/32 primary user@PE1# exit -
Configurez les protocoles de routage.
L’adresse voisine BGP interne est l’adresse de l’interface de bouclage du routeur PE2 de la Figure 2.
[edit] user@PE1# edit protocols [edit protocols] user@PE1# set mpls interface all user@PE1# set bgp group ibgp type internal user@PE1# set bgp group ibgp local-address 10.255.179.45 user@PE1# set bgp group ibgp family inet-vpn unicast user@PE1# set bgp group ibgp neighbor 10.255.179.71 user@PE1# set ospf area 0.0.0.0 interface fe-1/1/2.0 user@PE1# set ospf area 0.0.0.0 interface fxp0.0 disable user@PE1# set ospf area 0.0.0.0 interface lo0.0 user@PE1# set ldp interface all user@PE1# exit -
Configurez les stratégies de routage pour VPN-A et VPN-B.
[edit] user@PE1# edit policy-options [edit policy-options] user@PE1# set policy-statement VPN-A-export term a from protocol ospf user@PE1# set policy-statement VPN-A-export term a from interface ge-1/2/0.0 user@PE1# set policy-statement VPN-A-export term a then community add VPN-A user@PE1# set policy-statement VPN-A-export term a then accept user@PE1# set policy-statement VPN-A-export term b then reject user@PE1# set policy-statement VPN-A-import term a from protocol bgp user@PE1# set policy-statement VPN-A-import term a from community VPN-A user@PE1# set policy-statement VPN-A-import term a then accept user@PE1# set policy-statement VPN-A-import term b then reject user@PE1# set policy-statement VPN-B-export term a from protocol static user@PE1# set policy-statement VPN-B-export term a then community add VPN-B user@PE1# set policy-statement VPN-B-export term a then accept user@PE1# set policy-statement VPN-B-export term b then reject user@PE1# set policy-statement VPN-B-import term a from protocol bgp user@PE1# set policy-statement VPN-B-import term a from community VPN-B user@PE1# set policy-statement VPN-B-import term a then accept user@PE1# set policy-statement VPN-B-import term b then reject user@PE1# set policy-statement bgp-to-ospf from protocol bgp user@PE1# set policy-statement bgp-to-ospf then accept user@PE1# set community VPN-A members target:1:100 user@PE1# set community VPN-B members target:1:200 user@PE1# exit -
Configurez les instances de routage VPN-A et VPN-B, y compris l’instruction
no-vrf-propagate-ttldans VPN-A.[edit] user@PE1# edit routing-instances [edit routing-instances] user@PE1# set VPN-A instance-type vrf user@PE1# set VPN-A interface ge-1/2/0.0 user@PE1# set VPN-A route-distinguisher 10.255.179.45:100 user@PE1# set VPN-A interface ge-1/2/0.0 user@PE1# set VPN-A no-vrf-propagate-ttl user@PE1# set VPN-A vrf-import VPN-A-import user@PE1# set VPN-A vrf-export VPN-A-export user@PE1# set VPN-A protocols ospf export bgp-to-ospf user@PE1# set VPN-A protocols ospf area 0.0.0.0 interface ge-1/2/0.0 user@PE1# set VPN-B instance-type vrf user@PE1# set VPN-B interface so-0/1/0.0 user@PE1# set VPN-B route-distinguisher 10.255.179.45:300 user@PE1# set VPN-B vrf-import VPN-B-import user@PE1# set VPN-B vrf-export VPN-B-export user@PE1# set VPN-B routing-options static route 10.255.179.15/32 next-hop so-0/1/0.0 user@PE1# exit -
Définir le système autonome local.
[edit] user@PE1# edit routing-options [edit routing-options] user@PE1# set autonomous-system 1 user@PE1# exit -
Si vous avez terminé de configurer l’appareil, validez la configuration.
[edit] user@PE1# commit
Résultats
Confirmez votre configuration en saisissant les show interfacescommandes , show policy-options, show protocols, show routing-instanceset show routing-options .
user@PE1# show interfaces
lo0 {
unit 0 {
family inet {
address 10.255.179.45/32 {
primary;
}
}
}
}
user@PE1# show policy-options
policy-statement VPN-A-export {
term a {
from {
protocol ospf;
interface ge-1/2/0.0;
}
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement VPN-B-export {
term a {
from protocol static;
then {
community add VPN-B;
accept;
}
}
term b {
then reject;
}
}
policy-statement VPN-B-import {
term a {
from {
protocol bgp;
community VPN-B;
}
then accept;
}
term b {
then reject;
}
}
policy-statement bgp-to-ospf {
from protocol bgp;
then accept;
}
community VPN-A members target:1:100;
community VPN-B members target:1:200;
user@PE1# show protocols
mpls {
interface all;
}
bgp {
group ibgp {
type internal;
local-address 10.255.179.45;
family inet-vpn {
unicast;
}
neighbor 10.255.179.71;
}
}
ospf {
area 0.0.0.0 {
interface fe-1/1/2.0;
interface fxp0.0 {
disable;
}
interface lo0.0;
}
}
ldp {
interface all;
}
user@PE1# show routing-instances
VPN-A {
instance-type vrf;
interface ge-1/2/0.0;
no-vrf-propagate-ttl;
route-distinguisher 10.255.179.45:100;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
protocols {
ospf {
export bgp-to-ospf;
area 0.0.0.0 {
interface ge-1/2/0.0;
}
}
}
}
VPN-B {
instance-type vrf;
interface so-0/1/0.0;
route-distinguisher 10.255.179.45:300;
vrf-import VPN-B-import;
vrf-export VPN-B-export;
routing-options {
static {
route 10.255.179.15/32 next-hop so-0/1/0.0;
}
}
}
user@PE1# show routing-options autonomous-system 1;
Vérification
Pour vérifier l’opération, exécutez les commandes suivantes :
-
Voir le
TTL Actionchamp dans la sortie de lashow route extensive table VPN-Acommande. -
Voir le
TTL Actionchamp dans la sortie de lashow route extensive table VPN-Bcommande. -
Sur le périphérique CE1, exécutez la commande sur l
traceroute'adresse de bouclage du périphérique CE4. -
Sur le périphérique CE4, exécutez la commande sur l
traceroute'adresse de bouclage du périphérique CE1.