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 (BGP, OSPF oder RIP) oder statisches Routing konfigurieren. Für die Verbindung zu jedem CE-Router können Sie nur einen Routing-Typ konfigurieren.
In den folgenden Abschnitten wird erläutert, wie Sie das VPN-Routing zwischen dem PE- und dem CE-Router konfigurieren:
- BGP zwischen dem PE- und dem CE-Router konfigurieren
- Konfigurieren von OSPF zwischen dem PE- und dem CE-Router
- Konfigurieren von OSPF-Sham-Links 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 dem PE- und dem CE-Router
BGP zwischen dem PE- und dem CE-Router konfigurieren
Um BGP als Routing-Protokoll 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 den folgenden Hierarchieebenen einbinden:
[edit routing-instances routing-instance-name protocols][edit logical-systems logical-system-name routing-instances routing-instance-name protocols]Anmerkung:Die
[edit logical-systems]Hierarchieebene gilt nicht für Router der ACX-Serie.Bitte beachten Sie die folgenden Einschränkungen bezüglich der Konfiguration von BGP für Routing-Instanzen:
Konfigurieren Sie in einer VRF-Routing-Instanz die lokale AS-Nummer (Autonomous System) nicht mit einer AS-Nummer, die bereits von einem Remote-BGP-Peer in einer separaten VRF-Routing-Instanz verwendet wird. Dadurch wird eine autonome Systemschleife erstellt, 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]
Sie konfigurieren die AS-Nummer für einen BGP-Peer mit der
peer-asAnweisung auf Hierarchieebene[edit routing-instances routing-instance-name protocols bgp group group-name].
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 den Routern PE und CE
- Konfigurieren von OSPF Version 3 zwischen dem PE- und dem CE-Router
Konfigurieren von OSPF Version 2 zwischen den Routern PE und CE
Um OSPF Version 2 als Routing-Protokoll zwischen einem PE- und CE-Router zu konfigurieren, fügen Sie die ospf folgende Anweisung ein:
ospf {
area area {
interface interface-name;
}
}
Sie können diese Anweisung auf den folgenden Hierarchieebenen einbinden:
[edit routing-instances routing-instance-name protocols][edit logical-systems logical-system-name routing-instances routing-instance-name protocols]Anmerkung:Die
[edit logical-systems]Hierarchieebene 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 CE-Router zu konfigurieren, fügen Sie die ospf3 folgende Anweisung ein:
ospf3 {
area area {
interface interface-name;
}
}
Sie können diese Anweisung auf den folgenden Hierarchieebenen einbinden:
[edit routing-instances routing-instance-name protocols][edit logical-systems logical-system-name routing-instances routing-instance-name protocols]Anmerkung:Die
[edit logical-systems]Hierarchieebene gilt nicht für Router der ACX-Serie.
Konfigurieren von OSPF-Sham-Links für Layer-3-VPNs
Wenn Sie OSPF zwischen den PE- und CE-Routern eines Layer-3-VPN konfigurieren, können Sie auch OSPF-Sham-Links konfigurieren, um Probleme im Zusammenhang mit OSPF-Intra-Area-Verbindungen zu kompensieren.
In den folgenden Abschnitten werden OSPF-Sham-Links und deren Konfiguration beschrieben:
Übersicht über OSPF-Sham-Links
Abbildung 1 zeigt, wann Sie eine OSPF-Scheinverbindung konfigurieren können. Router CE1 und Router CE2 befinden sich im selben OSPF-Bereich. Diese CE-Router 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.
OSPF behandelt die Verbindung über das Layer-3-VPN als Interarea-Verbindung. Standardmäßig bevorzugt OSPF bereichsinterne Verknüpfungen gegenüber bereichsübergreifenden Verknüpfungen, sodass OSPF die bereichsübergreifende Sicherungsverknüpfung als aktiven Pfad auswählt. Dies ist in Konfigurationen, in denen die Intra-Area-Verbindung nicht der erwartete primäre Pfad für den Datenverkehr zwischen den CE-Routern ist, nicht akzeptabel.
Eine OSPF-Scheinverbindung ist auch eine bereichsinterne Verbindung, mit der Ausnahme, dass sie zwischen den PE-Routern konfiguriert wird, wie in Abbildung 1 dargestellt. Sie können die Metrik für die Scheinverbindung konfigurieren, um sicherzustellen, dass der Pfad über das Layer-3-VPN einem Backup-Pfad gegenüber einer gebietsinternen Verbindung, die die CE-Router verbindet, vorgezogen wird.
Sie sollten einen OSPF-Scheinlink unter den folgenden Umständen konfigurieren:
-
Zwei CE-Router sind über ein Layer-3-VPN miteinander verbunden.
-
Diese CE-Router befinden sich im selben OSPF-Bereich.
-
Zwischen den beiden CE-Routern wird eine Intra-Area-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 Internet-Entwurf draft-ietf-l3vpn-ospf-2547-01.txt, OSPF als PE/CE-Protokoll in BGP/MPLS-VPNs.
Konfigurieren von OSPF-Sham-Links
Der Shaping-Link ist ein nicht nummerierter Punkt-zu-Punkt-Intra-Area-Link und wird mittels einer Link-State-Advertisement (LSA) vom Typ 1 angekündigt. Sham-Links sind nur für Routing-Instanzen und OSPF-Version 2 gültig.
Jede Scheinverbindung wird durch eine Kombination aus der Endpunktadresse der lokalen und der Remote-Scheinverbindung und dem OSPF-Bereich, zu dem sie gehört, identifiziert. Sham-Links müssen manuell konfiguriert werden. Sie konfigurieren die Scheinverbindung zwischen zwei PE-Routern, die sich beide innerhalb derselben VRF-Routing-Instanz befinden.
Sie müssen die Adresse für den lokalen Endpunkt der Scheinverbindung angeben. Diese Adresse wird als Quelle für die Schein-Link-Pakete verwendet und wird auch vom Remote-PE-Router als Remote-Endpunkt der Scheinverbindung verwendet.
Die lokale Adresse des OSPF-Sham-Links 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 den folgenden Hierarchieebenen einbinden:
[Routing-Instanz-Protokolle routing-instance-name OSPF bearbeiten]
[Logische-Systeme logical-system-name Routing-Instanz-Protokolle routing-instance-name OSPF bearbeiten]
Die Remote-Adresse des OSPF-Sham-Links 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 Remote-Endpunkt anzugeben, fügen Sie die Anweisung sham-link-remote ein:
sham-link-remote address <metric number>;
Sie können diese Anweisung auf den folgenden Hierarchieebenen einbinden:
[Routing-Instanzen-Protokolle routing-instance-name OSPF-Bereich area-idbearbeiten]
[Bearbeiten: logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id]
Optional können Sie die Option "Metrik " einschließen, um einen Metrikwert für den Remote-Endpunkt festzulegen. Der Metrikwert gibt die Kosten für die Verwendung des Links an. Routen mit niedrigeren Gesamtpfadmetriken werden gegenüber Routen mit höheren Pfadmetriken bevorzugt.
Sie können einen Wert zwischen 1 und 65.535 konfigurieren. Der Standardwert ist 1.
Beispiel für OSPF-Sham-Links
Dieses Beispiel zeigt, wie OSPF-Sham-Links auf einem PE-Router aktiviert werden.
Im Folgenden finden Sie die Konfiguration der Loopback-Schnittstelle auf dem PE-Router. Die konfigurierte Adresse bezieht sich auf den lokalen Endpunkt der OSPF-Scheinverbindung:
[edit]
interfaces {
lo0 {
unit 1 {
family inet {
address 10.1.1.1/32;
}
}
}
}
Im Folgenden finden Sie die Routing-Instanzkonfiguration 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 Loopback-Schnittstelle 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 jedoch dabei helfen, die LSA-Übersetzung (für LSAs vom Typ 3 und Typ 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, ist mit derselben OSPF-Domänen-ID konfiguriert. Die standardmäßige 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 erhalten |
Domänen-ID der empfangenen Route |
Domänen-ID auf dem empfangenden Router |
Route neu verteilt und beworben als |
|---|---|---|---|
Route vom Typ 3 |
A.B.C.D |
A.B.C.D |
Typ 3 LSA |
Route vom Typ 3 |
A.B.C.D |
E.F.G.H |
Typ 5 LSA |
Route vom Typ 3 |
0.0.0.0 |
0.0.0.0 |
Typ 3 LSA |
Route vom Typ 3 |
Null |
0.0.0.0 |
Typ 3 LSA |
Route vom Typ 3 |
Null |
Null |
Typ 3 LSA |
Route vom Typ 3 |
0.0.0.0 |
Null |
Typ 3 LSA |
Route vom Typ 3 |
A.B.C.D |
Null |
Typ 5 LSA |
Route vom Typ 3 |
Null |
A.B.C.D |
Typ 3 LSA |
Route vom Typ 5 |
Nicht zutreffend |
Nicht zutreffend |
Typ 5 LSA |
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 einfügen. Die folgenden Konfigurationsbeschreibungen enthalten nur die OSPF-Anweisung der Version 2. Die Unteranweisungen gelten aber 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 den folgenden Hierarchieebenen einbinden:
[Routing-Instanz-Protokolle routing-instance-name OSPF bearbeiten]
[Logische-Systeme logical-system-name Routing-Instanz-Protokolle routing-instance-name OSPF bearbeiten]
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 jedoch explizit für LSAs vom Typ 5 konfigurieren, indem Sie die domain-vpn-tag-Anweisung einfügen:
no-domain-vpn-tag number;
Sie können diese Anweisung auf den folgenden Hierarchieebenen einbinden:
[Routing-Instanz-Protokolle routing-instance-name OSPF bearbeiten]
[Logische-Systeme logical-system-name Routing-Instanz-Protokolle routing-instance-name OSPF bearbeiten]
Der Bereich liegt zwischen 1 und 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-Updates von den anderen Remote-Spoke-PE-Routern, und diese werden in die Spoke-Routing-Instanz importiert. Von der Spoke-Routing-Instanz werden die OSPF-LSAs erstellt und an den CE-Router des Hubs 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-Updates 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, treten zwei Probleme in Bezug darauf auf, wie der Hub-PE-Router LSAs erzeugt und an den Hub-CE-Router sendet und wie der Hub-PE-Router LSAs verarbeitet, die vom Hub-CE-Router empfangen wurden:
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 erstellten LSAs das VPN-Routing-Tag festgelegt. Durch Festlegen des DN-Bits und des VPN-Routing-Tags werden Routing-Schleifen vermieden. Bei Typ-3-Zusammenfassungs-LSAs stellen Routing-Schleifen kein Problem dar, da der Hub-CE-Router als Area Border Router (ABR) die LSAs mit gelöschtem DN-Bit neu erstellt und an den Hub-PE-Router zurücksendet. Der Hub-CE-Router erstellt jedoch keine externen LSAs neu, da diese über einen AS-Flooding-Bereich verfügen.
Sie können die externen LSAs (bevor Sie sie an den Hub-CE-Router senden) mit leerem DN-Bit und dem VPN-Routing-Tag auf 0 erstellen, indem Sie die Routing-Instanzkonfiguration des Hub-PE-Routers ändern. Um das DN-Bit zu löschen und das VPN-Routing-Tag für externe LSAs, die von einem PE-Router stammen, auf Null zu setzen, konfigurieren Sie 0 für die domain-vpn-tag-Anweisung auf der Hierarchieebene [edit routing-instances routing-instance-name protocols ospf]. Sie sollten diese Konfiguration in die Routinginstanz 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 eintreffen, 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 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 der PE-Router als Nicht-ABR agiert, 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 am Hub-PE-Router vor, der die LSAs vom Hub-CE-Router empfängt.
Durch diese Konfigurationsänderung fungiert die Routinginstanz des PE-Routers als Nicht-ABR. Der PE-Router betrachtet dann die vom Hub-CE-Router eintreffenden LSAs so, als kämen sie aus einem zusammenhängenden Nicht-Backbone-Bereich.
Konfigurieren von RIP zwischen dem PE- und dem CE-Router
Für ein 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 hinzugefügt (instance_name.inet.0).
Um RIP als Routing-Protokoll zwischen PE und 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 den folgenden Hierarchieebenen einbinden:
[edit routing-instances routing-instance-name protocols][edit logical-systems logical-system-name routing-instances routing-instance-name protocols]Anmerkung:Die
[edit logical-systems]Hierarchieebene 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. Weitere 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
[edit logical-systems]Hierarchieebene gilt nicht für Router der ACX-Serie.
Um Routen, die von einer RIP-Routing-Instanz gelernt wurden, in mehrere Routing-Tabellen zu installieren, fügen Sie die rib-group group and-Anweisungen ein:
rib-group inet group-name;
group group-name {
neighbor interface-name;
}
Sie können diese Anweisungen auf den folgenden Hierarchieebenen einbinden:
[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 [edit logical-systems] Hierarchieebene gilt nicht für Router der ACX-Serie.
Um eine Routing-Tabellengruppe zu konfigurieren, fügen Sie die rib-groups folgende Anweisung ein:
rib-groups group-name;
Sie können diese Anweisung auf den folgenden Hierarchieebenen einbinden:
[edit routing-options][edit logical-systems logical-system-name routing-options]
Die [edit logical-systems] Hierarchieebene gilt nicht für Router der ACX-Serie.
Um eine Routing-Tabelle zu einer Routing-Tabellengruppe hinzuzufügen, schließen Sie die import-rib Anweisung ein. Der erste Name der Routingtabelle, der unter der import-rib Anweisung angegeben wird, muss der Name der Routingtabelle sein, die Sie konfigurieren. Weitere Informationen zum Konfigurieren von Routing-Tabellen und Routing-Tabellengruppen finden Sie unter Junos OS Routing Protocols Library.
import-rib [ group-names ];
Sie können diese Anweisung auf den folgenden Hierarchieebenen einbinden:
[edit routing-options rib-groups group-name][edit logical-systems logical-system-name routing-options rib-groups group-name]
Die [edit logical-systems] Hierarchieebene gilt nicht für Router der ACX-Serie.
RIP-Instanzen werden nur für VRF-Instanztypen unterstützt. Sie können mehrere Instanzen von RIP nur für die VPN-Unterstützung konfigurieren. Sie können RIP in der CE-PE-Umgebung (Customer Edge-Provider Edge) 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 Instance-Hierarchie konfiguriert sind, werden der Routing-Tabelle der Instance hinzugefügt. instance-name.inet.0
Routing-Tabellengruppen werden von RIP nicht unterstützt. Daher können keine Routen in mehrere Tabellen importiert werden, wie dies beim OSPF- oder OSPFv3-Protokoll der Fall ist.
Konfigurieren statischer Routen zwischen dem PE- und dem CE-Router
Sie können statische (unveränderliche) Routen zwischen den PE- und CE-Routern einer VPN-Routinginstanz konfigurieren. Um eine statische Route für ein VPN zu konfigurieren, müssen Sie sie innerhalb der VPN-Routinginstanzkonfiguration 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 folgende Anweisung ein:
static {
route destination-prefix {
next-hop [ next-hops ];
static-options;
}
}
Sie können diese Anweisung auf den folgenden Hierarchieebenen einbinden:
[edit routing-instances routing-instance-name routing-options][edit logical-systems logical-system-name routing-instances routing-instance-name routing-options]
Die [edit logical-systems] Hierarchieebene gilt nicht für Router der ACX-Serie.
Weitere Informationen zum Konfigurieren von Routing-Protokollen und statischen Routen finden Sie unter 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 aus 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-Domänen verbindet, können sich die Routen einer Domäne mit den Routen einer anderen überschneiden.
Die Domänen-ID, die in einer Routing-Instanz konfiguriert ist, identifiziert die OSPF-Domäne und wird verwendet, um den Ursprung der Route zu identifizieren. 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. Für die CE-Router gibt es keine besonderen Konfigurationsanforderungen.
Konfigurationsinformationen finden Sie in den folgenden Abschnitten:
- Konfigurieren von Schnittstellen auf Router PE1
- Routing-Optionen auf Router PE1 konfigurieren
- Konfigurieren von Protokollen auf Router PE1
- Konfigurieren von Richtlinienoptionen auf Router PE1
- Routinginstanz auf Router PE1 konfigurieren
- Konfigurationszusammenfassung 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;
}
}
}
Routing-Optionen auf Router PE1 konfigurieren
Auf der [edit routing-options] Hierarchieebene müssen Sie die router-id und-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 Routing-Informationen 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;
}
Routinginstanz auf Router PE1 konfigurieren
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 Hierarchieebene [edit routing-instance routing-instance-name] hinzu.
Die domain-id Anweisung wird auf Hierarchieebene [edit routing-instances routing-options protocols ospf] konfiguriert. Wie in Abbildung 2 dargestellt, muss die Routinginstanz auf Router PE2 dieselbe Domänen-ID wie die entsprechende Routinginstanz auf Router PE1 aufweisen, damit Routen von Router CE1 zu Router CE2 und umgekehrt als LSAs vom Typ 3 verteilt werden. Wenn Sie in den Routing-Instanzen unterschiedliche OSPF-Domänen-IDs 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;
}
}
}
}
}
Konfigurationszusammenfassung für Router PE1
Schnittstellen konfigurieren
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;
}
}
}
Routing-Optionen konfigurieren
routing-options {
router-id 10.255.14.216;
autonomous-system 65069;
}
Protokolle konfigurieren
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-Sham-Links
Sie können eine gebietsinterne Verbindung oder eine Scheinverbindung zwischen zwei Provider-Edge-Routing-Geräten (PE) erstellen, sodass der VPN-Backbone gegenüber der Backdoor-Verbindung bevorzugt 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 Backup-Verbindung verfügbar ist und sich die CE-Geräte im selben OSPF-Bereich befinden, wird standardmäßig diese Backup-Verbindung dem VPN-Backbone vorgezogen. Dies liegt daran, dass der Backup-Link als Intra-Area-Link betrachtet wird, während der VPN-Backbone immer als Interarea-Link betrachtet wird. Bereichsübergreifende Verknüpfungen werden immer gegenüber bereichsübergreifenden Verknüpfungen bevorzugt.
Bei der Scheinverbindung handelt es sich um eine nicht nummerierte Punkt-zu-Punkt-Intra-Area-Verbindung zwischen PE-Geräten. Wenn das VPN-Backbone über eine Schein-Intra-Area-Verbindung verfügt, kann diese Schein-Verbindung gegenüber der Backup-Verbindung bevorzugt werden, wenn die Schein-Verbindung eine niedrigere OSPF-Metrik als die Backup-Verbindung aufweist.
Der Scheinlink wird mithilfe von Link State Advertisements (LSAs) vom Typ 1 angekündigt. Sham-Links sind nur für Routing-Instanzen und OSPFv2 gültig.
Jeder Scheinlink wird durch die Kombination einer lokalen Endpunktadresse und einer Remote-Endpunktadresse identifiziert. Abbildung 3 zeigt eine OSPFv2-Scheinverbindung. Router CE1 und Router CE2 befinden sich im selben OSPFv2-Bereich. Diese Kunden-Edge-Routing-Geräte (CE) 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-Verbindung. Standardmäßig bevorzugt OSPFv2 bereichsinterne Verknüpfungen gegenüber bereichsübergreifenden Verknüpfungen, sodass OSPFv2 die bereichsübergreifende Sicherungsverknüpfung als aktiven Pfad auswählt. Dies ist in einer Konfiguration, in der die bereichsinterne Verbindung nicht der erwartete primäre Pfad für den Datenverkehr zwischen den CE-Routing-Geräten ist, nicht akzeptabel. Sie können die Metrik für die Scheinverbindung konfigurieren, um sicherzustellen, dass der Pfad über das Layer-3-VPN einem Backup-Pfad gegenüber einer gebietsinternen Verbindung, die die CE-Routing-Geräte verbindet, vorgezogen wird.
Für den Remote-Endpunkt können Sie die OSPFv2-Schnittstelle als Bedarfsschaltung konfigurieren, die IPsec-Authentifizierung konfigurieren (die eigentliche IPsec-Authentifizierung konfigurieren Sie separat) 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 bereichsübergreifende Verbindung konfiguriert.
Wenn keine bereichsinterne Verbindung zwischen den CE-Routing-Geräten besteht, müssen Sie keine OSPFv2-Scheinverbindung konfigurieren.
In Junos OS Version 9.6 und höher wird ein OSPFv2-Scheinlink in der Routing-Tabelle als ausgeblendete Route installiert. Darüber hinaus wird eine BGP-Route nicht nach OSPFv2 exportiert, wenn ein entsprechender OSPF-Sham-Link verfügbar ist.
In Junos OS Version 16.1 und höher werden OSPF-Sham-Links auf Standardinstanzen unterstützt. Die Kosten für den Sham-Link werden dynamisch auf die aigp-Metrik der BGP-Route gesetzt, wenn vom Benutzer keine Metrik für den Sham-Link konfiguriert wurde. Wenn die aigp-Metrik in der BGP-Route nicht vorhanden ist, werden die Kosten für die Scheinverbindung standardmäßig auf 1 gesetzt.
Beispiel: Konfigurieren von OSPFv2-Sham-Links
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
Der Shaping-Link ist ein nicht nummerierter Punkt-zu-Punkt-Intra-Area-Link und wird mittels einer Link-State-Advertisement (LSA) vom Typ 1 angekündigt. Sham-Links sind nur für Routing-Instanzen und OSPFv2 gültig.
Jeder Scheinlink wird durch eine Kombination aus der lokalen Endpunktadresse und einer Remote-Endpunktadresse 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 Weiterleitungs-Routinginstanz (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 vom Remote-PE-Routinggerät als Remote-Endpunkt der Scheinverbindung verwendet. Sie können auch die optionale metric Option zum Festlegen eines Metrikwerts für den Remote-Endpunkt hinzufügen. Der Metrikwert gibt die Kosten für die Verwendung des Links an. Routen mit niedrigeren Gesamtpfadmetriken werden gegenüber Routen mit höheren Pfadmetriken bevorzugt.
So aktivieren Sie OSPFv2-Scheinverbindungen auf einem PE-Routing-Gerä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-Sham-Link-Konfiguration ist ebenfalls in der Routing-Instanz enthalten. Sie konfigurieren die lokale Endpunktadresse des Scheinlinks, bei der es sich um die Loopback-Adresse des lokalen VPN handelt, und die Remoteendpunktadresse, bei der es sich um die Loopback-Adresse des Remote-VPN handelt. In diesem Beispiel wird die VRF-Routinginstanz rot genannt.
Abbildung 4 zeigt eine OSPFv2-Scheinverbindung.
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 Anbietergerät.
Die CLI-Schnellkonfiguration zeigt die Konfiguration für alle Geräte in Abbildung 4. Im Abschnitt Schritt-für-Schritt-Anleitung 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 Details, die für Ihre Netzwerkkonfiguration erforderlich sind, und kopieren Sie dann die Befehle und fügen Sie sie in die CLI auf Hierarchieebene [edit] 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
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
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-Scheinverbindungen auf jedem PE-Gerät:
-
Konfigurieren Sie die Schnittstellen, einschließlich zweier 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-zugewandten 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-seitigen 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-seitigen 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.
Fügen 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 der Backup-OSPF-Verbindung von Gerät CE1 wird 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 AS-Nummer (Autonomous System) 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 die Ausgabe nicht die gewünschte Konfiguration anzeigt, 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 Sham-Link-Schnittstellen
- Überprüfen der lokalen und Remote-Endpunkte des Sham-Links
- Überprüfen der Scheinlink-Nachbarschaften
- Überprüfen der Link-State-Ankündigung
- Überprüfen der Pfadauswahl
Überprüfen der Sham-Link-Schnittstellen
Zweck
Überprüfen Sie die Scheinverbindungsschnittstelle. 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 Sham-Links
Zweck
Überprüfen Sie die lokalen und Remote-Endpunkte der Scheinverbindung. Die MTU für die Scheinverbindungsschnittstelle 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 Schein-Links.
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
Stellen Sie sicher, dass die Router-LSA, die von der Instanz stammt, die Scheinlink-Nachbarschaft als nicht nummerierte Punkt-zu-Punkt-Verbindung überträgt. Die Linkdaten für Schein-Links 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 Backup-Pfads 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.
Konfigurieren 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 dem PE- und dem CE-Router haben. Die Verwendung von IBGP zwischen PE- und CE-Routern erfordert keine Konfiguration zusätzlicher Anweisungen. Die Verwendung von EBGP zwischen den Routern PE und CE 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 TTL-Wert (Time-to-Live) 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 zu dieser 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
Die folgenden Schritte beschreiben, wie diese Topologie aufgebaut wird und wie Pakete vom CE-Router CE2 an den CE-Router CE1 gesendet werden:
Die P-Router P1 und P3 bauen RSVP-LSPs untereinander auf und installieren ihre 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 Labelbindungen, die ein Label zum Erreichen von Router PE1 enthalten, an Router P3. Diese Label-Bindungen 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 Labelbindungen, 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 ankündigt, die er von Router CE1 gelernt hat, schließt er seine VPN-Bezeichnung ein. (Der PE-Router erstellt die VPN-Bezeichnung und bindet sie an die Schnittstelle zwischen dem PE- und dem CE-Router.) Wenn Router PE2 Routen ankündigt, die er von Router CE2 gelernt hat, sendet er sein VPN-Label 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, und dann das LDP-Label, mit dem Router PE1 erreicht wird. Dann leitet es die Pakete über die Schnittstelle so-0/0/1.0an Router P3 weiter.
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 den oberen Teil des Stacks, sodass das Paket jetzt vom RSVP-LSP umgeschaltet werden kann. An dieser Stelle 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 (obere) ist die RSVP-Bezeichnung.
Router P2 empfängt das Paket und schaltet es durch Austauschen des RSVP-Labels auf Router P1 um. Da Router P2 in dieser Topologie der vorletzte Hop-Router im LSP ist, wird das RSVP-Label angezeigt und das Paket über die Schnittstelle
so-1/1/0.0an Router P1 weitergeleitet. An diesem Punkt 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, wird das äußere Label (das LDP-Label) angezeigt und das Paket über die Schnittstelle
so-1/0/0.0an Router PE1 weitergeleitet. In dieser Topologie ist Router PE1 der ausgehende LDP-Router, sodass Router P1 die LDP-Bezeichnung abruft, anstatt sie gegen eine andere Bezeichnung auszutauschen. Zu diesem Zeitpunkt gibt es nur eine Bezeichnung auf dem Stapel, die VPN-Bezeichnung.Wenn Router PE1 das Paket empfängt, wird das VPN-Label angezeigt und das Paket als IPv4-Paket über die Schnittstelle
ge-1/1/0.0an Router CE1 weitergeleitet.
Ein ähnlicher Satz von Vorgängen tritt für Pakete auf, 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 umfassen Beispiele für Beschriftungswerte (siehe Abbildung 6).
LDP-Etiketten
Router PE1 kündigt das LDP-Label 3 für sich selbst an Router P1 an.
Router P1 kündigt LDP-Label 100.001 für Router PE1 bis Router P3 an.
Router P3 kündigt die LDP-Bezeichnung 100.002 für Router PE1 bis Router PE2 an.
RSVP-Etiketten
Router P1 kündigt RSVP-Label 3 für Router P2 an.
Router P2 kündigt die RSVP-Bezeichnung 100.003 für Router P3 an.
VPN-Bezeichnung
Router PE1 kündigt Router PE2 für die Route von Router CE1 zu Router CE2 die VPN-Bezeichnung 100.004 an.
von Etiketten
Bei einem Paket, das von Host B (siehe 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 PE1. Außerdem werden zwei Bezeichnungen 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 die von Router PE2 (100.002) hinzugefügte LDP-Bezeichnung aus und ersetzt sie durch die LDP-Bezeichnung, 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 die RSVP-Bezeichnung (100.003), da es sich 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/0Router PE1 entfernt die VPN-Bezeichnung (100.004). Außerdem wird die Next-Hop-Schnittstelle von
so-1/0/0ausgetauscht und durch die Next-Hop-Schnittstelle ersetzt.ge-1/1/0Router CE1 entfernt die Next-Hop-Schnittstelle von
ge-1/1/0und 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 Service-P-Router erforderlich sind.
In diesem Beispiel wird eine private AS-Nummer für die Routenunterscheidung und das Routenziel verwendet. Diese Nummer dient nur zur Veranschaulichung. Wenn Sie VPNs konfigurieren, sollten Sie eine zugewiesene AS-Nummer verwenden.
In den folgenden Abschnitten wird erläutert, wie Sie die VPN-Funktionalität auf den PE- und P-Routern konfigurieren. 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
- Routing-Instanzen für VPNs auf den PE-Routern konfigurieren
- Konfigurieren der VPN-Richtlinie auf den PE-Routern
- LDP-over-RSVP-VPN-Konfiguration zusammengefasst 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 all diesen Routern eine IGP konfigurieren oder statische Routen konfigurieren. Sie konfigurieren die IGP auf der primären Instanz des Routing-Protokollprozesses (RPD) (d. h. auf der Hierarchieebene [edit protocols] ), nicht innerhalb der VPN-Routinginstanz (d. h. nicht auf der Hierarchieebene [edit routing-instances] ).
Sie konfigurieren die IGP auf die übliche Weise. In diesem Konfigurationsbeispiel ist dieser Teil der Konfiguration nicht enthalten.
Aktivieren von LDP auf den PE- und P-Routern
In diesem Konfigurationsbeispiel ist das 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, die mit den PE-Routern verbunden sind, konfigurieren. Sie müssen LDP nur auf den Schnittstellen im Kern des Netzwerks des Service Providers konfigurieren. d. h. zwischen den PE- und P-Routern und zwischen den P-Routern. Sie müssen LDP nicht auf der Schnittstelle zwischen dem PE- und dem CE-Router 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 family inet konfigurieren, 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;
}
Obwohl Sie LDP auf Router P2 nicht konfigurieren müssen, können Sie ihn optional so konfigurieren, dass ein Fallback-LDP-Pfad bereitgestellt wird, falls der RSVP-LSP nicht mehr betriebsbereit 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 im 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 eine 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 Traffic Engineering-Unterstützung 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 des Routers 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 Traffic Engineering-Unterstützung 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 des Routers 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: Fügen Sie die
family inet-vpnAnweisung ein, um anzugeben, dass die IBGP-Sitzung für das VPN bestimmt ist.Loopback-Adresse: Fügen Sie die
local-addressAnweisung ein, die die Loopback-Adresse des lokalen PE-Routers angibt. Die IBGP-Sitzung für VPNs läuft über die Loopback-Adresse. Außerdem müssen Sie dielo0Schnittstelle auf Hierarchieebene[edit interfaces]konfigurieren. Dieser Teil der Routerkonfiguration ist im Beispiel nicht enthalten.Nachbaradresse: Fügen Sie die
neighborAnweisung ein, die die IP-Adresse des benachbarten PE-Routers angibt, 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;
}
}
}
Routing-Instanzen für VPNs auf den PE-Routern konfigurieren
Beide PE-Router bedienen VPN-A, daher müssen Sie auf jedem Router eine Routing-Instanz für das VPN konfigurieren, in dem Sie Folgendes definieren:
Routenunterscheidung, die 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.
Instance-Typ 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, die Konfiguration zu bestätigen, schlägt der Commit fehl.Anmerkung:In diesem Beispiel wird eine private AS-Nummer für die Routenunterscheidung verwendet. Diese Nummer dient nur zur Veranschaulichung. Wenn Sie VPNs konfigurieren, sollten Sie eine zugewiesene AS-Nummer verwenden.
Routing zwischen dem PE- und dem CE-Router, das erforderlich ist, damit der PE-Router VPN-bezogene Routen zu und von verbundenen CE-Routern verteilen kann. Sie können ein Routing-Protokoll (BGP, OSPF oder RIP) oder 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 zum und vom 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 PE-Router konfigurieren, damit die entsprechenden Routen in ihren VRF-Tabellen installiert werden, 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-Communities.
In diesem Beispiel wird eine private AS-Nummer für das Routenziel verwendet. Diese Nummer 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 die Router anzuwenden, schließen Sie die vrf-export vrf-import und-Anweisungen ein, wenn Sie die Routing-Instanz auf den PE-Routern konfigurieren. Die VRF-Import- und -Exportrichtlinien behandeln die Routenverteilung über die IBGP-Sitzung, die zwischen den PE-Routern ausgeführt wird.
LDP-over-RSVP-VPN-Konfiguration zusammengefasst 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;
}
}
Instanz-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;
}
}
Instanz-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 zum Weiterleiten von Datenverkehr an ein Layer-3-VPN. In der Regel sind eine oder mehrere Schnittstellen mit einem VPN verknüpft oder an dieses gebunden, indem sie in die Konfiguration der VPN-Routinginstanz aufgenommen werden. Durch die Bindung der Schnittstelle an das VPN wird die VRF-Tabelle des VPN verwendet, um Weiterleitungsentscheidungen für den eingehenden Datenverkehr auf dieser Schnittstelle zu treffen. Die Bindung der Schnittstelle schließt auch die lokalen Routen der Schnittstelle in der VRF-Tabelle ein, die die Auflösung des nächsten Hops 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, das HTTP-Datenverkehr (Hypertext Transfer Protocol) weiterleitet oder das nur Streamingmedien 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 Schnittstellen-Routing-Tabellengruppe definieren, die von inet.0 und den VRF-Tabellen gemeinsam genutzt wird, um lokale Routen zur VRF-Tabelle bereitzustellen.
Dieses Beispiel besteht aus zwei Client-Hosts (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 an Client E über VPN A mit einem Rückkanal, 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ückgabepfad, der standardmäßiges zielbasiertes Routing (unter Verwendung der Routingtabelle inet.0) verwendet.
Die Clients B und C senden Datenverkehr über das Standard-Routing (unter Verwendung der Routing-Tabelle inet.0) an das Internet, wobei ein Rückgabepfad ebenfalls Standard-Routing verwendet.
Dieses Beispiel veranschaulicht, dass es eine Vielzahl von Optionen bei der Konfiguration einer anwendungsbasierten Layer-3-VPN-Topologie gibt. Diese Flexibilität findet Anwendung in vielen Netzwerkimplementierungen, bei denen bestimmter Datenverkehr in einer eingeschränkten Routing-Umgebung weitergeleitet werden muss.
Dieses Konfigurationsbeispiel zeigt nur die Teile der Konfiguration für die filterbasierte Weiterleitung, Routinginstanzen und 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 zu den Clients A, B und C. Die Konfiguration wertet eingehenden Datenverkehr dahingehend aus, ob er über VPN oder standardmäßiges zielbasiertes 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 für die VRF-Tabelle bereitzustellen. Dazu definieren Sie eine Schnittstellen-Routing-Tabellengruppe und teilen 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 den 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 stimmt mit allem anderen Datenverkehr überein, der normalerweise mittels zielbasierter 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 interface der 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 für den Zugang zum Internet. Sie sollten diese Route in das lokale IBGP-Mesh einfügen, um einen Ausstiegspunkt 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 zum Bereitstellen von Next-Hop-Routen zur VRF-Tabelle, indem Sie eine Schnittstellenrouting-Tabellengruppe definieren und diese Gruppe für alle Routing-Tabellen 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 enthalten sein soll, und verteilen die statische Route in BGP um:
[edit]
routing-options {
interface-routes {
rib-group inet if-rib;
}
rib-groups {
if-rib {
import-rib [ inet.0 vpn-B.inet.0 ];
}
}
}
Um den Datenverkehr von VPN B zu Client D zu leiten, konfigurieren Sie die Routing-Instanz für VPN B auf Router F. Der gesamte eingehende Datenverkehr von Client D auf der Schnittstelle so-3/3/3.0 wird normalerweise ü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;
}
}
}
}