Dépannage des VPN de couche 3
Diagnostic des problèmes vpn courants de couche 3
Problème
Description
Pour résoudre les problèmes de configuration VPN de couche 3, commencez à une extrémité du VPN (le routeur de périphérie client local [CE] et suivez les routes vers l’autre extrémité du VPN (le routeur CE distant).
Solution
Les étapes de dépannage suivantes doivent vous aider à diagnostiquer des problèmes courants:
Si vous avez configuré un protocole de routage entre le pe (edge) du fournisseur local et les routeurs CE, vérifiez que l’peering et l’adjacence sont pleinement opérationnels. Dans ce cas, n’oubliez pas de spécifier le nom de l’instance de routage. Par exemple, pour vérifier les OSPF, saisissez la commande
show ospf neighbor instance routing-instance-namesur le routeur PE.Si l’peering et l’adjacence ne sont pas pleinement 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 PE et CE locaux peuvent s’envoyer un ping entre eux.
Pour vérifier que le routeur CE local peut ping l’interface VPN sur le routeur PE local, utilisez une commande au format suivant, en spécifiant l’adresse IP ou le nom du
pingrouteur PE:user@host> ping (ip-address | host-name)
Pour vérifier que le routeur PE local peut ping sur le routeur CE, utilisez une commande dans le format suivant, en 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
pingsortant:user@host> ping ip-address interface interface local echo-address
Souvent, l’peering ou l’adjacence entre le centre de CE et les routeurs PE locaux doivent se mettre en place avant qu’une commande
pingne soit réussie. Pour vérifier qu’une liaison fonctionne en laboratoire, supprimez l’interface de la fonction VRF (Routing and Forwarding) du VPN en supprimant l’instruction du niveau hiérarchique et en désintérestant lainterface[edit routing-instance routing-instance-name]configuration. Cette pratique supprime l’interface du VPN. Essayez à ping nouveau la commande. Si la commande réussit, configurez l’interface dans le VPN et vérifiez à nouveau la configuration du protocole de routage sur les routeurs PE et CE local.Sur le routeur PE local, vérifiez que les routes à partir du routeur CE local sont dans la table VRF ( routing-instance-name .inet.0):
user@host> show route table routing-instance-name.inet.0 <detail>
L’exemple suivant affiche les entrées de la table de routage. Ici, l’adresse loopback du routeur CE est et le protocole de routage entre le PE et CE
10.255.14.155/32routeurs BGP. L’entrée ressemble à n’importe quelle BGP annonce.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 en provenance du routeur CE local ne sont pas présentes dans la table de routage VRF, vérifiez que le routeur CE est des routes publicitaires vers le routeur PE. Si le routage statique est utilisé entre les routeurs CE et PE, assurez-vous que les routes statiques correctes sont configurées.
Sur un routeur PE distant, vérifiez que les routes à partir 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 commande contient les informations
show route table bgp.l3vpn.0 extensivesuivantes spécifiques au VPN:Dans le nom du préfixe (première ligne du produit), l’éminent routeur est ajouté au préfixe de route du routeur CE local. L’éminent routeur étant unique sur Internet, la concatonation de l’identre de route et du préfixe IP fournit des entrées de routage VPN-IP uniques de version 4 (IPv4).
Le
Route Distinguisherchamp répertorie l’éminent routeur séparément de l’adresse VPN-IPv4.Le champ affiche le nom du chemin de
label-switched-pathcommuté d’étiquettes (LSP) utilisé pour transporter le trafic VPN.Le
Pushchamp indique que les deux labels sont transportés dans le paquet VPN-IPv4. Le premier label est le label interne, c’est-à-dire le label VPN attribué par le routeur PE. Le deuxième label est l’étiquette extérieure, qui est un label RSVP.Le
Communitiessite répertorie la communauté cible.Le site répertorie les autres tables de routage du routeur sur lequel cette
Secondary tablesroute a été installée.
Si les routes en provenance du routeur CE local ne sont pas présentes dans la table de routage bgp.l3vpn.0 du routeur PE distant, faites les opérations suivantes:
Vérifiez le filtre d’importation VRF sur le routeur PE distant, configuré dans
vrf-importl’instruction. (Sur le routeur PE local, vous vérifiez le filtre d’exportation VRF, qui est configuré avecvrf-exportl’instruction.)Vérifiez qu’il existe un LSP opérationnel ou un chemin LDP entre les routeurs PE. Pour ce faire, vérifiez que les adresses IBGP du prochain saut sont dans le tableau inet.3.
Vérifiez que la session IBGP entre les routeurs PE est établie et configurée correctement.
Recherchez des routes « cachées », ce qui signifie généralement que les routes n’étaient pas correctement étiquetées. Pour ce faire, utilisez la
show route table bgp.l3vpn.0 hiddencommande.Vérifiez que le label interne correspond au label VPN interne attribué par le routeur PE local. Pour ce faire, utilisez la
show route table mplscommande.
L’exemple suivant affiche la sortie de cette commande sur le routeur PE distant. Ici, le label interne est
100004.... Push 100004, Push 10005 (top)
L’exemple suivant affiche le résultat de cette commande sur le routeur PE local, qui indique que le label interne correspond au label interne du
100004routeur 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 à partir 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, l’éminent routeur n’est plus prépendant au préfixe. La dernière ligne,
Primary Routing Tablerépertorie le tableau sur lequel cette voie a été apprise.Si les routes ne sont pas présentes dans cette table de routage, mais si elles étaient présentes dans la table de routage bgp.l3vpn.0 du routeur CE local, il se peut que ces routes n’ont pas passé la stratégie d’importation VRF sur le routeur PE distant.
Si un routeur VPN-IPv4 ne correspond à aucune stratégie, la route ne s’affiche pas du tout dans la table bgp.l3vpn et n’est donc pas présente dans la
vrf-importtable VRF. Si cela se produit, il peut indiquer que sur le routeur PE, vous avez configuré une autre instruction sur un autre VPN (avec une cible commune) et les routes apparaissent dans lavrf-importtable bgp.l3vpn.0, mais sont importés dans le mauvais VPN.Sur le route CE ur distant, vérifiez que les routes à partir 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 adaces (ou routes statiques) entre les routeurs PE et CE sont corrects.
Si vous déterminez que les routes originaires du routeur CE local sont correctes, vérifiez les routes originaires 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 commande pour vérifier l’accessibilité de divers routeurs dans une topologie VPN, et comment utiliser la commande pour vérifier le chemin que les paquets voyagent entre les ping traceroute routeurs VPN.
- Exigences
- Aperçu
- Ping sur le routeur CE depuis un autre CE routeur
- Ping sur les routeurs PE et CE distants à partir du routeur d CE local
- Ping sur un CE à partir d’une interface multiaccès
- Ping sur les routeurs PE connectés directement à partir des CE routeurs
- Ping sur les routeurs CE connectés directement à partir des routeurs PE
- Ping sur le routeur CE distant à partir du routeur PE local
- Dépannage de routes de façon incohérente à partir des interfaces Gigabit Ethernet
Exigences
Cet exemple utilise les composants matériels et logiciels suivants:
M Series routeurs de nouvelle M Series
Junos OS version ultérieure 10.0R1 et ultérieures
Aperçu
Topologie
La topologie de 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.
Ping sur le routeur CE depuis un autre CE routeur
Procédure
Procédure étape par étape
Les exemples suivants décrivent comment utiliser le ping et les commandes pour résoudre les problèmes de traceroute topologies VPN de couche 3. Vous pouvez pinger un CE de l’autre en spécifiant l’adresse loopback de l’autre CE comme adresse IP de la ping commande. Cette commande est réussi si les adresses de bouclure ont été annoncées par les routeurs CE sur leurs ping routeurs PE connectés directement. Le succès de ces commandes signifie également que le routeur CE1 peut ping vers n’importe quel équipement réseau au-delà du ping routeur CE2, et vice versa. La Figure 1 illustre la topologie référencé 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 bouclation du routeur CE1 et l’interface de bouclation 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 msLorsque vous utilisez la commande d’examiner le chemin utilisé par un VPN de couche 3, les routeurs du fournisseur (P) du réseau du fournisseur de services ne sont
traceroutepas affichés. Comme illustré ci-dessus, le saut entre routeur VPN1 et VPN2 s’affiche en tant que saut unique. Le routeur P (VPN3) illustré sur 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: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
Ping sur les routeurs PE et CE distants à partir du routeur CE local
Procédure
Procédure étape par étape
Depuis le routeur local CE, vous pouvez ping les interfaces VPN sur les routeurs PE et CE distants, qui sont des interfaces point à point. La Figure 1 illustre la topologie référencé dans les exemples suivants:
Routeur PING CE2 depuis le 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 depuis l’interface de loopback du routeur CE1 vers l’interface directement connectée du 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 msRouteur Ping PE2 (VPN2) à partir du routeur CE1 (VPN4). Dans ce cas, les paquets originaires du routeur CE1 sont envoyés au routeur PE2, puis au routeur CE2, puis au routeur PE2 avant que le routeur PE2 ne puisse répondre aux demandes ICMP (Internet Control Message Protocol). Vous pouvez vérifier cela à 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
Ping sur un CE à partir d’une interface multiaccess
Procédure
Procédure étape par étape
Vous ne pouvez pas ping CE routeur de l’autre si l’interface VPN est une interface multiaccess, telle que fe-1/1/2.0 l’interface du routeur CE1. Pour ping vers le routeur CE1 depuis le routeur CE2, vous devez soit inclure l’instruction au niveau de la hiérarchie sur le routeur PE1, soit configurer un routeur statique sur le routeur PE1 vers l’interface VPN du routeur vrf-table-label [edit routing-instances routing-instance-name] CE1. Si vous ajoutez vrf-table-label l’instruction de ping vers 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 saut suivant doit pointer vers le routeur CE1 (au niveau hiérarchique) et cette route doit être annoncée du routeur PE1 au routeur PE2, comme indiqué dans la
[edit routing-instance routing-instance-name]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 désormais utiliser le routeur CE1 depuis le 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
Ping sur les routeurs PE connectés directement à partir des CE routeurs
Procédure
Procédure étape par étape
À partir des interfaces de bouclation des routeurs CE, vous pouvez ping l’interface VPN sur le routeur PE connecté directement. La Figure 1 illustre la topologie référencé dans cette procédure:
Depuis l’interface loopback du routeur CE1 (VPN4), le ping de l’interface VPN,
fe-1/1/0.0sur 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
Depuis l’interface loopback du routeur CE2 (VPN5), le ping de l’interface VPN,
t3-0/0/3.0sur 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
Depuis l’interface loopback du routeur CE2 (VPN5), le ping de l’interface VPN,
t3-0/0/3.0sur 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 depuis l’interface de bouclure du routeur CE2 vers 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
Ping sur les routeurs CE connectés directement à partir des routeurs PE
Procédure
Procédure étape par étape
À partir des interfaces VPN et loopback des routeurs PE, vous pouvez ping l’interface VPN sur le routeur connecté CE direct. La Figure 1 illustre la topologie référencé dans cette procédure:
À partir de l’interface VPN du routeur PE (routeur PE1), vous pouvez ping vers l’interface VPN ou loopback sur le routeur CE connecté directement (routeur CE1).
Depuis l’interface VPN du routeur PE1 (VPN1), ping l’interface VPN,
fe-1/1/0.0sur 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
Depuis l’interface VPN du routeur PE1 (VPN1), ping l’interface de bouclure,
10.255.10.4sur 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 respectivement le chemin depuis l’interface VPN du routeur PE1 vers les interfaces VPN et loopback du routeur CE1, utilisez les commandes
traceroutesuivantes: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
Depuis l’interface VPN du routeur PE2 (VPN2), ping l’interface VPN,
t3-0/0/3.0sur 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
Depuis l’interface VPN du routeur PE2 (VPN2), ping l’interface de bouclure,
10.255.10.5sur 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 respectivement le chemin depuis l’interface VPN du routeur PE2 vers les interfaces VPN et loopback du routeur CE2, utilisez les commandes
traceroutesuivantes: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
Ping sur le routeur CE distant à partir du routeur PE local
Procédure
Procédure étape par étape
La procédure suivante n’est efficace que pour les VPN de couche 3. Pour ping vers 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 loopback.
Pour configurer une unité logique supplémentaire sur l’interface de bouclisation du routeur PE, configurez l’énoncé au niveau
unit[edit interfaces lo0]de la hiérarchie:[edit interfaces] lo0 { unit number { family inet { address address; } } }Configurez l’interface de bouclure pour l’instance de routage VPN de couche 3 sur le routeur PE local. Vous pouvez associer une interface de loopback logique à chaque instance de routage VPN de couche 3, ce qui vous permet de ping sur une instance de routage spécifique sur un routeur.
Indiquez l’interface de bouclisation que vous avez configurée à l’étape 1 en utilisant
interfacel’instruction au niveau de la[edit routing-instances routing-instance-name]hiérarchie:[edit routing-instances routing-instance-name] interface interface-name;
Il
interface-names’agit de l’unité logique de l’interface loopback (parlo0.1exemple).À partir de l’interface VPN du routeur PE, vous pouvez désormais ping vers l’unité logique de l’interface loopback du routeur CE distant:
user@host> ping interface interface host
Utilisez
interfacepour spécifier la nouvelle unité logique de l’interface de bouclation (par exemple,lo0.1). Pour plus d’informations sur l’utilisation de la commande, consultez la référence deping interfacecommande Interfaces Junos.
Dépannage de routes de façon incohérente à partir des 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, le Junos OS tente de localiser un routeur CE qui peut être désigné comme saut suivant. Si cela ne peut pas être fait, les routes annoncées à partir des interfaces Gigabit Ethernet sont abandonnées.
Dans de tels cas:
Utilisez l’instruction au niveau ou au niveau hiérarchique de l’instance de routage VRF sur un routeur CE du sous-réseau LAN, en configurant le routeur CE comme saut
static[edit routing-options][edit logical-systems logical-system-name routing-options]suivant. Tout le trafic qui se dirige vers les destinations directes de ce réseau se CE routeur. Vous pouvez ajouter deux routes statiques à deux routeurs CE sur le lan pour obtenir une redondance.Configurez l’énoncé au niveau de la hiérarchie pour mapgraphier le label interne d’un paquet vers une table de
vrf-table-label[edit routing-instances routing-instance-name]routage VRF spécifique. Cela permet d’examiner l’en-tête IP encapsulé pour forcer des recherches IP sur l’instance de routage VRF pour l’ensemble du trafic.Note:L’instruction n’est pas disponible pour toutes les interfaces de cœur de réseau ; par exemple, les interfaces canalisées
vrf-table-labelne sont pas prises en charge. Voir filtrage des paquets dans les VPN de couche 3 Basé sur les en-têtes IP pour plus d’informations sur la prise en charge de l’énoncé sur Ethernet et lesvrf-table-labelinterfaces SONET/SDH.
Exemple: Diagnostic des problèmes réseau liés aux VPN de couche 3 en désactivant la décrétisation TTL
Cet exemple montre comment désactiver la décrétation 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. Consultez le 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étisation TTL (Normal Time-to-Live). L’en-tête IP inclut un champ TTL qui sert de compteur de saut. À chaque saut acheminé, le TTL est décrété par un ; si le TTL atteint zéro avant que le paquet n’atteigne sa destination, le paquet est éliminé et (facultatif) un message TTL ICMP dépassé est envoyé à la source. MPLS étiquettes ont également un champ TTL. MPLS routeurs de nouvelle version copient le TTL d’un paquet IP lorsqu’ils pénètrent dans un chemin de commutation d’étiquettes (LSP). Un paquet IP contenant un TTL de 27 reçoit MPLS étiquette avec un TTL de 27. Junos OS déconsenement de la MPLS TTL d’un paquet MPLS encapsulé en lieu et place de l’IP TTL, à chaque saut de commutation d’étiquettes. Étant donné que MPLS TTL est copié (ou propagé) à partir de l’IP TTL, un traceroute répertorie chaque saut du chemin, qu’il soit acheminé ou commuté par étiquette. Lorsque le paquet quittera le LSP, le décrémenté MPLS TTL est propagé dans le champ IP TTL.
Par défaut, la propagation TTL est activée. L’énoncé global désactive la propagation TTL au niveau du routeur et affecte tous les no-propagate-ttl LSP signalés par RSVP ou LDP. Lorsqu’un routeur fait office de routeur d’entrée pour un LSP et que la configuration du routeur inclut l’instruction, le routeur pousse un en-tête MPLS avec une valeur TTL de 255, indépendamment du TTL de paquet no-propagate-ttl IP. Lorsqu’un routeur fait office d’avant-dernier routeur, il insère l’en-MPLS sans avoir à propager l’MPLS TTL dans le paquet IP. Ainsi, la valeur TTL de 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 prend l’priorité sur la configuration globale du routeur. Si vous désactivez la propagation TTL sur le routeur et activez expressément la propagation TTL pour une seule instance de routage VRF, la propagation TTL est en vigueur pour cette instance de routage. Pour permettre la propagation TTL sur une instance de routage VRF, inclure vrf-propagate-ttl l’instruction dans l’instance de routage.
Lorsque vous modifiez le comportement de propagation TTL, les anciens sauts suivants pour les routes VRF sont supprimés de la table de routage inet.3 et de nouveaux sauts sont ajoutés.
Vous devez uniquement configurer vrf-propagate-ttl l’ou no-vrf-propagate-ttl l’instruction sur les routeurs d’entrée.
Schéma de topologie
La figure 2 illustre la topologie utilisée dans cet exemple. Le routeur PE1 et le routeur PE2 sont deux VPN---VPN-A et VPN-B. Les équipements CE1 et CE4 appartiennent à VPN-A. Les équipements CE2 et CE5 appartiennent à VPN-B. Dans cet exemple, la propagation TTL du routeur PE1 est désactivée sur VPN-A mais pas sur VPN-B. Les paquets reçus par PE1 sur l’interface connectée au CE1 ont une propagation TTL désactivée. Cet exemple illustre la configuration du routeur PE1. Il n’est pas nécessaire d’inclure l’énoncé sur le routeur de no-vrf-propagate-ttl sortie (PE2).
Configuration
Procédure
CLI configuration rapide
Pour désactiver rapidement la propagation TTL dans une instance de routage VRF, copiez les commandes suivantes et collez les commandes dans le CLI.
[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 dans différents niveaux de la hiérarchie de configuration. Pour plus d’informations sur la navigation du CLI, consultez lemanuel Using the CLI Editor in Configuration Mode .
Pour configurer une carte de flux:
Configurez l’interface de bouclation.
[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 BGP voisin interne est l’adresse d’interface de bouclure du routeur PE2 dans 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
no-vrf-propagate-ttll’instruction dans 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é la configuration de l’équipement, commit the configuration.
[edit] user@PE1# commit
Résultats
Confirmez votre configuration en entrant les show interfaces show policy-options commandes , et show protocols show routing-instances show routing-options les
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 le fonctionnement, exécutez les commandes suivantes:
Voir le
TTL Actionchamp dans le résultat de lashow route extensive table VPN-Acommande.Voir le
TTL Actionchamp dans le résultat de lashow route extensive table VPN-Bcommande.Sur l’équipement CE1, exécutez la
traceroutecommande jusqu’à l’adresse loopback de l’équipement CE4.Sur l’équipement CE4, exécutez la
traceroutecommande jusqu’à l’adresse loopback de l’équipement CE1.