 Jo moin, wir machen nochmal weiter mit BGP. Wir haben gestern mit USPF die namensches Routing veranstaltet. Das ist für innerhalb eines Autonomensystems. Du musst dazu eben auch schon erklären, was ein AS ist. Damit man den ASM miteinander verbinden kann, sprich man BGP. Ich werde gleich kurz auf die Verwendung eingehen. Ich erkläre euch, wie der Zustandsautomat aussieht und für die Adjacency. Denn auch bei BGP muss man explizit Nachbarn, Nachbarschaften aufbauen, wie bei USPF auch. Es wird auf ein gewöhnliche Attribute an so einer Route dranhängen. Das sind ein paar März beim USPF. Das ist ein bisschen komplexer. Wie der Routing-Ausfallalgorithmus aussieht, warum und wie man filtert, was es mit der Adjacency Rip in und der Rip out auf sich hat. Und damit nur ein paar Literaturenweise. So, das ist BGP. BGP ist ein exterior Gateway Protokoll. Gestern haben wir über USPF gesprochen. Das ist ein interior Gateway Protokoll. Also intern benutzt. BGP wird hauptsächlich für externe Routing-Kommunikation verwendet. Also zwischen Netzwerken, sprich zwischen irgendwelchen Enterprises, Datacenter und Intersourceprovidern, da wird BGP eingesetzt. Ja, wie funktioniert das? Es gibt eine Art Hello-Protokoll. Da wird eine Adjacency geformt, wie bei USPF auch. Sobald so eine Adjacency da ist, tauschen die Router miteinander Network-Layer-Reachability-Informations aus. Hier rein nimmt man das. Kurz gesagt, das sind Präfixe. Also wir reden hier nicht davon, dass die ein Abbild haben von dem kompletten Netzwerk wie bei USPF, sondern wir tauschen hier tatsächlich Routen aus. Also es steht quasi das Präfix 8, 8, 8, 0, Slash 24. Mit diesen Attributen kannst du über mich erreichen. So, das ist das, was die Router miteinander austauschen. Ja, dann läuft der Algorithmus. Das elektriert die beste Route für jedes Präfix und dieses Präfix wird in die Routing-Tabelle übernommen und installiert. Und dann ist die Sache auch schon rum. WGP wird über TCP transportiert, über Portnode 79. Das wäre dann in euren Firewalls, wenn ihr welche konfiguriert, zu berücksichtigen, dass man das aufmacht. Sonst wird das nichts mit dem WGP. Ja, so ein Zuschwanzautomat. Jetzt habe ich eine Session konfiguriert zwischen zwei Routern. Ich habe mir jetzt einen Upstream-ISP gesucht und möchte mit dem jetzt meine WGP-Session bauen oder ein PIA. Dann konfiguriert es, dann geht es erstmal los. Wünft Schadzustand, das ist so ein Ding erst mal im Idle. So, Idle heißt, der Router hat noch nichts gemacht. Der kann dann dahergehen und so den Connect-Status wechseln. Das bedeutet, er wartet darauf, dass jemand sich zu ihm verbindet. Er macht den TCP-Port auf und wartet darauf, dass er jemand ein Sympaket schickt. Jetzt haben wir zwei Enden, A und B-Router. Beide warten. Man passiert natürlich erst mal nichts, wenn beide nur warten. Deswegen gibt es noch den Active-State. Das bedeutet, der eine Router, einer von denen oder beide kann passieren, das gleichzeitig passiert, gehen jetzt in den Active-State und versuchen, gegenseitig eine Verbindung aufzubauen. Dann schicken sich die TCP-Syn-Pakete und sagen, ich möchte mit dir eine ganze Session aufbauen. Wenn man das hat, dann senden die eine Open-Nachricht. Dafür gibt es einen Open-Send-Status. Dann sagen die so, ich bin der und der, ich habe lassen das AS und da kann noch eine Authentifizierung dranhängen. Damit klar ist, wer mit dem überhaupt sprechen möchte. Wenn dann jemand eine Open-Send-Nachricht empfangen hat, kann er nur Open-Confirmen-Nachricht schicken. Und wenn das dann mal alles angekommen ist, dann gibt es den endgültigen Zustand, den man haben möchte, das ist der Established-Zustand. Das heißt, wenn du eine BGP-Session habt und die ist nicht im Zustand established, dann wird die nicht funktionieren. Wenn der Active steht, heißt das nicht, dass das gut ist. Wenn das Active ist, dann ist das kaputt. Das ist die erste wichtige Erkenntnis. So, wenn es auf den Aus geht, wir haben so eine Session. Dann fangen wir an, Routen auszutauschen, also NLR-Rise. Und an jeder Route hängen so ein paar Attribute daran. Z.B. der Next-Top, der mir halt sagt, okay, dieses Präfix kann ich zu dem Router den Treffig, dafür kann ich dahin schicken. Dafür ist der Next-Top da. Dann gibt es die Local Preference, eine IS-Fahrt, eine Origin, ein Multi-Exit-Discriminator und Communities. Die gehen jetzt alle nach und nach durch. Und ich erkläre auch dann nach und nach, wofür die verwendet werden. So, der Next-Top. Ich habe gerade schon gesagt, ich muss erst mal wissen, du sagst mir jetzt, dass da irgendwie eine Route ist, 8, 8, 8, 0, slash 24 oder so was. Aber du sagst mir noch nicht, wo ich das hin schicken kann. Bloß, weil ich eine Route von jemandem bekomme, heißt das nicht, dass ich dem jenigen auch den Treffig schicken muss. Der kann mir sagen, ja, also ich bin der Route A. Ich schick dir die Route, aber den Treffig schickst du bitte nach B. Verwendungszwecks sind also solche Konstrukte, wie die Rout-Server an den Internet-Exchanges, das wir Thomas eben aufhin gewiesen hat. Der Rout-Server, der sollte ich nicht durch den Rout-Server gehen. Der Rout-Server soll die Routing-Information weiterleiten, aber nicht den Nutztreffig. Der Rout-Server würde dann sagen, ja, also ich bin der Rout-Server A und hier der PRZ, der hat mir das Prefigs geschickt und seine IP-Adresse ist so und so. Deswegen ist der Next-Top auch dieser PRZ, der da an diesem Internet-Exchange angeschlossen ist. So eine Route, der Next-Top, der muss nicht unbedingt lokal an meinem Connected-Interface angeschlossen sein. Dieser Next-Top, den ich bekomme, der kann auch nur auflösbar sein über eine andere Route, die ich bereits habe, z.B. über OSPF. Sprecher Next-Top kann auf irgendeinem Interface, auf irgendeinem entfernten Router liegen, innerhalb meines ISS, das ist ein Unterschied zu der staatlichen Routing, das wir gestern gemacht haben, der staatlichen Routine gestern war der Knackpunkt, dass ihr den Next-Top immer auf die IP-Adresse des nächsten Nachbarn auf dem Weg setzen musstet. Das ist hier anders. Der Next-Top kann auch indirekt sein, d.h. ihr dürftet da hängen und sagen, okay, ich habe den Router unten links, und der Router oben rechts ist mein Next-Top. Dann könnt ihr ihm seine Loopback-Adresse als Next-Top verwenden, und das funktioniert. Weil darunter das OSPF benutzt wird, um herauszufinden, wie ich den diesen Next-Top erreiche. Das ist ein ganz signifikanter Unterschied. Was passiert, wenn ich den Next-Top nicht auflösen kann, ich habe keine Route zum Next-Top, dann fällt die Routing-Entscheidung raus, die wird niemals installiert werden. Das ist das erste Kriterium, was geprüft für eine Route mich erreicht. Kann ich den Next-Top erreichen? Ja oder Nein, habe ich eine Route dahin? Ich habe keine Route. Kann ich die Route nicht verwenden? Die Route, die mir geschickt worden ist, kann ich nicht verwenden? Dann ist das Ding raus. Gehen wir davon aus, der Next-Top ist erreichbar. Wir wissen, wie wir da hinkommen. Dann gibt es einen Wert Local Prep. Dann kann man setzen an so einer Route. Das ist unser zweite Kriterium, um zu entscheiden, wo ich langrouten kann. Es wird sich verwendet, um eine Priorität meiner Peerings oder BGP Sessions zu konfigurieren. Ich habe jetzt drei Tools, es gibt drei verschiedene Arten von Interconnections, die man bauen kann. Es gibt Transits, Peerings und Kundenconnections. Typischerweise werde ich von meinem Kunden für bezahlt, wenn ich ihn treffig schicke. Wo werde ich mein Treffig am allerliebsten los? Natürlich bei meinem Kunden. Wenn ich hier bin, kriege ich eine hohe Local Prep, denn je größer der Local Prep-Wert ist, umso höher ist die Bevorzugung von den Routen, die ich von ihm bekomme. Dann werde ich versuchen, all mein Treffig da abzukippen. Zweite Stufe wären dann die Peerings, denn da zahle ich immer noch so gut wie nix für mein Treffig. Was ich da loswerden kann, möchte ich da loswerden. Und zu guter Letzt, was ich da nicht loswerden konnte, und konkret im Freifunk Rheinland-Backbone haben wir diese Werte konfiguriert. Jede Community bekommt eine Local Preference von 10.000, das heißt, alles was wir direkt eine Community raus senden können, das schicken wir auch direkt an eine Community raus. Das geht nicht an Peering oder an Transit, sondern geht direkt zu euch. Jedes Peering hat ein Local Prep von 1000. Das ist die zweite Option, wo wir das loswerden wollen und zu aller Letzt so Transit. Wir zahlen das zwar nicht unbedingt Geld für, aber wir bekommen auch nicht unendlich viel von. Das ist natürlich als allerletztes behandelt. Der Standardwert ist 100. Der Wertebereich liegt zwischen 0 und 4,3 Milliarden ungefähr, also ein 32-Bit-Wert. Der ist immer nur gültig innerhalb eines Eisses, der wird nicht mit der Route mit nach außen ändern. Das ist nichts, was der Pier mir mitteilt. Das ist was, was ich selber intern setze, wenn ich eine Route empfange. Wenn ich nichts setze, habe ich einen Standardwert 100 auf der Route. Das ist ein besserer Wert. Wenn ich mehrere Routen habe, ich habe die selbe Route, aber mehrere Quellen, also drei verschiedene Peerings, senden mir ein bestimmtes Präfix, 8, 8, 8, 0, 24 zum Beispiel, dann habe ich jetzt bei allen den gleichen Local Prep, dann kann ich mir nicht entscheiden, welchen nehme ich denn davon. Jetzt kommt der IS-Fahrt. Der IS-Fahrt ist die Liste aller autonome Systeme, die meine Route durchwandert hat und recht hat. Es kann z.B. so aussehen wie das hier, das wäre jetzt ein Fahrt von Malmars über AR Airborne, über EPHH zu den Hamburger Freifunkern. Das ist eine Route, die so auch schon beim Freifunkern angekommen ist. Ein kürzerer IS-Fahrt ist immer ein besserer IS-Fahrt. Der IS-Fahrt sagt nicht aus, wie viele Router auf dem Weg liegen oder wie viel Bandbreite ich da habe. Der sagt nur aus, wie viele IS-Seligen dazwischen. Im Optimalfall besteht ein IS mit viel Bandbreite dazwischen. Das kann aber auch sein, dass da ganz viele Router sind mit ganz wackelegen Verwindungen, wo irgendwo ein Ding dazwischen ist, der nur 20 Megabit hat. Das berücksichtigt BGP nicht. Das muss ich selber weganginieren, manuell. Mich herausfindet, dass das lahm ist und ich woanders langen möchte und da muss ich mein Routing halt ändern. Ich nehme die Local-Pref-Ender oder der gleiche mehr und das woanders hinschicke. Man kann Parfrepending veranstalten. Hier mehrfach immer IS-Fahrt auftaucht. Warum mache ich das? Das mache ich deswegen, weil ich vielleicht weniger treffig auf dem Fahrt empfangen möchte. Ich möchte zum Beispiel gerne viel treffig von meinen Peerings empfangen und wenig treffig von meinen Transits. Irgendwer da draußen sieht es diesen IS-Fahrt. Wenn ich den Netz lang mache über meine Transits, dann erhöhe ich die Wahrscheinlichkeit, dass der Weg über ein Peering kürzer ist und ich da den Treffig reinbekomme oder ich habe mit einem demselben Peer 2 BGP Sessions und ich möchte, dass er mir den Treffig unbedingt in einer Location reinkippt und nicht in der anderen, dann mache ich ein paar Frepending beim einen und bei dem anderen nicht. Aber der kürzere IS-Fahrt ist, da sollte der Treffig hoffentlich auch ankommen. Dafür kann man sowas verwenden. Der IS-Fahrt dient außerdem der Verhinderung von Schleifen beim Routing. Das heißt, so eine Routing-Information die ja quasi unendlich im Kreis wandern, wenn ich das nicht irgendwo mal brechen würde, ich empfange eine Route und dann pack ich mein eigenes IS da rein und schicke ich das weiter an all meine Nachbarn an meine Kunden und die schicken das wieder an irgendwelchen und dann kommt das vielleicht wieder bei mir an. Das erkenne ich aber dann, weil nämlich mein eigenes IS immer IS-Fahrt enthalten ist und dann höre ich damit auf, das zu akzeptieren. Sag ich so, nee, das kommt ja schon von mir, das akzeptiere ich nicht wieder. So werden Schleifen im Internet verhindert. Das ist die Frage, wo kommt die Route eigentlich her? Also wie ist die in das BGP reingekommen? Da gibt es drei verschiedene Werte. Da gibt es IGP, IGP und Incomplete. Diese Werte kann man per Routing-Policy explizit setzen. Das sagt nicht unbedingt aus, bloß weil da IGP steht, dass jetzt jemand das aus einem OSPF in das BGP hinein kopiert hat. Das heißt, nur jemand hat diesen Wert da reingesetzt. IGP wird bevorzugt über EGP, wird bevorzugt über Incomplete. Das heißt, typischerweise setzt da eigentlich jeder da draußen, setzt das auf IGP, dass die Sache geregelt. Ist aber wichtig, dass man das weiß, denn wenn ich mal vor der Situation stehe und mich frage, warum wird diese eine Route benutzt und nicht die andere, das ist einer der Tiebreaker. Das muss man dann vergleichen, warum wird denn jetzt die IGP-Route über die Incomplete-Route verwendet zum Beispiel. Das muss man dann auch wiederum den Treffig in mein Netz hinein steuern, indem ich bei der eine Route in die eine Richtung hingehe und sage, ja, ich mache jetzt hier das ist jetzt die Route Origin of IGP und bei dem anderen auf Incomplete. Dann sollte der Treffig eigentlich links rumkommen, wenn der AS-Fahrt gleich lang ist aus der Sicht des anderen ASs. Es wird aber nicht so wirklich oft benutzt, weil das ist ein Wert, den man häufig vergisst, wenn man sich so ein paar Routigeforzen mal anguckt als Network Engineer. Das ist immer so das Ding, das verwendet eigentlich keiner für Treffige-Engineering, nicht so wirklich. Ja, da gibt es noch die MED, der Multi-Exit Discriminator, der tut genau das, was der Name sagt. Er unterscheidet mehrere Exits aus dem selben AS. Das heißt, der wird per se erst mal nur verwendet, wenn ich mehrere Peerings mit einem mit dem selben AS habe. Das ist auch wieder ein 32-Bit Wert. Höherer Wert ist schlechterer Wert. Das heißt, je kleiner die MED ist, umso besser. Die wird auch nicht über Asse hinaus announced. Das ist auch wieder ein Wert, den ich nur an meinen Nachbarn weitergebe und der resettet das normalerweise. Sprich, wenn A das an B setzt, diese MED an einer Route und B gibt das an irgendwem weiter, dann ist diese MED weg. Den Wert sieht er dann nicht mehr. Das ist nur, um zu regeln, dass ich das nicht mehr verwendet habe. Das ist das Ding. Da kann ja jetzt jemand anders steuern, wo ich meinen Treffig lang sende. Das will ich vielleicht gar nicht. Weil ich sage, ich habe zwei Peerings Frankfurt, Berlin. Meine Server steht in Frankfurt. Natürlich möchte ich meinem Peer den Treffig wo geben in Frankfurt, weil da muss ich nicht nach Berlin karen und in der Leitung kaufen. Aber dann kommt der Peer her und sagt, ich möchte den Treffig aber in Berlin haben, ich möchte mir kein Leitung nach Frankfurt kaufen. Ja gut, aber wir pehlen ja in Frankfurt und ich möchte das gar in Frankfurt loswerden, weil wir pehlen da ja. Also mache ich was, ich überschreib die MED und sage dir, du sagst mir zwar, dass da die Metrik so und so ist, also die MED, aber das interessiert mich einfach nicht. Ist mir egal. Kannst du jetzt sagen, dass ein Treffig in Berlin will, ich gebe das trotzdem in Frankfurt ab. Einige Äste machen das, unter anderem mit Frau vom Rheinland. Google macht das auch. Damit könnt ihr theoretisch steuern, wo der Fraf von Rheinland euch den Treffig abkippt. Aber das wollen wir nicht, weil ihr sollt eigentlich später mal irgendwann, wenn wir das kriptfältig haben, sechs Tunnel haben, sprich von jedem Router, den wir haben, sollt ihr den Tunnel zu jeder Eurosupernote haben, damit wir den Treffig niemals, wenn der in Berlin ankommt, nach Düsseldorf schieben müssen, weil eure Supernote gerade in Düsseldorf connectiert ist und ihr da die bessere MED ernanzt habt. Deswegen überschreiben wir diesen Wert. Der ist übrigens optional. Also nicht jede Route hat eine MED. Wenn keine da ist, gilt die MED null. Es gibt halt keine. Dann gibt es noch Communities. Ja, was ist eine Community? Das ist ein numerisches Attribut, was erstmal keine Bedeutung hat, quasi. Das ist einfach so, ja, ich kann da mal so einen Wert dran tackern an eine Route und sagen, ja, die kann ich jetzt identifizieren. Die lerne ich in Frankfurt und die kommt jetzt irgendwie in Berlin an, intern und hier sprich ich nachher noch drüber und vielleicht möchte ich die aber in Berlin gar nicht bevorzugen, weil ich die in Frankfurt gelernt habe und meine Kapazität nach Frankfurt voll teuer ist. Aber wie kenne ich denn jetzt, dass die Route aus Frankfurt kam? Na gut, ich gehe in Frankfurt einfach hin und sage so, ja, der Wert 1234, heißt, das war in Frankfurt gelernt und dann packe ich das damit dran oder kann ich ein Filter bauen in Berlin und er sagt, ja gut, wenn da der Wert 1234 dran hängt, dann setzt sich die Local Preff runter und es einfach ist das. Wir haben so ein Konzept, wir haben zum Beispiel diesen Community Wert hier, das bedeutet, wir haben die Route in Düsseldorf gelernt, der 194er, das ist Frankfurt, 195er ist Berlin und 200 bedeutet so, ja, das ist eine globale Route. Das heißt, wie wollen wir nicht nur lokal benutzen in der Metro, wo wir die gelernt haben, sondern im kompletten Netz. Das heißt, da sind wir bereit, diesen Treffig auch fertig, unser eigenes Netz zu schieben. Das machen wir zum Beispiel dann, wenn wir einen Peering haben in einer Stadt und zwar nur in einer Stadt und wir das für so wichtig in dieses Peering, dass wir bereit sind, unseren Backbone linked damit voll zu stopfen. Zum Beispiel in Netcolon, die peeren wir nur am Essex in Düsseldorf und wir wollen halt, wenn wir Treffig in Berlin haben für Netcolon, wollen wir den nicht in Berlin einen Transit geben und dann an Netcolon, sollen wir transportieren in selber bis nach Düsseldorf und geben es dann da ab. In den Bellnort-Communities, das sind diese beiden hier, ich kann da was dranhängen und sagen, ich enanz das zwar an meinen Pier, aber der soll das an niemanden weitergeben. Das heißt, wenn der selber Treffig hat, dann darf er mir den schicken, aber er darf niemand davon erzählen, dass ich ihm die Route geschickt habe. Das nennt man noExport. Da gibt es noch Neu-Advertise, das heißt, ich sage meinem Nachbarn-Router von meinem Apps for ISP oder meinem Pier oder wie auch immer, teile ich diese Route mit einem Router, der darf das lernen, aber er darf das nicht mal an seine internen Router in seinem IS weitergeben. Wann ist das sinnvoll? Fragwürdig. Also im Internet brauchst du es typischerweise nicht, wenn du jetzt mehrere ISP betreibst, die Idee gehören und du hast irgendwie bestimmte Server an genau diesem einen Router direkt dranhängen und du willst diesen Treffig haben, aber keinen anderen Treffig aus dem Netz dahinter, dann könntest du diese NeuAdvertise-Regel setzen, dann würden diese Server, die an diesem Router, einer anderen, die da irgendwo hinterhängen. Dafür könntest du das verhindern. Ja, wie läuft diese Routenauswahl? Ich bin gerade ein bisschen durchgegangen. Also die erste Frage ist immer, ist der Nextop erreichbar? Wenn ich erreichbar ist, dann fällt die Route schon mal weg, dann kann ich die eh nicht benutzen. Dann stellt sich die Frage, jetzt bekomme ich ein Präfix von mehreren Quellen, ja, wo habe ich den höchsten Local-Pref konfiguriert? Mein Kunden bevorzugt über ein Transit, über ein Peering, ein Peering bevorzugt und weiß, wo ich lang will. Jetzt habe ich aber vielleicht mehrere Peerings, die wir alle das gleiche Präfix irgendwie schicken, warum auch immer. Dann stellt sich die Frage, wer hat denn, welches NLRI, was ich empfangen habe, hat denn jetzt hier den kürzesten Nahesfahrt? Wenn da immer noch keine eindeutige Kanalisegebnisse rauskommt, dann überprüfe ich, wer hat denn hier den kleinsten Origin-Wert gesetzt? Wenn der jetzt immer noch gleich ist, was zu vermuten ist, weil das Ding wahrscheinlich aus derselben Quelle kommt und eine verschiedene NLRI hat, dann stellt sich die Frage, ja, kommt das vom selben Nachbarn, vom selben Nachbar AS? Wenn ich also schon runter bin auf ein AS, wenn ich das entschieden habe, dann stellt sich die Frage, wer welches advertisement hier hat, denn jetzt die kleinste MED? Aber das interessiert mich normalerweise nicht, wie ich gerade gesagt habe, ich resette das persönlich gerne. Wenn ich dann immer noch keine Entscheidung habe, dann gucke ich mir an, wenn ich eine Nachbar von den Nachbarn aus bekomme, hat er die kleinste RouterID. Jetzt kann ich aber mehrere BGP-Sessions haben mit einem und demselben, zwischen genau zwei Routern. Wenn ich zwei Kabel habe, mit zwei Mal IP drauf, dann habe ich hier eine BGP-Session und da eine BGP-Session zwischen A und B. Das heißt, die RouterID ist ja dann am beiden Peerings gleich und damit kann ich immer noch keine Entscheidung treffen. Dann bleibt nur noch ein Kriterium über, nämlich was mit der Nachbar-IP-Adresse. Ich habe wahrscheinlich nicht die gleichen IP-Adressen auf beiden Links. Einer von den beiden hat das Niedsgeriss-Hubnet und das Peeringe Winter. Da schicke ich den Treffig raus. Wenn ich das dann habe, dann installe ich mir das in meine Routing-Tabelle und dann geht es weiter. Ja, jetzt bekomme ich Routen, aber es gibt ja Routen, die möchte ich vielleicht gar nicht haben. Oder die sollen nicht unfeilig akzeptiert werden, weil ich zum Beispiel die MED-Bar schreiben möchte oder weil ich den Local-Pref setzen möchte. Dafür brauche ich ein Filter. Auch nicht jede Route soll gesendet werden. Wie soll ich in der MED setzen, geschrieben? Vergesst den Punkt. Aber pass-prepending möchte ich vielleicht machen. Ich möchte nur eine Route ernauenzen in eine Richtung und da möchte ich den Eisfahrt günstig verlängern, weil ich den Treffig da eigentlich nicht haben möchte. Das ist nur ein Backup-Link. Aber miteinander möchte ich das schon haben. Dafür brauche ich mir Routing-Filter. Ja, wie gerade gesagt, nicht alles möchte ich akzeptieren. Hier sind mal so ein paar Sachen, die ich akzeptieren möchte, auf irgendeiner BGP-Sitzung im Internet. Den eigenen Adressbereich möchte ich natürlich nicht von irgendwem announced haben, mir gegenüber. Ja, das ist Mainz. Und da soll mir nicht irgendwer erzählen, dass ich das über den abwickeln soll. Der wird dann zum Ende in der Mitte bei meinem eigenen Treffig zwischen meinen eigenen Maschinen. Ich hatte ja nicht meinen eigenen Treffig über ein externes Netz. Das soll das. Unsinn. Das ist ein weiter IP-Adressen. Werden im Internet nicht geroutet. Wenn die jemand announced, das geht technisch, dann laufe ich halt auch gefahr, dass da die IP-Adressen nicht intern beim Netzverwende, dass ich da den Treffig auf einmal nach außen jage und irgendwer da was mitsniffen kann. Deswegen möchte ich auch das ausfiltern. FC 6598, das sind auch keine eindeutigen IP-Adressen. Das ist ein Spezialbereich für Transitioning-Netze, wo Nutt gefahren wird, Provider-Seitig. Das sind auch Netze, die ich nicht haben will. Multicast, die haben wir natürlich nicht unicast geroutet. Kann man auch wegpacken. Reservierte IP-Bereiche, die Default-Route möchte ich typischerweise nicht haben. Ihr wollt das wahrscheinlich schon, weil wir vom Fraffung-Renner Backbone euch noch keine Full-Table schicken, sondern wir schicken euch eine Default-Route und dann wollt ihr die nicht ausfiltern. Eigentlich wollt ihr den Filter haben, der nur die Default-Route akzeptiert. Die Lubeck-Range 127-8, das wird im Internet nicht benutzt. Das kann man auch rausfiltern. Und Dinge, die für irgendwelche Dokumentationen reserviert sind, die Subnetze da, das kann auch alles weg, das braucht man nicht. Ja, was möchte ich denn raus schicken? Ja, ich möchte im Grunde erst mal nichts raus schicken, was ich nicht selber empfangen möchte. Das ist mal ganz wichtig. Also sorgt dafür, dass ihr bitte keinen F1918 irgendwie uns gegenüber announced oder irgendwie im Andersgegenüber, macht das niemals. Ihr wollt dann eigentlich, also mit der einen Ausnahme, ihr wollt euch auch ein eigener Adressbereich announced. Also die Liste, die da gerade war, die Liste, bei dem was ihr raus schickt an jemanden, also euer eigener Adressbereich soll dann natürlich sein. Und normalerweise soll auch nur euer eigener Adressbereich sein. Wenn ihr selber noch Netze hinter euch habt, Kunden, die wollt ihr auch upstream anounzen zu euren Peerings und Transits, weil sonst sind eure Kunden nicht erreichbar. Gegenüber euren Kunden, ja, entweder wollt ihr den Full Table schicken, weil die alles von euch haben wollen, dann macht ihr das. Oder ihr schickt dir eine Default-Route. Das ist was wir an typischerweise mit euch machen. Wir machen gleich so die Grundlagen zu BGP. Wir machen gleich ein bisschen Praxis dazu im Lab. Es gibt da zwei ISPs, mit denen ihr Peeren werdet. Der Router 1 geht an ISP A, der Router 2 geht an ISP B. Ich hoffe, das funktioniert gleich, der mag es auch noch ein bisschen dran umfummeln. Hier sind ein paar Literatur-Hinweise, wer sich weiter mit BGP beschäftigen möchte, es ist nicht nur dieses eine RFC, es gibt einen ganzen Haufen RFCs dazu. Der Standard ist wirklich groß. Es gibt noch viel mehr Anwendungsmöglichkeiten für den Austausch von Routing-info zum Internet. Wer da mehr darüber erfahren möchte, kann mich ja mal ansprechen. Dieses Buch Building Reliable Networks with Border-Gateware-Protocol von 2002 von Iliad von Venom. Damit habe ich es persönlich gelernt. Das ist ein relativ kurzes Buch. Es hat nur so 180 Seiten ungefähr. Da ist auch mal das essentielle eigentlich drin erklärt, wie man so ein Provider-Netz betreibt. Wenn es mehr an Details geht, dann würde ich BGP Design Implementation empfehlen. Routing-Internet habe ich gestern schon aufhin gewiesen. Da gibt es noch so einen kompletten Überblick, wie es Routing-Internet dann so läuft. Gibt es Fragen? Ja, Folien gibt es später bestimmt, ja. Mikrofonengeln? Wenn jetzt irgendwo eine neue Route hinzugefügt wird von irgendwem, wie lange dauert das bis alle anderen diese Einroute auch kennen? Typischerweise dort ist das was im Brech von Sekunden. Das heißt, gestern bei diesem OSPF hatten wir auch da hattest du uns so ein Live-Intervall quasi angegeben. Das lag irgendwie bei 40 Sekunden. Und du hattest gesagt, ich glaube, das stellt dir dann runter auf 2. Gibt es sowas bei BGP auch? Oder wird das einfach immer, wenn es eine Änderung gibt, wird die ernauenst? Die Änderung, also auch bei OSPF, wo ich das aufhin gewiesen habe, ist nur dafür da, um die Adjacency zu steuern. Ist nicht dafür da, um zu steuern, zu erkennen, dass ein Linkdown gegangen ist. Wenn der Link irgendwo down geht, wird das sofort propagiert bei OSPF. Und das konvegiert typischerweise in weniger als 200 Millisekunden. Auch bei BGP, wenn eine Route verschwindet, aus meiner Routing-Tabelle, dann zeige ich meinen Nachbarn mit, dann schieße ich den, eine sogenannte Withdraw-Message und sage den, dieses Prefix, was ich mit dem Linkdown habe. Sofade können lang sein, da können viele, viele Router zwischenliegen, deswegen kann so ein Withdraw, bis das global durch ist, auf allen Routern weltweit, kann das mal im Bereich von Sekunden liegen. Mitunter vielleicht auch bis hin zu Minuten, aber typischerweise so, was man so beobachtet, in ein paar Sekunden ist das weg, wenn du das wegkonfigurierst. Oder wenn das verschwindet, weil das seine Routing-Tabelle verschwunden ist. Wenn es bei BGP geht, ja es gibt auch da ein Timer, das ist aber nicht so strikt wie bei OSPF, bei OSPF müssen an beiden Enden der Hell- und Dead Timer über einstimmen, sonst kommt die Jessens nicht zu stehen. Das ist hier anders bei BGP, gibt es ein Keeper-Live-Timer, der steht typischerweise aus 60 Sekunden und der Timenmord steht auf 180 Sekunden. Ich bräuchte das viel länger, aber wenn der nicht über einstimmt, da wird der kürzere Wert genommen, der kleinere Wert. Also mein Hello-Intervall ist quasi eine Sekunde, dann machen das beide Seiten so. Da wird es darauf geeinigt. Ja, gibt es noch Fragen hier für die Leute, die im Stream zuschauen? Weiß ich noch mal darauf hin, IAC Hackint, Channel Routing Days? Ja, Frage zu MED und Path-Prepending. Ist das der Effekt von beiden das selber am Ende? Also kann ich auch meine Piers dazu bewegen um Path-Prepending mit Treffig über eine bestimmte Richtung zu schicken und warum ist das okay und MED nicht okay oder ist das ein Unterschied vom Effekt her? Du kannst, wenn du das nur mit der Nachpapier betrachtest, dann kannst du MED und Path-Prepending gleichermaßen verwenden, was den selben Effekt. Wenn ich dir die MED überschreibe, dann kannst du dich hingehen und sagen, dann verlängere ich da und sage, dann ist Path-Prepending interessiert mich nicht. Das macht man typischerweise aber nicht. Also die MED habe ich gerade gesagt, die endet von ihrer Bedeutung nach beim Nachbarn. Das heißt, der teilt seinen Nachbarn nicht mit, wie die MED war. Sein Nachbar-AS. Der IS-Fahrt, wenn er mal prependet ist, dann bleibt er prependet. Das heißt, wenn ich nur von meinem Nachbar-AS Steuermöchte, wo der sein Treffig reinkippt, dann muss ich Path-Prepending machen. Da wird mir die MED nicht helfen. Wenn die Quelle nicht in dem Nachbar-AS ist, was wahrscheinlich nicht der Fall ist. Kurze Nachfrage. Vielleicht habe ich es nicht ganz mitgekriegt. Du meintest, mit dem AS-Prepending könnte ich das genauso steuern zwischen zwei ASen. Aber dann hattest du gesagt, das ist aber transitiv. Das heißt, der muss das dann ja durchgeben. Das heißt, der muss das dann durchgeben. Das heißt, der muss das dann durchgeben. Das heißt, der muss das dann ja durchgeben. Wenn er es dann die Route wieder weiter gibt. Die IS-Fahrt, ja. Die MED ist nicht transitiv, aber der AS-Pars natürlich schon. Aber in dem Routing-Algorithmus stand doch, dass irgendwie nach der Erreichbarkeit des Next-Tops dann die Länge des AS-Pars das Nächste ist. Und müssen sich nicht alle an diesen Algorithmus halten. Also an den Entscheidungsalgorithmus, dass der AS-Pars dann das Nächste ist. Das heißt, wenn ich ihm irgendwie einen längeren Schicke, dann muss er den Kürzeren nehmen. Der Standard sagt das so, ja. Trotzdem kann man das so konfigurieren, dass das nicht passiert. Was ich nicht tun darf, ist, ich darf nicht hingehen und deinen AS-Pars-Repending wegnehmen und dann Weiterannouncen verändern. Das kann ich nicht machen. Ich kann aber hingehen und sagen, für mich persönlich interessiert das nicht, ob ich ihn treffig daraus schicke oder daraus schicke. Aufgrund des AS-Pars-Rependings. Die Wahrnehmung der Anleitung existiert ein paar Frepending nicht. Wenn ich aber die Route weiter schicke an jemand anderen, dann ist ein paar Frepending immer noch da. Weil sonst glaube ich Gefahr, dass ich Schleifen erzeugt und umstellen. Guten Morgen, aus dem IRC erreicht uns die Frage von Paradox. Auf mindestens einer Folie stand IBGP auf anderen BGP. Wo liegt der Unterschied? Von EBGP spricht man, wenn das eine BGP-Session WGP-Session ist, wo am beiden Enden die selbe AS-Nummer ist, also innerhalb meines Netzes. Da gibt es gleich noch eine Session zu nach dem Lab. Da zeige ich noch, was IBGP ist, wie man es verwendet und das ist eigentlich der Hauptsicher Unterschied. Die Art der Routenverbreitung ist auch ein bisschen anders. Das, was ich alles da erzählt habe, gilt erst mal jetzt nur für eBGP. Noch mal ganz zurück am Anfang zu der Next-Top-Geschichte. Da hat es so ja gesagt, irgendwie ja, man kann dann auch irgendwie über OSPF löst, man dann halt den Next-Top auf und dann wird das dann halt da lang geschickt. Aber wenn ich da jetzt in größerem Umfang halt irgendwie Routen bekomme, dann halt mit dem anderen Next-Top und ich schicke die dann durch mein IGP durch, also durch mein AS durch mit hilfliches IGP, dann müssen die Pakete ja irgendwie von den Routern dazwischen ja auch irgendwie richtig weitergeleitet werden. Das heißt, woher wissen die denn jetzt, wo ihnen das da irgendwie muss richten, die sich dann auch nur nach dem Next-Top, aber der steht ja in den Datenpaketen nicht drin oder keine Ahnung oder wie funktioniert das dann? Guter Punkt. Also wenn du, du hast jetzt eine Router, der macht eine BGP-Session, irgendwie kommt das da an und dazwischen ist ein Haufen Router und die haben jetzt diese Routen nicht, die irgendwie auf dem Weg, also den Router, die auf dem Weg liegen, gibt es diese Routen nicht, die du eigentlich brauchst, um das Paket zu vorwohren, dann würden die ja geblackholed werden. Deswegen machst du IBGP typischerweise und hast auf allen Routern auch eine volle Routing-Tabelle und die wissen auch mal, wo es lang geht. Das heißt dann irgendwie, dass mit dem OSPF war ein Fake? Nee, nee, nee. Kann es weg. Du brauchst IBGP in deinem Netz, da komme ich gleich dazu in der nächsten Session und damit das IBGP sich überhaupt gegenseitig erreichen kann und runter, dafür brauchst du den OSPF immer noch. Also man macht dann praktisch irgendwie zwischen zwei Routern sowohl OSPF als auch IBGP. Genau. Aber du machst das IBGP nicht nur zwischen direkt benachbarten Routern, sondern zwischen allen. Ein Full Mesh. Jeder Router in deinem Netz spricht IBGP mit jedem anderen Router. Aber warum das so ist, da komme ich in die nächsten Session zu. Vielleicht noch mal eine Anmerkung zu den Filtern. Man sollte ja RFC 1918 filtern, das sollte man aber nicht nur mit den Routen Informationen tun, sondern das sollte man auch mit konkreten Paketen tun, die einen erreichen. Oh ja. Nur dass man keine Routen akzeptiert, heißt nicht, dass jemand einem keine Pakete schickt, die an RFC 1918 adressiert sind. Das heißt, man sollte tunlich beides tun. Böse Piers können natürlich auch hängen und sagen, du schickst mir die Route nicht, dann setze ich halt eine statische Route. Geht der Treffig trotzdem darüber? Oder man hat eine Default-Route. Auch das geht. Also hier kommt die Anmerkung, man möchte sein ausgehenden Treffig auch bitte filtern. Wenn ihr die Vollroute von uns habt, heißt das nicht, dass wir F1918 adressierte Pakete von euch empfangen wollen. Also setz da bitte ein IP-Tablesfilter auf euren Routern ein, um alles, was nicht, was an eine dieser genannten Adressbereiche geht, bitte auszufiltern. Ihr kriegt eine Default-Route, das heißt, alles, was euer Router nicht selber kennt, das schickt an die Default-Route, dann bekommen wir F1918 Pakete und haben den Backbone hängen unnötigerweise. Das könnt ihr wegfiltern. Das sollt ihr bitte auch tun. Eigentlich solltet ihr ein Source-Filter bauen und sagen, alles, was eine Source-IP auch was eine Source-IP hat, die nicht der Adressbereich ist, den wir euch zugeteilt haben, das sollt ihr nicht an uns schicken. Wenn da nicht diese Source-IP dran ist, dann wollen wir das Paket nicht haben. Wir haben aktuell noch keinen Filter dafür, aber der kommt. Aufgrund mancher Nachfrage machen wir, wenn wir nachher noch Zeit haben, glaube ich mal eine Best-Practice-Session How to connect your Fryphone-Community. Ich hatte noch eine Sache, ich habe ja gerade kurz von Internet-Exchanges gesprochen. Olli hat jetzt was zu Communities erzählt, die man an so einer Routen-Information dran hängen kann. Bei Internet-Exchanges ist es so, z.B. beim ESIX, die Reibdatenmang enthält ja die Information darüber, welche Route legitim ist, Announce zu werden aus einem bestimmten IS. Der ESIX betreibt Routesauber. Wenn man damit piert, bekommt man die Informationen über andere Mitglieder und die validieren die Routeninformationen, die ein PS schicken gegen die Information in der Reibdatenmang und die taggen diese Routen dann mit einer WBGP-Community. Das heißt, ich muss das nicht mehr tun, ich muss die nicht mehr validieren gegen die Datenmang, sondern ich kann mich darauf verlassen, dass der ESIX das tut und der hängt dann entsprechende Communities an diese Routen dran und ich kann anhand der Communities ausfiltern, ob das jetzt ein Announcement ist, was anhand der Reibdatenmang legitim ist oder ob das Announcement ist, was in der Reibdatenmang so nicht drinsteht und könnte das dann anhand der Community verwerfen. Philip wird jetzt nochmals organisatorisch das erzählen, glaube ich. Ja, danke, tackt erst mal. Applaus.