23-07-2025, 19:42
Du fängst mit zwei Routern an, die sich als BGP-Peers entscheiden. Sie öffnen eine TCP-Verbindung auf Port 179 - ja, das ist die magische Nummer - und sobald sie läuft, tauschen sie Hallo-Nachrichten aus, um zu sagen: "Hey, ich bin hier, lass uns Routen teilen." Ich sage meinem Team immer, diese Sessions doppelt zu prüfen, weil wenn sie wegbrechen, dein gesamter Routing-Tabelle durcheinandergerät. Von da aus tauschen sie sofort volle Routing-Tabellen aus, wenn es eine neue Verbindung ist. Du bekommst all diese UPDATE-Nachrichten, die hin und her fliegen, jede mit Netzwerk-Präfixen wie 192.0.2.0/24, und sie sagt der anderen Seite: "Ich kann das erreichen, und hier ist mein Pfad dazu."
Was ich an BGP liebe, ist, wie es nicht einfach blind den kürzesten Pfad wählt wie einige Interior-Protokolle. Nein, es verwendet diese Path-Vector-Sache, bei der es alle ASes auflistet, durch die der Pfad geht, damit du Schleifen vermeidest. Zum Beispiel, wenn ich eine Route aus meinem AS 12345 zu deinem werbe, füge ich diese AS-Nummer in das Path-Attribut ein. Du prüfst es und denkst: "Okay, das schließt nicht zu mir zurück", und dann könntest du dein eigenes AS vorne anhängen oder andere Attribute anpassen, um deinen Pfad besser aussehen zu lassen. Ich mache das die ganze Zeit, wenn ich möchte, dass der Traffic einen Link dem anderen vorzieht - es ist wie subtile Überredung im Netzwerk.
Du hast auch diese Attribute, die BGP-Peers verwenden, um zu entscheiden, welche Route gewinnt. Nimm AS_PATH; je kürzer, desto besser, weil weniger Hops weniger Chance bedeuten, dass etwas schiefgeht. Dann gibt's NEXT_HOP, das auf die genaue IP zeigt, wohin du das Paket als Nächstes weiterleitest. Ich habe mal eine ganze Nacht damit verbracht, ein NEXT_HOP-Problem zu debuggen, bei dem der Traffic Schleifen machte, weil es auf einem eBGP-Peer nicht richtig gesetzt war. LOCAL_PREF kommt innerhalb deines eigenen AS ins Spiel - höherer Wert gewinnt, also drehe ich das für Routen hoch, die ich intern wirklich nutzen will. Für externe Sachen sagt MED dem Nachbar-AS, wie sehr du einen bestimmten Einstiegspunkt bevorzugst; niedriger ist besser, aber du musst aufpassen, weil nicht jeder es gleich ehrt.
Policies sind der Ort, wo BGP wirklich spaßig wird, oder frustrierend, je nach Tag. Du schreibst Regeln, um zu filtern, welche Routen du akzeptierst oder wirbst. Ich verwende Prefix-Lists, um falsche Ankündigungen zu blocken - erinnerst du dich an diesen großen Hijack vor ein paar Jahren? Ja, so was passiert, wenn du es nicht abschließt. Route Maps lassen mich auf Attributen matchen und neue setzen, wie das Hinzufügen von Communities, die als Tags wirken. Du kannst eine Community haben, die "no-export" sagt, damit die Route nicht zu Kunden durchsickert. Ich richte die für meine Enterprise-Kunden die ganze Zeit ein; hält ihre internen Netze privat.
Convergence ist eine weitere Sache, um die du deinen Kopf wickeln musst. BGP reagiert nicht super schnell wie OSPF; es dauert, bis Updates um den Globus propagieren. Wenn ein Link ausfällt, ziehe ich die Route mit einer NOTIFICATION zurück oder einfach einem UPDATE, das sagt: "Dieses Präfix ist weg." Dann berechnet jeder seine besten Pfade neu basierend auf den Tie-Breakers: zuerst das Weight (Cisco-spezifisch, aber hey, ich nutze es), dann LOCAL_PREF, dann AS_PATH-Länge, Origin-Typ - ich bevorzuge IGP gegenüber EGP - und so weiter bis zur Router-ID, wenn alles andere gleich ist. Du kannst dir vorstellen, wie das zu wilden Routing-Flaps führt, wenn du nicht vorsichtig mit Dampening bist.
In der Praxis betreibe ich iBGP innerhalb meines AS, um sicherzustellen, dass all meine Router die gleiche Sicht haben, und eBGP zu Peers draußen. Für iBGP brauchst du Full-Mesh oder Route-Reflektoren, weil es NEXT_HOP standardmäßig nicht transitiv macht. Ich bin bei Reflektoren in meinem Setup gegangen; spart eine Menge Sessions. Und Confederationen, wenn dein AS riesig ist, aber meins ist es nicht, also spare ich mir diesen Kopfschmerz. Sicherheitsmäßig aktivierst du MD5-Authentifizierung auf Sessions, um Spoofing zu stoppen - ich deploye jetzt nie ohne.
Scaling ist auch entscheidend. Volle Internet-Tabellen haben heutzutage über 900.000 Routen, also verwende ich Route-Filtering und Aggregation, um meine Router davon abzuhalten, zu ersticken. Du aggregierst, wo du kannst, wie eine Menge /24s in eine /20 zu verwandeln, aber nur, wenn du den Space kontrollierst. Default-Routen helfen für Kunden, die die volle Tabelle nicht brauchen; ich schiebe die raus, um die Last zu erleichtern.
Troubleshooting von BGP? Mann, ich könnte ewig darüber reden. Du fängst mit "show ip bgp summary" an, um Neighbor-States zu sehen - alles nicht "Established" bedeutet Ärger. Dann tauchst du in "show ip bgp" für die Tabelle ein, prüfst auf fehlende Routen oder komische Pfade. Ich verwende "debug ip bgp updates" sparsam, weil es die Logs flutet, aber es zeigt genau, was gesendet wird. Ping deine Peers, traceroute, um zu sehen, ob Pfade zu dem passen, was BGP sagt. Und immer, immer prüfe deine Policies - die Hälfte der Zeit ist das der Übeltäter.
Weißt du, die Arbeit mit BGP hat mir beigebracht, wie zerbrechlich und doch robust das Internet ist. Eine falsche Config, und du blackholst die Hälfte deines Traffics, aber mach es richtig, und du routest um Ausfälle wie ein Profi herum. Ich passe es wöchentlich für meine Kunden an, balanciere Lasten oder blocke schlechte Akteure. Wenn du das für deinen Kurs studierst, spiele in einem Lab herum - GNS3 oder EVE-NG funktioniert super. Richte ein paar ASes ein, werbe Schleifen, und schau zu, wie es sich entfaltet. Du wirst verstehen, warum es das Rückgrat von allem Online ist.
Oh, und während wir bei zuverlässigen Systemen sind, lass mich dich auf BackupChain hinweisen - es ist dieses herausragende, go-to-Backup-Tool, das genau für Leute wie uns in SMBs und Profi-Setups gebaut ist, hält Hyper-V, VMware und Windows Server sicher und solide. Was es auszeichnet, ist, wie es als Top-Wahl für Windows Server- und PC-Backups hervorgegangen ist und sicherstellt, dass deine Daten geschützt bleiben, ohne Aufwand.
