4. VPN-Routenverteilung über BGP

4. VPN-Routenverteilung über BGP (VPN Route Distribution via BGP)

Die PE-Router nutzen BGP, um VPN-Routen untereinander zu verteilen (genauer: um VPN-Routen untereinander verteilbar zu machen).

Wir erlauben jedem VPN einen eigenen Adressraum (address space); das bedeutet, dass eine gegebene Adresse in verschiedenen VPN auf unterschiedliche Systeme verweisen kann. Führen zwei Routen zu einem selben IP-Adresspräfix (prefix) tatsächlich zu unterschiedlichen Systemen, ist es wichtig, dass BGP sie nicht als vergleichbare Routen behandelt; andernfalls würde BGP möglicherweise nur eine installieren und das andere System unerreichbar machen. Zudem müssen wir sicherstellen, dass mittels Richtlinie (policy) entschieden wird, welche Pakete welche Route nutzen — nachdem BGP mehrere installiert hat, darf in einem bestimmten VRF nur eine dieser Routen erscheinen.

Diese Ziele erreichen wir durch eine neue Adressfamilie (address family), wie folgt beschrieben.

4.1. Die VPN-IPv4-Adressfamilie (The VPN-IPv4 Address Family)

Die BGP-Multiprotokoll-Erweiterungen [BGP-MP] ermöglichen BGP, Routen aus mehreren „Adressfamilien“ zu tragen. Wir führen das Konzept der „VPN-IPv4-Adressfamilie“ ein. Eine VPN-IPv4-Adresse ist eine 12-Byte-Größe, die mit einem 8 Byte großen Route Distinguisher (RD) beginnt, gefolgt von einer 4 Byte großen IPv4-Adresse. Nutzen mehrere VPN dasselbe IPv4-Adresspräfix, wandeln die PE diese Präfixe in eindeutige VPN-IPv4-Adresspräfixe um. Dies stellt sicher, dass BGP, selbst wenn dieselbe Adresse in verschiedenen VPN verwendet wird, dennoch völlig verschiedene Routen zu dieser Adresse transportieren kann — eine pro VPN.

Da VPN-IPv4-Adressen und IPv4-Adressen unterschiedlichen Adressfamilien angehören, werden sie von BGP niemals als vergleichbare Adressen behandelt.

Der RD ist lediglich eine Zahl; er enthält keine inhärente Information. Er identifiziert weder die Herkunft der Route noch die Menge der VPN, an die die Route verteilt wird. Der einzige Zweck des RD ist es, für ein gemeinsames IPv4-Präfix unterschiedliche Routen erzeugen zu können. Wo die Route neu verteilt wird, erfordert andere Mittel (siehe Abschnitt 4.3).

Der RD kann auch genutzt werden, um mehrere verschiedene Routen zu einem System zu erzeugen. Wir erörterten den Fall, dass die Route zu einem bestimmigsten Server (server) für Intranet- und Extranet-Verkehr unterschiedlich sein soll. Dies lässt sich durch zwei VPN-IPv4-Routen mit gleichem IPv4-Teil, aber unterschiedlichem RD erreichen. Dadurch kann BGP mehrere verschiedene Routen zu einem System installieren und mittels Richtlinie (siehe Abschnitt 4.3.5) entscheiden, welche Pakete welche Route nutzen.

Die Struktur des RD ist so gewählt, dass jeder Diensteanbieter seinen eigenen Nummerierungsraum (numbering space, also eigene RD-Vergabe) ohne Konflikt mit den Vergaben anderer Diensteanbieter verwalten kann. Ein RD besteht aus drei Feldern: einem 2 Byte großen Typfeld (type), einem Administratorfeld (administrator) und einem zugewiesenen Nummernfeld (assigned number). Der Wert des Typfelds bestimmt die Länge der beiden anderen Felder sowie die Semantik des Administratorfelds. Das Administratorfeld kennzeichnet eine autoritative Instanz (authority), und das zugewiesene Nummernfeld enthält eine von dieser Instanz für einen bestimmten Zweck zugewiesene Nummer. Beispielsweise kann ein RD ein Administratorfeld mit einer autonomen Systemnummer (Autonomous System number, ASN) und ein (anderes) 4 Byte großes Feld mit einer Nummer aus dem Nummerierungsraum enthalten, der von dem SP verwaltet wird, dem die ASN zugewiesen wurde.

Der Zweck dieser RD-Struktur ist es sicherzustellen, dass ein SP, der den VPN-Backbone-Dienst bereitstellt, stets einen eindeutigen RD erzeugen kann. Für BGP ist diese Struktur jedoch bedeutungslos — wenn BGP die beiden Adresspräfixe vergleicht, ignoriert er die Struktur vollständig.

Die PE müssen so konfiguriert werden, dass Routen zu einem bestimmten CE mit einem bestimmten RD assoziiert sind. Diese Konfiguration kann bewirken, dass alle Routen zu einem bestimmten CE demselben RD zugeordnet werden, oder dass verschiedene Routen — selbst wenn sie zum selben CE führen — unterschiedlichen RD zugeordnet werden.

4.2. Kodierung von Route Distinguishern (Encoding of Route Distinguishers)

Wie bereits gesagt, besteht eine VPN-IPv4-Adresse aus einem 8 Byte großen Route Distinguisher gefolgt von einer 4 Byte großen IPv4-Adresse. Die Kodierung des RD lautet:

• Typfeld (Type Field): 2 Byte
• Wertfeld (Value Field): 6 Byte

Die Interpretation des Wertfelds hängt vom Wert des Typfelds ab. Derzeit sind drei Werte des Typfelds definiert: 0, 1 und 2.

• Typ 0: Das Wertfeld besteht aus zwei Unterfeldern:

  • Administrator-Unterfeld (Administrator subfield): 2 Byte
  • Zugewiesenes-Nummern-Unterfeld (Assigned Number subfield): 4 Byte

  Das Administrator-Unterfeld muss eine autonome Systemnummer enthalten. Stammt diese ASN aus dem öffentlichen ASN-Raum, muss sie von der zuständigen Instanz zugewiesen worden sein (die Verwendung von Werten aus dem privaten ASN-Raum wird dringend discouraged). Das zugewiesene Nummernfeld enthält eine Nummer aus dem Nummerierungsraum, der von dem Unternehmen verwaltet wird, dem die ASN zugewiesen wurde.

• Typ 1: Das Wertfeld besteht aus zwei Unterfeldern:

  • Administrator-Unterfeld: 4 Byte
  • Zugewiesenes-Nummern-Unterfeld: 2 Byte

  Das Administrator-Unterfeld muss eine IP-Adresse enthalten. Stammt diese IP-Adresse aus dem öffentlichen IP-Adressraum, muss sie von der zuständigen Instanz zugewiesen worden sein (die Verwendung von Adressen aus dem privaten IP-Adressraum wird dringend discouraged). Das zugewiesene Nummernfeld enthält eine Nummer aus dem Nummerierungsraum, der von dem Unternehmen verwaltet wird, dem die IP-Adresse zugewiesen wurde.

• Typ 2: Das Wertfeld besteht aus zwei Unterfeldern:

  • Administrator-Unterfeld: 4 Byte
  • Zugewiesenes-Nummern-Unterfeld: 2 Byte

  Das Administrator-Unterfeld muss eine 4 Byte große autonome Systemnummer (Autonomous System number) [BGP-AS4] enthalten. Stammt diese ASN aus dem öffentlichen ASN-Raum, muss sie von der zuständigen Instanz zugewiesen worden sein (die Verwendung von Werten aus dem privaten ASN-Raum wird dringend discouraged). Das zugewiesene Nummernfeld enthält eine Nummer aus dem Nummerierungsraum, der von dem Unternehmen verwaltet wird, dem die ASN zugewiesen wurde.

4.3. Steuerung der Routenverteilung (Controlling Route Distribution)

In diesem Abschnitt erörtern wir, wie die Verteilung von VPN-IPv4-Routen gesteuert wird.

Wenn ein PE-Router über seine Verbindung zu einem bestimmten CE an ein bestimmtes VPN „angehängt“ ist, lernt er einige IP-Routen dieses VPN von dem betreffenden CE-Router. Routen, die von einem bestimmten CE-Router über einen bestimmten Attachment Circuit gelernt wurden, können in den mit diesem Attachment Circuit assoziierten VRF installiert werden. Welche davon installiert werden, hängt davon ab, wie der PE die Routen vom CE lernt. Insbesondere wird dies beim PE/CE-Routing-Protokoll (routing protocol) durch dessen Entscheidungsprozess (decision process) bestimmt, wie in Abschnitt 7 besprochen.

Diese Routen werden dann in VPN-IPv4-Routen umgewandelt und nach BGP „exportiert“ (export). Gibt es mehrere Routen zu einem bestimmten VPN-IPv4-Präfix, wählt BGP mittels seines Entscheidungsprozesses die „beste“ (best) aus. Diese Route wird dann von BGP an die anderen PE verteilt, die sie benötigen. Bei diesen anderen PE wählt BGP erneut die beste VPN-IPv4-Route für ein gegebenes Präfix. Die ausgewählte VPN-IPv4-Route wird dann zurück in eine IP-Route umgewandelt und in einen oder mehrere VRF „importiert“ (import). Ob sie tatsächlich im VRF installiert wird, hängt vom Ergebnis der BGP- und IGP-Entscheidungsprozesse ab. Schließlich können alle im VRF installierten Routen an die assoziierten CE-Router verteilt werden.

4.3.1. Das Route-Target-Attribut (The Route Target Attribute)

Jeder VRF ist mit einem oder mehreren Route-Target-Attributen (RT) assoziiert.

Wenn ein PE-Router aus einer von einem CE gelernten IPv4-Route eine VPN-IPv4-Route erzeugt, wird die Route mit einem oder mehreren Route-Target-Attributen assoziiert. Diese Attribute werden von BGP als Routenattribute mitgeführt.

Jede Route, die mit dem Route Target T assoziiert ist, muss an jeden PE-Router verteilt werden, der einen mit dem Route Target T assoziierten VRF besitzt. Wenn ein PE-Router eine solche Route empfängt, ist sie berechtigt (eligible), in die mit T assoziierten VRF dieses PE installiert zu werden. (Ob sie tatsächlich installiert wird, hängt vom Ergebnis der BGP- und IGP-Entscheidungsprozesse ab.)

Ein Route-Target-Attribut kann als Kennzeichnung einer Menge von Standorten angesehen werden (genauer gesagt identifiziert es eigentlich eine Menge von VRF). Ein Route-Target mit einer Route zu assoziieren, macht diese Route berechtigt, in die VRF eingefügt zu werden, die zur Weiterleitung des Verkehrs von den entsprechenden Standorten genutzt werden.

Es gibt eine Menge von Route Targets, die die PE an Routen anhängen, die von einem Standort S gelernt wurden; nennen wir sie „Export Targets“. Es gibt zudem eine Menge von Route Targets, die der PE nutzt, um zu entscheiden, ob eine von einem anderen PE empfangene Route in den mit Standort S assoziierten VRF eingefügt werden darf; nennen wir sie „Import Targets“. Diese beiden Mengen sind verschieden und müssen nicht identisch sein. Beachten Sie: Eine bestimmte VPN-IPv4-Route ist nur dann berechtigt, in einem bestimmten VRF installiert zu werden, wenn es ein Route Target gibt, das sowohl zu den Route Targets der Route als auch zu den Import Targets dieses VRF gehört.

Die Funktion des Route-Target-Attributs ähnelt der des BGP-Communities-Attributs. Dessen Format ist für den vorliegenden Zweck jedoch unzureichend, da es nur einen 2 Byte großen Nummernraum erlaubt. Wir beabsichtigen, das Format wie für den RD (siehe Abschnitt 4.2) zu strukturieren, sodass ein Typfeld die Länge des Administratorfelds festlegt und der Rest des Attributs aus dem Nummerierungsraum des angegebenen Administrators stammt. Dies lässt sich mit BGP-Extended-Communities erreichen. Die hier erörterten Route Targets werden als BGP-Extended-Community Route Target [BGP-EXTCOMM] kodiert und haben eine dem RD ähnliche Struktur.

Wenn ein BGP-Speaker (speaker) mehrere Routen zu demselben VPN-IPv4-Präfix empfängt, werden die BGP-Routenpräferenzregeln (route preference) genutzt, um die von BGP zu installierende VPN-IPv4-Route auszuwählen.

Beachten Sie: Eine Route kann nur einen RD haben, aber mehrere Route Targets. In BGP ist die Verwendung einer einzigen Route mit mehreren Attributen (statt mehrerer Routen) vorteilhaft für die Skalierbarkeit (scalability). Man könnte das Route-Target-Attribut eliminieren, indem man mehr Routen erzeugt (also mehr RD verwendet), aber das verschlechtert die Skalierbarkeit.

Wie entscheidet der PE, welche Route-Target-Attribute er einer gegebenen Route zuordnet? Es gibt verschiedene Möglichkeiten. Der PE kann konfiguriert werden, alle Routen zu einem bestimmten Standort mit einem bestimmten Route Target zu assoziieren. Alternativ kann der PE konfiguriert werden, manche Routen zu einem Standort mit einem Route Target und andere mit einem anderen Route Target zu assoziieren.

Sind PE und CE selbst BGP-Peers (siehe Abschnitt 7), kann der SP dem Kunden in gewissem Maße erlauben, festzulegen, wie seine Routen verteilt werden. SP und Kunde müssen sich im Voraus auf die Menge der RT einigen, die der Kunde an seine VPN-Routen anhängen darf. Der CE kann dann eine oder mehrere dieser RT an jede IP-Route anhängen, die er an den PE verteilt. Dies ermöglicht dem Kunden, seine Routenverteilungsrichtlinie in vereinbarten Grenzen dynamisch festzulegen. Darf der CE RT an seine Routen anhängen, muss der PE alle Routen mit RT filtern, die der Kunde nicht verwenden darf. Andernfalls muss der PE die RT entfernen, bevor er die Kundenroute in eine VPN-IPv4-Route umwandelt.

4.3.2. Routenverteilung zwischen PEs über BGP (Route Distribution Among PEs by BGP)

Sind zwei Standorte eines VPN mit PE verbunden, die im selben autonomen System (Autonomous System) stehen, können diese PE ihre VPN-IPv4-Routen über ihre IBGP-Verbindungen austauschen. („IBGP“ bezeichnet die Menge der Protokolle und Prozesse, die auf einer BGP-Verbindung verwendet werden, wenn beide BGP-Speaker im selben autonomen System sind. Dies unterscheidet sich von „EBGP“ — der Menge der Prozesse zwischen zwei BGP-Speakers in verschiedenen autonomen Systemen.) Alternativ kann jeder PE eine IBGP-Verbindung zu einem Route Reflector (route reflector) [BGP-RR] aufbauen.

Wenn ein PE-Router eine VPN-IPv4-Route über BGP verteilt, verwendet er seine eigene Adresse als „BGP Next Hop“ (BGP next hop). Diese Adresse ist als VPN-IPv4-Adresse mit RD 0 kodiert. ([BGP-MP] verlangt, dass die Next-Hop-Adresse derselben Adressfamilie wie die NLRI angehört.) Zugleich wird ein MPLS-Label (label) zugewiesen und verteilt. (Wesentlich verteilt der PE-Router keine VPN-IPv4-Route, sondern eine „mit Etikette versehene VPN-IPv4-Route“ — Labeled VPN-IPv4 route. Siehe [MPLS-BGP].) Wenn ein PE ein empfangenes Paket mit diesem Label an der Spitze des Stapels verarbeitet, poppt (pop) er den Stapel und behandelt das Paket entsprechend.

Dieser PE kann die genaue Menge der im VRF vorhandenen Routen verteilen, oder er kann eine Zusammenfassung (summarization) bilden und einen Aggregat (aggregate) dieser Routen verteilen, oder eine Kombination.

Angenommen, ein PE hat für Route R ein Label L zugewiesen und diese Label-Zuordnung über BGP verteilt. Ist R ein Aggregat einer Routenmenge im VRF, weiß der PE, dass am Backbone eintreffende Pakete mit diesem Label ihre Zieladresse in einem VRF nachschlagen müssen. Schlägt der PE das Label in seiner Label Information Base nach, erfährt er, welcher VRF zu verwenden ist. Ist R hingegen kein Aggregat, erfährt er beim Nachschlagen des Labels den Egress-Attachment Circuit (egress attachment circuit) und den Kapselungs-Header des Pakets. In diesem Fall erfolgt kein VRF-Nachschlag.

Wir gehen davon aus, dass der häufigste Fall der ist, in dem die Route kein Aggregat ist. Das Aggregat ist jedoch nützlich, wenn der VRF viele Host-Routen (host route, etwa bei Einwahl — dial-in) enthält oder mit einer LAN-Schnittstelle (Local Area Network, LAN) assoziiert ist (wo jedes System im LAN einen anderen Egress-Layer-2-Header hat, aber nicht für jedes dieser Systeme eine Route verteilt wird).

Ob jede Route ein eigenes Label erhält, ist eine Implementierungsentscheidung. Mehrere Algorithmen sind denkbar, um zu entscheiden, ob zwei Routen dasselbe Label erhalten:

• Man kann das gesamte VRF ein einziges Label teilen lassen, sodass alle Routen dieses VRF dasselbe Label teilen. Wenn der Egress-PE ein Paket mit diesem Label empfängt, muss er die IP-Zieladresse des Pakets in diesem VRF (dem „Egress VRF“) nachschlagen, um den Egress-Attachment Circuit und die entsprechende Data-Link-Kapselung (data link) zu bestimmen.

• Man kann jeden Attachment Circuit ein eigenes Label teilen lassen, sodass alle Routen mit demselben „Egress-Attachment Circuit“ dasselbe Label teilen. Dies vermeidet einen Egress-VRF-Nachschlag, wenngleich möglicherweise ein Nachschlag (etwa ARP) zur Bestimmung der Data-Link-Kapselung nötig bleibt.

• Man kann jeder Route ein eigenes Label geben. So kann das PE/CE-Routing bei einer Route, die über einen von mehreren Attachment Circuits erreichbar ist, den bevorzugten Pfad von einem auf einen anderen umschalten, ohne dafür ein neues Label zu verteilen.

Weitere Algorithmen sind möglich. Die Wahl liegt beim Egress-PE; sie ist ansonsten transparent.

Bei der Nutzung so über BGP verteilter MPLS-Labels setzen wir voraus, dass ein MPLS-Paket mit einem solchen Label vom Router, der die entsprechende BGP-Route installiert hat, zum BGP-Next-Hop-Router getunnelt (tunnel) werden kann. Dies erfordert entweder einen Label-Switched-Path zwischen diesen beiden Routern oder die Möglichkeit, eine andere Tunneltechnik (z. B. [MPLS-in-IP-GRE]) zu nutzen.

Der Tunnel kann einem „Best-Effort“-Routing (best effort) folgen oder einem Traffic-Engineered-Routing (traffic-engineered). Zwischen einem Paar von Routern kann es einen solchen Tunnel oder mehrere mit möglicherweise unterschiedlichen QoS-Eigenschaften (Quality of Service) geben. Für die VPN-Architektur ist entscheidend, dass ein solcher Tunnel existiert. Um die Interoperabilität (interoperability) zwischen Systemen zu gewährleisten, die diese VPN-Architektur mit MPLS-Label-Switched-Paths als Tunneltechnik implementieren, müssen alle diese Systeme das Label Distribution Protocol (LDP) [MPLS-LDP] unterstützen. Insbesondere muss auf Schnittstellen außer LC-ATM [MPLS-ATM] und LC-FR [MPLS-FR] der Downstream-Unsolicited-Modus und auf LC-ATM- und LC-FR-Schnittstellen der Downstream-on-Demand-Modus unterstützt werden.

Folgt der Tunnel einem Best-Effort-Routing, findet der PE die Route zum entfernten Endpunkt (remote endpoint), indem er dessen IP-Adresse in der Default-Forwarding-Tabelle nachschlägt.

Ein PE-Router — sofern er nicht Route Reflector (siehe Abschnitt 4.3.3) oder ASBR (Autonomous System Border Router) eines Multi-Provider-VPN (siehe Abschnitt 10) ist — sollte eine VPN-IPv4-Route nur installieren, wenn er mindestens einen VRF hat, dessen Import Target mit einem Route Target der Route identisch ist. Ein eingehender Filter (inbound filtering) sollte genutzt werden, um solche Routen zu verwerfen. Wird später einem VRF ein neuer Import Target hinzugefügt (ein „VPN Join“), muss der PE jene Routen nachträglich erwerben, die er zuvor verworfen haben könnte. Dies kann mit dem in [BGP-RFSH] beschriebenen Refresh-Mechanismus erfolgen. Auch der Outbound-Route-Filtering-Mechanismus [BGP-ORF] kann genutzt werden, um das Filtern dynamischer zu machen.

Ebenso kann ein PE, wenn ein bestimmtes Import Target in keinem seiner VRF mehr existiert (als Ergebnis einer oder mehrerer „VPN Prune“-Operationen), alle Routen verwerfen, die dadurch kein Import Target seines VRF mehr als Route Target besitzen.

Ein Router, der mit keinem VPN verbunden ist und kein Route Reflector ist (also ein P-Router), installiert niemals VPN-IPv4-Routen.

Beachten Sie: VPN-Join- und VPN-Prune-Operationen sind nicht störend (non-disruptive), sofern der Refresh-Mechanismus aus [BGP-RFSH] genutzt wird; es muss keine BGP-Verbindung abgebaut werden.

Aufgrund dieser Verteilungsregeln muss kein PE die Routen aller unterstützten VPN halten; dies ist eine wichtige Skalierbarkeitsüberlegung.

4.3.3. Verwendung von Route Reflectors (Use of Route Reflectors)

Anstatt ein vollständiges IBGP-Netz (mesh) zwischen den PE aufzubauen, ist es vorteilhaft, BGP-Route Reflectors [BGP-RR] zur Verbesserung der Skalierbarkeit zu nutzen. Alle üblichen Techniken zur Skalierbarkeit mit Route Reflectors (etwa Hierarchien (hierarchy)) stehen zur Verfügung.

Route Reflectors sind die einzigen Systeme, die Routing-Informationen zu VPN benötigen, mit denen sie nicht direkt verbunden sind. Dennoch muss kein einzelner Route Reflector die VPN-IPv4-Routen aller vom Backbone unterstützten VPN kennen.

Wir skizzieren zwei verschiedene Möglichkeiten, wie die Menge der VPN-IPv4-Routen auf eine Menge von Route Reflectors aufgeteilt wird.

1. Jeder Route Reflector wird mit einer Liste von Route Targets vorkonfiguriert. Zur Redundanz können mehrere Route Reflectors mit derselben Liste vorkonfiguriert werden. Der Route Reflector nutzt die vorkonfigurierte Liste, um seinen eingehenden Routenfilter aufzubauen. Der Route Reflector kann mit den Techniken aus [BGP-ORF] auf jedem seiner Peers (ob ein anderer Route Reflector oder ein PE) den Outbound-Route-Filter (ORF) installieren, der seine vorkonfigurierte Route-Target-Liste enthält. Beachten Sie, dass der Route Reflector ORF von anderen Route Reflectors akzeptieren sollte, d. h. er sollte ihnen die ORF-Fähigkeit (capability) ankündigen.

   Ein Diensteanbieter kann die vorkonfigurierte Route-Target-Liste auf einem Route Reflector ändern. Dabei ändert der Route Reflector die ORFs, die er auf allen seinen IBGP-Peers installiert hat. Um die Änderungshäufigkeit der Konfiguration auf den Route Reflectors zu verringern, kann jeder Route Reflector mit einem Block (block) von Route Targets vorkonfiguriert werden. So ist — wenn ein neues VPN ein neues Route Target benötigt — bereits einer oder mehrere Route Reflectors (vorab) mit diesem Route Target konfiguriert.

   Ist ein bestimmter PE nicht Kunde aller Route Reflectors, erfordert das Hinzufügen eines neuen VPN zu diesem PE („VPN Join“), dass er Kunde des (bzw. der) Route Reflector(s) wird, der die Routen dieses VPN hält. Ebenso kann das Entfernen eines bestehenden VPN von einem PE („VPN Prune“) dazu führen, dass dieser PE nicht mehr Kunde bestimmter Route Reflectors sein muss. In beiden Fällen sind Join- und Prune-Operationen nicht störend (bei Nutzung von [BGP-RFSH]) und erfordern niemals den Abbau einer BGP-Verbindung, sondern nur deren Neuaubau.

   (Mit „Hinzufügen eines neuen VPN zu einem PE“ meinen wir: Hinzufügen eines neuen Import Targets zu einem seiner VRF oder Hinzufügen eines neuen VRF, dessen Import Target keiner seiner anderen VRF entspricht.)

2. Eine andere Methode besteht darin, jeden PE zum Kunden einer Menge von Route Reflectors zu machen. Statt eine Route-Target-Liste vorzukonfigurieren und einen eingehenden Routenfilter auf die von seinen Kunden (PE) empfangenen Routen anzuwenden, akzeptiert der Route Reflector alle Routen von allen seinen Kunden (PE). Der Route Reflector verfolgt die Menge der Route Targets, die von allen von ihm empfangenen Routen getragen werden. Wenn er von einem Kunden eine Route mit einem Route Target empfängt, das nicht in dieser Menge ist, wird das Route Target sofort der Menge hinzugefügt. Hat er andererseits keine Route mehr mit einem bestimmten Route Target aus der Menge, sollte der Route Reflector das Entfernen dieses Route Targets aus der Menge verzögern (um einige Stunden).

   Der Route Reflector nutzt diese Menge, um den eingehenden Routenfilter aufzubauen, den er auf Routen anwendet, die er von anderen Route Reflectors empfängt. Er kann auch ORFs nutzen, um den passenden Ausgangsfilter auf anderen Route Reflectors zu installieren. Wie bei der ersten Methode sollte der Route Reflector ORF von anderen Route Reflectors akzeptieren und ihnen daher die ORF-Fähigkeit ankündigen.

   Wenn der Route Reflector diese Menge ändert, muss er seinen eingehenden Routenfilter unverzüglich ändern. Nutzt der Route Reflector ORFs, müssen diese unverzüglich angepasst werden. Nutzt er keine ORFs und fügt der Menge ein neues Route Target hinzu, muss er nach Änderung des eingehenden Filters einen BGP-Refresh (BGP Refresh) an die anderen Route Reflectors senden.

   Die Verzögerung von „einigen Stunden“ erlaubt dem Route Reflector, Routen mit einem bestimmten RT zu behalten, selbst wenn er seinen letzten an solchen Routen interessierten Kunden verloren hat. Dies verhindert, dass all diese Routen neu erworben werden müssten, falls das Verschwinden des Kunden nur vorübergehend war.

   Mit diesem Prozess sind VPN-Join- und VPN-Prune-Operationen ebenfalls nicht störend.

   Beachten Sie, dass diese Technik nicht korrekt funktioniert, wenn ein PE-Kunde einen VRF hat, dessen Import Target nicht zu seinen Export Targets gehört.

Bei diesen Verfahren „entdeckt“ (auto-discover) ein an ein bestimmtes VPN angeschlossener PE-Router automatisch die anderen an dasselbe VPN angeschlossenen PE. Das Hinzufügen eines neuen PE-Routers oder das Anschließen eines bestehenden PE an ein neues VPN erfordert keine Rekonfiguration der anderen PE-Router.

So wie kein PE-Router alle VPN-IPv4-Routen kennen muss, die vom Backbone unterstützt werden, stellen diese Verteilungsregeln sicher, dass kein Route Reflector (RR) alle vom Backbone unterstützten VPN-IPv4-Routen kennen muss. Daher ist die Gesamtzahl solcher Routen, die das Backbone unterstützen kann, durch die Kapazität eines einzelnen Geräts nicht begrenzt und kann nahezu unbegrenzt wachsen.

4.3.4. Wie VPN-IPv4-NLRI in BGP transportiert wird (How VPN-IPv4 NLRI Is Carried in BGP)

Die BGP-Multiprotokoll-Erweiterungen [BGP-MP] werden genutzt, um die NLRI zu kodieren. Ist das AFI-Feld (Address Family Identifier) auf 1 und das SAFI-Feld (Subsequent Address Family Identifier) auf 128 gesetzt, ist die NLRI eine mit Label versehene VPN-IPv4-Adresse. AFI 1 wird verwendet, da das Netzwerkschichtprotokoll dieser NLRI weiterhin IP ist. Beachten Sie, dass diese VPN-Architektur nicht die Fähigkeit verlangt, unmarkierte VPN-IPv4-Adressen zu verteilen.

Damit zwei BGP-Speakers mit Label versehene VPN-IPv4-NLRI austauschen können, müssen sie die BGP-Capabilities-Advertisement nutzen, um sicherzustellen, dass beide solche NLRI korrekt verarbeiten können. Dies erfolgt gemäß [BGP-MP] mit Capability-Code 1 (Multiprotocol BGP) und AFI=1, SAFI=128.

Die Kodierung der mit Label versehenen VPN-IPv4-NLRI ist in [MPLS-BGP] festgelegt, wobei das Präfix aus einem 8 Byte großen RD gefolgt von einem IPv4-Präfix besteht.

4.3.5. Aufbau von VPN mit Route Targets (Building VPNs Using Route Targets)

Durch geeignete Konfiguration von Import und Export lassen sich verschiedene VPN-Typen aufbauen.

Angenommen, man möchte eine voll vermaschte geschlossene Benutzergruppe (closed user group) erzeugen, also eine Menge von Standorten, von denen jeder direkt zu jedem anderen Verkehr (traffic) senden kann, aber weder zu noch von anderen Standorten. Dann wird jeder Standort mit einem VRF assoziiert; man wählt ein einziges Route-Target-Attribut und weist es als Import- und Export-Target jedem VRF zu und weist es keinem anderen VRF als Import- oder Export-Target zu.

Ein anderer Fall: Angenommen, man möchte ein „Hub-and-Spoke“-VPN erzeugen. Dies lässt sich mit zwei Route-Target-Werten erreichen, einer für „Hub“, einer für „Spoke“. Am VRF des Hub-Standorts ist „Hub“ das Export-Target und „Spoke“ das Import-Target. Am VRF des Spoke-Standorts ist „Hub“ das Import-Target und „Spoke“ das Export-Target.

So ist die Methode zur Steuerung der Verteilung von Routing-Informationen zwischen Standortmengen sehr flexibel, was wiederum große Flexibilität beim Aufbau von VPN bietet.

4.3.6. Routenverteilung zwischen VRFs in einem einzelnen PE (Route Distribution Among VRFs in a Single PE)

Selbst wenn zwei VRF im selben PE sind, können Routen von einem VRF in ein anderes verteilt werden, wenngleich man in diesem Fall nicht sagen kann, die Route werde über BGP verteilt. Die Entscheidung, eine bestimmte Route von einem VRF in ein anderes im selben PE zu verteilen, ist jedoch dieselbe, als wären die VRF auf verschiedenen PE. Sie hängt also vom Route-Target-Attribut der Route (bzw. dem, das ihr zugewiesen worden wäre, wenn sie über BGP verteilt worden wäre) und den Import Targets des zweiten VRF ab.