Verteilung von VPN-Routen
In diesem Thema wird die Konfiguration eines Routers für die Verarbeitung von Routeninformationen in BGP, MPLS-Signalübertragung und Richtlinien beschrieben.
Aktivieren des Routing-Informationsaustauschs für VPNs
Für Layer-2-VPNs , Layer-3-VPNs , Routing-Instanzen virtueller Router, VPLS, EVPNs und Layer-2-Circuits müssen die PE- und P-Router des Service Providers Routing-Informationen austauschen können. Dazu müssen Sie entweder eine IGP (z. B. OSPF oder IS-IS) oder statische Routen auf diesen Routern konfigurieren. Sie konfigurieren die IGP auf der Master-Instanz des Routing-Protokollprozesses auf Hierarchieebene [edit protocols] , nicht in der für das VPN verwendeten Routing-Instanz, d. h. nicht auf [edit routing-instances] Hierarchieebene.
Wenn Sie den PE-Router konfigurieren, konfigurieren Sie keine Zusammenfassung der Loopback-Adressen des PE-Routers an der Bereichsgrenze. Die Loopback-Adresse jedes PE-Routers sollte als separate Route angezeigt werden.
Konfiguration von IBGP-Sitzungen zwischen PE-Routern in VPNs
Sie müssen eine IBGP-Sitzung zwischen den PE-Routern konfigurieren, damit die PE-Router Informationen über Routen aus dem VPN austauschen können. Die PE-Router verlassen sich auf diese Informationen, um zu bestimmen, welche Label für datenverkehr verwendet werden sollen, der für Remote-Standorte bestimmt ist.
Konfigurieren Sie eine IBGP-Sitzung für das VPN wie folgt:
[edit protocols]
bgp {
group group-name {
type internal;
local-address ip-address;
family evpn {
signaling;
}
family (inet-vpn | inet6-vpn) {
unicast;
}
family l2vpn {
signaling;
}
neighbor ip-address;
}
}
Die IP-Adresse in der local-address Anweisung ist die Adresse der Loopback-Schnittstelle am lokalen PE-Router. Die IBGP-Sitzung für das VPN läuft über die Loopback-Adresse. (Sie müssen auch die Loopback-Schnittstelle auf [edit interfaces] Hierarchieebene konfigurieren.)
Die IP-Adresse in der neighbor Anweisung ist die Loopback-Adresse des benachbarten PE-Routers. Wenn Sie RSVP-Signalisierung verwenden, ist diese IP-Adresse dieselbe Adresse, die Sie in der to Anweisung auf [edit mpls label-switched-path lsp-path-name] Hierarchieebene angegeben haben, wenn Sie den MPLS-LSP konfigurieren.
Mit family der Anweisung können Sie die IBGP-Sitzung für Layer-2-VPNs , VPLS, EVPNs oder für Layer-3-VPNs konfigurieren.
Um eine IBGP-Sitzung für Layer-2-VPNs und VPLS zu konfigurieren, fügen Sie die
signalingAnweisung auf[edit protocols bgp group group-name family l2vpn]Hierarchieebene ein:[edit protocols bgp group group-name family l2vpn] signaling;
Um eine IBGP-Sitzung für EVPNs zu konfigurieren, fügen Sie die
signalingAnweisung auf[edit protocols bgp group group-name family evpn]Hierarchieebene ein:[edit protocols bgp group group-name family evpn] signaling;
Um eine IPv4-IBGP-Sitzung für Layer-3-VPNs zu konfigurieren, konfigurieren Sie die
unicastAnweisung auf[edit protocols bgp group group-name family inet-vpn]Hierarchieebene:[edit protocols bgp group group-name family inet-vpn] unicast;
Um eine IPv6-IBGP-Sitzung für Layer-3-VPNs zu konfigurieren, konfigurieren Sie die
unicastAnweisung auf[edit protocols bgp group group-name family inet6-vpn]Hierarchieebene:[edit protocols bgp group group-name family inet6-vpn] unicast;
Sie können sowohl als auch family inet family inet-vpn beides family inet6 und family inet6-vpn innerhalb derselben Peergruppe konfigurieren. Auf diese Weise können Sie die Unterstützung sowohl für IPv4- als auch für IPv4-VPN-Routen oder sowohl für IPv6- als auch für IPv6-VPN-Routen innerhalb derselben Peer-Gruppe aktivieren.
Konfigurieren von Aggregiert-Labeln für VPNs
Aggregierte Label für VPNs ermöglichen es einer Routing-Plattform von Juniper Networks, eine Reihe eingehender Label (von einem Peer-Router empfangene Label) in einem einzigen Weiterleitungsetikett zu aggregieren, das aus den eingehenden Labeln ausgewählt wird. Das einzelne Weiterleitungsetikett entspricht einem einzelnen nächsten Hop für diesen Labelsatz. Die Label-Aggregation reduziert die Anzahl der VPN-Label, die der Router untersuchen muss.
Damit eine Gruppe von Labeln ein aggregiertes Weiterleitungsetikett gemeinsam hat, müssen sie derselben FEC (Forwarding Äquivalenzklasse) gehören. Die gekennzeichneten Pakete müssen dieselbe Ziel-Ausgangsschnittstelle haben.
Wenn Sie die community community-name Anweisung mit der aggregate-label Anweisung verwenden, können Sie Präfixe mit einer gemeinsamen Ursprungsgemeinschaft angeben. Diese Präfixe werden durch die Richtlinie auf dem Peer-PE festgelegt und stellen einen FEC auf dem Peer-PE-Router dar.
Wenn die Ziel-Community versehentlich anstelle der Ursprungs-Community festgelegt wird, können Weiterleitungsprobleme am Ausgangs-PE führen. Alle Präfixe aus dem Peer-PE scheinen im selben FEC zu sein, was zu einem einzigen inneren Label für alle CE-Router hinter einem bestimmten PE im selben VPN führt.
Um mit Routenreflektoren in Layer-3-VPN-Netzwerken zu arbeiten, aggregiert der M10i-Router von Juniper Networks eine Reihe eingehender Label nur, wenn die Routen:
Empfangen vom selben Peer-Router
Haben Sie dieselbe Site of Origin Community
Haben Sie den gleichen Nächsten Hop
Die Anforderung für den nächsten Hop ist wichtig, weil Routenreflektoren Routen weiterleiten, die von verschiedenen BGP-Peers zu einem anderen BGP-Peer stammen, ohne den nächsten Hop dieser Routen zu ändern.
Um aggregierte Label für VPNs zu konfigurieren, fügen Sie die Aggregate-Label-Anweisung ein:
aggregate-label { community community-name; }
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie in der Anweisungszusammenfassung für diese Anweisung.
Informationen zur Konfiguration einer Community finden Sie unter Understanding BGP Communities, Extended Communities and Large Communities as Routing Policy Match Conditions.For information to configure a community, see Understanding BGP Communities, Extended Communities, and Large Communities as Routing Policy Match Conditions.
Konfigurieren eines Signaling Protocol und LSPs für VPNs
Damit VPNs funktionieren, müssen Sie ein Signalisierungsprotokoll aktivieren, entweder LDP oder RSVP auf den Provider Edge (PE)-Routern und auf den Provider -Routern (P). Außerdem müssen Sie Label-Switched Paths (LSPs) zwischen den Eingangs- und Ausgangsroutern konfigurieren. In einer typischen VPN-Konfiguration müssen Sie LSPs von jedem PE-Router zu allen anderen PE-Routern, die an dem VPN teilnehmen, in einem vollständigen Mesh konfigurieren.
Wie bei jeder Konfiguration mit MPLS können Sie keine core-bezogenen Schnittstellen auf den PE-Routern über dichte Fast-Ethernet-PICs konfigurieren.
Führen Sie die Schritte in einem der folgenden Abschnitte aus, um ein Signalübertragungsprotokoll zu aktivieren:
Verwendung von LDP für VPN-Signalübertragung
Um LDP für DIE VPN-Signalübertragung zu verwenden, führen Sie die folgenden Schritte auf den PE- und Provider (P)-Routern aus:
Konfigurieren Sie die LDP auf den Schnittstellen im Kern des Netzwerks des Service Provider, indem Sie die
ldpAnweisung auf Hierarchieebene[edit protocols]angeben.Sie müssen LDP nur auf den Schnittstellen zwischen PE-Routern oder zwischen PE- und P-Routern konfigurieren. Sie können sich diese als "core-orientierte" Schnittstellen vorstellen. Sie müssen keine LDP auf der Schnittstelle zwischen PE- und Customer Edge (CE)-Routern konfigurieren.
[edit] protocols { ldp { interface type-fpc/pic/port; } }Konfigurieren Sie die MPLS-Adressfamilie auf den Schnittstellen, auf denen Sie LDP aktiviert haben (die Schnittstellen, die Sie in Schritt 1 konfiguriert haben), indem Sie die
family mplsAnweisung auf Hierarchieebene[edit interfaces type-fpc/pic/port unit logical-unit-number]angeben.[edit] interfaces { type-fpc/pic/port { unit logical-unit-number { family mpls; } } }Konfigurieren Sie OSPF oder IS-IS auf jedem PE- und P-Router.
Sie konfigurieren diese Protokolle in der Master-Instanz des Routingprotokolls, nicht in der Routing-Instanz, die für das VPN verwendet wird.
Um OSPF zu konfigurieren, fügen Sie die
ospfAnweisung auf[edit protocols]Hierarchieebene ein. Sie müssen mindestens einen Backbone-Bereich auf mindestens einer der Schnittstellen des Routers konfigurieren.[edit] protocols { ospf { area 0.0.0.0 { interface type-fpc/pic/port; } } }Um IS-IS zu konfigurieren, fügen Sie die
isisAnweisung auf[edit protocols]Hierarchieebene ein und konfigurieren Sie die Loopback-Schnittstelle und die[edit interfaces]International Organization for Standardization (ISO)-Familie auf Hierarchieebene. Mindestens müssen Sie IS-IS auf dem Router aktivieren, einen Network Entity Title (NET) auf einer der Routerschnittstellen (vorzugsweise Loopback-Schnittstelle, lo0) konfigurieren und die ISO-Familie auf allen Schnittstellen konfigurieren, auf denen IS-IS ausgeführt werden soll. Wenn Sie IS-IS aktivieren, sind Level 1 und 2 standardmäßig aktiviert. Im Folgenden ist die mindeste IS-IS-Konfiguration. In deraddressAnweisungaddressist das NET.[edit] interfaces { lo0 { unit logical-unit-number { family iso { address address; } } } type-fpc/pic/port { unit logical-unit-number { family iso; } } } protocols { isis { interface all; } }
Verwendung von RSVP für VPN-Signalübertragung
Führen Sie die folgenden Schritte aus, um RSVP für VPN-Signalübertragung zu verwenden:
Konfigurieren Sie das Traffic-Engineering auf jedem PE-Router.
Dazu müssen Sie ein Interior Gateway Protocol (IGP) konfigurieren, das Traffic Engineering (entweder IS-IS oder OSPF) unterstützt, und Traffic-Engineering-Unterstützung für dieses Protokoll aktivieren.
Um die Unterstützung für OSPF Traffic Engineering zu ermöglichen, fügen Sie die
traffic-engineeringAnweisung auf Hierarchieebene[edit protocols ospf]ein:[edit protocols ospf] traffic-engineering { shortcuts; }Für IS-IS ist der Traffic-Engineering-Support standardmäßig aktiviert.
Aktivieren Sie auf jedem PE- und P-Router RSVP an den Schnittstellen, die am Label-Switched Path (LSP) teilnehmen.
Auf dem PE-Router sind diese Schnittstellen die Eingangs- und Ausgangspunkte zum LSP. Auf dem P-Router verbinden diese Schnittstellen den LSP zwischen den PE-Routern. Aktivieren Sie RSVP nicht auf der Schnittstelle zwischen dem PE und den CE-Routern, da diese Schnittstelle nicht Teil des LSP ist.
Um RSVP auf den PE- und P-Routern zu konfigurieren, fügen Sie die
interfaceAnweisung auf Hierarchieebene[edit protocols rsvp]ein. Fügen Sie eineinterfaceAnweisung für jede Schnittstelle ein, auf der Sie RSVP aktivieren.[edit protocols] rsvp { interface interface-name; interface interface-name; }Konfigurieren Sie auf jedem PE-Router einen MPLS-LSP mit dem PE-Router, der der Ausgangspunkt des LSP ist.
Fügen Sie dazu die Anweisungen und
label-switched-pathAnweisungeninterfaceauf[edit protocols mpls]Hierarchieebene ein:[edit protocols] mpls { interface interface-name; label-switched-path path-name { to ip-address; } }Geben Sie in der
toAnweisung die Adresse des Ausgangspunkts des LSP an, bei dem es sich um eine Adresse auf dem entfernten PE-Router handelt.Geben Sie in der
interfaceAnweisung den Namen der Schnittstelle (sowohl den physischen als auch den logischen Teil) an. Fügen Sie eineinterfaceAnweisung für die Schnittstelle ein, die dem LSP zugeordnet ist.Wenn Sie den logischen Teil derselben Schnittstelle auf
[edit interfaces]Hierarchieebene konfigurieren, müssen Sie auch diefamily inetanweisungenfamily mplskonfigurieren:[edit interfaces] interface-name { unit logical-unit-number { family inet; family mpls; } }Aktivieren Sie MPLS auf allen P-Routern, die am LSP teilnehmen, indem Sie die
interfaceAnweisung auf Hierarchieebene[edit mpls]angeben.Fügen Sie eine
interfaceAnweisung für jede Verbindung zum LSP ein.[edit] mpls { interface interface-name; interface interface-name; }Aktivieren Sie MPLS auf der Schnittstelle zwischen den PE- und CE-Routern, indem Sie die
interfaceAnweisung auf Hierarchieebene[edit mpls]angeben.Auf diese Weise kann der PE-Router dem Datenverkehr, der den LSP betritt, ein MPLS-Label zuweisen oder das Label vom Datenverkehr, der den LSP verlässt, entfernen.
[edit] mpls { interface interface-name; }Informationen zur Konfiguration von MPLS finden Sie unter Konfigurieren des Eingangsrouters für MPLS-signalierte LSPs.
Siehe auch
Konfigurieren von Richtlinien für die VRF-Tabelle auf PE-Routern in VPNs
Auf jedem PE-Router müssen Sie Richtlinien definieren, die festlegen, wie Routen in die VRF-Tabelle des Routers importiert und exportiert werden. In diesen Richtlinien müssen Sie das Routenziel definieren, und Sie können optional den Routenursprung definieren.
Um die Richtlinie für die VRF-Tabellen zu konfigurieren, führen Sie die Schritte in den folgenden Abschnitten aus:
- Konfigurieren des Routenziels
- Konfigurieren des Routenursprungs
- Konfigurieren einer Importrichtlinie für die VRF-Tabelle des PE-Routers
- Konfigurieren einer Exportrichtlinie für die VRF-Tabelle des PE-Routers
- Anwendung von VRF-Export- und BGP-Exportrichtlinien
- Konfigurieren eines VRF-Ziels
Konfigurieren des Routenziels
Als Teil der Richtlinienkonfiguration für die VPN-Routing-Tabelle müssen Sie ein Routenziel definieren, das definiert, zu welchem VPN die Route gehört. Wenn Sie verschiedene Arten von VPN-Services (Layer-2-VPNs , Layer-3-VPNs , EVPNs oder VPLS) auf demselben PE-Router konfigurieren, achten Sie darauf, dass Sie eindeutige Routenzielwerte zuweisen, um zu vermeiden, dass der falschen VPN-Routing-Tabelle Routen- und Signalinformationen hinzugefügt werden.
Um das Routenziel zu konfigurieren, fügen Sie die target Option in die community Anweisung ein:
community name members target:community-id;
Sie können diese Anweisung auf den folgenden Hierarchieebenen einschließen:
[edit policy-options][edit logical-systems logical-system-name policy-options]
name ist der Name der Community.
community-id ist die Kennung der Community. Geben Sie es in einem der folgenden Formate an:
as-number:number, wobeias-numberist eine AS-Zahl (ein 2-Byte-Wert) undnumberein 4-Byte-Community-Wert. Die AS-Nummer kann im Bereich 1 bis 65.535 liegen. Wir empfehlen, eine von der IANA zugewiesene, nichtprivate AS-Nummer zu verwenden, vorzugsweise die eigene ISP-Nummer oder die eigene AS-Nummer des Kunden. Der Gemeinschaftswert kann eine Zahl im Bereich 0 bis 4.294.967.295 (232 – 1) sein.ip-address:number, wobeiip-addressist eine IPv4-Adresse (ein 4-Byte-Wert) undnumberein 2-Byte-Community-Wert. Die IP-Adresse kann eine beliebige global eindeutige Unicast-Adresse sein. Wir empfehlen, dass Sie die Adresse verwenden, die Sie in der Anweisung konfigurieren, bei derrouter-ides sich um eine nichtprivate Adresse im zugewiesenen Präfixbereich handelt. Der Gemeinschaftswert kann eine Zahl im Bereich von 1 bis 65.535 sein.
Konfigurieren des Routenursprungs
In den Import- und Exportrichtlinien für die VRF-Tabelle des PE-Routers können Sie optional den Routenursprung (auch Als Ursprungsstandort bezeichnet) für die VRF-Routen eines PE-Routers mithilfe einer VRF-Exportrichtlinie zuweisen, die auf externe BGP(MP-EBGP)-VPN-IPv4-Routenaktualisierungen angewendet wird, die an andere PE-Router gesendet werden.
Durch den Abgleich des zugewiesenen Routenursprungsattributs in einer empfangenden VRF-Importrichtlinie wird sichergestellt, dass VPN-IPv4-Routen, die durch MP-EBGP-Updates von einem PE gelernt wurden, nicht von einem anderen PE, das mit demselben Standort verbunden ist, auf dieselbe VPN-Site reimportiert werden.
Führen Sie die folgenden Schritte aus, um einen Routenursprung zu konfigurieren:
Fügen Sie die
communityAnweisung mit deroriginOption ein:community name members origin:community-id;
Sie können diese Anweisung auf den folgenden Hierarchieebenen einschließen:
[edit policy-options][edit logical-systems logical-system-name policy-options]
nameist der Name der Community.community-idist die Kennung der Community. Geben Sie es in einem der folgenden Formate an:as-number:number, wobeias-numberist eine AS-Zahl (ein 2-Byte-Wert) undnumberein 4-Byte-Community-Wert. Die AS-Nummer kann im Bereich 1 bis 65.535 liegen. Wir empfehlen, eine von der IANA zugewiesene, nichtprivate AS-Nummer zu verwenden, vorzugsweise die eigene ISP-Nummer oder die eigene AS-Nummer des Kunden. Der Gemeinschaftswert kann eine Zahl im Bereich 0 bis 4.294.967.295 (232 – 1) sein.ip-address:number, wobeiip-addressist eine IPv4-Adresse (ein 4-Byte-Wert) undnumberein 2-Byte-Community-Wert. Die IP-Adresse kann eine beliebige global eindeutige Unicast-Adresse sein. Wir empfehlen, dass Sie die Adresse verwenden, die Sie in der Anweisung konfigurieren, bei derrouter-ides sich um eine nichtprivate Adresse im zugewiesenen Präfixbereich handelt. Der Gemeinschaftswert kann eine Zahl im Bereich von 1 bis 65.535 sein.
Fügen Sie die Community in die Importrichtlinie für die VRF-Tabelle des PE-Routers ein, indem Sie die
communityAnweisung mit demcommunity-idin Schritt 1 definierten Bezeichner auf Hierarchieebene[edit policy-options policy-statement import-policy-name term import-term-name from]konfigurieren. Siehe Konfigurieren einer Importrichtlinie für die VRF-Tabelle des PE-Routers.Wenn die Klausel der
fromRichtlinie keine Voraussetzung für die Gemeinschaft vorgibt, kann dievrf-importErklärung, in der die Richtlinie angewendet wird, nicht übernommen werden. Der Commit-Vorgang von Junos OS wird die Validierungsprüfung nicht bestanden.Fügen Sie die Community in die Exportrichtlinie für die VRF-Tabelle des PE-Routers ein, indem Sie die
communityAnweisung mit demcommunity-idin Schritt 1 definierten Bezeichner auf Hierarchieebene[edit policy-options policy-statement export-policy-name term export-term-name then]konfigurieren. Siehe Konfigurieren einer Exportrichtlinie für die VRF-Tabelle des PE-Routers.
Ein Konfigurationsbeispiel finden Sie unter Konfigurieren des Routenursprungs für VPNs .
Konfigurieren einer Importrichtlinie für die VRF-Tabelle des PE-Routers
Jedes VPN kann eine Richtlinie haben, die definiert, wie Routen in die VRF-Tabelle des PE-Routers importiert werden. Eine Importrichtlinie wird auf Routen angewendet, die von anderen PE-Routern im VPN empfangen werden. Eine Richtlinie muss alle Routen auswerten, die über die IBGP-Sitzung mit dem Peer-PE-Router empfangen werden. Wenn die Routen mit den Bedingungen übereinstimmen, wird die Route in der VRF-Tabelle des PE-Routers routing-instance-name.inet.0 installiert. Eine Importrichtlinie muss einen zweiten Ausdruck enthalten, der alle anderen Routen ablehnt.
Sofern eine Importrichtlinie nur eine then reject Erklärung enthält, muss sie einen Verweis auf eine Community enthalten. Andernfalls schlägt der Commit fehl, wenn Sie versuchen, die Konfiguration zu bestätigen. Sie können mehrere Importrichtlinien konfigurieren.
Eine Importrichtlinie bestimmt, was in eine angegebene VRF-Tabelle importiert werden soll, basierend auf den VPN-Routen , die von den PE-Remote-Routern über IBGP gelernt wurden. Die IBGP-Sitzung wird auf [edit protocols bgp] Hierarchieebene konfiguriert. Wenn Sie auch eine Importrichtlinie auf Hierarchieebene [edit protocols bgp] konfigurieren, werden die Importrichtlinien auf [edit policy-options] Hierarchie- und [edit protocols bgp] Hierarchieebene durch einen logischen UND-Vorgang kombiniert. Auf diese Weise können Sie Datenverkehr als Gruppe filtern.
Gehen Sie folgendermaßen vor, um eine Importrichtlinie für die VRF-Tabelle des PE-Routers zu konfigurieren:
Um eine Importrichtlinie zu definieren, fügen Sie die Anweisung ein
policy-statement. Für alle PE-Router muss eine Importrichtlinie immer diepolicy-statementAnweisung enthalten, mindestens:policy-statement import-policy-name { term import-term-name { from { protocol bgp; community community-id; } then accept; } term term-name { then reject; } }Sie können die
policy-statementAnweisung auf den folgenden Hierarchieebenen einschließen:[edit policy-options][edit logical-systems logical-system-name policy-options]
Die
import-policy-nameRichtlinie bewertet alle Routen, die über die IBGP-Sitzung mit dem anderen PE-Router empfangen werden. Wenn die Routen mit den Bedingungen in derfromAnweisung übereinstimmen, wird die Route in der .inet.0 VRF-Tabelle des PE-Routers routing-instance-nameinstalliert. Der zweite Begriff in der Richtlinie lehnt alle anderen Routen ab.Weitere Informationen zum Erstellen von Richtlinien finden Sie im Benutzerhandbuch für Routing-Richtlinien, Firewall-Filter und Traffic Policer.
Sie können optional einen regulären Ausdruck verwenden, um eine Reihe von Communitys zu definieren, die für die VRF-Importrichtlinie verwendet werden sollen.
Mithilfe der Anweisung auf
[edit policy-options policy-statement policy-statement-name]Hierarchieebene können Sie beispielsweise Folgendescommunitykonfigurieren:[edit policy-options vrf-import-policy-sample] community high-priority members *:50
Beachten Sie, dass Sie einen regulären Ausdruck nicht als Teil einer erweiterten Routing-Community konfigurieren können. Weitere Informationen zur Konfiguration regulärer Ausdrücke für Communitys finden Sie unter Grundlegendes zum Definieren von BGP-Communitys und erweiterten Communities .
Um eine Importrichtlinie zu konfigurieren, fügen Sie die Anweisung ein
vrf-import:vrf-import import-policy-name;
Sie können diese Anweisung auf den folgenden Hierarchieebenen einschließen:
[edit routing-instances routing-instance-name][edit logical-systems logical-system-name routing-instances routing-instance-name]
Konfigurieren einer Exportrichtlinie für die VRF-Tabelle des PE-Routers
Jedes VPN kann eine Richtlinie haben, die definiert, wie Routen aus der VRF-Tabelle des PE-Routers exportiert werden. Auf Routen, die an andere PE-Router im VPN gesendet werden, wird eine Exportrichtlinie angewendet. Eine Exportrichtlinie muss alle Routen auswerten, die über die Routing-Protokollsitzung mit dem CE-Router empfangen werden. (Diese Sitzung kann die Routing-Protokolle BGP, OSPF oder Routing Information Protocol [RIP] oder statische Routen verwenden.) Wenn die Routen mit den Bedingungen übereinstimmen, wird das angegebene Community-Ziel (das Routenziel) hinzugefügt und in die entfernten PE-Router exportiert. Eine Exportrichtlinie muss einen zweiten Begriff enthalten, der alle anderen Routen ablehnt.
Die in der VPN-Routing-Instanz definierten Exportrichtlinien sind die einzigen Exportrichtlinien, die für die VRF-Tabelle gelten. Alle Exportrichtlinien, die Sie für die IBGP-Sitzung zwischen den PE-Routern definieren, haben keine Auswirkungen auf die VRF-Tabelle. Sie können mehrere Exportrichtlinien konfigurieren.
Gehen Sie folgendermaßen vor, um eine Exportrichtlinie für die VRF-Tabelle des PE-Routers zu konfigurieren:
Für alle PE-Router muss eine Exportrichtlinie VPN-Routen an und von den angeschlossenen CE-Routern entsprechend dem Typ des Routingprotokolls verteilen, das Sie zwischen den CE- und PE-Routern innerhalb der Routing-Instanz konfigurieren.
Um eine Exportrichtlinie zu definieren, fügen Sie die Anweisung ein
policy-statement. Eine Exportrichtlinie muss immer diepolicy-statementAnweisung enthalten, mindestens:policy-statement export-policy-name { term export-term-name { from protocol (bgp | ospf | rip | static); then { community add community-id; accept; } } term term-name { then reject; } }Hinweis:Die Konfiguration der
community addAnweisung ist eine Voraussetzung für Layer-2-VPN-VRF-Exportrichtlinien . Wenn Sie diecommunity addAnweisung in diecommunity setAnweisung ändern, wird die Verbindung möglicherweise vom Router am Ausgang der Layer-2-VPN-Verbindung unterbrochen.Hinweis:Wenn Sie Draft-Rosen-Multicast-VPNs konfigurieren, die im quellspezifischen Modus ausgeführt werden, und
vrf-exportdie Anweisung zur Angabe der Exportrichtlinie verwenden, muss die Richtlinie einen Ausdruck haben, der Routen aus der Routingtabelle vrf-name.mdt.0 akzeptiert. Dieser Begriff sorgt für die korrekte PE-Autoermittlung mithilfe derinet-mdtAdressfamilie.Bei der Konfiguration von Draft-Rosen-Multicast-VPNs, die im quellspezifischen Modus ausgeführt werden, und mit der
vrf-targetAnweisung wird die VRF-Exportrichtlinie automatisch generiert und akzeptiert automatisch Routen aus der Routingtabelle vrf-name.mdt.0.Sie können die
policy-statementAnweisung auf den folgenden Hierarchieebenen einschließen:[edit policy-options][edit logical-systems logical-system-name policy-options]
Die
export-policy-nameRichtlinie wertet alle Routen aus, die über die Routing-Protokollsitzung mit dem CE-Router empfangen werden. (Diese Sitzung kann die Routing-Protokolle BGP, OSPF oder RIP oder statische Routen verwenden.) Wenn die Routen mit den Bedingungen in derfromAnweisung übereinstimmen, wird das in derthen community addAnweisung angegebene Community-Ziel hinzugefügt und in die entfernten PE-Router exportiert. Der zweite Begriff in der Richtlinie lehnt alle anderen Routen ab.Weitere Informationen zum Erstellen von Richtlinien finden Sie im Benutzerhandbuch für Routing-Richtlinien, Firewall-Filter und Traffic Policer.
Um die Richtlinie anzuwenden, fügen Sie die Anweisung ein
vrf-export:vrf-export export-policy-name;
Sie können diese Anweisung auf den folgenden Hierarchieebenen einschließen:
[edit routing-instances routing-instance-name][edit logical-systems logical-system-name routing-instances routing-instance-name]
Anwendung von VRF-Export- und BGP-Exportrichtlinien
Wenn Sie eine VRF-Exportrichtlinie anwenden, wie unter Konfigurieren einer Exportrichtlinie für die VRF-Tabelle des PE-Routers beschrieben, werden Routen von VPN-Routing-Instanzen basierend auf dieser Richtlinie an andere PE-Router angeboten, während die BGP-Exportrichtlinie ignoriert wird.
Wenn Sie die vpn-apply-export Anweisung in die BGP-Konfiguration einbeziehen, werden sowohl die VRF-Export- als auch die BGP-Gruppen- oder Nachbarnexportrichtlinien angewendet (zuerst VRF, dann BGP), bevor Routen in den VPN-Routing-Tabellen zu anderen PE-Routern angekündigt werden.
Wenn ein PE-Gerät auch als Route Reflector (RR) oder Autonomous System Boundary Router (ASBR) in einem Carrier-over-Carrier- oder Inter-AS-VPN fungiert, wird die Next-Hop-Manipulation in der vrf-export-Richtlinie ignoriert.
Wenn Sie die vpn-apply-export Anweisung einschließen, beachten Sie Folgendes:
In die Routingtabelle bgp.l3vpn.0 importierte Routen behalten die Attribute der ursprünglichen Routen bei (z. B. bleibt eine OSPF-Route auch dann eine OSPF-Route, wenn sie in der Routingtabelle bgp.l3vpn.0 gespeichert ist). Dies sollte Ihnen bewusst sein, wenn Sie eine Exportrichtlinie für Verbindungen zwischen einem IBGP PE-Router und einem PE-Router, einem Route Reflector und einem PE-Router oder AS Boundary Router (ASBR)-Peer-Router konfigurieren.
Standardmäßig werden alle Routen in der Routingtabelle bgp.l3vpn.0 in die IBGP-Peers exportiert. Wenn die letzte Anweisung der Exportrichtlinie alle verweigert wird und die Exportrichtlinie nicht speziell für Routen in der Routingtabelle bgp.l3vpn.0 übereinstimmt, werden keine Routen exportiert.
Um sowohl die VRF-Export- als auch die BGP-Exportrichtlinien auf VPN-Routen anzuwenden, fügen Sie die Anweisung ein vpn-apply-export :
vpn-apply-export;
Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisung einschließen können, finden Sie im Abschnitt "Statement Summary" für diese Anweisung.
Konfigurieren eines VRF-Ziels
Wenn Sie die vrf-target Anweisung in die Konfiguration einer VRF-Ziel-Community aufnehmen, werden standardmäßige VRF-Import- und Exportrichtlinien generiert, die Routen mit der angegebenen Ziel-Community akzeptieren und tagten. Sie können dennoch komplexere Richtlinien erstellen, indem Sie VRF-Import- und Exportrichtlinien explizit konfigurieren. Diese Richtlinien überschreiben die Standardrichtlinien, die beim Konfigurieren der vrf-target Anweisung generiert werden.
Wenn Sie die Und export die import Optionen der vrf-target Anweisung nicht konfigurieren, wird die angegebene Community-Zeichenfolge in beide Richtungen angewendet. Die import Keywords bieten export Ihnen mehr Flexibilität, sodass Sie für jede Richtung eine unterschiedliche Community festlegen können.
Die Syntax für die VRF-Ziel-Community ist kein Name. Sie müssen es im Format target:x:yangeben. Ein Community-Name kann nicht angegeben werden, da Sie dazu auch die Community-Mitglieder für diese Community mithilfe der policy-options Erklärung konfigurieren müssen. Wenn Sie die policy-options Anweisungen definieren, können Sie einfach die VRF-Import- und Exportrichtlinien wie gewohnt konfigurieren. Der Zweck der vrf-target Anweisung besteht darin, die Konfiguration zu vereinfachen, indem Sie die meisten Anweisungen auf [edit routing-instances] Hierarchieebene konfigurieren können.
Um ein VRF-Ziel zu konfigurieren, fügen Sie die Anweisung ein vrf-target :
vrf-target community;
Sie können diese Anweisung auf den folgenden Hierarchieebenen einschließen:
[edit routing-instances routing-instance-name][edit logical-systems logical-system-name routing-instances routing-instance-name]
Es folgt ein Beispiel für die Konfiguration der vrf-target Anweisung:
[edit routing-instances sample] vrf-target target:69:102;
Um die vrf-target Anweisung mit den export Und import Optionen zu konfigurieren, fügen Sie die folgenden Anweisungen ein:
vrf-target { export community-name; import community-name; }
Sie können diese Anweisung auf den folgenden Hierarchieebenen einschließen:
[edit routing-instances routing-instance-name][edit logical-systems logical-system-name routing-instances routing-instance-name]
Konfigurieren des Routenursprungs für VPNs
Sie können den Routenursprung verwenden, um zu verhindern, dass Routen, die von einem Kunden-Edge (CE)-Router gelernt wurden, mit Herkunftsgemeinschaft gekennzeichnet sind, von einem anderen CE-Router derselben AS wieder auf sie zurückgepriesen werden.
Im Beispiel wird der Routenursprung verwendet, um zu verhindern, dass vom CE-Router A gelernte Routen, die mit Ursprungsgemeinschaft gekennzeichnet sind, durch AS 200 wieder zum CE-Router E angeboten werden. Die Beispieltopologie ist in Abbildung 1 dargestellt.
In dieser Topologie befinden sich CE-Router A und CE-Router E im selben AS (AS200). Sie verwenden EBGP, um Routen mit ihren jeweiligen Provider-Edge (PE)-Routern, PE-Router B und PE-Router D auszutauschen. Die beiden CE-Router verfügen über eine Back-Verbindung.
In den folgenden Abschnitten wird beschrieben, wie Sie den Routenursprung für eine Gruppe von VPNs konfigurieren:
- Konfiguration der Site of Origin Community auf CE-Router A
- Konfigurieren der Community auf CE-Router A
- Anwenden der Richtlinienaussage auf CE-Router A
- Konfigurieren der Richtlinie für PE-Router D
- Konfigurieren der Community auf PE-Router D
- Anwendung der Richtlinie auf PE-Router D
Konfiguration der Site of Origin Community auf CE-Router A
Im folgenden Abschnitt wird beschrieben, wie Sie DEN CE-Router A konfigurieren, um Routen mit einer Ursprungsgemeinschaft zum PE-Router B anzukündigen.
In diesem Beispiel werden direkte Routen so konfiguriert, dass sie angekündigt werden, aber jede Route kann konfiguriert werden.
Konfigurieren Sie eine Richtlinie, um Routen mit my-soo der Community auf dem CE-Router A wie folgt anzukündigen:
[edit]
policy-options {
policy-statement export-to-my-isp {
term a {
from {
protocol direct;
}
then {
community add my-soo;
accept;
}
}
}
}
Konfigurieren der Community auf CE-Router A
Konfigurieren Sie die my-soo Community auf CE-Router A wie folgt:
[edit]
policy-options {
community my-soo {
members origin:100:1;
}
}
Anwenden der Richtlinienaussage auf CE-Router A
Wenden Sie die Richtlinie "export-to-my-isp" als Exportrichtlinie auf das EBGP-Peering auf dem CE-Router A wie folgt an:
[edit]
protocols {
bgp {
group my_isp {
export export-to-my-isp;
}
}
}
Wenn Sie den show route receive-protocol bgp detail Befehl ausstellen, sollten Sie die folgenden Routen sehen, die von PE-Router B mit my-soo Community stammen:
user@host> show route receive-protocol bgp 10.12.99.2 detail
inet.0: 16 destinations, 16 routes (15 active, 0 holddown, 1 hidden)
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
vpn_blue.inet.0: 8 destinations, 10 routes (8 active, 0 holddown, 0 hidden)
* 10.12.33.0/30 (2 entries, 1 announced)
Nexthop: 10.12.99.2
AS path: 100 I
Communities: origin:100:1
10.12.99.0/30 (2 entries, 1 announced)
Nexthop: 10.12.99.2
AS path: 100 I
Communities: origin:100:1
* 10.255.71.177/32 (1 entry, 1 announced)
Nexthop: 10.12.99.2
AS path: 100 I
Communities: origin:100:1
* 192.168.64.0/21 (1 entry, 1 announced)
Nexthop: 10.12.99.2
AS path: 100 I
Communities: origin:100:1
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
__juniper_private1__.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0
hidden)
Konfigurieren der Richtlinie für PE-Router D
Konfigurieren Sie eine Richtlinie für DEN PE-Router D, die verhindert, dass Routen mit my-soo Community-Tags von CE-Router A dem CE-Router E wie folgt angeboten werden:
[edit]
policy-options {
policy-statement soo-ce1-policy {
term a {
from {
community my-soo;
then {
reject;
}
}
}
}
}
Konfigurieren der Community auf PE-Router D
Konfigurieren Sie die Community auf DEM PE-Router D wie folgt:
[edit]
policy-options {
community my-soo {
members origin:100:1;
}
}
Anwendung der Richtlinie auf PE-Router D
Um zu verhindern, dass vom CE-Router A erlernte Routen an DEN CE-Router E angeboten werden (die beiden Router können diese Routen direkt kommunizieren), wenden Sie die soo-ce1-policy Richtlinienaussage als Exportrichtlinie auf die PE-Router D- und CE-Router E EBGP-Sitzung vpn_bluean.
Zeigen Sie die EBGP-Sitzung auf dem PE-Router D mit dem show routing-instances Befehl an.
user@host# show routing-instances
vpn_blue {
instance-type vrf;
interface fe-2/0/0.0;
vrf-target target:100:200;
protocols {
bgp {
group ce2 {
advertise-peer-as;
peer-as 100;
neighbor 10.12.99.6;
}
}
}
}
Wenden Sie die soo-ce1-policy Richtlinienaussage als Exportrichtlinie auf die PE-Router D- und CE-Router E-EBGP-Sitzung vpn_blue wie folgt an:
[edit routing-instances]
vpn_blue {
protocols {
bgp {
group ce2{
export soo-ce1-policy;
}
}
}
}