Konfigurieren des Routings zwischen PE- und CE-Routern
Dieses Thema enthält Informationen zum Konfigurieren des Routings auf PE- und CE-Routern in einem Layer 3-VPN.
Konfigurieren des Routings zwischen PE- und CE-Routern in Layer 3-VPNs
Damit der PE-Router VPN-bezogene Routen zu und von verbundenen CE-Routern verteilen kann, müssen Sie das Routing innerhalb der VPN-Routing-Instanz konfigurieren. Sie können ein Routing-Protokoll konfigurieren – BGP, OSPF oder RIP – oder Sie können statisches Routing konfigurieren. Für die Verbindung mit jedem CE-Router konfigurieren Sie in der Regel einen Routingtyp, aber in einigen Fällen können Sie sowohl statische Routen als auch Routingprotokollkonfigurationen einschließen.
In den folgenden Abschnitten wird erläutert, wie das VPN-Routing zwischen den Routern PE und CE konfiguriert wird:
- Konfigurieren von BGP zwischen dem PE- und dem CE-Router
- Konfigurieren von OSPF zwischen dem PE- und dem CE-Router
- Konfigurieren von OSPF-Scheinlinks für Layer 3-VPNs
- Konfigurieren einer OSPF-Domänen-ID
- Konfigurieren von RIP zwischen dem PE- und dem CE-Router
- Konfigurieren statischer Routen zwischen den Routern PE und CE
Konfigurieren von BGP zwischen dem PE- und dem CE-Router
Um BGP als Routingprotokoll zwischen dem PE- und dem CE-Router zu konfigurieren, fügen Sie die bgp folgende Anweisung ein:
bgp {
group group-name {
peer-as as-number;
neighbor ip-address;
}
}
Sie können diese Anweisung auf folgenden Hierarchieebenen einfÃ1/4hren:
[edit routing-instances routing-instance-name protocols][edit logical-systems logical-system-name routing-instances routing-instance-name protocols]Anmerkung:Die Hierarchieebene
[edit logical-systems]gilt nicht für Router der ACX-Serie.Beachten Sie die folgenden Einschränkungen bei der Konfiguration von BGP für Routinginstanzen:
Konfigurieren Sie in einer VRF-Routinginstanz die AS-Nummer (Local Autonomous System) nicht mit einer AS-Nummer, die bereits von einem Remote-BGP-Peer in einer separaten VRF-Routing-Instanz verwendet wird. Dadurch entsteht eine autonome Systemschleife, in der alle von diesem Remote-BGP-Peer empfangenen Routen ausgeblendet werden.
Sie konfigurieren die lokale AS-Nummer entweder mit der
autonomous-systemAnweisung auf der[edit routing-instances routing-instance-name routing-options]Hierarchieebene oder mit derlocal-asAnweisung auf einer der folgenden Hierarchieebenen:[edit routing-instances routing-instance-name protocols bgp][edit routing-instances routing-instance-name protocols bgp group group-name][edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]
Die AS-Nummer für einen BGP-Peer konfigurieren Sie über die
peer-asAnweisung auf der[edit routing-instances routing-instance-name protocols bgp group group-name]Hierarchieebene.
Konfigurieren von OSPF zwischen dem PE- und dem CE-Router
Sie können OSPF (Version 2 oder Version 3) so konfigurieren, dass VPN-bezogene Routen zwischen PE- und CE-Routern verteilt werden.
In den folgenden Abschnitten wird beschrieben, wie OSPF als Routing-Protokoll zwischen dem PE- und dem CE-Router konfiguriert wird:
- Konfigurieren von OSPF Version 2 zwischen dem PE- und dem CE-Router
- Konfigurieren von OSPF Version 3 zwischen dem PE- und dem CE-Router
Konfigurieren von OSPF Version 2 zwischen dem PE- und dem CE-Router
Um OSPF Version 2 als Routing-Protokoll zwischen einem PE- und einem CE-Router zu konfigurieren, fügen Sie die ospf folgende Anweisung ein:
ospf {
area area {
interface interface-name;
}
}
Sie können diese Anweisung auf folgenden Hierarchieebenen einfÃ1/4hren:
[edit routing-instances routing-instance-name protocols][edit logical-systems logical-system-name routing-instances routing-instance-name protocols]Anmerkung:Die Hierarchieebene
[edit logical-systems]gilt nicht für Router der ACX-Serie.
Konfigurieren von OSPF Version 3 zwischen dem PE- und dem CE-Router
Um OSPF Version 3 als Routing-Protokoll zwischen einem PE- und einem CE-Router zu konfigurieren, fügen Sie die ospf3 folgende Anweisung ein:
ospf3 {
area area {
interface interface-name;
}
}
Sie können diese Anweisung auf folgenden Hierarchieebenen einfÃ1/4hren:
[edit routing-instances routing-instance-name protocols][edit logical-systems logical-system-name routing-instances routing-instance-name protocols]Anmerkung:Die Hierarchieebene
[edit logical-systems]gilt nicht für Router der ACX-Serie.
Konfigurieren von OSPF-Scheinlinks für Layer 3-VPNs
Wenn Sie OSPF zwischen den PE- und CE-Routern eines Layer 3-VPN konfigurieren, können Sie auch OSPF-Scheinlinks konfigurieren, um Probleme im Zusammenhang mit OSPF-Verbindungen innerhalb von Bereichen zu kompensieren.
In den folgenden Abschnitten werden OSPF-Scheinlinks und deren Konfiguration beschrieben:
Übersicht über OSPF-Scheinlinks
Abbildung 1 zeigt, wann Sie einen OSPF-Scheinlink konfigurieren können. Router CE1 und Router CE2 befinden sich im selben OSPF-Bereich. Diese CE-Router sind durch ein Layer-3-VPN über Router PE1 und Router PE2 miteinander verbunden. Darüber hinaus sind Router CE1 und Router CE2 über eine Intra-Area-Verbindung verbunden, die als Backup dient.
OSPF behandelt die Verbindung über das Layer-3-VPN als Interarea-Link. Standardmäßig bevorzugt OSPF standortinterne Verbindungen gegenüber standortübergreifenden Verbindungen, sodass OSPF die gebietsinterne Sicherungsverbindung als aktiven Pfad auswählt. Dies ist nicht akzeptabel in Konfigurationen, in denen die bereichsinterne Verbindung nicht der erwartete primäre Pfad für den Datenverkehr zwischen den CE-Routern ist.
Ein OSPF-Scheinlink ist ebenfalls ein Intra-Area-Link, mit dem Unterschied, dass er zwischen den PE-Routern konfiguriert ist, wie in Abbildung 1 dargestellt. Sie können die Metrik für den Scheinlink konfigurieren, um sicherzustellen, dass der Pfad über das Layer 3-VPN einem Backup-Pfad über eine bereichsinterne Verbindung zwischen den CE-Routern vorgezogen wird.
Sie sollten einen OSPF-Scheinlink unter den folgenden Umständen konfigurieren:
-
Zwei CE-Router sind durch ein Layer-3-VPN miteinander verbunden.
-
Diese CE-Router befinden sich im selben OSPF-Bereich.
-
Zwischen den beiden CE-Routern wird eine bereichsinterne Verbindung konfiguriert.
Wenn keine bereichsinterne Verbindung zwischen den CE-Routern besteht, müssen Sie keine OSPF-Scheinverbindung konfigurieren.
Weitere Informationen zu OSPF-Scheinlinks finden Sie im Internetentwurf draft-ietf-l3vpn-ospf-2547-01.txt, OSPF as the PE/CE Protocol in BGP/MPLS-VPNs.
Konfigurieren von OSPF-Scheinlinks
Bei der Scheinverbindung handelt es sich um eine nicht nummerierte Punkt-zu-Punkt-Verbindung innerhalb eines Bereichs, die mittels einer Link-State-Advertisement (LSA) vom Typ 1 beworben wird. Scheinlinks gelten nur für Routinginstanzen und OSPF Version 2.
Jeder Scheinlink wird durch eine Kombination aus der lokalen und Remote-Endpunktadresse des Scheinlinks und dem OSPF-Bereich, zu dem er gehört, identifiziert. Scheinlinks müssen manuell konfiguriert werden. Sie konfigurieren die Scheinverbindung zwischen zwei PE-Routern, die sich beide in derselben VRF-Routinginstanz befinden.
Sie müssen die Adresse für den lokalen Endpunkt des Scheinlinks angeben. Diese Adresse wird als Quelle für die Scheinverbindungspakete verwendet und wird auch vom Remote-PE-Router als Remote-Endpunkt der Scheinverbindung verwendet.
Die lokale Adresse des OSPF-Scheinlinks muss mit einer Loopback-Adresse für das lokale VPN angegeben werden. Die Route zu dieser Adresse muss von BGP weitergegeben werden. Geben Sie die Adresse für den lokalen Endpunkt mit der local-Option der sham-link-Anweisung an:
sham-link { local address; }
Sie können diese Anweisung auf folgenden Hierarchieebenen einfÃ1/4hren:
[Routing-Instanzen routing-instance-name , Protokolle, OSPF bearbeiten]
[Logische Systeme logical-system-name , Routinginstanzen routing-instance-name , Protokolle, OSPF]
Die Remote-Adresse der OSPF-Scheinverbindung muss mit einer Loopback-Adresse für das Remote-VPN angegeben werden. Die Route zu dieser Adresse muss von BGP weitergegeben werden. Um die Adresse für den Remoteendpunkt anzugeben, fügen Sie die Anweisung sham-link-remote ein:
sham-link-remote address <metric number>;
Sie können diese Anweisung auf folgenden Hierarchieebenen einfÃ1/4hren:
[Routing-Instanzen routing-instance-name , Protokolle, OSPF-Bereich area-id]
[Logical-Systems logical-system-name , Routing-Instanzen routing-instance-name , Protokolle, OSPF-Bereich area-id]
Optional können Sie die Metrikoption einschließen, um einen Metrikwert für den Remoteendpunkt festzulegen. Der Metrikwert gibt die Kosten für die Verwendung des Links an. Routen mit niedrigeren Gesamtpfadmetriken werden gegenüber solchen mit höheren Pfadmetriken bevorzugt.
Sie können einen Wert zwischen 1 und 65.535 konfigurieren. Der Standardwert ist 1.
Beispiel für OSPF-Scheinlinks
In diesem Beispiel wird gezeigt, wie OSPF-Scheinlinks auf einem PE-Router aktiviert werden.
Im Folgenden finden Sie die Konfiguration der Loopback-Schnittstelle auf dem PE-Router. Die konfigurierte Adresse gilt für den lokalen Endpunkt des OSPF-Scheinlinks:
[edit]
interfaces {
lo0 {
unit 1 {
family inet {
address 10.1.1.1/32;
}
}
}
}
Im Folgenden finden Sie die Konfiguration der Routinginstanz auf dem PE-Router, einschließlich der Konfiguration für die OSPF-Scheinverbindung. Die lokale Anweisung sham-link wird mit der Adresse für die lokale Loopbackschnittstelle konfiguriert:
[edit]
routing-instances {
example-sham-links {
instance-type vrf;
interface e1-1/0/2.0;
interface lo0.1;
route-distinguisher 3:4;
vrf-import vpn-red-import;
vrf-export vpn-red-export;
protocols {
ospf {
sham-link local 10.1.1.1;
area 0.0.0.0 {
sham-link-remote 10.2.2.2 metric 1;
interface e1-1/0/2.0 metric 1;
}
}
}
}
}
Konfigurieren einer OSPF-Domänen-ID
Für die meisten OSPF-Konfigurationen mit Layer 3-VPNs müssen Sie keine OSPF-Domänen-ID konfigurieren. Bei einem Layer 3-VPN, das mehrere OSPF-Domänen verbindet, kann die Konfiguration von OSPF-Domänen-IDs Ihnen jedoch dabei helfen, die LSA-Übersetzung (für LSAs der Typen 3 und 5) zwischen den OSPF-Domänen und Backdoor-Pfaden zu steuern. Jede VPN-Routing- und Weiterleitungstabelle (VRF) in einem PE-Router, der einer OSPF-Instanz zugeordnet ist, wird mit derselben OSPF-Domänen-ID konfiguriert. Die Standard-OSPF-Domänen-ID ist der NULL-Wert 0.0.0.0. Wie in Tabelle 1 dargestellt, wird eine Route mit einer NULL-Domänen-ID anders behandelt als eine Route ohne Domänen-ID.
Route empfangen |
Domänen-ID der empfangenen Route |
Domänen-ID auf dem empfangenden Router |
Route neu verteilt und angekündigt als |
|---|---|---|---|
Route Typ 3 |
A.B.C.D |
A.B.C.D |
LSA Typ 3 |
Route Typ 3 |
A.B.C.D |
E.F.G.H |
LSA Typ 5 |
Route Typ 3 |
0.0.0.0 |
0.0.0.0 |
LSA Typ 3 |
Route Typ 3 |
Null |
0.0.0.0 |
LSA Typ 3 |
Route Typ 3 |
Null |
Null |
LSA Typ 3 |
Route Typ 3 |
0.0.0.0 |
Null |
LSA Typ 3 |
Route Typ 3 |
A.B.C.D |
Null |
LSA Typ 5 |
Route Typ 3 |
Null |
A.B.C.D |
LSA Typ 3 |
Route Typ 5 |
Nicht zutreffend |
Nicht zutreffend |
LSA Typ 5 |
Sie können eine OSPF-Domänen-ID sowohl für Version 2 als auch für Version 3 von OSPF konfigurieren. Der einzige Unterschied in der Konfiguration besteht darin, dass Sie Anweisungen auf der Hierarchieebene [ edit routing-instances routing-instance-name protocols ospf] für OSPF Version 2 und auf der Hierarchieebene [ edit routing-instances routing-instance-name protocols ospf3] für OSPF Version 3 einschließen. Die folgenden Konfigurationsbeschreibungen enthalten nur die OSPF-Anweisung Version 2. Die Unteranweisungen gelten jedoch auch für OSPF Version 3.
Um eine OSPF-Domänen-ID zu konfigurieren, fügen Sie die domain-id-Anweisung ein:
domain-id domain-Id;
Sie können diese Anweisung auf folgenden Hierarchieebenen einfÃ1/4hren:
[Routing-Instanzen routing-instance-name , Protokolle, OSPF bearbeiten]
[Logische Systeme logical-system-name , Routinginstanzen routing-instance-name , Protokolle, OSPF]
Sie können ein VPN-Tag für die externen OSPF-Routen festlegen, die vom PE-Router generiert werden, um Schleifen zu verhindern. Standardmäßig wird dieses Tag automatisch berechnet und muss nicht konfiguriert werden. Sie können das Domänen-VPN-Tag für LSAs vom Typ 5 jedoch explizit konfigurieren, indem Sie die Anweisung domain-vpn-tag einfügen:
no-domain-vpn-tag number;
Sie können diese Anweisung auf folgenden Hierarchieebenen einfÃ1/4hren:
[Routing-Instanzen routing-instance-name , Protokolle, OSPF bearbeiten]
[Logische Systeme logical-system-name , Routinginstanzen routing-instance-name , Protokolle, OSPF]
Der Bereich reicht von 1 bis 4.294.967.295 (232 – 1). Wenn Sie VPN-Tags manuell festlegen, müssen Sie für alle PE-Router im VPN denselben Wert festlegen.
Ein Beispiel für diese Art der Konfiguration finden Sie unter Konfigurieren einer OSPF-Domänen-ID für ein Layer 3-VPN.
Hub-and-Spoke-Layer 3-VPNs und OSPF-Domänen-IDs
Das Standardverhalten einer OSPF-Domänen-ID verursacht einige Probleme für Hub-and-Spoke-Layer 3-VPNs, die mit OSPF zwischen dem Hub-PE-Router und dem Hub-CE-Router konfiguriert sind, wenn die Routen nicht aggregiert werden. Eine Hub-and-Spoke-Konfiguration verfügt über einen Hub-PE-Router mit direkten Verbindungen zu einem Hub-CE-Router. Der Hub-PE-Router empfängt Layer-3-BGP-Aktualisierungen von den anderen Remote-Spoke-PE-Routern, die in die Spoke-Routing-Instanz importiert werden. Von der Spoke-Routing-Instanz werden die OSPF-LSAs erstellt und an den Hub-CE-Router gesendet.
Der Hub-CE-Router aggregiert diese Routen in der Regel und sendet diese neu erstellten LSAs dann zurück an den Hub-PE-Router. Der Hub-PE-Router exportiert die BGP-Aktualisierungen an die Remote-Spoke-PE-Router, die die aggregierten Präfixe enthalten. Wenn es jedoch nicht aggregierte Typ 3-Zusammenfassungs-LSAs oder externe LSAs gibt, ergeben sich zwei Probleme in Bezug darauf, wie der Hub-PE-Router LSAs erstellt und an den Hub-CE-Router sendet, und wie der Hub-PE-Router die vom Hub-CE-Router empfangenen LSAs verarbeitet:
Standardmäßig ist für alle LSAs, die vom Hub-PE-Router in der Spoke-Routing-Instanz stammen, das DN-Bit festgelegt. Außerdem ist für alle extern stammenden LSAs das VPN-Routing-Tag festgelegt. Durch das Festlegen des DN-Bits und des VPN-Routing-Tags können Routing-Schleifen vermieden werden. Bei Zusammenfassungs-LSAs vom Typ 3 sind Routing-Schleifen kein Problem, da der Hub-CE-Router als Area Border Router (ABR) die LSAs mit dem DN-Bit ohne Bit neu erstellt und an den Hub-PE-Router zurücksendet. Der CE-Router des Hubs erstellt externe LSAs jedoch nicht neu, da sie über einen AS-Flooding-Bereich verfügen.
Sie können die externen LSAs erstellen (bevor Sie sie an den Hub-CE-Router senden), wenn das DN-Bit frei ist und das VPN-Routing-Tag auf 0 festgelegt ist, indem Sie die Routing-Instanzkonfiguration des Hub-PE-Routers ändern. Um das DN-Bit zu löschen und das VPN-Routing-Tag auf externen LSAs, die von einem PE-Router stammen, auf Null zu setzen, konfigurieren Sie 0 für die Anweisung domain-vpn-tag auf der Hierarchieebene [ospf edit routing-instances routing-instance-name protocols]. Sie sollten diese Konfiguration in die Routing-Instanz auf dem Hub-PE-Router einschließen, der dem Hub-CE-Router zugewandt ist, an den die LSAs gesendet werden. Wenn der Hub-CE-Router externe LSAs vom Hub-PE-Router empfängt und diese dann zurück an den Hub-PE-Router weiterleitet, kann der Hub-PE-Router die LSAs in seiner OSPF-Routenberechnung verwenden.
Wenn LSAs, die vom Hub-CE-Router überflutet werden, an der Routing-Instanz des Hub-PE-Routers ankommen, berücksichtigt der Hub-PE-Router, der als ABR fungiert, diese LSAs nicht in seinen OSPF-Routenberechnungen, obwohl für die LSAs die DN-Bits nicht festgelegt sind und für die externen LSAs kein VPN-Routing-Tag festgelegt ist. Es wird angenommen, dass die LSAs aus einem disjunkten Backbone-Bereich stammen.
Sie können die Konfiguration der Routing-Instanz des PE-Routers so ändern, dass sich der PE-Router als Nicht-ABR verhält, indem Sie die disable-Anweisung auf der Hierarchieebene [edit routing-instances routing-instance-name protocols ospf domain-id] einfügen. Sie nehmen diese Konfigurationsänderung an dem Hub-PE-Router vor, der die LSAs vom Hub-CE-Router empfängt.
Durch diese Konfigurationsänderung fungiert die Routing-Instanz des PE-Routers als Nicht-ABR. Der PE-Router betrachtet dann die LSAs, die vom Hub-CE-Router kommen, so, als kämen sie aus einem zusammenhängenden Nicht-Backbone-Bereich.
Konfigurieren von RIP zwischen dem PE- und dem CE-Router
Bei einem Layer 3-VPN können Sie RIP auf dem PE-Router konfigurieren, um die Routen des CE-Routers zu lernen oder die Routen des PE-Routers an den CE-Router weiterzugeben. RIP-Routen, die von Nachbarn gelernt wurden, die auf einer beliebigen [edit routing-instances] Hierarchieebene konfiguriert sind, werden der inet Tabelle der Routing-Instanz (instance_name.inet.0) hinzugefügt.
Um RIP als Routing-Protokoll zwischen dem PE- und dem CE-Router zu konfigurieren, fügen Sie die rip folgende Anweisung ein:
rip {
group group-name {
export policy-names;
neighbor interface-name;
}
}
Sie können diese Anweisung auf folgenden Hierarchieebenen einfÃ1/4hren:
[edit routing-instances routing-instance-name protocols][edit logical-systems logical-system-name routing-instances routing-instance-name protocols]Anmerkung:Die Hierarchieebene
[edit logical-systems]gilt nicht für Router der ACX-Serie.
Standardmäßig kündigt RIP die empfangenen Routen nicht an. Um Routen von einem PE-Router zu einem CE-Router anzukündigen, müssen Sie eine Exportrichtlinie auf dem PE-Router für RIP konfigurieren. Informationen zum Definieren von Richtlinien für RIP finden Sie unter RIP-Importrichtlinie.
Um eine Exportrichtlinie für RIP anzugeben, fügen Sie die export folgende Anweisung ein:
export [ policy-names ];
Sie können diese Anweisung für RIP auf den folgenden Hierarchieebenen einschließen:
[edit routing-instances routing-instance-name protocols rip group group-name][edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name]Anmerkung:Die Hierarchieebene
[edit logical-systems]gilt nicht für Router der ACX-Serie.
Um Routen, die von einer RIP-Routing-Instanz gelernt wurden, in mehrere Routing-Tabellen zu installieren, schließen Sie die rib-group and-Anweisungen group ein:
rib-group inet group-name;
group group-name {
neighbor interface-name;
}
Sie können diese Anweisungen auf den folgenden Hierarchieebenen einschließen:
[edit protocols rip][edit routing-instances routing-instance-name protocols rip][edit logical-systems logical-system-name protocols rip][edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip]
Die Hierarchieebene [edit logical-systems] gilt nicht für Router der ACX-Serie.
Um eine Routing-Tabelle-Gruppe zu konfigurieren, fügen Sie die rib-groups folgende Anweisung ein:
rib-groups group-name;
Sie können diese Anweisung auf folgenden Hierarchieebenen einfÃ1/4hren:
[edit routing-options][edit logical-systems logical-system-name routing-options]
Die Hierarchieebene [edit logical-systems] gilt nicht für Router der ACX-Serie.
Um einer Routing-Tabelle-Gruppe eine Routing-Tabelle hinzuzufügen, schließen Sie die import-rib Anweisung ein. Der erste Name der Routing-Tabelle, der unter der import-rib Anweisung angegeben wird, muss der Name der Routing-Tabelle sein, die Sie konfigurieren. Weitere Informationen zum Konfigurieren von Routing-Tabellen und Routing-Tabellen-Gruppen finden Sie in der Junos OS Routing Protocols Library.
import-rib [ group-names ];
Sie können diese Anweisung auf folgenden Hierarchieebenen einfÃ1/4hren:
[edit routing-options rib-groups group-name][edit logical-systems logical-system-name routing-options rib-groups group-name]
Die Hierarchieebene [edit logical-systems] gilt nicht für Router der ACX-Serie.
RIP-Instances werden nur für VRF-Instance-Typen unterstützt. Sie können mehrere Instanzen von RIP nur für die VPN-Unterstützung konfigurieren. Sie können RIP in der Kunden-Edge-Provider-Edge-Edge-Umgebung (CE-PE) verwenden, um Routen vom CE-Router zu lernen und die Instance-Routen des PE-Routers im CE-Router weiterzugeben.
RIP-Routen, die von Nachbarn gelernt wurden, die unter einer beliebigen Instanzhierarchie konfiguriert sind, werden der Routing-Tabelle der Instanz hinzugefügt. instance-name.inet.0
RIP unterstützt keine Routing-Tabelle Gruppen. Daher können keine Routen in mehrere Tabellen importiert werden, wie dies beim OSPF- oder OSPFv3-Protokoll der Fall ist.
Konfigurieren statischer Routen zwischen den Routern PE und CE
Sie können statische (unveränderliche) Routen zwischen den PE- und CE-Routern einer VPN-Routing-Instanz konfigurieren. Um eine statische Route für ein VPN zu konfigurieren, müssen Sie sie in der Konfiguration der VPN-Routinginstanz auf Hierarchieebene [edit routing-instances routing-instance-name routing-options] konfigurieren.
Um eine statische Route zwischen dem PE- und dem CE-Router zu konfigurieren, fügen Sie die static Anweisung ein:
static {
route destination-prefix {
next-hop [ next-hops ];
static-options;
}
}
Sie können diese Anweisung auf folgenden Hierarchieebenen einfÃ1/4hren:
[edit routing-instances routing-instance-name routing-options][edit logical-systems logical-system-name routing-instances routing-instance-name routing-options]
Die Hierarchieebene [edit logical-systems] gilt nicht für Router der ACX-Serie.
Weitere Informationen zum Konfigurieren von Routing-Protokollen und statischen Routen finden Sie in der Junos OS Routing Protocols Library.
Konfigurieren einer OSPF-Domänen-ID für ein Layer 3-VPN
In diesem Beispiel wird veranschaulicht, wie eine OSPF-Domänen-ID für ein VPN konfiguriert wird, indem OSPF als Routingprotokoll zwischen dem PE- und dem CE-Router verwendet wird. Routen von einer OSPF-Domäne benötigen eine OSPF-Domänen-ID, wenn sie in BGP als VPN-IPv4-Routen in VPNs mit mehreren OSPF-Domänen verteilt werden. In einem VPN, das mehrere OSPF-Domains verbindet, können sich die Routen einer Domain mit den Routen einer anderen überschneiden.
Die Domänen-ID, die in einer Routinginstanz konfiguriert ist, identifiziert die OSPF-Domäne und wird zur Identifizierung des Routenursprungs verwendet. Die Domänen-ID, die für eine Community-Richtlinie konfiguriert ist, wird beim Festlegen exportierter Routen verwendet.
Weitere Informationen zu OSPF-Domänen-IDs und Layer 3-VPNs finden Sie unter Konfigurieren des Routings zwischen PE- und CE-Routern in Layer 3-VPNs.
Abbildung 2 zeigt die Konfigurationstopologie dieses Beispiels. Es wird nur die Konfiguration für Router PE1 bereitgestellt. Die Konfiguration für Router PE2 kann der Konfiguration für Router PE1 ähneln. Es gibt keine besonderen Konfigurationsanforderungen für die CE-Router.
Konfigurationsinformationen finden Sie in den folgenden Abschnitten:
- Konfigurieren von Schnittstellen auf Router PE1
- Konfigurieren von Routing-Optionen auf Router PE1
- Konfigurieren von Protokollen auf Router PE1
- Konfigurieren von Richtlinienoptionen auf Router PE1
- Konfigurieren der Routing-Instanz auf Router PE1
- Konfigurationsübersicht für Router PE1
Konfigurieren von Schnittstellen auf Router PE1
Sie müssen zwei Schnittstellen für Router PE1 konfigurieren: die Schnittstelle für den so-0/0/0 Datenverkehr zu Router CE1 (San Francisco) und die Schnittstelle für den so-0/0/1 Datenverkehr zu einem P-Router im Netzwerk des Service Providers.
Konfigurieren Sie die Schnittstellen für Router PE1:
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.19.1.2/30;
}
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.19.2.1/30;
}
family mpls;
}
}
}
Konfigurieren von Routing-Optionen auf Router PE1
Auf der [edit routing-options] Hierarchieebene müssen Sie die router-id and-Anweisungen autonomous-system konfigurieren. Die router-id Anweisung identifiziert Router PE1.
Konfigurieren Sie die Routing-Optionen für Router PE1:
[edit]
routing-options {
router-id 10.255.14.216;
autonomous-system 65069;
}
Konfigurieren von Protokollen auf Router PE1
Auf Router PE1 müssen Sie MPLS, BGP, OSPF und LDP auf Hierarchieebene [edit protocols] konfigurieren:
[edit]
protocols {
mpls {
interface so-0/0/1.0;
}
bgp {
group San-Francisco-Chicago {
type internal;
preference 10;
local-address 10.255.14.216;
family inet-vpn {
unicast;
}
neighbor 10.255.14.224;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/1.0;
}
}
ldp {
interface so-0/0/1.0;
}
}
Konfigurieren von Richtlinienoptionen auf Router PE1
Auf Router PE1 müssen Sie Richtlinien auf Hierarchieebene [edit policy-options] konfigurieren. Diese Richtlinien stellen sicher, dass die CE-Router im Layer 3-VPN Routing-Informationen austauschen. In diesem Beispiel tauscht Router CE1 in San Francisco Routinginformationen mit Router CE2 in Chicago aus.
Konfigurieren Sie die Richtlinienoptionen auf dem PE1-Router:
[edit]
policy-options {
policy-statement vpn-import-VPN-A {
term term1 {
from {
protocol bgp;
community import-target-VPN-A;
}
then accept;
}
term term2 {
then reject;
}
}
policy-statement vpn-export-VPN-A {
term term1 {
from protocol ospf;
then {
community add export-target-VPN-A;
accept;
}
}
term term2 {
then reject;
}
}
community export-target-VPN-A members [target:10.255.14.216:11 domain-id:192.0.2.1:0];
community import-target-VPN-A members target:10.255.14.224:31;
}
Konfigurieren der Routing-Instanz auf Router PE1
Sie müssen eine Layer-3-VPN-Routing-Instanz auf Router PE1 konfigurieren. Um anzugeben, dass es sich bei der Routing-Instanz um ein Layer 3-VPN handelt, fügen Sie die instance-type vrf Anweisung auf der [edit routing-instance routing-instance-name] Hierarchieebene hinzu.
Die domain-id Anweisung wird auf Hierarchieebene [edit routing-instances routing-options protocols ospf] konfiguriert. Wie in Abbildung 2 dargestellt, muss die Routing-Instanz auf Router PE2 dieselbe Domänen-ID wie die entsprechende Routing-Instanz auf Router PE1 aufweisen, damit Routen von Router CE1 zu Router CE2 und umgekehrt als LSAs vom Typ 3 verteilt werden. Wenn Sie unterschiedliche OSPF-Domänen-IDs in den Routing-Instanzen für Router PE1 und Router PE2 konfigurieren, werden die Routen von jedem CE-Router als LSAs vom Typ 5 verteilt.
Konfigurieren Sie die Routing-Instanz auf Router PE1:
[edit]
routing-instances {
VPN-A-San-Francisco-Chicago {
instance-type vrf;
interface so-0/0/0.0;
route-distinguisher 10.255.14.216:11;
vrf-import vpn-import-VPN-A;
vrf-export vpn-export-VPN-A;
routing-options {
router-id 10.255.14.216;
}
protocols {
ospf {
domain-id 192.0.2.1;
export vpn-import-VPN-A;
area 0.0.0.0 {
interface so-0/0/0.0;
}
}
}
}
}
Konfigurationsübersicht für Router PE1
Konfigurieren von Schnittstellen
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.19.1.2/30;
}
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.19.2.1/30;
}
family mpls;
}
}
}
Konfigurieren von Routing-Optionen
routing-options {
router-id 10.255.14.216;
autonomous-system 65069;
}
Konfigurieren von Protokollen
protocols {
mpls {
interface so-0/0/1.0;
}
bgp {
group San-Francisco-Chicago {
type internal;
preference 10;
local-address 10.255.14.216;
family inet-vpn {
unicast;
}
neighbor 10.255.14.224;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/1.0;
}
}
ldp {
interface so-0/0/1.0;
}
}
VPN-Richtlinie konfigurieren
policy-options {
policy-statement vpn-import-VPN-A {
term term1 {
from {
protocol bgp;
community import-target-VPN-A;
}
then accept;
}
term term2 {
then reject;
}
}
policy-statement vpn-export-VPN-A {
term term1 {
from protocol ospf;
then {
community add export-target-VPN-A;
accept;
}
}
term term2 {
then reject;
}
}
community export-target-VPN-A members [ target:10.255.14.216:11 domain-id:192.0.2.1:0 ];
community import-target-VPN-A members target:10.255.14.224:31;
}
Routing-Instanz für Layer 3-VPN
routing-instances {
VPN-A-San-Francisco-Chicago {
instance-type vrf;
interface so-0/0/0.0;
route-distinguisher 10.255.14.216:11;
vrf-import vpn-import-VPN-A;
vrf-export vpn-export-VPN-A;
routing-options {
router-id 10.255.14.216;
}
protocols {
ospf {
domain-id 192.0.2.1;
export vpn-import-VPN-A;
area 0.0.0.0 {
interface so-0/0/0.0;
}
}
}
}
}
Übersicht über OSPFv2-Scheinlinks
Sie können eine bereichsinterne Verbindung oder eine Scheinverbindung zwischen zwei PE-Routinggeräten (Provider Edge) erstellen, sodass der VPN-Backbone dem Backdoor-Link vorgezogen wird. Ein Backdoor-Link ist ein Backup-Link, der Kunden-Edge-Geräte (CE) verbindet, falls das VPN-Backbone nicht verfügbar ist. Wenn eine solche Sicherungsverbindung verfügbar ist und sich die CE-Geräte im selben OSPF-Bereich befinden, wird diese Sicherungsverbindung standardmäßig dem VPN-Backbone vorgezogen. Dies liegt daran, dass die Backup-Verbindung als Intra-Area-Link betrachtet wird, während der VPN-Backbone immer als Interarea-Link betrachtet wird. Intra-Area-Links werden immer gegenüber Interarea-Links bevorzugt.
Bei der Scheinverbindung handelt es sich um eine nicht nummerierte Punkt-zu-Punkt-Verbindung innerhalb des Bereichs zwischen PE-Geräten. Wenn das VPN-Backbone über eine Scheinverbindung innerhalb eines Bereichs verfügt, kann diese Scheinverbindung dem Sicherungslink vorgezogen werden, wenn der Scheinlink eine niedrigere OSPF-Metrik als die Sicherungsverbindung aufweist.
Der Scheinlink wird mithilfe von Link State Advertisements (LSAs) vom Typ 1 angekündigt. Scheinlinks sind nur für Routinginstanzen und OSPFv2 gültig.
Jeder Scheinlink wird durch die Kombination einer lokalen Endgeräteadresse und einer Remoteendpunktadresse identifiziert. Abbildung 3 zeigt einen OSPFv2-Scheinlink. Router CE1 und Router CE2 befinden sich im selben OSPFv2-Bereich. Diese Kunden-Edge (CE)-Routing-Geräte sind über ein Layer-3-VPN über Router PE1 und Router PE2 miteinander verbunden. Darüber hinaus sind Router CE1 und Router CE2 über eine Intra-Area-Verbindung verbunden, die als Backup dient.
OSPFv2 behandelt die Verbindung über das Layer-3-VPN als Interarea-Link. Standardmäßig bevorzugt OSPFv2 standortinterne Verbindungen gegenüber standortübergreifenden Verbindungen, sodass OSPFv2 die gebietsinterne Sicherungsverbindung als aktiven Pfad auswählt. Dies ist nicht akzeptabel in einer Konfiguration, in der die Verbindung innerhalb des Bereichs nicht der erwartete primäre Pfad für den Datenverkehr zwischen den CE-Routing-Geräten ist. Sie können die Metrik für die Scheinverbindung konfigurieren, um sicherzustellen, dass der Pfad über das Layer-3-VPN einem Backup-Pfad über eine bereichsinterne Verbindung zwischen den CE-Routing-Geräten vorgezogen wird.
Für den Remoteendpunkt können Sie die OSPFv2-Schnittstelle als Bedarfsschaltung konfigurieren, die IPsec-Authentifizierung konfigurieren (die eigentliche IPsec-Authentifizierung wird separat konfiguriert) und den Metrikwert definieren.
Sie sollten einen OSPFv2-Scheinlink unter den folgenden Umständen konfigurieren:
Zwei CE-Routing-Geräte sind über ein Layer-3-VPN miteinander verbunden.
Diese CE-Routing-Geräte befinden sich im selben OSPFv2-Bereich.
Zwischen den beiden CE-Routing-Geräten wird eine bereichsinterne Verbindung konfiguriert.
Wenn keine bereichsinterne Verbindung zwischen den CE-Routing-Geräten vorhanden ist, müssen Sie keine OSPFv2-Scheinverbindung konfigurieren.
In Junos OS Version 9.6 und höher ist ein OSPFv2-Scheinlink in der Routing-Tabelle als versteckte Route installiert. Außerdem wird eine BGP-Route nicht nach OSPFv2 exportiert, wenn ein entsprechender OSPF-Scheinlink verfügbar ist.
In Junos OS Version 16.1 und höher werden OSPF-Scheinlinks auf Standardinstanzen unterstützt. Die Kosten für den Scheinlink werden dynamisch auf die aigp-Metrik der BGP-Route festgelegt, wenn der Benutzer keine Metrik für den Scheinlink konfiguriert hat. Wenn die aigp-metrik nicht in der BGP-Route vorhanden ist, werden die Scheinverbindungskosten standardmäßig auf 1 gesetzt.
Beispiel: Konfigurieren von OSPFv2-Scheinlinks
In diesem Beispiel wird gezeigt, wie OSPFv2-Scheinverbindungen auf einem PE-Routinggerät aktiviert werden.
Anforderungen
Vor der Konfiguration dieses Beispiels ist keine spezielle Konfiguration erforderlich, die über die Geräteinitialisierung hinausgeht.
Überblick
Bei der Scheinverbindung handelt es sich um eine nicht nummerierte Punkt-zu-Punkt-Verbindung innerhalb eines Bereichs, die mittels einer Link-State-Advertisement (LSA) vom Typ 1 beworben wird. Scheinlinks sind nur für Routinginstanzen und OSPFv2 gültig.
Jeder Scheinlink wird durch eine Kombination aus der lokalen Endgeräteadresse und einer Remoteendpunktadresse sowie dem OSPFv2-Bereich, zu dem er gehört, identifiziert. Sie konfigurieren manuell die Scheinverbindung zwischen zwei PE-Geräten, die sich beide in derselben VPN-Routing- und Weiterleitungsinstanz (VRF) befinden, und geben die Adresse für den lokalen Endpunkt der Scheinverbindung an. Diese Adresse wird als Quelle für die Scheinverbindungspakete verwendet und wird auch von dem Remote-PE-Routinggerät als Remoteendpunkt der Scheinverbindung verwendet. Sie können auch die optionale metric Option zum Festlegen eines Metrikwerts für den Remoteendpunkt einschließen. Der Metrikwert gibt die Kosten für die Verwendung des Links an. Routen mit niedrigeren Gesamtpfadmetriken werden gegenüber solchen mit höheren Pfadmetriken bevorzugt.
So aktivieren Sie OSPFv2-Scheinlinks auf einem PE-Routinggerät:
Konfigurieren Sie eine zusätzliche Loopback-Schnittstelle auf dem PE-Routing-Gerät.
Konfigurieren Sie die VRF-Routing-Instanz, die Layer-3-VPNs auf dem PE-Routing-Gerät unterstützt, und ordnen Sie den Scheinlink einem vorhandenen OSPF-Bereich zu. Die OSPFv2-Scheinverbindungskonfiguration ist ebenfalls in der Routinginstanz enthalten. Sie konfigurieren die lokale Endpunktadresse der Scheinverbindung, bei der es sich um die Loopback-Adresse des lokalen VPNs handelt, und die Adresse des Remote-Endgeräts, bei der es sich um die Loopback-Adresse des Remote-VPN handelt. In diesem Beispiel hat die VRF-Routinginstanz den Namen rot.
Abbildung 4 zeigt einen OSPFv2-Scheinlink.
Topologie
Die Geräte in der Abbildung stellen die folgenden Funktionen dar:
CE1 und CE2 sind die Edge-Geräte des Kunden.
PE1 und PE2 sind die Edge-Geräte des Anbieters.
P ist das Provider-Gerät.
Die CLI-Schnellkonfiguration zeigt die Konfiguration für alle Geräte in Abbildung 4. Im Abschnitt Schritt-für-Schritt-Vorgehensweise werden die Schritte auf Gerät PE1 beschrieben.
Konfiguration
Verfahren
CLI Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle erforderlichen Details, damit sie Ihrer Netzwerkkonfiguration entsprechen, und kopieren Sie dann die Befehle, und fügen Sie sie dann in die CLI auf der [edit] Hierarchieebene ein.
CE1
set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.1/30 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 10.0.0.17/30 set interfaces lo0 unit 0 family inet address 192.0.2.1/24 set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 metric 100 set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct then accept set routing-options router-id 192.0.2.1 set routing-options autonomous-system 1
PE1-KARTON
set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.2/30 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 10.1.1.5/30 set interfaces fe-1/2/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.0.2.2/24 set interfaces lo0 unit 1 family inet address 198.51.100.2/24 set protocols mpls interface fe-1/2/1.0 set protocols bgp group toR4 type internal set protocols bgp group toR4 local-address 192.0.2.2 set protocols bgp group toR4 family inet-vpn unicast set protocols bgp group toR4 neighbor 192.0.2.4 set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ldp interface fe-1/2/1.0 set protocols ldp interface lo0.0 set policy-options policy-statement bgp-to-ospf term 1 from protocol bgp set policy-options policy-statement bgp-to-ospf term 1 then accept set policy-options policy-statement bgp-to-ospf term 2 then reject set routing-instances red instance-type vrf set routing-instances red interface fe-1/2/0.0 set routing-instances red interface lo0.1 set routing-instances red route-distinguisher 2:1 set routing-instances red vrf-target target:2:1 set routing-instances red protocols ospf export bgp-to-ospf set routing-instances red protocols ospf sham-link local 198.51.100.2 set routing-instances red protocols ospf area 0.0.0.0 sham-link-remote 198.51.100.4 metric 10 set routing-instances red protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set routing-instances red protocols ospf area 0.0.0.0 interface lo0.1 set routing-options router-id 192.0.2.2 set routing-options autonomous-system 2
P
set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.6/30 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 10.1.1.9/30 set interfaces fe-1/2/1 unit 0 family mpls set interfaces lo0 unit 3 family inet address 192.0.2.3/24 set protocols mpls interface all set protocols ospf area 0.0.0.0 interface lo0.3 passive set protocols ospf area 0.0.0.0 interface all set protocols ldp interface all set routing-options router-id 192.0.2.3
PE2-KARTON
set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.10/30 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 10.1.1.13/30 set interfaces fe-1/2/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.0.2.4/32 set interfaces lo0 unit 1 family inet address 198.51.100.4/32 set protocols mpls interface fe-1/2/0.0 set protocols bgp group toR2 type internal set protocols bgp group toR2 local-address 192.0.2.4 set protocols bgp group toR2 family inet-vpn unicast set protocols bgp group toR2 neighbor 192.0.2.2 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set protocols ldp interface fe-1/2/0.0 set protocols ldp interface lo0.0 set policy-options policy-statement bgp-to-ospf term 1 from protocol bgp set policy-options policy-statement bgp-to-ospf term 1 then accept set policy-options policy-statement bgp-to-ospf term 2 then reject set routing-instances red instance-type vrf set routing-instances red interface fe-1/2/1.0 set routing-instances red interface lo0.1 set routing-instances red route-distinguisher 2:1 set routing-instances red vrf-target target:2:1 set routing-instances red protocols ospf export bgp-to-ospf set routing-instances red protocols ospf sham-link local 198.51.100.4 set routing-instances red protocols ospf area 0.0.0.0 sham-link-remote 198.51.100.2 metric 10 set routing-instances red protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set routing-instances red protocols ospf area 0.0.0.0 interface lo0.1 set routing-options router-id 192.0.2.4 set routing-options autonomous-system 2
CE2
set interfaces fe-1/2/0 unit 14 family inet address 10.1.1.14/30 set interfaces fe-1/2/0 unit 14 family mpls set interfaces fe-1/2/0 unit 18 family inet address 10.0.0.18/30 set interfaces lo0 unit 5 family inet address 192.0.2.5/24 set protocols ospf area 0.0.0.0 interface fe-1/2/0.14 set protocols ospf area 0.0.0.0 interface lo0.5 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.18 set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct then accept set routing-options router-id 192.0.2.5 set routing-options autonomous-system 3
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Weitere Informationen zum Navigieren in der CLI finden Sie unter Ändern der Junos OS-Konfiguration im CLI-Benutzerhandbuch.
So konfigurieren Sie OSPFv2-Scheinlinks auf jedem PE-Gerät:
-
Konfigurieren Sie die Schnittstellen, einschließlich zwei Loopback-Schnittstellen.
[edit interfaces] user@PE1# set fe-1/2/0 unit 0 family inet address 10.1.1.2/30 user@PE1# set fe-1/2/0 unit 0 family mpls user@PE1# set fe-1/2/1 unit 0 family inet address 10.1.1.5/30 user@PE1# set fe-1/2/1 unit 0 family mpls user@PE1# set lo0 unit 0 family inet address 192.0.2.2/24 user@PE1# set lo0 unit 1 family inet address 198.51.100.2/24
-
Konfigurieren Sie MPLS auf der Core-Schnittstelle.
[edit protocols mpls] user@PE1# set interface fe-1/2/1.0
-
Konfigurieren Sie internes BGP (IBGP).
[edit ] user@PE1# set protocols bgp group toR4 type internal user@PE1# set protocols bgp group toR4 local-address 192.0.2.2 user@PE1# set protocols bgp group toR4 family inet-vpn unicast user@PE1# set protocols bgp group toR4 neighbor 192.0.2.4
-
Konfigurieren Sie OSPF auf der Core-Schnittstelle und auf der Loopback-Schnittstelle, die in der Hauptinstanz verwendet wird.
[edit protocols ospf area 0.0.0.0] user@PE1# set interface fe-1/2/1.0 user@PE1# set interface lo0.0 passive
-
Konfigurieren Sie LDP oder RSVP auf der Core-Schnittstelle und auf der Loopback-Schnittstelle, die in der Hauptinstanz verwendet wird.
[edit protocols ldp] user@PE1# set interface fe-1/2/1.0 user@PE1# set interface lo0.0
-
Konfigurieren Sie eine Routing-Richtlinie für die Verwendung in der Routing-Instanz.
[edit policy-options policy-statement bgp-to-ospf] user@PE1# set term 1 from protocol bgp user@PE1# set term 1 then accept user@PE1# set term 2 then reject
-
Konfigurieren Sie die Routing-Instanz.
[edit routing-instances red] user@PE1# set instance-type vrf user@PE1# set interface fe-1/2/0.0 user@PE1# set route-distinguisher 2:1 user@PE1# set vrf-target target:2:1 user@PE1# set protocols ospf export bgp-to-ospf user@PE1# set protocols ospf area 0.0.0.0 interface fe-1/2/0.0
-
Konfigurieren Sie den OSPFv2-Scheinlink.
Schließen Sie die zusätzliche Loopback-Schnittstelle in die Routing-Instanz und auch in die OSPF-Konfiguration ein.
Beachten Sie, dass die Metrik auf der Sham-Link-Schnittstelle auf 10 festgelegt ist. Auf dem Backup-OSPF-Link von Gerät CE1 ist die Metrik auf 100 festgelegt. Dies führt dazu, dass der Scheinlink der bevorzugte Link ist.
[edit routing-instances red] user@PE1# set interface lo0.1 user@PE1# set protocols ospf sham-link local 198.51.100.2 user@PE1# set protocols ospf area 0.0.0.0 sham-link-remote 198.51.100.4 metric 10 user@PE1# set protocols ospf area 0.0.0.0 interface lo0.1
-
Konfigurieren Sie die Nummer des autonomen Systems (AS) und die Router-ID.
[edit routing-options] user@PE1# set router-id 192.0.2.2 user@PE1# set autonomous-system 2
-
Wenn Sie mit der Konfiguration des Geräts fertig sind, bestätigen Sie die Konfiguration.
[edit] user@R1# commit
Befund
Bestätigen Sie Ihre Konfiguration, indem Sie die show interfaces und die show routing-instances Befehle eingeben. Wenn in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.
Ausgang für PE1:
user@PE1# show interfaces
fe-1/2/0 {
unit 0{
family inet {
address 10.1.1.2/30;
}
family mpls;
}
}
fe-1/2/1 {
unit 0 {
family inet {
address 10.1.1.5/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.0.2.2/24;
}
}
unit 1 {
family inet {
address 198.51.100.2/24;
}
}
}
user@PE1# show protocols
mpls {
interface fe-1/2/1.0;
}
bgp {
group toR4 {
type internal;
local-address 192.0.2.2;
family inet-vpn {
unicast;
}
neighbor 192.0.2.4;
}
}
ospf {
area 0.0.0.0 {
interface fe-1/2/1.0;
interface lo0.0 {
passive;
}
}
}
ldp {
interface fe-1/2/1.0;
interface lo0.0;
}
user@PE1# show policy-options
policy-statement bgp-to-ospf {
term 1 {
from protocol bgp;
then accept;
}
term 2 {
then reject;
}
}
user@PE1# show routing-instances
red {
instance-type vrf;
interface fe-1/2/0.0;
interface lo0.1;
route-distinguisher 2:1;
vrf-target target:2:1;
protocols {
ospf {
export bgp-to-ospf;
sham-link local 198.51.100.2;
area 0.0.0.0 {
sham-link-remote 198.51.100.4 metric 10;
interface fe-1/2/0.0;
interface lo0.1;
}
}
}
}
user@PE1# show routing-options router-id 192.0.2.2; autonomous-system 2;
Verifizierung
Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen der Scheinlinkschnittstellen
- Überprüfen der lokalen und Remote-Endpunkte des Scheinlinks
- Überprüfen der Scheinlink-Nachbarschaften
- Überprüfen der Link-State-Ankündigung
- Überprüfen der Pfadauswahl
Überprüfen der Scheinlinkschnittstellen
Zweck
Überprüfen Sie die Scheinlink-Schnittstelle. Der Scheinlink wird in OSPFv2 als Schnittstelle behandelt, wobei der Name als angezeigt wird shamlink.<unique identifier>, wobei der eindeutige Bezeichner eine Zahl ist. Beispiel: shamlink.0. Der Scheinlink wird als Punkt-zu-Punkt-Schnittstelle angezeigt.
Aktion
Geben Sie im Betriebsmodus den show ospf interface instance instance-name Befehl ein.
user@PE1> show ospf interface instance red Interface State Area DR ID BDR ID Nbrs lo0.1 DR 0.0.0.0 198.51.100.2 0.0.0.0 0 fe-1/2/0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1 shamlink.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Überprüfen der lokalen und Remote-Endpunkte des Scheinlinks
Zweck
Überprüfen Sie die lokalen und Remoteendpunkte der Scheinverbindung. Die MTU für die Schein-Link-Schnittstelle ist immer Null.
Aktion
Geben Sie im Betriebsmodus den show ospf interface instance instance-name detail Befehl ein.
user@PE1> show ospf interface shamlink.0 instance red Interface State Area DR ID BDR ID Nbrs shamlink.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1 Type: P2P, Address: 0.0.0.0, Mask: 0.0.0.0, MTU: 0, Cost: 10 Local: 198.51.100.2, Remote: 198.51.100.4 Adj count: 1 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None Protection type: None, No eligible backup Topology default (ID 0) -> Cost: 10
Überprüfen der Scheinlink-Nachbarschaften
Zweck
Überprüfen Sie die Nachbarschaften zwischen den konfigurierten Scheinlinks.
Aktion
Geben Sie im Betriebsmodus den show ospf neighbor instance instance-name Befehl ein.
user@PE1> show ospf neighbor instance red Address Interface State ID Pri Dead 10.1.1.1 fe-1/2/0.0 Full 192.0.2.1 128 35 198.51.100.4 shamlink.0 Full 198.51.100.4 0 31
Überprüfen der Link-State-Ankündigung
Zweck
Vergewissern Sie sich, dass die von der Instance stammende Router-LSA die Scheinlink-Nachbarschaft als nicht nummerierten Punkt-zu-Punkt-Link aufweist. Die Linkdaten für Scheinlinks sind eine Zahl, die von 0x80010000 bis 0x8001ffff reicht.
Aktion
Geben Sie im Betriebsmodus den show ospf database instance instance-name Befehl ein.
user@PE1> show ospf database instance red
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 192.0.2.1 192.0.2.1 0x80000009 1803 0x22 0x6ec7 72
Router 192.0.2.5 192.0.2.5 0x80000007 70 0x22 0x2746 72
Router *198.51.100.2 198.51.100.2 0x80000006 55 0x22 0xda6b 60
Router 198.51.100.4 198.51.100.4 0x80000005 63 0x22 0xb19 60
Network 10.0.0.18 192.0.2.5 0x80000002 70 0x22 0x9a71 32
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 198.51.100.2 198.51.100.4 0x80000002 72 0xa2 0x343 36
Extern *198.51.100.4 198.51.100.2 0x80000002 71 0xa2 0xe263 36
Überprüfen der Pfadauswahl
Zweck
Stellen Sie sicher, dass der Layer 3-VPN-Pfad anstelle des Sicherungspfads verwendet wird.
Aktion
Geben Sie im Betriebsmodus den traceroute Befehl von Gerät CE1 zu Gerät CE2 ein.
user@CE1> traceroute 192.0.2.5
traceroute to 192.0.2.5 (192.0.2.5), 30 hops max, 40 byte packets
1 10.1.1.2 (10.1.1.2) 1.930 ms 1.664 ms 1.643 ms
2 * * *
3 10.1.1.10 (10.1.1.10) 2.485 ms 1.435 ms 1.422 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
4 192.0.2.5 (192.0.2.5) 1.347 ms 1.362 ms 1.329 ms
Bedeutung
Der Traceroute-Vorgang zeigt, dass das Layer-3-VPN der bevorzugte Pfad ist. Wenn Sie den Scheinlink entfernen oder die OSPF-Metrik so ändern, dass dieser Sicherungspfad bevorzugt wird, zeigt die Traceroute an, dass der Sicherungspfad bevorzugt wird.
Konfiguration von EBGP-Multihop-Sitzungen zwischen PE- und CE-Routern in Layer-3-VPNs
Sie können eine EBGP- oder IBGP-Multihop-Sitzung zwischen den PE- und CE-Routern eines Layer-3-VPN konfigurieren. Auf diese Weise können Sie einen oder mehrere Router zwischen den PE- und CE-Routern haben. Die Verwendung von IBGP zwischen PE- und CE-Routern erfordert keine Konfiguration zusätzlicher Anweisungen. Die Verwendung von EBGP zwischen dem PE- und dem CE-Router erfordert jedoch die Konfiguration der multihop Anweisung.
Um eine externe BGP-Multihop-Sitzung für die Verbindung zwischen dem PE- und dem CE-Router zu konfigurieren, fügen Sie die multihop Anweisung auf dem PE-Router ein. Um Routingschleifen zu vermeiden, müssen Sie einen Time-to-Live (TTL)-Wert für die Multihop-Sitzung konfigurieren:
multihop ttl-value;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung konfigurieren können, finden Sie im Zusammenfassungsabschnitt für diese Anweisung.
Konfigurieren einer LDP-over-RSVP-VPN-Topologie
In diesem Beispiel wird gezeigt, wie Sie eine VPN-Topologie einrichten, in der LDP-Pakete über einen RSVP-LSP getunnelt werden. Diese Konfiguration besteht aus den folgenden Komponenten (siehe Abbildung 5):
-
Ein VPN (VPN-A)
-
Zwei PE-Router
-
LDP als Signalisierungsprotokoll zwischen den PE-Routern und ihren benachbarten P-Routern
-
Ein RSVP-LSP zwischen zwei der P-Router, über die LDP getunnelt wird
In den folgenden Schritten wird beschrieben, wie diese Topologie eingerichtet wird und wie Pakete vom CE-Router CE2 an den CE-Router CE1 gesendet werden:
-
Die P-Router P1 und P3 richten untereinander RSVP-LSPs ein und installieren deren Loopback-Adressen in ihren inet.3-Routing-Tabellen.
-
PE-Router PE1 baut eine LDP-Sitzung mit Router P1 über die Schnittstelle
so-1/0/0.0auf. -
Router P1 richtet eine LDP-Sitzung mit der Loopback-Adresse von Router P3 ein, die über den RSVP-LSP erreichbar ist.
-
Router P1 sendet seine Label-Bindungen, die ein Label zum Erreichen von Router PE1 enthalten, an Router P3. Diese Labelbindungen ermöglichen es Router P3, LDP-Pakete an Router PE1 weiterzuleiten.
-
Router P3 baut eine LDP-Sitzung mit Router PE2 über die Schnittstelle
so0-0/0/0.0auf und richtet eine LDP-Sitzung mit der Loopback-Adresse von Router P1 ein. -
Router P3 sendet seine Label-Bindungen, die ein Label zum Erreichen von Router PE2 enthalten, an Router P1. Diese Label-Bindungen ermöglichen es Router P1, LDP-Pakete an die Loopback-Adresse von Router PE2 weiterzuleiten.
-
Die Router PE1 und PE2 bauen IBGP-Sitzungen miteinander auf.
-
Wenn Router PE1 Router PE2 Routen mitteilt, die es von Router CE1 gelernt hat, schließt es seine VPN-Bezeichnung ein. (Der PE-Router erstellt das VPN-Label und bindet es an die Schnittstelle zwischen dem PE- und dem CE-Router.) Ähnlich verhält es sich, wenn Router PE2 Routen ankündigt, die er von Router CE2 gelernt hat, sendet er seine VPN-Bezeichnung an Router PE1.
Wenn Router PE2 ein Paket an Router CE1 weiterleiten möchte, schiebt er zwei Labels auf den Label-Stack des Pakets: Zuerst das VPN-Label, das an die Schnittstelle zwischen Router PE1 und Router CE1 gebunden ist, dann das LDP-Label, das verwendet wird, um Router PE1 zu erreichen. Dann werden die Pakete über die Schnittstelle so-0/0/1.0an Router P3 weitergeleitet.
-
Wenn Router P3 die Pakete von Router PE2 empfängt, tauscht er das LDP-Label aus, das sich oben auf dem Stack befindet (gemäß seiner LDP-Datenbank) und schiebt auch ein RSVP-Label auf die Oberseite des Stacks, sodass das Paket nun vom RSVP-LSP gewechselt werden kann. Zu diesem Zeitpunkt befinden sich drei Bezeichnungen auf dem Stapel: die innere (untere) Bezeichnung ist die VPN-Bezeichnung, die mittlere ist die LDP-Bezeichnung und die äußere (oben) ist die RSVP-Bezeichnung.
-
Router P2 empfängt das Paket und leitet es durch Tauschen des RSVP-Labels an Router P1 weiter. Da Router P2 in dieser Topologie der vorletzte Hop-Router im LSP ist, holt er das RSVP-Label hervor und leitet das Paket über die Schnittstelle
so-1/1/0.0an Router P1 weiter. Zu diesem Zeitpunkt befinden sich zwei Bezeichnungen auf dem Stapel: Die innere Bezeichnung ist die VPN-Bezeichnung und die äußere ist die LDP-Bezeichnung. -
Wenn Router P1 das Paket empfängt, öffnet er das äußere Label (das LDP-Label) und leitet das Paket über die Schnittstelle
so-1/0/0.0an Router PE1 weiter. In dieser Topologie ist Router PE1 der ausgehende LDP-Router, sodass Router P1 das LDP-Label ausgibt, anstatt es durch ein anderes Label zu ersetzen. Zu diesem Zeitpunkt gibt es nur eine Bezeichnung auf dem Stapel, die VPN-Bezeichnung. -
Wenn Router PE1 das Paket empfängt, holt er das VPN-Label hervor und leitet das Paket als IPv4-Paket über die Schnittstelle
ge-1/1/0.0an Router CE1 weiter.
Ein ähnlicher Satz von Vorgängen wird für Pakete ausgeführt, die von Router CE1 gesendet werden und für Router CE2 bestimmt sind.
In der folgenden Liste wird erläutert, wie für Pakete, die von Router CE2 an Router CE1 gesendet werden, die LDP-, RSVP- und VPN-Labels von den verschiedenen Routern angekündigt werden. Diese Schritte enthalten Beispiele für Beschriftungswerte (siehe Abbildung 6).
-
LDP-Labels
-
Router PE1 meldet LDP-Label 3 für sich selbst an Router P1.
-
Router P1 meldet LDP-Label 100.001 für Router PE1 zu Router P3.
-
Router P3 kündigt LDP-Label 100.002 für Router PE1 an Router PE2 an.
-
-
RSVP-Labels
-
Router P1 meldet RSVP-Label 3 an Router P2.
-
Router P2 meldet RSVP-Label 100.003 an Router P3.
-
-
VPN-Label
-
Router PE1 meldet VPN-Label 100.004 an Router PE2 für die Route von Router CE1 zu Router CE2.
-
Etiketten
Für ein Paket, das von Host B in Abbildung 6 an Host A gesendet wird, ändern sich die Paket-Header und -Labels, wenn das Paket an sein Ziel gelangt:
-
Das Paket, das von Host B stammt, hat die Quelladresse B und die Zieladresse A im Header.
-
Router CE2 fügt dem Paket einen nächsten Hop der Schnittstelle
so-1/0/0hinzu. -
Router PE2 tauscht den nächsten Hop der Schnittstelle
so-1/0/0aus und ersetzt ihn durch einen nächsten Hop von PE1. Außerdem werden zwei Labels für das Erreichen von Router PE1 hinzugefügt, zuerst die VPN-Bezeichnung (100.004) und dann die LDP-Bezeichnung (100.002). Das VPN-Label ist also das innere (untere) Label auf dem Stack und das LDP-Label ist das äußere Label. -
Router P3 tauscht das LDP-Label aus, das von Router PE2 (100.002) hinzugefügt wurde, und ersetzt es durch sein LDP-Label, um Router PE1 (100.001) zu erreichen. Außerdem wird das RSVP-Label für das Erreichen von Router P2 (100.003) hinzugefügt.
-
Router P2 entfernt das RSVP-Label (100.003), da es sich dabei um den vorletzten Hop im MPLS-LSP handelt.
-
Router P1 entfernt die LDP-Bezeichnung (100.001), da es sich um den vorletzten LDP-Router handelt. Außerdem wird der nächste Hop von PE1 ausgetauscht und durch die Next-Hop-Schnittstelle ersetzt.
so-1/0/0 -
Router PE1 entfernt die VPN-Bezeichnung (100.004). Außerdem wird die Next-Hop-Schnittstelle von ausgetauscht und durch die Next-Hop-Schnittstelle ersetzt
so-1/0/0.ge-1/1/0 -
Router CE1 entfernt die Next-Hop-Schnittstelle von
ge-1/1/0, und der Paket-Header enthält jetzt nur noch die Quelladresse B und die Zieladresse A.
Im letzten Abschnitt dieses Beispiels werden die Anweisungen zusammengefasst, die zum Konfigurieren der VPN-Funktionalität auf jedem der in Abbildung 5 dargestellten Dienst-P-Router erforderlich sind.
In diesem Beispiel wird eine private AS-Nummer für die Routenunterscheidung und das Routenziel verwendet. Diese Zahl dient nur zur Veranschaulichung. Wenn Sie VPNs konfigurieren, sollten Sie eine zugewiesene AS-Nummer verwenden.
In den folgenden Abschnitten wird erläutert, wie die VPN-Funktionalität auf den PE- und P-Routern konfiguriert wird. Die CE-Router haben keine Informationen über das VPN, daher konfigurieren Sie sie normal.
- Aktivieren einer IGP auf den PE- und P-Routern
- Aktivieren von LDP auf den PE- und P-Routern
- Aktivieren von RSVP und MPLS auf dem P-Router
- Konfigurieren des MPLS-LSP-Tunnels zwischen den P-Routern
- Konfigurieren von IBGP auf den PE-Routern
- Konfigurieren von Routinginstanzen für VPNs auf den PE-Routern
- Konfigurieren der VPN-Richtlinie auf den PE-Routern
- LDP-over-RSVP-VPN-Konfiguration Zusammenfassung nach Router
Aktivieren einer IGP auf den PE- und P-Routern
Damit die PE- und P-Router Routing-Informationen untereinander austauschen können, müssen Sie auf allen diesen Routern oder statische Routen konfigurieren. Sie konfigurieren die IGP auf der primären Instanz des Routingprotokollprozesses (rpd) (d. h. auf der [edit protocols] Hierarchieebene), nicht innerhalb der VPN-Routinginstanz (d. h. nicht auf der [edit routing-instances] Hierarchieebene).
Sie konfigurieren die IGP auf die Standardweise. In diesem Konfigurationsbeispiel ist dieser Teil der Konfiguration nicht enthalten.
Aktivieren von LDP auf den PE- und P-Routern
In diesem Konfigurationsbeispiel ist LDP das Signalisierungsprotokoll zwischen den PE-Routern. Damit das VPN funktioniert, müssen Sie LDP auf den beiden PE-Routern und auf den P-Routern konfigurieren, die mit den PE-Routern verbunden sind. Sie müssen LDP nur auf den Schnittstellen im Core des Netzwerks des Service Providers konfigurieren. d. h. zwischen den PE- und P-Routern und zwischen den P-Routern. Sie müssen LDP auf der Schnittstelle zwischen den PE- und CE-Routern nicht konfigurieren.
In diesem Konfigurationsbeispiel konfigurieren Sie LDP auf den Loopback-Schnittstellen der P-Router, da dies die Schnittstellen sind, auf denen der MPLS-LSP konfiguriert ist.
Auf den PE-Routern müssen Sie auch konfigurieren family inet , wenn Sie die logische Schnittstelle konfigurieren.
Konfigurieren Sie auf Router PE1 LDP:
[edit protocols]
ldp {
interface so-1/0/0.0;
}
[edit interfaces]
so-1/0/0 {
unit 0 {
family mpls;
}
}
Konfigurieren Sie auf Router PE2 LDP:
[edit protocols]
ldp {
interface so-0/0/0.0;
}
[edit interfaces]
so-0/0/1 {
unit 0 {
family mpls;
}
}
Konfigurieren Sie auf Router P1 LDP:
[edit protocols]
ldp {
interface so-1/0/0.0;
interface lo0;
}
Konfigurieren Sie auf Router P3 LDP:
[edit protocols]
ldp {
interface lo0;
interface so-0/0/0.0;
}
Auf Router P2 müssen Sie LDP zwar nicht konfigurieren, aber Sie können es optional so konfigurieren, dass ein Fallback-LDP-Pfad bereitgestellt wird, falls der RSVP-LSP nicht mehr funktionsfähig ist:
[edit protocols]
ldp {
interface so-1/1/0.0;
interface at-2/0/0.0;
}
Aktivieren von RSVP und MPLS auf dem P-Router
Auf dem P-Router P2 müssen Sie RSVP und MPLS konfigurieren, da dieser Router auf dem MPLS-LSP-Pfad zwischen den P-Routern P1 und P3 vorhanden ist:
[edit]
protocols {
rsvp {
interface so-1/1/0.0;
interface at-2/0/0.0;
}
mpls {
interface so-1/1/0.0;
interface at-2/0/0.0;
}
}
Konfigurieren des MPLS-LSP-Tunnels zwischen den P-Routern
In diesem Konfigurationsbeispiel wird LDP über einen RSVP-LSP getunnelt. Daher müssen Sie zusätzlich zur Konfiguration von RSVP die Traffic-Engineering-Unterstützung in einer IGP aktivieren und einen MPLS-LSP erstellen, um den LDP-Datenverkehr zu tunneln.
Aktivieren Sie auf Router P1 RSVP und konfigurieren Sie ein Ende des MPLS-LSP-Tunnels. In diesem Beispiel ist die Unterstützung für Traffic Engineering für OSPF aktiviert, und Sie konfigurieren MPLS auf den Schnittstellen zum LSP und zum Router PE1. In der to Anweisung geben Sie die Loopback-Adresse von Router P3 an.
[edit]
protocols {
rsvp {
interface so-1/0/1.0;
}
mpls {
label-switched-path P1-to-P3 {
to 10.255.100.1;
ldp-tunneling;
}
interface so-1/0/0.0;
interface so-1/0/1.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-1/0/0.0;
interface so-1/0/1.0;
}
}
}
Aktivieren Sie auf Router P3 RSVP und konfigurieren Sie das andere Ende des MPLS-LSP-Tunnels. Auch hier ist die Unterstützung für Traffic Engineering für OSPF aktiviert, und Sie konfigurieren MPLS auf den Schnittstellen zum LSP und zum Router PE2. In der to Anweisung geben Sie die Loopback-Adresse von Router P1 an.
[edit]
protocols {
rsvp {
interface at-2/0/1.0;
}
mpls {
label-switched-path P3-to-P1 {
to 10.255.2.2;
ldp-tunneling;
}
interface at-2/0/1.0;
interface so-0/0/0.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface at-2/0/1.0;
interface so-0/0/0.0;
}
}
}
Konfigurieren von IBGP auf den PE-Routern
Konfigurieren Sie auf den PE-Routern eine IBGP-Sitzung mit den folgenden Eigenschaften:
-
VPN-Familie: Um anzugeben, dass die IBGP-Sitzung für das VPN bestimmt ist, fügen Sie die
family inet-vpnAnweisung ein. -
Loopback-Adresse: Fügen Sie die
local-addressAnweisung hinzu und geben Sie die Loopback-Adresse des lokalen PE-Routers an. Die IBGP-Sitzung für VPNs läuft über die Loopback-Adresse. Außerdem müssen Sie dielo0Schnittstelle auf Hierarchieebene[edit interfaces]konfigurieren. Das Beispiel enthält diesen Teil der Konfiguration des Routers nicht. -
Nachbaradresse: Fügen Sie die
neighborAnweisung hinzu und geben Sie die IP-Adresse des benachbarten PE-Routers an, bei der es sich um seine Loopback-Adresse (lo0) handelt.
Konfigurieren Sie auf Router PE1 IBGP:
[edit]
protocols {
bgp {
group PE1-to-PE2 {
type internal;
local-address 10.255.1.1;
family inet-vpn {
unicast;
}
neighbor 10.255.200.2;
}
}
}
Konfigurieren Sie auf Router PE2 IBGP:
[edit]
protocols {
bgp {
group PE2-to-PE1 {
type internal;
local-address 10.255.200.2;
family inet-vpn {
unicast;
}
neighbor 10.255.1.1;
}
}
}
Konfigurieren von Routinginstanzen für VPNs auf den PE-Routern
Beide PE-Router bedienen VPN-A, daher müssen Sie auf jedem Router eine Routinginstanz für das VPN konfigurieren, in dem Sie Folgendes definieren:
-
Route Distinguisher, der für jede Routinginstanz auf dem PE-Router eindeutig sein muss. Es wird verwendet, um die Adressen in einem VPN von denen in einem anderen VPN zu unterscheiden.
-
Instanztyp von
vrf, der die VRF-Tabelle auf dem PE-Router erstellt. -
Schnittstellen, die mit den CE-Routern verbunden sind.
-
VRF-Import- und Exportrichtlinien, die auf jedem PE-Router, der dasselbe VPN bedient, identisch sein müssen. Sofern die Importrichtlinie nicht nur eine
then rejectAnweisung enthält, muss sie einen Verweis auf eine Community enthalten. Andernfalls, wenn Sie versuchen, einen Commit für die Konfiguration auszuführen, schlägt der Commit fehl.Anmerkung:In diesem Beispiel wird eine private AS-Nummer für die Routenunterscheidung verwendet. Diese Zahl dient nur zur Veranschaulichung. Wenn Sie VPNs konfigurieren, sollten Sie eine zugewiesene AS-Nummer verwenden.
-
Routing zwischen den PE- und CE-Routern, das erforderlich ist, damit der PE-Router VPN-bezogene Routen zu und von verbundenen CE-Routern verteilen kann. Sie können ein Routing-Protokoll konfigurieren – BGP, OSPF oder RIP – oder Sie können statisches Routing konfigurieren.
Konfigurieren Sie auf Router PE1 die folgende Routing-Instanz für VPN-A. In diesem Beispiel verwendet Router PE1 RIP, um Routen zu und von dem CE-Router zu verteilen, mit dem er verbunden ist.
[edit]
routing-instance {
VPN-A {
instance-type vrf;
interface ge-1/0/0.0;
route-distinguisher 65535:0;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
protocols {
rip {
group PE1-to-CE1 {
neighbor ge-1/0/0.0;
}
}
}
}
}
Konfigurieren Sie auf Router PE2 die folgende Routing-Instanz für VPN-A. In diesem Beispiel verwendet Router PE2 OSPF, um Routen zu und von dem CE-Router zu verteilen, mit dem er verbunden ist.
[edit]
routing-instance {
VPN-A {
instance-type vrf;
interface so-1/2/0.0;
route-distinguisher 65535:1;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
protocols {
ospf {
area 0.0.0.0 {
interface so-1/2/0.0;
}
}
}
}
}
Konfigurieren der VPN-Richtlinie auf den PE-Routern
Sie müssen VPN-Import- und Exportrichtlinien auf jedem der PE-Router so konfigurieren, dass sie die entsprechenden Routen in ihren VRF-Tabellen installieren, die sie zum Weiterleiten von Paketen innerhalb eines VPN verwenden. Für VPN-A lautet die VRF-Tabelle VPN-A.inet.0.
In der VPN-Richtlinie konfigurieren Sie auch VPN-Ziel-Communitys.
In diesem Beispiel wird eine private AS-Nummer für das Routenziel verwendet. Diese Zahl dient nur zur Veranschaulichung. Wenn Sie VPNs konfigurieren, sollten Sie eine zugewiesene AS-Nummer verwenden.
Konfigurieren Sie auf Router PE1 die folgenden VPN-Import- und Exportrichtlinien:
Die in diesem Beispiel gezeigten Richtlinienqualifizierer sind nur diejenigen, die für die Funktion des VPN erforderlich sind. Sie können bei Bedarf zusätzliche Qualifizierer für alle von Ihnen konfigurierten Richtlinien konfigurieren.
[edit]
policy-options {
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement VPN-A-export {
term a {
from protocol rip;
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
community VPN-A members target:65535:00;
}
Konfigurieren Sie auf Router PE2 die folgenden VPN-Import- und Exportrichtlinien:
[edit]
policy-options {
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement VPN-A-export {
term a {
from protocol ospf;
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
community VPN-A members target:65535:00;
}
Um die VPN-Richtlinien auf den Routern anzuwenden, schließen Sie die vrf-export and-Anweisungen vrf-import ein, wenn Sie die Routinginstanz auf den PE-Routern konfigurieren. Die VRF-Import- und -Exportrichtlinien behandeln die Routenverteilung in der IBGP-Sitzung, die zwischen den PE-Routern ausgeführt wird.
LDP-over-RSVP-VPN-Konfiguration Zusammenfassung nach Router
Router PE1
Routing-Instanz für VPN-A
routing-instance {
VPN-A {
instance-type vrf;
interface ge-1/0/0.0;
route-distinguisher 65535:0;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
}
}
Instance Routing (Protokoll)
protocols {
rip {
group PE1-to-CE1 {
neighbor ge-1/0/0.0;
}
}
}
Schnittstellen
interfaces {
so-1/0/0 {
unit 0 {
family mpls;
}
}
ge-1/0/0 {
unit 0;
}
}
Primäre Protokollinstanz
protocols {
}
LDP aktivieren
ldp {
interface so-1/0/0.0;
}
MPLS aktivieren
mpls {
interface so-1/0/0.0;
interface ge-1/0/0.0;
}
Konfigurieren von IBGP
bgp {
group PE1-to-PE2 {
type internal;
local-address 10.255.1.1;
family inet-vpn {
unicast;
}
neighbor 10.255.100.1;
}
}
VPN-Richtlinie konfigurieren
policy-options {
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement VPN-A-export {
term a {
from protocol rip;
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
community VPN-A members target:65535:00;
}
Router P1
Primäre Protokollinstanz
protocols {
}
RSVP aktivieren
rsvp {
interface so-1/0/1.0;
}
LDP aktivieren
ldp {
interface so-1/0/0.0;
interface lo0.0;
}
MPLS aktivieren
mpls {
label-switched-path P1-to-P3 {
to 10.255.100.1;
ldp-tunneling;
}
interface so-1/0/0.0;
interface so-1/0/1.0;
}
Konfigurieren von OSPF für Traffic Engineering Support
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-1/0/0.0;
interface so-1/0/1.0;
}
}
Router P2
Primäre Protokollinstanz
protocols {
}
RSVP aktivieren
rsvp {
interface so-1/1/0.0;
interface at-2/0/0.0;
}
MPLS aktivieren
mpls {
interface so-1/1/0.0;
interface at-2/0/0.0;
}
Router P3
Primäre Protokollinstanz
protocols {
}
RSVP aktivieren
rsvp {
interface at-2/0/1.0;
}
LDP aktivieren
ldp {
interface so-0/0/0.0;
interface lo0.0;
}
MPLS aktivieren
mpls {
label-switched-path P3-to-P1 {
to 10.255.2.2;
ldp-tunneling;
}
interface at-2/0/1.0;
interface so-0/0/0.0;
}
Konfigurieren von OSPF für Traffic Engineering Support
ospf {
traffic-engineering;
area 0.0.0.0 {
interface at-2/0/1.0;
interface at-2/0/1.0;
}
}
Router PE2
Routing-Instanz für VPN-A
routing-instance {
VPN-A {
instance-type vrf;
interface so-1/2/0.0;
route-distinguisher 65535:1;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
}
}
Instance Routing (Protokoll)
protocols {
ospf {
area 0.0.0.0 {
interface so-1/2/0.0;
}
}
}
Schnittstellen
interfaces {
so-0/0/0 {
unit 0 {
family mpls;
}
}
so-1/2/0 {
unit 0;
}
}
Primäre Protokollinstanz
protocols {
}
LDP aktivieren
ldp {
interface so-0/0/0.0;
}
MPLS aktivieren
mpls {
interface so-0/0/0.0;
interface so-1/2/0.0;
}
Konfigurieren von IBGP
bgp {
group PE2-to-PE1 {
type internal;
local-address 10.255.200.2;
family inet-vpn {
unicast;
}
neighbor 10.255.1.1;
}
}
VPN-Richtlinie konfigurieren
policy-options {
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement VPN-A-export {
term a {
from protocol ospf;
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
community VPN-A members target:65535:01;
}
Konfigurieren einer anwendungsbasierten Layer-3-VPN-Topologie
Dieses Beispiel veranschaulicht einen anwendungsbasierten Mechanismus für die Weiterleitung von Datenverkehr an ein Layer 3-VPN. In der Regel sind eine oder mehrere Schnittstellen einem VPN zugeordnet oder an ein VPN gebunden, indem sie in die Konfiguration der VPN-Routinginstanz einbezogen werden. Durch die Bindung der Schnittstelle an das VPN wird die VRF-Tabelle des VPN verwendet, um Weiterleitungsentscheidungen für eingehenden Datenverkehr auf dieser Schnittstelle zu treffen. Die Bindung der Schnittstelle umfasst auch die lokalen Routen der Schnittstelle in der VRF-Tabelle, die die Next-Hop-Auflösung für VRF-Routen bereitstellt.
In diesem Beispiel wird mit einem Firewall-Filter definiert, welcher eingehende Datenverkehr auf einer Schnittstelle über die Standard-Routing-Tabelle inet.0 und welcher eingehende Datenverkehr über die VRF-Tabelle weitergeleitet wird. Sie können dieses Beispiel so erweitern, dass eingehender Datenverkehr auf einer Schnittstelle an ein oder mehrere VPNs umgeleitet werden kann. Sie können z. B. eine Konfiguration definieren, um ein VPN zu unterstützen, das Datenverkehr basierend auf der Quelladresse weiterleitet, HTTP-Datenverkehr (Hypertext Transfer Protocol) weiterleitet oder nur Streaming-Medien weiterleitet.
Damit diese Konfiguration funktioniert, müssen die folgenden Bedingungen erfüllt sein:
-
Die Schnittstellen, die eine filterbasierte Weiterleitung verwenden, dürfen nicht an das VPN gebunden sein.
-
Als Routing-Mittel muss statisches Routing verwendet werden.
-
Sie müssen eine Schnittstelle Routing-Tabelle Gruppe definieren, die von inet.0 und den VRF-Tabellen gemeinsam genutzt wird, um lokale Routen zur VRF-Tabelle bereitzustellen.
Dieses Beispiel besteht aus zwei Clienthosts (Client D und Client E), die sich in zwei verschiedenen VPNs befinden und Datenverkehr sowohl innerhalb des VPN als auch an das Internet senden möchten. Die Pfade sind wie folgt definiert:
-
Client A sendet Datenverkehr über VPN A an Client E mit einem Rücklaufpfad, der ebenfalls VPN A verwendet (unter Verwendung der VRF-Tabelle des VPN).
-
Client B sendet Datenverkehr an Client D über VPN B mit einem Rückwegpfad, der standardmäßiges zielbasiertes Routing verwendet (unter Verwendung der Routing-Tabelle inet.0).
-
Die Clients B und C senden Datenverkehr über Standardrouting (unter Verwendung der Routing-Tabelle inet.0) an das Internet, wobei der Rückgabepfad ebenfalls Standardrouting verwendet.
Dieses Beispiel verdeutlicht, dass es eine Vielzahl von Optionen für die Konfiguration einer anwendungsbasierten Layer-3-VPN-Topologie gibt. Diese Flexibilität kommt in vielen Netzwerkimplementierungen zum Einsatz, bei denen bestimmter Datenverkehr in einer Umgebung mit eingeschränkten Routing-Einstellungen weitergeleitet werden muss.
Dieses Konfigurationsbeispiel zeigt nur die Teile der Konfiguration für die filterbasierte Weiterleitung, die Routinginstanzen und die Richtlinie. Es wird nicht veranschaulicht, wie ein Layer-3-VPN konfiguriert wird.
Abbildung 7 veranschaulicht die in diesem Beispiel verwendete Netzwerktopologie.
Konfiguration auf Router A
Auf Router A konfigurieren Sie die Schnittstelle für die Clients A, B und C. Die Konfiguration wertet den eingehenden Datenverkehr aus, um zu bestimmen, ob er mittels VPN oder Standard-Destinations-basiertem Routing weitergeleitet werden soll.
Zuerst wenden Sie einen Eingangsfilter an und konfigurieren die Schnittstelle:
[edit]
interfaces {
fe-1/1/0 {
unit 0 {
family inet {
filter {
input fbf-vrf;
}
address 192.168.1.1/24;
}
}
}
}
Da die Schnittstellen, die die filterbasierte Weiterleitung verwenden, nicht an ein VPN gebunden sein dürfen, müssen Sie eine alternative Methode konfigurieren, um Next-Hop-Routen zur VRF-Tabelle bereitzustellen. Definieren Sie dazu eine Routing-Tabelle-Gruppe für Schnittstellen und teilen Sie diese Gruppe für alle Routing-Tabellen:
[edit]
routing-options {
interface-routes {
rib-group inet if-rib;
}
rib-groups {
if-rib {
import-rib [ inet.0 vpn-A.inet.0 vpn-B.inet.0 ];
}
}
}
Sie wenden den folgenden Filter auf eingehenden Datenverkehr auf der Schnittstelle fe-1/1/0.0an. Der erste Begriff gleicht den Datenverkehr von Client A ab und leitet ihn an die Routinginstanz für VPN A weiter. Der zweite Begriff gleicht Datenverkehr von Client B ab, der für Client D bestimmt ist, und leitet ihn an die Routinginstanz für VPN B weiter. Der dritte Term entspricht dem gesamten anderen Verkehr, der normalerweise mittels destinationsbasierter Weiterleitung gemäß den Routen in inet.0 weitergeleitet wird.
[edit firewall family family-name]
filter fbf-vrf {
term vpnA {
from {
source-address {
192.168.1.1/32;
}
}
then {
routing-instance vpn-A;
}
}
term vpnB {
from {
source-address {
192.168.1.2/32;
}
destination-address {
192.168.3.0/24;
}
}
then routing-instance vpn-B;
}
}
term internet {
then accept;
}
Anschließend konfigurieren Sie die Routing-Instanzen für VPN A und VPN B. Beachten Sie, dass diese Anweisungen mit Ausnahme der interface Anweisung alle erforderlichen Anweisungen zum Definieren eines Layer 3-VPN enthalten.
[edit]
routing-instances {
vpn-A {
instance-type vrf;
route-distinguisher 172.21.10.63:100;
vrf-import vpn-A-import;
vrf-export vpn-A-export;
}
vpn-B {
instance-type vrf;
route-distinguisher 172.21.10.63:200;
vrf-import vpn-B-import;
vrf-export vpn-B-export;
}
}
Konfiguration auf Router E
Konfigurieren Sie auf Router E eine Standardroute, um das Internet zu erreichen. Sie sollten diese Route in das lokale IBGP-Mesh einfügen, um einen Ausgangspunkt aus dem Netzwerk bereitzustellen.
[edit]
routing-options {
static {
route 0.0.0.0/0 next-hop so-2/2/2.0 discard
}
}
Konfigurieren Sie die Schnittstelle zu Client E so, dass der gesamte eingehende Datenverkehr auf der Schnittstelle fe-1/1/1.0 , der der VPN-Richtlinie entspricht, über VPN A weitergeleitet wird:
[edit]
routing-instances {
vpn-A {
interface fe-1/1/1.0
instance-type vrf;
route-distinguisher 172.21.10.62:100;
vrf-import vpn-A-import;
vrf-export vpn-A-export;
routing-options {
static {
route 192.168.2.0/24 next-hop fe-1/1/1.0;
}
}
}
}
Konfiguration auf Router F
Da die Schnittstellen, die die filterbasierte Weiterleitung verwenden, nicht an ein VPN gebunden sein dürfen, konfigurieren Sie eine alternative Methode, um Next-Hop-Routen zur VRF-Tabelle bereitzustellen, indem Sie eine Schnittstelle Routing-Tabelle Gruppe definieren und diese Gruppe für alle Routingtabellen freigeben. Um eine Route zurück zu den Clients für das normale inet.0-Routing bereitzustellen, definieren Sie eine statische Route, die in inet.0 eingeschlossen werden soll, und verteilen die statische Route in BGP neu:
[edit]
routing-options {
interface-routes {
rib-group inet if-rib;
}
rib-groups {
if-rib {
import-rib [ inet.0 vpn-B.inet.0 ];
}
}
}
Um Datenverkehr von VPN B an Client D weiterzuleiten, konfigurieren Sie die Routing-Instanz für VPN B auf Router F. Der gesamte eingehende Verkehr von Client D auf der Schnittstelle so-3/3/3.0 wird normal über die Zieladresse basierend auf den Routen in inet.0 weitergeleitet.
[edit]
routing-instances {
vpn-B {
instance-type vrf;
route-distinguisher 172.21.10.64:200;
vrf-import vpn-B-import;
vrf-export vpn-B-export;
routing-options {
static {
route 192.168.3.0/24 next-hop so-3/3/3.0;
}
}
}
}