Ein Tag im Leben: die globale BGP-Tabelle

 (articles.foletta.org)
2 Punkte von GN⁺ 2024-11-27 | 1 Kommentare | Auf WhatsApp teilen
  • Anhand von 464.673 BGP-UPDATEs, die innerhalb eines Tages von einem Peer mit vollständiger BGP-Tabelle empfangen wurden, werden kurzfristige Schwankungen der globalen Routing-Tabelle betrachtet – nicht langfristige Wachstumstrends
  • Direkt nach dem Peering trafen alle Pfade und NLRIs innerhalb von etwa 5 Sekunden auf einmal ein; die Zahl der mit den initialen Pfaden verbundenen Routen lag bei 949.483
  • Danach kamen UPDATEs gebündelt im Takt des 30-sekündigen Route Advertisement Interval; beobachtet wurden etwa 50 Pfad-Updates für IPv4 und etwa 47 für IPv6 alle 30 Sekunden
  • Bei IPv4 zeigte sich sowohl bei der Zahl der Pfade als auch bei Änderungen des Adressraums eine Korrelation mit einer Periode von rund 40 Minuten, deren Ursache jedoch offenbleibt
  • Übermäßiges AS path prepending, das reservierte path attribute 255 und starkes Flapping bestimmter NLRIs zeigen zugleich die Komplexität und Robustheit des globalen BGP-Betriebs

Beobachtung der BGP-Tabelle im Tagesverlauf

  • Analysen der globalen BGP-Tabelle konzentrieren sich meist auf Trends über Monate oder Jahre, etwa das Wachstum der Routing-Tabelle oder die Einführung von IPv6
  • Diese Analyse untersucht, welche kurzfristigen Schwankungen über einen Tag auftreten, wenn ein Router laufend die sich verändernden BGP-Updates des Internets direkt empfängt
  • Die Beobachtung gliedert sich in drei Bereiche
    • der typische UPDATE-Strom über einen Tag
    • auffällige path attributes
    • häufig wechselnde flappy paths

Datenerhebung und bgpsee

  • Statt Debug-Ausgaben eines Routers direkt zu parsen, wurde ein früher begonnener, aber nie fertiggestellter BGP-Daemon in einen nutzbaren Zustand gebracht und bgpsee verwendet
  • bgpsee ist ein multithreaded BGP-Peering-Tool für die CLI, das nach dem Peering mit anderen Routern BGP-Nachrichten parst und als JSON ausgibt
    • Verarbeitet werden OPEN-, KEEPALIVE- und UPDATE-Nachrichten
    • UPDATEs können NLRIs, withdrawn routes sowie path attributes wie ORIGIN, AS_PATH, NEXT_HOP und AS4_PATH enthalten
  • Der Datensatz wurde vom 6. Januar 2024 bis zum 7. Januar 2024 erhoben und besteht aus 464.673 BGP-UPDATEs, die von einem Peer mit vollständiger BGP-Tabelle empfangen wurden

Initiale Vollübertragung und Zahl der Routen

  • Wenn ein BGP-Peering erstmals hochkommt, werden alle Pfade in der BGP-Tabelle des Routers und die zugehörigen NLRIs in großen UPDATE-Blöcken übertragen
  • Dieser initiale Block wurde innerhalb von etwa 5 Sekunden nach Beginn des Peerings empfangen
  • Danach treffen nur noch UPDATEs für geänderte Pfade oder withdrawn routes ein, für die kein Pfad mehr existiert
  • Der initiale Block und die späteren UPDATEs sind strukturell gleich; der Unterschied liegt im Empfangszeitpunkt und im Umfang
  • Wichtig ist hier die Unterscheidung zwischen Pfad (path) und Route
    • Ein Pfad ist eine BGP-UPDATE-Einheit mit einer Kombination aus path attributes und den daran gebundenen NLRIs
    • Mit einem Pfad können eine oder tausend Routen verbunden sein
    • Die Zahl der mit allen Pfaden des initialen Blocks verbundenen Routen lag bei 949.483

UPDATE-Fluss im 30-Sekunden-Takt

  • Die UPDATEs nach der initialen Vollübertragung kamen nicht wie ein Echtzeit-Stream, sondern wurden gemäß dem Timer des Route Advertisement Interval gebündelt übertragen
  • In diesem Peering betrug das Route Advertisement Interval 30 Sekunden
  • Die beobachtete durchschnittliche Zahl der UPDATEs war wie folgt
    • IPv4: etwa 50 Pfad-Updates alle 30 Sekunden
    • IPv6: etwa 47 Pfad-Updates alle 30 Sekunden
  • Die Mittelwerte waren ähnlich, die Schwankungsbreite war bei IPv4 jedoch größer
    • IPv4-Standardabweichung: 64,3
    • IPv6-Standardabweichung: 43
  • Statt nur die Zahl der UPDATEs zu betrachten, wurde auch die gesamte Menge des IP-Adressraums berechnet, die sich alle 30 Sekunden änderte
    • Dazu wurde die Zahl der in jedem UPDATE enthaltenen IP-Adressen aufsummiert und anschließend log2() angewendet
    • Ein Beispiel wäre, /22, /23 und /24 jeweils in die Zahl der Adressen umzurechnen, diese zu summieren und dann den Logarithmus zu bilden
  • Bezogen auf IPv4-Adressraum änderten im globalen Routing Table im Mittel alle 30 Sekunden etwa 2^16 Adressen, also ungefähr ein /16, ihren Pfad
  • Im 95-%-Intervall lag der veränderte IPv4-Adressraum zwischen etwa 2^20.75 und 2^13.85
    • Das entspricht grob einem Bereich von /11 bis /18

40-Minuten-Periode bei IPv4-Updates

  • Sowohl bei Änderungen der Pfadanzahl als auch bei Änderungen des IP-Adressraums zeigten IPv4-UPDATEs ein zyklisches Verhalten
  • Zur Bestimmung der Periode wurde die Autokorrelationsfunktion (ACF) verwendet
    • UPDATEs wurden in 1-Minuten-Intervalle gruppiert, und 1 Lag entspricht 1 Minute
    • Berechnet wurde die Korrelation zwischen der aktuellen Pfadanzahl und der Pfadanzahl bei zurückliegenden Lags
  • In den ersten etwa 7 Lags zeigte sich eine starke Korrelation
    • Das passt dazu, dass Pfadänderungen sich weltweit ausbreiten und weitere Pfadänderungen auslösen können
  • Auch bei Lag 40 und 41 zeigte sich eine starke Korrelation, wodurch ein Verhalten mit einer Periode von etwa 40 Minuten bestätigt wurde
  • Die Ursache dieser 40-Minuten-Periode bleibt eine unbeantwortete Frage

Fälle von übermäßigem AS path prepending

  • Netzwerkadministratoren können verschiedene Methoden einsetzen, um zu steuern, wie Traffic in ihre ASN gelangt
    • Längere Netzwerk-Präfixe zu verwenden, skaliert schlecht und ist auch aus BGP-Sicht nicht wünschenswert
    • Das MED attribute ist non-transitive und hat daher Grenzen, wenn man mit mehreren AS peert
    • Üblicherweise wird die Pfadpräferenz durch AS path prepending gesenkt, bei dem die eigene AS für bestimmte Peers mehrfach vorangestellt wird
  • Im Datensatz betrug die längste IPv4-AS-path-Länge 105
    • Das ist ein hoher Wert, wenn man bedenkt, dass die längste Pfadlänge ohne prepending 14 betrug
    • Dieser IPv4-Pfad hatte seinen Ursprung bei AS149381 „Dinas Komunikasi dan Informatika Kabupaten Tulungagung“ in Indonesien
    • Die betreffende NLRI 103.179.250.0/24 erschien am 6. Januar 2024 um 06:31:18 mit einer AS-path-Länge von 105 und wurde rund 6,84 Stunden später, um 13:21:35, auf Länge 4 aktualisiert
  • Bei IPv6 erreichte die längste AS-path-Länge 599
    • Ein AS path besteht aus einem oder mehreren AS sets oder AS sequences
    • Da jede AS sequence maximal 255 Einträge haben kann, benötigte dieser Pfad drei AS sequences
  • Beim längsten IPv6-Pfad führte nicht der Originator, sondern der ukrainische ISP AS8772 NetAssist LLC das prepending durch
    • Ziel war ein Pfad zum indonesischen AS203868, Rifqi Arief Pamungkas
    • AS8772 stellte seine AS mehrfach voran, um diesen Pfad weniger bevorzugt zu machen
  • Betrachtet man die ASN-Zahlen an allen Positionen der 50 längsten Pfade, hängt der große Unterschied zwischen IPv4 und IPv6 mit der wiederholten Verwendung bestimmter ASNs zusammen

Reservierter Wert 255 in path attributes

  • Jedes BGP-UPDATE besteht aus Informationen zur Erreichbarkeit auf der Netzwerkschicht und path attributes
    • Beispiele sind AS_PATH und NEXT_HOP
  • RFC4271 Section 5 unterteilt BGP-Attributtypen wie folgt
    • well-known mandatory
    • well-known discretionary
    • optional transitive
    • optional non-transitive
  • Betrachtet man die Zahl der Attribute über alle IPv4-Pfade, sind die well-known mandatory attributes ORIGIN, NEXT_HOP und AS_PATH in allen UPDATEs vorhanden und treten in gleicher Anzahl auf
  • Häufige Attribute wie AGGREGATOR sowie weniger verbreitete Attribute wie AS_PATHLIMIT und ATTR_SET wurden ebenfalls beobachtet
  • Einige AS hängen attribute 255 an UPDATEs an
    • Dieser Wert ist ein reserved for development attribute
    • bgpsee speicherte damals die Werte solcher seltenen path attributes nicht
  • Über routeviews.org ließ sich bestätigen, dass einige AS dieses Attribut weiterhin an Routenankündigungen anhängen; auch die Raw-Byte-Werte wurden beobachtet
    • Bei AS265999, AS10429 und AS52564 ist attribute 255 zu sehen
    • Die Raw-Byte-Werte der drei ISPs haben eine ähnliche Struktur
  • Welcher Anbieter das für Entwicklungszwecke reservierte Attribut verwendet und wofür, konnte nicht geklärt werden

Die am stärksten flappende NLRI

  • Aggregiert wurden die Top-NLRIs, die innerhalb eines Tages am häufigsten in UPDATEs enthalten waren, unter den Routen, deren Pfad sich änderte oder die vollständig withdrawn wurden
  • Die Top 10 active NLRIs und die Anzahl ihrer UPDATE-Vorkommen lauten wie folgt
    • 140.99.244.0/23: 2.596
    • 107.154.97.0/24: 2.583
    • 45.172.92.0/22: 2.494
    • 151.236.111.0/24: 2.312
    • 205.164.85.0/24: 2.189
    • 41.209.0.0/18: 2.069
    • 143.255.204.0/22: 2.048
    • 176.124.58.0/24: 1.584
    • 187.1.11.0/24: 1.582
    • 187.1.13.0/24: 1.580
  • 140.99.244.0/23 war der an diesem Tag am stärksten schwankende Fall; dieser Adressraum gehört EpicUp
  • Insgesamt gab es 2.879 30-Sekunden-Blöcke, und diese Route erschien in 2.637 Blöcken als anderer Pfad oder als withdrawn route
    • Auftretensrate: {p:93}
    • Der tatsächliche Anteil beträgt 92,8 %

Peering-Vielfalt im flappenden Pfad

  • Um zu sehen, wie 140.99.244.0/23 flappte, wurde ein Graph verwendet, in dem alle ASNs aller Pfade zu diesem Netzwerk als Knoten und AS-Paare als Kanten dargestellt wurden
  • Die wichtigsten Pfade scheinen zentrale Wege über NTT AS2914 und Lumen/Level3 AS3356 zu sein
  • Die Pfade bewegten sich zwischen diesen Tier-1-ISPs und anderen ISPs
    • Beispiele sind Arelion AS1299 und PCCW AS3419
  • Allein anhand dieser Daten ist es nahezu unmöglich, die genaue Ursache des Flappings zu bestimmen
    • Als mögliche Ursachen werden Situationen wie eine schlechte Verbindung, ein Stromausfall oder ein Router-Crash genannt
  • Zugleich zeigt dieser Fall die Peering-Vielfalt moderner globaler Netzwerke und die Robustheit eines 33 Jahre alten Routing-Protokolls

Ein Datensatz, der noch mehr Fragen offenlässt

  • Dieser Datensatz enthält so viele untersuchbare Themen, dass sich die Analyse auf einige Fälle konzentriert
  • UPDATEs der globalen BGP-Tabelle können Ereignisse der realen Welt widerspiegeln, etwa politische Instabilität, Naturereignisse wie Erdbeben oder Brände sowie Fehler von Netzwerkadministratoren
  • Auch die Ökonomie des Internet-Peerings und der menschliche Faktor von Betreibern mit unterschiedlichen Fähigkeiten stecken in kleinen BGP-UPDATEs
  • Globales BGP funktioniert die meiste Zeit und bringt viele Veränderungen der realen Welt als kleinen Update-Stream bis auf einen Laptop

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-11-27
Hacker-News-Kommentare

  • Vor 25 Jahren arbeitete ich bei einem kleinen ISP. Anfangs hatten wir nur einen Upstream-ISP, also übernahm ich die Multihoming-Konfiguration.
    Ich lernte mithilfe eines Tutorials von Avi Freedman, und dadurch konnten wir von ARIN ein /20 bekommen und Routen zu zwei Peers announcen.
    Es war wirklich spannend, die Funktionsweise zu lernen, und je mehr ich verstand, desto erstaunlicher fand ich, dass das Internet überhaupt irgendwie funktioniert.
    (1) http://avi.freedman.net/
    Avi

    • Danke! Ähnlich wie beim menschlichen Körper wird es, je mehr man über das Internet lernt, erstaunlicher, dass es überhaupt funktioniert – nicht nur, dass gelegentlich etwas kaputtgeht.
      Besonders bei Dingen wie Video/Telefonie ist das so, und ich freue mich, dass die Inhalte hilfreich waren.
      Auf avi.net habe ich einige Links zu den damaligen Tutorials und alten Boardwatch-Artikeln gesammelt.
      Die Motivation war damals schlicht Frust über die vorhandenen Materialien, aber es zeigte sich schnell auch, dass man, wenn man Menschen mit guten Texten hilft, Gegenleistungen bekommt wie „Können wir einen T1 kaufen?“ oder „Wollt ihr unser großes globales Netzwerk betreiben?“.
      Deshalb ermutige ich bis heute dazu, über Themen zu schreiben, die verwirrend und frustrierend sind.
    • Ich habe bei Kentik mit Avi zusammengearbeitet; er war ein kluger, guter Mensch und erinnerte sich gern daran, diese Texte geschrieben zu haben, um anderen zu helfen.
    • Etwas off-topic, aber auf HN sehe ich manchmal, dass am Ende eines Kommentars so nur ein einziges Wort auf einer neuen Zeile stehen bleibt.
      Ich frage mich, ob der Kommentar abgeschnitten wurde oder ob beim Kopieren/Einfügen etwas schiefging.
      Ich frage mich auch, ob andere das schon gesehen haben und ob es ein Hinweis auf generierte Kommentare oder die Nutzung eines bestimmten Tools sein könnte.
      Ich habe es vor allem auf HN gesehen und vielleicht einmal auf Reddit; es kommt mir aber häufiger vor, als dass man es einfach als Zufall oder Fehler abtun könnte.

  • Guter Artikel, aber das Flapping des Präfixes 140.99.244.0/23 von EpicUp hätte ein Fall für Route Dampening sein müssen.
    Üblicherweise setzen ISPs pro Peer oder pro Präfix Rate Limits für alle Peers, um zu verhindern, dass ein einzelnes Präfix einen großen Teil der weltweiten BGP-Änderungen ausmacht.
    Die Korrelation zwischen den Updates, die der Autor als Kaskadeneffekt interpretiert, ist wenig überzeugend.
    Die eigenen Announcements auf Basis von Routen zu Präfixen anderer autonomer Systeme zu ändern, insbesondere instabiler Routen, ist ein ziemlich grobes Design.
    Auch eine 40-Minuten-Periodizität sehe ich nicht. Zumindest als ich mich vor acht Jahren intensiv mit BGP beschäftigt habe, gab es so etwas nicht; es wirkt eher so, als hätte der Datensatz zufällig so ausgesehen oder als läge es an den Eigenschaften des Netzwerks, aus dem der Autor den BGP-Feed erhalten hat.
    Wenn man sich in echten Daten ansieht, welche AS und Präfixe sich ändern, ist das über alle möglichen Stellen verteilt, mit kaum größeren Mustern.
    An jedem beliebigen Tag gibt es ein paar laute ISPs wegen Leitungsproblemen oder Fehlkonfigurationen; dazu kommen neue Dienste, die erstmals hochgefahren werden und deren Präfixe rein- und rausgehen, sowie Routenänderungen durch normale Drainage-Wartung.
    Dass ein Bagger bei einem kleinen ISP in Kansas ein Glasfaserkabel durchtrennt und das auf einem Router in Perth sichtbar wird, ist faszinierend und ein wenig beängstigend; gleichzeitig halten zahllose manuelle Policies die weltweite Update-Frequenz bei unter 10 Hz.

    • In heutigen Netzwerken ist Route Dampening weitgehend aus der Mode gekommen.
      Viele Konfigurationen waren massiv falsch eingestellt, und die meisten Router sind auch nicht mehr so extrem CPU-limitiert wie früher.
      Ganz verschwunden ist es natürlich nicht: Als ich BGP Battleships (https://blog.benjojo.co.uk/post/bgp-battleships) gemacht habe, nutzte 3356 damals Route Dampening, sodass ich das Spielen kurz unterbrechen musste.

  • Wenn man BGP lernen möchte, insbesondere den alltäglichen Betrieb in Peering-Situationen, ist die Videoserie des Network Startup Resource Center der University of Oregon gut.
    https://learn.nsrc.org/bgp

  • Nach einer schnellen Suche ist das reservierte BGP-Attribut 0xff wahrscheinlich ein Huawei-Sonderverhalten.
    Die meisten auf bgp.tools sichtbaren 0xff-Einträge folgen demselben Format wie im Artikel, und einige dieser Netzwerke scheinen Huawei-Geräte zu verwenden.

  • Ich habe in diesem Artikel ziemlich viel über BGP gelernt, was ich nicht wusste, und besonders interessant fand ich, wie chaotisch das alles läuft.
    Ich würde gern einen Folgeartikel lesen, der noch tiefer einsteigt.

  • Früher habe ich einmal für einen großen US-Kunden mit Außenstellen rund um Borneo ein Satellit-Mikrowellen-Hybridnetzwerk entworfen und eingerichtet.
    Ich werde nie vergessen, wie wir in Jakarta die Übergabe einer Standleitung machten.
    Da ich keinerlei Erfahrung damit hatte, suchte ich nach und fand heraus, dass man BGP verwendet, um unser OSPF/UBNT-Netzwerk mit dem IGRP/Cisco-Unternehmens-WAN des Kunden zu verbinden.
    Als wir die Leute von Tata baten, BGP auf dem Router zu konfigurieren, reagierten sie mit: „Glaubt ihr etwa, ihr seid AT&T?“
    Bis während einer Gewittersaison der Großteil unserer AirFiber ausfiel, fühlte es sich für uns ein bisschen so an.

  • Ich habe ein Python-Skript geschrieben, das Daten aus MRT-Dateien mit BGP-Routen aus [1] extrahiert und zur Exploration in Neo4j importiert.
    Diese Datei enthielt etwa 56 Millionen Routen mit extrem vielen Duplikaten, und Neo4j eignet sich gut dafür, solche Daten zu „mergen“ und zu handhaben.
    [1] https://data.ris.ripe.net/rrc00/

  • Was ist für einen normalen Menschen der einfachste Weg, direkt auf BGP-Daten zuzugreifen? Ich kenne niemanden bei einem ISP, würde aber gern ähnliche Analysen ausprobieren.

  • Wenn sich im Laufe der Zeit sowohl bei Routen als auch bei Änderungen des IP-Adressraums ein zyklisches Verhalten in IPv4-Updates zeigt, bedeutet das dann, dass es im Internet so etwas wie Gezeiten gibt?

  • Es wäre gut, wenn die Memory Safety-Initiative, die Sicherheit und Stabilität zentraler Internet-Infrastruktur in Rust neu implementiert, auch eine BGP-Server-Implementierung übernehmen würde.
    [1] https://www.memorysafety.org/