BGP Route Reflection mit JunOS

Heute möchten wir Sie an ein etwas fortgeschrittenes Thema heranführen: BGP Route Reflection. Wir erklären, warum man so etwas braucht, wann man es idealerweise einsetzt, welche Devices man dazu verwenden kann und wie man diese konfiguriert. Dieser Artikel richtet sich an halbwegs erfahrene oder interessierte Netzwerker, die schon mit dem Border Gateway Protocol in Berührung gekommen sind, aber bisher noch nie einen Route Reflector brauchten – oder  einfach nicht wussten, dass sie einen gebrauchten können.

01: Motivation – Warum brauchen wir Route Reflektoren?

Früher: …war diese Frage relativ einfach zu beantworten…

(Fast) jeder der ein Autonomes System (AS) betreibt, muss dafür sorgen, dass dieses weltweit erreichbar ist. Dazu muss man über das Border Gateway Protocol (BGP) seine zugewiesenen Prefixes (Netze) anderen Routern bekannt machen. Diese Grenzrouter (ASBR) bekommen dann von den jeweiligen anderen ASBR die entsprechenden Prefixes des Internets zugewiesen.

Wenn man nun mehr als einen ASBR (Grenzrouter) in einem AS (Autonomen System) hat, müssen diese Router untereinander ebenfalls per BGP (internal BGP oder kurz iBGP) verbunden werden, damit sie diese extern gelernte Routen (external BGP oder kurz eBGP) den anderen Grenzroutern bekannt geben. Eine Verwendung des internen Routingprotokolls (iGP) für diese Aufgabe scheidet aus vielen Gründen aus – insbesondere, weil ein iGP mit mehr als  500.000 Routen garantiert überfordert wäre und den Betrieb einstellen würde.

Da nun jeder ASBR mit jedem anderen ASBR eine iBGP-Session (BGP ist TCP-basierend, darum sagt man Session) aufbauen muss, kommt man zu folgendem Schaubild, wenn man beispielsweise sechs ASBR in seinem autonomen System (AS) besitzt – klassisches „Full Mesh“ eben.

Das bedeutet, dass man jede Session einzeln konfigurieren muss (BGP macht aus guten Gründen kein „AutoDiscovery“), was neben RAM-Bedarf auf den Routern gleich zum nächsten Problem führt: Dem massiv steigenden Aufwand der Administration der Sessions in einem Full Mesh. Der Mathematiker sagt uns, dass  (N*(N-1))/2 braucht.

Die individuelle Schmerzgrenze des administrativen Aufwands ist zwar bei jedem Menschen anders, aber im Schnitt hört der Spaß bei etwa 20 Routern auf, da dies 190 einzelne BGP-Sessions und 380 Konfigurationsschritte bedeuten würde.

Genau an dieser Stelle greift ein Route Reflector (RR) ein, denn er „zentralisiert“ alle iBGP-Sessions auf sich und reduziert somit den Aufwand erheblich.

 

Somit müssen nur noch die Route Reflektoren (im Schaubild grau) untereinander vollvermascht sein und jeder sogenannte Client Router (im Schaubild blau) muss nur noch eine Session zu den Route Reflektoren aufbauen.

Man sollte immer mehr als einen RR (Route Reflector) haben, um für Redundanz zu sorgen, denn es gilt die alte Bauernregel:
Sind alle Route Reflektoren weg, liegt Dein ASN im Dreck!
Es soll schon große Netzbetreiber gegeben haben, die bei zwei Route Reflektoren einen in Hardwarewartung hatten und den anderen mit einem Stromausfall verloren haben. Daher sollten mindestens drei Route Reflektoren in einem AS vorhanden sein.

Jetzt gibt es im wirklichen Leben (zumindest leider nicht in dem des Autors) nicht allzu oft die Situation, dass man ein AS mit wirklich vielen ASBRs betreibt (>20), wo man endlich einmal die Theorie ausprobieren könnte, um einen Route Reflector so richtig sinnvoll einzusetzen, was uns stehenden Fußes dazu bringt nach dem „heute“ zu fragen und warum man einen Blog-Artikel über dieses Thema schreiben muss.

Heute: Bedeutung von BGP wächst und somit der Bedarf an Route Reflektoren

Heute hat sich BGP unversehens von einem „IPv4 Only“ Protokoll zu einem Schweizer Taschenmesser der loopfreien Signalisierung von Network Layer Reachability Informationen (NLRI) jeder Art gemausert.

Auf deutsch: Alle ernst zu nehmenden Provider-Backbones,  MPLS-Services (L3VPN, VPLS, eVPN, …) basieren unter der Haube auf BGP.
Juniper Networks geht sogar so weit, dass das Protokoll, welches innerhalb einer QFabric (Datacenter Switching Lösung mit el mucho 10/40 GE Ports) den Transport von MAC-NLRIs  bewerkstelligt, BGP mit leichten Erweiterungen ist. Die Route Reflektoren in dem Konstrukt heißen dann übrigens Directoren.

Seit geraumer Zeit beobachten wir einen weiteren Trend:
Auch IT-fremde Großunternehmen oder Mittelständler gönnen sich den „Luxus“ eines eigenen MPLS-Backbones – hier bitte nicht verwechseln mit „Ich kaufe mir ein MPLS L3VPN bei der DTAG und zahle gerne meinen Beitrag zum Anstieg der T-Aktie“.

In diesem Fall kommt man dann ganz schnell in die Situation, dass man mehr als die oben genannten 20 ASBRs besitzt, da im Kontekt von L3VPN/VPLS Services jedes PE-Devices (Grenzrouter im „MPLS“ – Davon gibt es normalerweise an jedem Standort mindestens einen) eine Art ASBR ist, die man per iBGP miteinander verbinden muss.

Und Tada: Auf einmal braucht ein mittelständisches Unternehmen, das die Vorzüge eines echten eigenen BackBones nutzen will, Route Reflektoren.

Hinweis: Die auf diesem Bild dargestellten Verbindungspfeile sind keine „Standleitungen“ sondern nur iBGP Sessions – eine physikalische Topologie muss völlig losgelöst davon betrachtet werden!

 

Mit dieser hoffentlich spannenden Einleitung können wir uns nun einigen ausgewählten technischen Hintergründen widmen.

02: Technische Hintergrundinformationen

Allgemeines zu iBGP

Eine Grundvoraussetzung, damit iBGP wie erwartet funktioniert, ist dass die Router, welche per iBGP Routen miteinander austauschen sollen, sich direkt erreichen können, da BGP keine Netztopologien wie ein iGP kennt. Dies kann entweder durch eine direkte L2-Verbindung (Ethernet, …)  erfolgen, oder alternativ durch einen Tunnel (GRE, bzw. üblicherweise ein MPLS Label Switched Path). Bei „normalen“ Provider Backbones sind hier immer LSPs (Label Switched Paths) im Spiel.
Im Folgenden wird auch nur auf den Fall eingegangen, dass alle iBGP Peers, die Forwarding-Aufgaben erfüllen (RRs müssen das nicht zwingend) per LSP miteinander verbunden sind. GRE und andere Ausnahmen werden nicht betrachtet.
Hinweis: Bei JunOS landen dann die Router-IPs (lo0) in der Routing Tabelle inet.3.

Beispiel:

 

Terminologie Route Reflektoren

Bei den BGP-Peers im Kontext der Route Reflektoren muss wie folgt differenziert werden:

• Client: Ein Router, der unterhalb eines Route Reflectors angeordnet ist, z.B. ein „normaler“ ASBR oder ein PE-Router.
• Non-Client: Ein Router der auf gleicher Ebene mit einem RR angeordnet ist, z.B. ein weiterer Route Reflector.

Route Reflektoren (RR) arbeiten innerhalb eines AS nach folgendem Schema:

• Wird die Route von einem „Non-Client“ gelernt, nur an „Clients“ weitergeben.
• Wird die Route von  einem „Client“ gelernt, an alle weitergeben, nur nicht an den Client, der die Route gebracht hat.
• Wird die Route  extern (eBGP) gelernt, an alle weitergeben („Clients“, „Non-Clients“).

Ein weiteres Attribut, was an eine durch einen RR gelernte Route angehängt wird, ist die sogenannte Cluster-ID. In der Cluster-List wird die Liste von RRs zusammengestellt durch die eine Route schon gelangt ist.

Dadurch wird in jedem Fall Loop-Freiheit und eine passende Verteilung der Routen gewährleistet.

Mit dem entsprechenden Hintergrundwissen können wir uns jetzt mitten ins Getümmel der Konfiguration stürzen.

03: Wie konfiguriert man Route Reflection unter JunOS?

Fall 1: Route Reflektor in „Forwarding-Zone“

Im Falle, dass der RR innerhalb des normalen Forwarding-Bereichs aufgestellt ist, ist die Konfiguration sehr einfach, da hier die Tabelle inet.3 schon durch unser Label Distribution Protokoll (Hier idealerweise LDP – Der Grund dafür ist ein anderer Artikel) brav gefüllt wurde und unsere „Tunnel“ zwischen allen iBGP Peers bestehen.

Somit muss man sich nur noch um die Konfiguration der Route Reflektor Funktionalität kümmern, was mit dem Schlüsselwort „cluster“ erfolgt:

Auf den Client-Neighbors muss man ganz normale iBGP-Sessions zu den RRs konfigurieren, auf den anderen RRs muss man analog dem ersten RR vorgehen, nur mit anderer Cluster IP (Im Beispiel 192.168.255.101).

Fall 2: Route Reflektor außerhalb der „Forwarding-Zone“

Sollte sich der RR außerhalb der Forwarding-Zone befinden, d.h. es gibt keine LSPs die ihn mit den anderen iBGP Members verbinden und die Tabelle inet.3 ist leer, wird die Sache etwas trickreicher aber nicht unlösbar.

Primärziel ist es, die Tabelle inet.3 mit passenden Next-Hops zu füllen. Dies kann erreicht werden, indem man sich hier anstatt des Label Distribution Protokolls einfach des normalen iGPs (z.B. OSPF) bedient:

 

Idealerweise ergänzt man die Konfiguration des Route Reflectors, dass Routen aus dem BGP nicht in die FIB geschrieben werden, da dies bei einem RR, der sich ausserhalb des Datenpfads befindet nicht notwendig ist und abhängig von PFE zu viel unnützem Overhead führen kann:

Damit wäre das Primärziel „iBGP Peers in inet.3“ erreicht und man kann analog Beispiel 1 weitermachen…

04: Welche Juniper-Geräte kann man als Route Reflektoren verwenden?

Einfache Antwort: Alle, wo es der Hersteller erlaubt.

Komplizierte Antwort: Es kommt darauf an, wie viele Routen man reflektieren will.

Generische Eckdaten für einen guten Route Reflektor sind:

a) Viel RAM – Viele Routen brauchen viel RAM!
b) Viel CPU – Viele Routen brauchen viel Zeit um reflektiert zu werden!
c) Zuverlässige Hardware – Denn geht die defekt, ist Ihr AS in Gefahr!
c) Alles andere (PFE, LineCards, …) ist eher weniger relevant.

 

Konkret sind laut Dokumentation folgende Plattformen supported:

• J-Series (abgekündigt und hat extra Lizenz gebraucht – zu langsam, zu wenig (offiziellen) RAM für eine FullTable )
• M-Series
• MX-Series
• PTX-Series
• T-Series

Bei allen Plattformen ist es empfohlen, die schnellste verfügbare Routing Engine mit dem meisten RAM zu nehmen (siehe oben).

Hot Tip: Es gibt von Juniper noch den VRR (Virtual Route Reflector), der ein virtualisiertes JunOS ohne Forwarding-Plane ist, welches auf X86 Hardware in einem Hypervisor laufen kann. Damit wäre das RAM und CPU Thema ein für alle Mal vom Tisch.

1. Das Teil ist noch ziemlich neu (17.07.2014) und noch ziemlich undokumentiert – Es fühlt sich also fast an wie eine offizielle Juniper Olive. 😉
2. Das Image, das man von Juniper bekommt ist ein QEMU Image, was in ein bootbares VMWare Image umgewandelt werden kann.
3. Der VRR schnurrt ziemlich gut in unserem teamix Lab und leistet da seit einiger Zeit gute Dienste!
4. Fazit: 11 von 10 Punkten für einen Hersteller, der wirklich verstanden hat, dass Virtualisierung nicht böse ist.

 

05: Links und Quellen

Example: Configuring a Route Reflector

Example: Configuring Route Resolution on Route Reflectors

Wikipedia: Route Reflector (Englisch)

Wie immer gilt auch beim Thema Route Reflection: Sollten Sie Fragen haben, oder Unterstützung benötigen, freuen wir uns über Ihre Nachricht.

Series Navigation

<< Datenblatt und Realität: Stromverbrauch von Juniper GerätenJunos SNMP Utility MIB – oder: Wie monitore ich Werte die eigentlich nicht in SNMP vorhanden sind? >>