Fehlerbehebung bei Layer 3-VPNs
Diagnose häufiger Layer-3-VPN-Probleme
Problem
Beschreibung
Um Probleme in der Layer-3-VPN-Konfiguration zu beheben, beginnen Sie an einem Ende des VPN (dem lokalen Kunden-Edge [CE]-Router) und folgen Sie den Routen zum anderen Ende des VPN (dem Remote-CE-Router).
Lösung
Die folgenden Schritte zur Fehlerbehebung sollten Ihnen bei der Diagnose allgemeiner Probleme helfen:
Wenn Sie ein Routing-Protokoll zwischen den lokalen Provider-Edge -Routern (PE) und CE-Routern konfiguriert haben, überprüfen Sie, ob Peering und Adjacency vollständig in Betrieb sind. Geben Sie dabei den Namen der Routing-Instanz an. Geben Sie beispielsweise den Befehl auf dem PE-Router ein, um die
show ospf neighbor instance routing-instance-nameOSPF-Adjacencies zu überprüfen.Wenn Peering und Adjacency nicht vollständig in Betrieb sind, überprüfen Sie die Routing-Protokollkonfiguration auf dem CE-Router und überprüfen Sie die Routing-Protokollkonfiguration für die zugehörige VPN-Routing-Instanz auf dem PE-Router.
Prüfen Sie, ob sich die lokalen CE- und PE-Router gegenseitig anpingen können.
Um zu überprüfen, ob der lokale CE-Router die VPN-Schnittstelle auf dem lokalen PE-Router pingen kann, verwenden Sie einen
pingBefehl im folgenden Format, geben Sie die IP-Adresse oder den Namen des PE-Routers an:user@host> ping (ip-address | host-name)
Um zu überprüfen, ob der lokale PE-Router den CE-Router pingen kann, verwenden Sie einen
pingBefehl im folgenden Format, indem Sie die IP-Adresse oder den Namen des CE-Routers, den Namen der für das VPN verwendeten Schnittstelle und die Quell-IP-Adresse (die lokale Adresse) in ausgehenden Echo-Anforderungspaketen angeben:user@host> ping ip-address interface interface local echo-address
Oft muss das Peering oder die Zusammenarbeit zwischen den lokalen CE- und lokalen PE-Routern her, bevor ein
pingBefehl erfolgreich ist. Um zu überprüfen, ob ein Link in einer Laborumgebung funktionsfähig ist, entfernen Sie die Schnittstelle aus der VPN-Routing- und Weiterleitungsumgebung (VRF), indem Sie dieinterfaceAnweisung aus der[edit routing-instance routing-instance-name]Hierarchieebene löschen und die Konfiguration erneut einfügen. Dadurch wird die Schnittstelle vom VPN entfernt. Versuchen Sie dann den ping Befehl erneut. Wenn der Befehl erfolgreich ist, konfigurieren Sie die Schnittstelle wieder in das VPN und überprüfen Sie die Routing-Protokollkonfiguration auf den lokalen CE- und PE-Routern erneut.Prüfen Sie auf dem lokalen PE-Router, ob sich die Routen vom lokalen CE-Router in der VRF-Tabelle (routing-instance-name.inet.0) befinden:
user@host> show route table routing-instance-name.inet.0 <detail>
Das folgende Beispiel zeigt die Routing-Tabelleneinträge. Hier ist
10.255.14.155/32die Loopback-Adresse des CE-Routers und das Routing-Protokoll zwischen den PE- und CE-Routern BGP. Der Eintrag sieht aus wie jede gewöhnliche BGP-Ankündigung.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.155Wenn die Routen des lokalen CE-Routers in der VRF-Routingtabelle nicht vorhanden sind, überprüfen Sie, ob der CE-Router Routen zum PE-Router annorbt. Wenn statisches Routing zwischen den CE- und PE-Routern verwendet wird, stellen Sie sicher, dass die richtigen statischen Routen konfiguriert sind.
Prüfen Sie auf einem entfernten PE-Router, ob die Routen vom lokalen CE-Router in der Routingtabelle bgp.l3vpn.0 vorhanden sind:
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.0Die Ausgabe des
show route table bgp.l3vpn.0 extensiveBefehls enthält die folgenden VPN-spezifischen Informationen:Im Prefix-Namen (der ersten Zeile der Ausgabe) wird der Routenscheider zum Routenpräfix des lokalen CE-Routers hinzugefügt. Da der Routenscheider innerhalb des Internets eindeutig ist, liefert die Verkettung von Routenscheider und IP-Präfix eindeutige VPN-IP Version 4 (IPv4)-Routing-Einträge.
Das
Route DistinguisherFeld listet den Routenscheider separat von der VPN-IPv4-Adresse auf.Das
label-switched-pathFeld zeigt den Namen des Label-Switched Path (LSP), der zur Übertragung des VPN-Datenverkehrs verwendet wird.Das
PushFeld zeigt beide Label, die im VPN-IPv4-Paket übertragen werden. Das erste Label ist das innere Label, also das VPN-Label, das vom PE-Router zugewiesen wurde. Das zweite Label ist das äußere Label, bei dem es sich um ein RSVP-Label handelt.Das
CommunitiesFeld listet die Ziel-Community auf.Das
Secondary tablesFeld listet weitere Routing-Tabellen auf diesem Router auf, in dem diese Route installiert wurde.
Wenn in der Routingtabelle bgp.l3vpn.0 auf dem entfernten PE-Router keine Routen vom lokalen CE-Router vorhanden sind, gehen Sie wie folgt vor:
Überprüfen Sie den VRF-Importfilter auf dem entfernten PE-Router, der in der
vrf-importAnweisung konfiguriert ist. (Auf dem lokalen PE-Router überprüfen Sie den VRF-Exportfilter, der mit dervrf-exportAnweisung konfiguriert ist.)Prüfen Sie, ob ein betrieblicher LSP oder ein LDP-Pfad zwischen den PE-Routern vorhanden ist. Überprüfen Sie dazu, ob sich die IBGP-Next-Hop-Adressen in der Tabelle inet.3 befinden.
Prüfen Sie, ob die IBGP-Sitzung zwischen den PE-Routern richtig eingerichtet und konfiguriert ist.
Suchen Sie nach "versteckten" Routen, was normalerweise bedeutet, dass Routen nicht richtig gekennzeichnet wurden. Verwenden Sie dazu den
show route table bgp.l3vpn.0 hiddenBefehl.Prüfen Sie, ob das innere Label mit dem inneren VPN-Label übereinstimmt, das vom lokalen PE-Router zugewiesen wird. Verwenden Sie dazu den
show route table mplsBefehl.
Das folgende Beispiel zeigt die Ausgabe dieses Befehls auf dem PE-Remote-Router. Hier ist
100004das innere Label .... Push 100004, Push 10005 (top)
Das folgende Beispiel zeigt die Ausgabe dieses Befehls auf dem lokalen PE-Router, was zeigt, dass das innere Label von
100004mit dem inneren Label auf dem entfernten PE-Router übereinstimmt:... 100004 *[VPN/7] 06:56:25, metric 1 > to 192.168.197.141 via fe-1/0/0.0, Pop
Prüfen Sie auf dem entfernten PE-Router, ob die Routen des lokalen CE-Routers in der VRF-Tabelle (routing-instance-name.inet.0) vorhanden sind:
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.0In dieser Routingtabelle ist der Routenscheider dem Präfix nicht mehr vorgeprägt. In der letzten Zeile wird die Tabelle aufgeführt,
Primary Routing Tableaus der diese Route gelernt wurde.Wenn die Routen in dieser Routing-Tabelle nicht vorhanden sind, aber in der Routingtabelle bgp.l3vpn.0 auf dem lokalen CE-Router vorhanden waren, haben die Routen möglicherweise nicht die VRF-Importrichtlinie auf dem entfernten PE-Router bestanden.
Wenn eine VPN-IPv4-Route mit keiner
vrf-importRichtlinie übereinstimmt, wird die Route überhaupt nicht in der bgp.l3VPN-Tabelle angezeigt und ist daher in der VRF-Tabelle nicht vorhanden. Wenn dies der Fall ist, kann dies darauf hinweisen, dass Sie auf dem PE-Router eine weiterevrf-importAnweisung für ein anderes VPN konfiguriert haben (mit einem gemeinsamen Ziel), und die Routen werden in der Tabelle bgp.l3VPN.0 angezeigt, aber in das falsche VPN importiert.Prüfen Sie auf dem Remote-CE-Router, ob die Routen vom lokalen CE-Router in der Routing-Tabelle (inet.0) vorhanden sind:
user@host> show route
Wenn die Routen nicht vorhanden sind, überprüfen Sie die Routing-Protokollkonfiguration zwischen den entfernten PE- und CE-Routern und stellen Sie sicher, dass Peers und Adjacencies (oder statische Routen) zwischen den PE- und CE-Routern korrekt sind.
Wenn Sie feststellen, dass die Vom lokalen CE-Router ausgehenden Routen korrekt sind, überprüfen Sie die vom Remote-CE-Router ausgehenden Routen, indem Sie diesen Vorgang wiederholen.
Beispiel: Fehlerbehebung bei Layer 3-VPNs
In diesem Beispiel wird gezeigt, wie Sie mit dem ping Befehl die Zugänglichkeit verschiedener Router in einer VPN-Topologie überprüfen und wie Sie mit dem Befehl überprüfen traceroute können, welchen Pfad Pakete zwischen den VPN-Routern bewegen.
- Anforderungen
- Übersicht
- Pingen des CE-Routers von einem anderen CE-Router
- Pingen der Remote-PE- und CE-Router vom lokalen CE-Router
- Pingen eines CE-Routers über eine Multiaccess-Schnittstelle
- Pingen der direkt verbundenen PE-Router von den CE-Routern
- Pinging der direkt verbundenen CE-Router von den PE-Routern
- Pingen des Remote-CE-Routers vom lokalen PE-Router
- Fehlerbehebung bei inkonsistent angekündigten Routen von Gigabit-Ethernet-Schnittstellen
Anforderungen
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
Router der M-Serie
Junos OS Version 10.0R1 und höher
Übersicht
Topologie
Die in Abbildung 1 dargestellte Topologie veranschaulicht das Netzwerk, das in diesem Beispiel verwendet wird, um zu demonstrieren, wie sie die Ping- und Traceroute-Befehle verwenden, um die Konnektivität zwischen den Routern zu testen, die an einem Layer-3-VPN teilnehmen.
Pingen des CE-Routers von einem anderen CE-Router
Verfahren
Schritt-für-Schritt-Verfahren
Im Folgenden wird beschrieben, wie Sie den Ping und traceroute die Befehle zur Fehlerbehebung bei Layer-3-VPN-Topologien verwenden. Sie können einen CE-Router vom anderen anpingen, indem Sie die Loopback-Adresse des anderen CE-Routers als IP-Adresse im ping Befehl angeben. Dieser ping Befehl ist erfolgreich, wenn die Loopback-Adressen von den CE-Routern ihren direkt angeschlossenen PE-Routern angekündigt wurden. Der Erfolg dieser ping Befehle bedeutet auch, dass Router CE1 alle Netzwerkgeräte über Router CE2 hinaus anpingen kann und umgekehrt. Abbildung 1 zeigt die Topologie, auf die in den folgenden Schritten verwiesen wird:
Ping-Router CE2 (VPN5) vom Router 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
Verwenden
tracerouteSie den Folgenden Befehl, um den Pfad von der Loopback-Schnittstelle des Routers CE1 zur Loopback-Schnittstelle des Routers CE2 zu bestimmen: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 msWenn Sie den
traceroutevon einem Layer-3-VPN verwendeten Pfad mit dem Befehl untersuchen, werden die Provider (P)-Router im Netzwerk des ServiceAnbieters nicht angezeigt. Wie oben dargestellt, wird der Sprung von Router VPN1 zu Router VPN2 als single Hop angezeigt. Der in Abbildung 1 dargestellte P-Router (VPN3) wird nicht angezeigt.Ping-Router CE1 (VPN4) vom Router 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
Verwenden
tracerouteSie den folgenden Befehl, um den Pfad vom Router CE2 zum Router CE1 zu bestimmen: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
Pingen der Remote-PE- und CE-Router vom lokalen CE-Router
Verfahren
Schritt-für-Schritt-Verfahren
Über den lokalen CE-Router können Sie die VPN-Schnittstellen der entfernten PE- und CE-Router anpingen, bei denen es sich um Punkt-zu-Punkt-Schnittstellen handelt. Abbildung 1 zeigt die Topologie, auf die in den folgenden Beispielen verwiesen wird:
Ping-Router CE2 vom Router 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
Verwenden
tracerouteSie den Folgenden Befehl, um den Pfad von der Loopback-Schnittstelle des Routers CE1 zur direkt angeschlossenen Schnittstelle des Routers CE2 zu bestimmen: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 msPing-Router PE2 (VPN2) vom Router CE1 (VPN4). In diesem Fall gehen Pakete, die von Router CE1 stammen, zu Router PE2, dann zu Router CE2 und zurück zu Router PE2, bevor Router PE2 auf ICMP-Anforderungen (Internet Control Message Protocol) reagieren kann. Sie können dies mithilfe des
tracerouteBefehls überprüfen.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
Verwenden
tracerouteSie den folgenden Befehl, um den Pfad von Router CE1 zu Router PE2 zu bestimmen: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
Pingen eines CE-Routers über eine Multiaccess-Schnittstelle
Verfahren
Schritt-für-Schritt-Verfahren
Sie können einen CE-Router nicht vom anderen pingen, wenn es sich bei der VPN-Schnittstelle um eine Multiaccess-Schnittstelle handelt, wie z. B. die fe-1/1/2.0 Schnittstelle am Router CE1. Zum Ping des Routers CE1 von Router CE2 müssen Sie entweder die vrf-table-label Anweisung auf [edit routing-instances routing-instance-name] Hierarchieebene auf Router PE1 hinzufügen oder eine statische Route auf Router PE1 zur VPN-Schnittstelle von Router CE1 konfigurieren. Wenn Sie die vrf-table-label Anweisung zum Ping eines Routers einschließen, können Sie keine statische Route konfigurieren.
Wenn Sie eine statische Route auf Router PE1 zur VPN-Schnittstelle des Routers CE1 konfigurieren, muss der nächste Hop auf Router CE1 (auf
[edit routing-instance routing-instance-name]Hierarchieebene) zeigen, und diese Route muss von Router PE1 zu Router PE2 angekündigt werden, wie in der folgenden Konfiguration dargestellt:[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; } } } }Jetzt können Sie Router CE1 vom Router CE2 anpingen:
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
Um den Pfad zwischen diesen beiden Schnittstellen zu bestimmen, verwenden Sie den
tracerouteFolgenden Befehl: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
Pingen der direkt verbundenen PE-Router von den CE-Routern
Verfahren
Schritt-für-Schritt-Verfahren
Von den Loopback-Schnittstellen auf den CE-Routern können Sie die VPN-Schnittstelle am direkt angeschlossenen PE-Router anpingen. Abbildung 1 zeigt die Topologie, auf die in diesem Verfahren verwiesen wird:
Von der Loopback-Schnittstelle auf Router CE1 (VPN4), Ping der VPN-Schnittstelle,
fe-1/1/0.0, auf Router 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
Von der Loopback-Schnittstelle auf Router CE2 (VPN5), Ping der VPN-Schnittstelle,
t3-0/0/3.0, auf Router 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
Von der Loopback-Schnittstelle auf Router CE2 (VPN5), Ping der VPN-Schnittstelle,
t3-0/0/3.0, auf Router 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
Verwenden
tracerouteSie den Folgenden Befehl, um den Pfad von der Loopback-Schnittstelle auf Router CE2 zu den VPN-Schnittstellen auf Router PE2 zu bestimmen: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
Pinging der direkt verbundenen CE-Router von den PE-Routern
Verfahren
Schritt-für-Schritt-Verfahren
Von den VPN- und Loopback-Schnittstellen auf den PE-Routern können Sie die VPN-Schnittstelle am direkt angeschlossenen CE-Router anpingen. Abbildung 1 zeigt die Topologie, auf die in diesem Verfahren verwiesen wird:
Über die VPN-Schnittstelle des PE-Routers (Router PE1) können Sie die VPN- oder Loopback-Schnittstelle am direkt angeschlossenen CE-Router (Router CE1) anpingen.
Von der VPN-Schnittstelle auf Router PE1 (VPN1), Ping der VPN-Schnittstelle,
fe-1/1/0.0, auf Router 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
Von der VPN-Schnittstelle auf Router PE1 (VPN1), Ping der Loopback-Schnittstelle,
10.255.10.4, auf Router 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
Um den Pfad von der VPN-Schnittstelle auf Router PE1 zu den VPN- bzw. Loopback-Schnittstellen auf Router CE1 zu bestimmen, verwenden Sie die folgenden
tracerouteBefehle: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
Von der VPN-Schnittstelle auf Router PE2 (VPN2), Ping der VPN-Schnittstelle,
t3-0/0/3.0, auf Router 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
Von der VPN-Schnittstelle auf Router PE2 (VPN2), Ping der Loopback-Schnittstelle,
10.255.10.5, auf Router 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
Um den Pfad von der VPN-Schnittstelle auf Router PE2 zu den VPN- bzw. Loopback-Schnittstellen auf Router CE2 zu bestimmen, verwenden Sie die folgenden
tracerouteBefehle: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
Pingen des Remote-CE-Routers vom lokalen PE-Router
Verfahren
Schritt-für-Schritt-Verfahren
Das folgende Verfahren ist nur für Layer-3-VPNs wirksam. Um einen Remote-CE-Router von einem lokalen PE-Router in einem Layer-3-VPN anpingen zu können, müssen Sie die folgenden Schnittstellen konfigurieren:
Konfigurieren Sie eine logische Einheit für die Loopback-Schnittstelle.
Um eine zusätzliche logische Einheit auf der Loopback-Schnittstelle des PE-Routers zu konfigurieren, konfigurieren Sie die
unitAnweisung auf[edit interfaces lo0]Hierarchieebene:[edit interfaces] lo0 { unit number { family inet { address address; } } }Konfigurieren Sie die Loopback-Schnittstelle für die Layer-3-VPN-Routing-Instanz auf dem lokalen PE-Router. Sie können jeder Layer-3-VPN-Routing-Instanz eine logische Loopback-Schnittstelle zuordnen, sodass Sie eine bestimmte Routing-Instanz auf einem Router anpingen können.
Geben Sie die Loopback-Schnittstelle, die Sie in Schritt 1 konfiguriert haben, mit der
interfaceAnweisung auf[edit routing-instances routing-instance-name]Hierarchieebene an:[edit routing-instances routing-instance-name] interface interface-name;
Die
interface-nameist die logische Einheit auf der Loopback-Schnittstelle (z. Blo0.1. ).Über die VPN-Schnittstelle des PE-Routers können Sie jetzt die logische Einheit auf der Loopback-Schnittstelle des Remote-CE-Routers anpingen:
user@host> ping interface interface host
Verwenden Sie
interface, um die neue logische Einheit auf der Loopback-Schnittstelle anzugeben (z. Blo0.1. ). Weitere Informationen zur Verwendung desping interfaceBefehls finden Sie in der Junos Interfaces Command Reference.
Fehlerbehebung bei inkonsistent angekündigten Routen von Gigabit-Ethernet-Schnittstellen
Verfahren
Schritt-für-Schritt-Verfahren
Für direkte Routen in einem LAN in einem Layer-3-VPN versucht Das Junos OS, einen CE-Router zu lokalisieren, der als nächster Hop bezeichnet werden kann. Wenn dies nicht möglich ist, werden die angekündigten Routen von Gigabit-Ethernet-Schnittstellen unterbrochen.
In solchen Fällen:
Verwenden Sie die
staticAnweisung auf der[edit logical-systems logical-system-name routing-options][edit routing-options]Hierarchieebene in der VRF-Routinginstanz zu einem CE-Router im LAN-Subnetz und konfigurieren Sie den CE-Router als nächsten Hop. Der gesamte Datenverkehr zu direkt in diesem LAN wird an den CE-Router gehen. Sie können zwei statische Routen zu zwei CE-Routern im LAN hinzufügen, um Redundanz zu erhalten.Konfigurieren Sie die
vrf-table-labelAnweisung auf den[edit routing-instances routing-instance-name]Hierarchieebenen, um das innere Label eines Pakets einer bestimmten VRF-Routingtabelle zu zuordnen. Dies ermöglicht die Untersuchung des gekapselten IP-Headers, um IP-Lookups auf der VRF-Routing-Instanz für den gesamten Datenverkehr zu erzwingen.Hinweis:Die
vrf-table-labelAnweisung ist nicht für jede Core-orientierte Schnittstelle verfügbar, z. B. werden kanalisierte Schnittstellen nicht unterstützt. Informationen zurvrf-table-labelUnterstützung der Aussage über Ethernet- und SONET/SDH-Schnittstellen finden Sie unter Filterung von Paketen in Layer-3-VPNs basierend auf IP-Headern.
Beispiel: Diagnose von Netzwerkproblemen im Zusammenhang mit Layer-3-VPNs durch Deaktivierung der TTL-Dekrementierung
Dieses Beispiel zeigt, wie Sie die TTL-Dekrementierung in einer einzigen VRF-Routing-Instanz in einem Layer-3-VPN-Szenario deaktivieren.
Anforderungen
Bevor Sie beginnen:
Konfigurieren Sie die Routerschnittstellen. Siehe Konfigurationshandbuch für Netzwerkschnittstellen.
Übersicht
Zur Diagnose von Netzwerkproblemen im Zusammenhang mit VPNs kann es nützlich sein, die normale Time-to-Live (TTL)-Dekrementierung zu deaktivieren. Der IP-Header enthält ein TTL-Feld, das als Hopzähler dient. Bei jedem Gerouteten Hop wird die TTL um eins dekrementiert. Wenn die TTL null erreicht, bevor das Paket sein Ziel erreicht, wird das Paket verworfen und (optional) eine ICMP-TTL-Überschreitungsnachricht an die Quelle gesendet. MPLS-Label haben auch ein TTL-Feld. MPLS-Router kopieren die TTL eines IP-Pakets, wenn es einen Label-Switched Path (LSP) eingibt. Ein IP-Paket mit einer TTL von 27 erhält ein MPLS-Label mit einer TTL von 27. Junos OS dekrementiert die MPLS-TTL eines MPLS-gekapselten Pakets anstelle der IP-TTL an jedem Label-Switched Hop. Da die MPLS-TTL von der IP-TTL kopiert (oder weitergegeben) wird, listet ein Traceroute jeden Hop im Pfad auf, sei es geroutet oder label-switched. Wenn das Paket den LSP verlässt, wird die dekrementierte MPLS-TTL wieder in das IP-TTL-Feld weitergegeben.
Standardmäßig ist die TTL-Verbreitung aktiviert. Die globale no-propagate-ttl Anweisung deaktiviert die TTL-Ausbreitung auf Routerebene und wirkt sich auf alle RSVP-signalisierte oder LDP-signalisierte LSPs aus. Wenn ein Router als Eingangsrouter für einen LSP fungiert und die Routerkonfiguration die no-propagate-ttl Anweisung enthält, pusht der Router unabhängig von der IP-Paket-TTL einen MPLS-Header mit einem TTL-Wert von 255. Wenn ein Router als vorletzter Router fungiert, wird der MPLS-Header übertragen, ohne die MPLS-TTL in das IP-Paket zu übertragen. Somit bleibt der IP-Paket-TTL-Wert unabhängig von der Hopanzahl des LSP erhalten.
Anstatt das TTL-Ausbreitungsverhalten auf Routerebene zu konfigurieren, können Sie das Verhalten für die Routen in einer VRF-Routing-Instanz konfigurieren. Dieses Beispiel zeigt, wie Sie die TTL-Verbreitung für die Routen in einer einzigen VRF-Routing-Instanz deaktivieren können, anstatt auf globaler Routerebene.
Die Konfiguration pro VRF hat Vorrang vor der globalen Routerkonfiguration. Wenn Sie die TTL-Ausbreitung auf dem Router deaktivieren und die TTL-Ausbreitung für eine einzige VRF-Routing-Instanz explizit aktivieren, ist die TTL-Ausbreitung für diese Routing-Instanz wirksam. Um die TTL-Verbreitung in einer VRF-Routing-Instanz explizit zu aktivieren, fügen Sie die vrf-propagate-ttl Anweisung in die Routing-Instanz ein.
Wenn Sie das TTL-Ausbreitungsverhalten ändern, werden alte Next Hops für VRF-Routen aus der Routingtabelle inet.3 gelöscht und neue next Hops hinzugefügt.
Sie müssen nur die vrf-propagate-ttl Oder-Anweisung no-vrf-propagate-ttl auf den Eingangsroutern konfigurieren.
Topologiediagramm
Abbildung 2 zeigt die in diesem Beispiel verwendete Topologie. Router PE1 und Router PE2 verfügen über zwei VPNs---VPN-A und VPN-B. Die Geräte CE1 und CE4 gehören zu VPN-A. Die Geräte CE2 und CE5 gehören zu VPN-B. In diesem Beispiel ist die TTL-Verbreitung von Router PE1 auf VPN-A, nicht aber auf VPN-B deaktiviert. Pakete, die von PE1 auf der mit CE1 verbundenen Schnittstelle empfangen werden, haben die TTL-Ausbreitung deaktiviert. Dieses Beispiel zeigt die Konfiguration auf Router PE1. Sie müssen die Anweisung auf dem no-vrf-propagate-ttl Ausgangsrouter (PE2) nicht einschließen.
Konfiguration
Verfahren
CLI-Schnellkonfiguration
Um die TTL-Ausbreitung in einer VRF-Routing-Instanz schnell zu deaktivieren, kopieren Sie die folgenden Befehle und fügen sie in die CLI ein.
[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
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Informationen zum Navigieren in der CLI finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus.
So konfigurieren Sie eine Datenstromzuordnung:
Konfigurieren Sie die Loopback-Schnittstelle.
[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
Konfigurieren Sie die Routing-Protokolle.
Die interne BGP-Neighbor-Adresse ist die Loopback-Schnittstellenadresse des Routers PE2 in Abbildung 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
Konfigurieren Sie Routing-Richtlinien für VPN-A und 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
Konfigurieren Sie die VPN-A- und VPN-B-Routing-Instanzen, einschließlich der
no-vrf-propagate-ttlAnweisung in 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
Definieren Sie das lokale autonome System.
[edit] user@PE1# edit routing-options [edit routing-options] user@PE1# set autonomous-system 1 user@PE1# exit
Wenn Sie mit der Konfiguration des Geräts fertig sind, bestätigen Sie die Konfiguration.
[edit] user@PE1# commit
Ergebnisse
Bestätigen Sie Ihre Konfiguration, indem Sie die show interfacesBefehle , show policy-options, , show protocols, show routing-instancesund show routing-options eingeben.
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;
Überprüfung
Führen Sie die folgenden Befehle aus, um den Vorgang zu überprüfen:
Sehen Sie das
TTL ActionFeld in der Ausgabe desshow route extensive table VPN-ABefehls.Sehen Sie das
TTL ActionFeld in der Ausgabe desshow route extensive table VPN-BBefehls.Führen Sie auf Gerät CE1 den Befehl an die
tracerouteLoopback-Adresse des Geräts CE4 aus.Führen Sie auf Dem Gerät CE4 den Befehl an die
tracerouteLoopback-Adresse des Geräts CE1 aus.