 So, wir haben ja so eben beim eBGP Lab ein bisschen gemerkt, dass das alles suboptimal ist, wenn nur die Border-Router irgendwie eBGP mit den ISPs sprechen, aber die Router-Internen sich gar nicht verständigen können über ihre vollständigen Mutig-Informationen. Wenn ich die Localprevter irgendwo setze auf dem einen Router, dann weiß der andere Router da gar nichts von. Wie der Max auch gesagt hat, selbst wenn ich das dann relativotiere in USPF, da gehen die ganzen Sachen verloren. Deswegen sprechen wir jetzt über eBGP und zwar in der Geschmacksrichtung eBGP. So, ich werde darauf eingeben, wie man das verwendet, wie man das grundsätzlich verbaut, was ein eBGP Full-Mesh ist, warum er das unbedingt haben wollt. Ja, was passiert denn, wenn man das nicht hat? Wie sieht die Routenauswahl dann aus? Der Algorithmus von soeben, der wird noch ein bisschen komplexer. Was Routreflection und Confederation sind. Ja, legen wir mal los. Also, wofür verwendet man das? Das verwendet man dazu, um die Routen, die man per eBGP irgendwo gelernt hat, innerhalb seines Netzes weiter zu verbreiten. Das heißt auch Router 3 und 4. Die kannten jetzt ja gar keine Routing-Informationen, die von externen kamen. Wenn man jetzt eine IBGP-Session bauen würde zwischen Routern 1 und 4 und 1 und 3 zum Beispiel, dann würde der Router 1 die Routen, die er von extern bekommen hat, an die Router 3 und 4 weitergeben. In dem Moment hätten die die ganzen Routenehrer Routing-Tabelle. Also grundsätzlich verwendet man IBGP, indem man Sessions aufbaut, über die Loopback-Adressen eurer Router. Jetzt macht das doch alles viel mehr Sinn, warum ihr die habt. Die Idee ist, jeder Router, den ihr habt, muss mit jedem Router eine IBGP-Session bauen. Warum ist das so? Das ist deswegen so, weil jede per IBGP empfangene Route, also eine Route, die von einem Nachbarn kam, der dasselbe AS hat wie ich selber, wird nicht per IBGP weitergegeben. Warum ist das so? Weil, wenn man das weiter gibt, es gibt keinen Attribut, was da verändert werden würde und damit habe ich keine Loop Detection mehr. Das heißt, wenn ich eine Route bekomme per IBGP und ich gebe die weiter an jemand anderen per IBGP, dann weiß der nicht, woher ich das bekommen habe, würde ich eben das wieder zusenden und der mir wieder und dann rotiert das ewig im Kreis, was auch zu Routengloops führt. Und das ist halt der Grund, warum man Fulmersch braucht, weil die Routigen sonst unvollständig sind. Das heißt, jeder Router muss mit jedem Router pieren. Nicht nur die Router, die direkt nebeneinander stehen, sondern wenn ich zwei Router habe, die nur einen Weg über einen dritten Router in der Mitte haben, da müssen diese beiden Routern in beiden Enden trotzdem eine IBGP-Session miteinander bauen. So ein Fulmersch, das bedeutet natürlich, wenn ich fünf Router habe, dann hat jeder Router vier IBGP-Sessions, nämlich alle vier anderen Routern in meinem Netz. Wenn ich 400 Router habe, dann habe ich 399 IBGP-Sessions auf jedem Router. Und meine Gesamtanzahl, die geht quadratisch hoch von meinem IBGP-Sessions, die ich in meinem letzten Jahr habe. Das skaliert nicht. Deswegen gibt es eine Ausnahme von dieser Fulmersch-Regel, das nennt sich Routreflection. Da komme ich später drauf zu sprechen, wie man das einsetzt, wann man das einsetzt und warum man das vielleicht nicht einsetzt. So ein Fulmersch, das würde bei sechs Routern so aussehen. Das sieht im Freitag von Rheinland-Bekborn exakt so aus. Da ist oft ein Fulmersch. Bei sechs Routern lohnt sich das nicht, Routreflection zu machen. Mit Routreflection würde das, wo ist denn die Slide hin? Ohne Momentung. Wer hat die denn weggemacht? Gut, bleiben wir mal im Fulmersch. So sieht das Fulmersch aus. Wenn wir das nicht hätten, gehen wir davon aus, wir haben sowas. Die schwarzen, die ihr seht, das sind physikalische Netzwerkverbindungen. Diese roten Bögen hier, das sind IBGP-Sessions zwischen den Loopback-Adressen dieser Router. Der R2 mit dem R3 und der R1 mit dem R4. Es gibt zwei eBGP-Sessions zum globalen Internet. Gehen wir davon aus, da kommt eine Default-Route rein. Meistwegen vom selben Abstimmprovider. Der Router 1, der empfängt diese Route und die kommt per eBGP rein. Die geht dann per IBGP weiter. Also eine Route, die per eBGP empfangen wird, wird per IBGP weiterannounced. Eine Route, die per IBGP reinkam, wird nicht per IBGP weitergegeben. Das heißt, der R3 lernt jetzt diese Default-Route. Und da steht dran, Next-Top ist dieser Router R1. So, wie kommt er da hin? Die Loopback-Adresse von diesem R1, die hat der R4 in seiner Routing-Tabelle, weil die zusammen OSPF sprechen, diesen ganzen Netzwerk. Das heißt, dieser Next-Top wird rikorsiv aufgelöst. Der Next-Top, der in der Route drinste, die per IBGP kam, der Next-Top ist nicht der R3, sondern der R1. Der R4 weiß deswegen, dass er zum R3 muss, um zum R1 zu kommen, weil das im OSPF so berechnet worden ist. So, das heißt, wenn der jetzt hier die Route dahin gar nicht hätte, dann wird er zwar die Rute vielleicht empfangen, aber er hätte den Next-Top nicht. Er kann den nicht auflösen und dann geht es auch nicht weiter. Das heißt, aller Treffig, den der R4 jetzt ins Internet jagen möchte, den schickt er an den R3. So, der R3, der hat aber nur eine IBGP-Session, nämlich mit dem R2. Das heißt, sein Next-Top für alles, für seine Default-Route ist der R2. Und dann fragt er es den OSPF, ja, wie komme ich denn zum R2? Und er sagt, das OSPF eben ja über R4. Jetzt kommt er ein Paket vom R4 beim R3 an, weil für R4 ist R3 der kürzeste Weg ins Internet. Und R3 guckt sich das Paket an und sagt sich, ja, das ist meine Default-Route. Und der Next-Top für meiner Default-Route ist R2. Wie komme ich denn zu R2? Über R4. Und dann ticke ich das Paket dahin zurück an den R4. Und dann guckt der R4 sich das andere zu hören. Da kriege ich das hin, ja, meine Default-Route. Der Next-Top für meiner Default-Route war doch R1. Wie komme ich denn zum R1? OSPF sagt R3. Und das Paket wieder zu R3. Und das geht so lange, bis die TTL abgelaufen ist von dem Paket. Ihr habt nur Routing-Schleifen. Ja, die TTL hochdrehen, das wird es natürlich lösen. Nicht. Die Lösung ist, dass der R4 mit dem R3 und der R4 mit dem R2 und der R3 auch mit dem R1 eine IBGP-Session baut. Dann haben alle die gleichen Routing-Informationen. Alle haben dieselben Next-Top ausgewählt. Das ist ja bestimmt ein Grad. Und können dann, wenn Sie mehrere Exits haben hier, anhand der IGP-Metrik, also der OSPF-Metrik, können die berechnen, welcher der Nächste ist und können den benutzen. Und das Paket kommt nicht zurück. Weil im OSPF haben ja alle den kürzesten Weg berechnet, das ist ein konsistentes Bild, haben wir ja gestern besprochen. Dann ist das Problem gelöst. So, wie sieht denn dann die gesamte Entscheidung aus, wie ich eine Route auswähle? Das ist im Grunde der Algorithmus von Soeben. Der ist aber ein bisschen komplexer. Also erst mal bleibt wieder die Frage, ist der Next-Top erreichbar? Was haben wir? Localprev, nehmen wir den höchsten. Gut, alles klar. ASPaf, kürzester ASPaf, hat gewinnt. Die Origin, geschenkt. MED, gut sagen wir mal, wir haben nur einen Nachbarn oder wir haben verschiedene Nachbarn. Und jetzt kommt die Frage, gut, wie ist diese Route zu mir gekommen? Ist die per EBGP gekommen oder per IBGP gekommen? Und da wird EBGP typischerweise bevorzugt. Also bevor ich jetzt weitergucke auf die weiteren Kriterien, sieben bis zehn, gucke ich mir an, habe ich die eine Route zufällig, wie ich sie hier auf dem EBGP vom Upstream bekommen und die andere Route per IBGP von einem meiner Router in meinem IS, dann gehe ich sofort zum Upstream ISP und schick das raus. Das möchte ich dann intern in meinem Netz nicht mehr von A nach B kachen, um das dann an einem anderen ISP zu geben. Gehen wir davon aus, ich habe jetzt nur IBGP-Routen, so wie hier unser Beispielrouter R3 zum Beispiel oder R4, die haben wir gar keinen EBGP, Sessions Determinieren auf R1 und R2. Dann stellt sich die Frage, ja, gut, wie komme ich denn jetzt zum Nextop? Und da wird geschaut, zu welchem Nextop habe ich denn die kürzeste, die kleinste Metrik? Warum habe ich mehrere Metriken? Wenn ich einen Full Mesh habe auf R3, dann bekommt R3 einmal die Defaultroute von R1 und von R2. Jetzt hat er die zwei Mal da drin, das sind verschiedene Nextops. Und jetzt gucke ich bei dem Nextop, von beiden Nextops habe ich dann die kleinere USPF-Metrik. Und das dürfte in dem Falle, wenn man davon ausgeht, dass jeder Link hier eine gleiche Metrik hat, dann würde er R3 zu R1 ruten. Und zwar immer. Der R4, der würde sagen, ja, gut, ich gehe dann immer nach R2. Und irgendwann habe ich auch keinen Loop mehr. Weil der R3, sein Internet-Treffig nicht an den R4 steht und der R4 nicht an den R3 ist der Link hier, der würde gar keinen Treffig, sein Internet geht, befördern. Wenn ich jetzt davon ausgehe, ich habe immer noch die gleiche Metrik. Ich habe zwei gleichwertige Fahre. Wenn ich jetzt ECMP aktiviert habe, Equal Cost Multi-Puffing, dann werden alle Wege die gleich viel kosten in die Routing-Tabelle installiert. Und dann geht es zu einem Flow hier lang, ein Flow hier lang und ein Flow hier lang. Wenn man das nicht aktiviert hat, dann geht das noch weiter, das ganze Spiel. Dann gibt es die Cluster List. Was das genau ist, dann komme ich gleich noch zu. Gehen wir davon aus, wir haben keine Routreflection und fällt der Punkt 8 natürlich weg. Dann geht es mit der Router-ID weiter. Der kleinste Router gewinnt. Das habe ich immer noch, zwei Sessions zum selben Nachbarn, zum selben Nachbar-Router, bleibt nur die Nachbar-IP-Adresse über. Und dann weiß ich, wo geht es lang. Das passiert. Diese Routing-Ausweile wird für jedes Präfix einzeln ausgeführt. Die Routing-Table empfangt 575.000 Routen. Das dient nach 575.000 mal durch, wenn die Routen empfangt. IBGP Routreflection soll das ermöglicht, Ausnahmen von der Full-Mesh-Regel. Das heißt, dass eine per IBGP empfangende Route per IBGP weitergegeben wird. Aber das führt ja zu Loops, wie ich es eben gesagt habe. Und damit das nicht passiert, gibt es die Cluster List, das ist wie der HS-Fahrt. Der gibt dann an, diese Cluster-Liste gibt an, man kann die gruppieren und kann sagen, ich habe zwei, die bilden zusammen einen Cluster, die bekommen eine ID. Und diese IDs werden an die Route mit rangeheftet, in die Cluster-ID-Liste. Das heißt, wenn ich jetzt zwei Pärchen Routreflektoren habe, und das eine Pärchen hat das bekommen, schickt das an den zweiten, da wird das zweite das vielleicht an Dritten geben und das dritte wieder an den ersten, aber dann sehen die sich selbst in der Cluster-Liste und sagen, ja, das kam ja schon von uns. Und dann ist die Loop gebrochen. So funktioniert das. Wenn man so ein Routreflektor konfigurieren will, setzt das voraus, dass man, aber für den Routreflektoren, also man wählt, man pickt sich die raus, man pickt sich irgendwelche Router in seinem Netz und sagt so, der soll jetzt mal hier ein Routreflektor machen. Da konfiguriert man die IBGP Sessions zu bestimmten Nachbarn als Routreflektor Clients. An den Clients macht man gar nichts Besonderes, außer dass man die anderen IBGP Sessions abreißt. Man lässt nur die zu den Routreflektoren stehen. Man kann auch die anderen noch stehen lassen, wie man will. Also typisches Setup ist auch, dass man innerhalb eines Stadtnetzes ein Fullmesh macht und dann zwischen den Städten ein Pärchen Routreflektoren immer hat. Man hat in Frankfurt ein paar Router stehen, das sind zwei Routreflektoren in Amsterdam und in London. Und dann sprechen die Routreflektoren, alle miteinander sind vollvermarscht und innerhalb der Stadt sind alle vollvermarscht innerhalb einer Stadt. Dadurch war ich halt eine ganze Menge IBGP Sessions. Aber in der Größe und bewegte euch typischerweise nicht. Deswegen erwarte ich nicht, dass ihr mit Routreflexion erst mal rumfuchtet. Ja, das sieht dann so aus bei einem 6-Router-Netz. Das hat aber auch ein paar Nachteile, deswegen machen wir das im Backbomber uns nicht. Wenn wir jetzt da unten diese beiden Router als Routreflektoren betiteln würden, also das hier, das sind IBGP Sessions. Das sind nicht die physischen Verbindungen. Ganz wichtig, das ist nur die Signalisierung der Routen. Das wäre jetzt, sag ich mal, unsere Frankfurter Router. Und Düsseldorf spricht nur noch mit Frankfurt und Berlin spricht auch noch mit Frankfurt. Und Frankfurt kachelt uns ab, wie es da passiert ist. Da wir uns ein Netz gesplittet, kämen Berliner Routen nicht mehr in Düsseldorf an, weil die Routreflektoren halt weg sind. Also robuster ist schon ein Fullmash, aber irgendwann geht es halt auch nicht mehr. Und solange man keine Routreflexion braucht, sollte man das auch bitte nicht machen. Dann gibt es noch eine andere Möglichkeit, wie man diese Fullmash-Regel durchbrechen kann. Sogenannte Confederations. Die Idee ist, ich unterteile meine Eis in mehrere Unteraise, intern. Dann sage ich, okay, Düsseldorf ist eine Eis, Frankfurt ist eine Eis, Berlin ist eine Eis. Und zwischen den Essen gilt eine ganz normalen IBGP Peeringregeln. Die konfigure ich als ganz normale Peerings. Und nach außen hin, muss ich sagen, ja, das ist eine Confederation. Und meine internen Eise sind X, Y und Z. Und nach außen hin tauchen meine drei internen Eise nicht auf. Ich kann auch innerhalb jedes einzelnen Super-Eis nicht ganz Großes in der Zaube. Allerdings gibt es ein paar Probleme, wenn man das benutzt. Oder Scar-Probleme, weswegen das sich keiner großen Verbreitung erfreut, dieses Konzept. Nämlich, man kann mit BGP auch noch ein paar andere wilde Sachen machen, wie Lea II, Lea III VPN, so ein VPS-Dienst und so weiter und so fort. Und die haben historisch nicht funktioniert mit Confederations, deswegen, die sich im ISP-Umfeld nicht durchgesetzt haben. Ich persönlich habe noch bei keinem Netz noch lange gesehen. Never ever. Route Reflection is the way to go.