Warum BGP-Communities besser sind als AS-Pfad-Prepends

Das Internet in seiner reinsten Form ist ein lose verbundener Graph aus unabhängigen Netzwerken (auch Autonome Systeme, kurz AS, genannt). Diese Netzwerke informieren ihre Nachbarn (auch Peers genannt) mit dem Signalisierungsprotokoll BGP (Border Gateway Protocol) über die Erreichbarkeit von IP-Präfixen (einer Gruppe von IP-Adressen) in und durch ihr Netzwerk. Ein Teil dieses Austauschs enthält nützliche Metadaten über das IP-Präfix und diese Daten werden für Routing-Entscheidungen im Netzwerk verwendet. Ein Beispiel für solche Metadaten ist der vollständige AS-Pfad, der aus den verschiedenen autonomen Systemen besteht, die ein IP-Paket auf dem Weg zu seinem Ziel durchlaufen muss.

Da wir unsere Pakete so schnell wie möglich am Zielort sehen möchten, empfiehlt sich der kürzeste Pfad für ein bestimmtes Präfix. Hier kommt das sogenannte Prepending ins Spiel.

Routing im Internet, eine Einführung

Sprechen wir kurz über die grundlegende Funktionsweise des Internets und stürzen uns danach in die praktischen Details.

Das Internet ist im Kern ein massiv verknüpftes Netzwerk aus Tausenden von Netzwerken. Jedes Netzwerk hat zwei wichtige Eigenschaften:

1. Eine AS-Nummer (ASN): eine 32-Bit-Ganzzahl, die ein Netzwerk eindeutig identifiziert. Zum Beispiel lautet eine der Cloudflare-ASNs (wir haben mehrere) 13335.

2. IP-Präfixe: Ein IP-Präfix ist ein Bereich von IP-Adressen, die in Zweierpotenzen gebündelt sind: Im IPv4-Raum bilden zwei Adressen ein /31-Präfix, vier ein /30 und so weiter, bis hin zu /0, was eine Abkürzung für „alle IPv4-Präfixe“ ist. Dasselbe gilt für IPv6, aber anstatt maximal 32 Bits zu aggregieren, können Sie bis zu 128 Bits aggregieren. Die Abbildung unten zeigt diese Beziehung zwischen IP-Präfixen in umgekehrter Reihenfolge: ein /24 enthält zwei /25, das wiederum zwei /26 enthält, und so weiter.

Für die Kommunikation im Internet müssen Sie Ihr Ziel erreichen können, und hier kommen die Routing-Protokolle ins Spiel. Sie kümmern sich darum, dass jeder Internetknoten die Zieladresse Ihrer Nachricht kennt (und dass der Empfänger eine Nachricht zurücksenden kann).

Wie bereits erwähnt, werden diese Ziele durch IP-Adressen identifiziert, und zusammenhängende Bereiche von IP-Adressen werden als IP-Präfixe ausgedrückt. Wir verwenden beim Routing IP-Präfixe für mehr Effizienz: Es wäre unglaublich komplex und ressourcenintensiv, den Überblick über vier Milliarden (2³²) IP-Adressen in IPv4 zu behalten.

Erinnern Sie sich nun daran, dass Autonome Systeme unabhängig betrieben und kontrolliert werden. Wie teile ich im Netzwerk der Internetnetzwerke der Quelle A in einem anderen Netzwerk mit, dass es einen verfügbaren Pfad zum Ziel B in meinem Netzwerk (oder über dieses) gibt? Hier kommt BGP ins Spiel! BGP ist das Border Gateway Protocol und wird verwendet, um Erreichbarkeitsinformationen zu signalisieren. Signalnachrichten, die vom Quell-ASN erzeugt werden, nennt man „Ankündigungen“, da sie dem Internet mitteilen, dass die IP-Adressen im Präfix online und erreichbar sind.

Sehen Sie sich die obige Abbildung an. Quelle A sollte nun wissen, wie sie über zwei verschiedene Netzwerke zu Ziel B gelangt!

So würde eine echte BGP-Nachricht aussehen:

BGP Message
    Type: UPDATE Message
    Path Attributes:
        Path Attribute - Origin: IGP
        Path Attribute - AS_PATH: 64500 64496
        Path Attribute - NEXT_HOP: 198.51.100.1
        Path Attribute - COMMUNITIES: 64500:13335
        Path Attribute - Multi Exit Discriminator (MED): 100
    Network Layer Reachability Information (NLRI):
        192.0.2.0/24

Wie Sie sehen, enthalten BGP-Nachrichten mehr als nur das IP-Präfix (das NLRI-Bit) und den Pfad, sondern auch eine Reihe anderer Metadaten, mit zusätzlichen Informationen über den Pfad. Zu den weiteren Feldern gehören Communities (mehr dazu später) sowie MED oder der Ursprungscode. MED ist ein Vorschlag für andere direkt verbundene Netzwerke, welcher Pfad genommen werden sollte, wenn mehrere Optionen zur Verfügung stehen, und der niedrigste Wert gewinnt. Der Ursprungscode kann einer von drei Werten sein: IGP, EGP oder Incomplete. IGP wird eingestellt, wenn der Ursprung des Präfixes über BGP erfolgt, EGP wird nicht mehr verwendet (es ist ein uraltes Routing-Protokoll), und Incomplete wird eingestellt, wenn Sie ein Präfix von einem anderen Routing-Protokoll (wie IS-IS oder OSPF) an BGP weiterleiten.

Da die Quelle A nun weiß, wie sie über zwei verschiedene Netzwerke zum Ziel B gelangt, kommen wir zum Thema Traffic-Engineering!

Traffic-Engineering

Traffic-Engineering ist ein wichtiger Bestandteil der täglichen Verwaltung eines jeden Netzwerks. Genau wie in der physischen Welt können Betreiber Umleitungen einrichten, um die Verkehrsströme in ihr Netzwerk (eingehend, inbound) und aus ihrem Netzwerk (ausgehend, outbound) zu optimieren. Outbound-Traffic-Engineering ist wesentlich einfacher als Inbound-Traffic-Engineering, da die Betreiber zwischen benachbarten Netzwerken wählen und sogar einem bestimmten Traffic Vorrang vor anderen einräumen können. Im Gegensatz dazu erfordert das Inbound Traffic Engineering die Beeinflussung eines Netzwerks, das von einem anderen Betreiber verwaltet wird. Die Autonomie und Selbstverwaltung eines Netzwerks ist von größter Bedeutung, so dass die Betreiber verfügbare Tools verwenden, um eingehende Paketströme aus anderen Netzwerken zu informieren oder zu gestalten. Das Verständnis und die Verwendung dieser Tools ist komplex und kann eine Herausforderung sein.

Die verfügbaren Tools für das Traffic-Engineering, sowohl für eingehende als auch für ausgehende Verbindungen, basieren auf der Manipulation von Attributen (Metadaten) einer bestimmten Route. Da es hier um Traffic-Engineering zwischen unabhängigen Netzwerken geht, werden wir die Attribute einer EBGP-gelernten Route manipulieren. BGP kann in zwei Kategorien unterteilt werden:

1. EBGP: BGP-Kommunikation zwischen zwei verschiedenen ASNs
2. IBGP: BGP-Kommunikation innerhalb desselben ASN

Während das Protokoll dasselbe ist, können bei einer IBGP-Sitzung bestimmte Attribute ausgetauscht werden, die bei einer EBGP-Sitzung nicht ausgetauscht werden. Eines dieser Attribute ist die lokale Präferenz. Mehr dazu in Kürze.

BGP Auswahl des besten Pfades

Wenn ein Netzwerk mit mehreren anderen Netzwerken und Providern verbunden ist, kann es von vielen dieser Netzwerke Pfadinformationen zum gleichen IP-Präfix erhalten, wobei jedes dieser Netzwerke leicht unterschiedliche Eigenschaften aufweist. Es ist dann Aufgabe des empfangenden Netzwerks, mit Hilfe eines BGP-Algorithmus zur Auswahl des besten Pfads das „beste“ Präfix (und die beste Route) auszuwählen und diesen zur Weiterleitung des IP-Traffics zu verwenden. Ich habe „beste“ in Anführungszeichen gesetzt, da „beste“ eine subjektive Anforderung ist. „Das Beste“ ist häufig der kürzeste Weg, aber was für mein Netzwerk das Beste sein kann, ist für ein anderes Netzwerk nicht unbedingt das beste Ergebnis.

BGP berücksichtigt bei der Filterung der empfangenen Optionen mehrere Präfix-Attribute. Anstatt jedoch all diese Attribute zu einem einzigen Auswahlkriterium zusammenzufassen, verwendet BGP bei der Auswahl des besten Pfads die Attribute in Stufen. Wenn die verfügbaren Attribute auf einer Stufe für die Auswahl des besten Pfads ausreichen, wird der Algorithmus mit dieser Auswahl beendet.

Der BGP-Algorithmus zur Auswahl des besten Pfads ist sehr umfangreich und umfasst 15 einzelne Schritte zur Auswahl des besten verfügbaren Pfads für ein bestimmtes Präfix. Angesichts der vielen Schritte will das Netzwerk den besten Pfad so früh wie möglich auswählen. Die ersten vier Schritte werden am häufigsten verwendet und haben den größten Einfluss. Sie sind in der Abbildung unten als Trichter dargestellt.

Die Wahl des kürzesten Pfades ist in der Regel eine gute Idee, weshalb die „AS-Pfadlänge“ ein früher Schritt im Algorithmus ist. In der obigen Abbildung erscheint die „AS-Pfadlänge“ jedoch an zweiter Stelle, obwohl mit diesem Attribut der kürzeste Pfad ermittelt wird. Sprechen wir also über den ersten Schritt: die lokale Präferenz.

Lokale Präferenz
Die lokale Präferenz ist bei Betreibern sehr beliebt, weil sie damit eine Kombination aus Route und Pfad auswählen können. Sie ist das erste Attribut des Algorithmus, denn sie ist für jede Kombination aus Route+Nachbarn+AS-Pfad einzigartig.

Ein Netzwerk legt die lokale Präferenz beim Import einer Route fest (nachdem es von der Route von einem Nachbarnetzwerk erfahren hat). Es handelt sich um eine nicht-transitive Eigenschaft, d. sph. es ist ein Attribut, das niemals in einer EBGP-Nachricht an andere Netzwerke gesendet wird. Das bedeutet zum Beispiel, dass der Betreiber von AS 64496 die lokale Präferenz von Routen zu seinen eigenen (oder transitierenden) IP-Präfixen im benachbarten AS 64511 nicht festlegen kann. Die Unmöglichkeit, dies zu tun, ist einer der Gründe, warum das Inbound Traffic Engineering über EBGP so schwierig ist.

Das Prepending erhöht künstlich die Länge der AS-Pfade
Da kein Netzwerk in der Lage ist, die lokale Präferenz für ein Präfix innerhalb eines anderen Netzwerks direkt festzulegen, ist die Änderung des AS-Pfads die erste Möglichkeit, die Entscheidungen anderer Netzwerke zu beeinflussen. Wenn die nächsten Hops gültig sind und die lokale Präferenz für alle verschiedenen Pfade für eine bestimmte Route gleich ist, ist die Modifizierung des AS-Pfads eine offensichtliche Option für die Änderung des Pfads, den der Traffic zu Ihrem Netzwerk nehmen wird. In einer BGP-Nachricht sieht das Prepending wie folgt aus:

Vorher:

BGP Message
    Type: UPDATE Message
    Path Attributes:
        Path Attribute - Origin: IGP
        Path Attribute - AS_PATH: 64500 64496
        Path Attribute - NEXT_HOP: 198.51.100.1
        Path Attribute - COMMUNITIES: 64500:13335
        Path Attribute - Multi Exit Discriminator (MED): 100
    Network Layer Reachability Information (NLRI):
        192.0.2.0/24

Nachher:

BGP Message
    Type: UPDATE Message
    Path Attributes:
        Path Attribute - Origin: IGP
        Path Attribute - AS_PATH: 64500 64496 64496
        Path Attribute - NEXT_HOP: 198.51.100.1
        Path Attribute - COMMUNITIES: 64500:13335
        Path Attribute - Multi Exit Discriminator (MED): 100
    Network Layer Reachability Information (NLRI):
        192.0.2.0/24

Insbesondere können die Betreiber AS-Pfade voranstellen. Beim Prepending von AS-Pfaden fügt ein Betreiber dem Pfad zusätzliche autonome Systeme hinzu (normalerweise verwendet der Betreiber sein eigenes AS, aber das wird im Protokoll nicht erzwungen). Auf diese Weise kann die Länge eines AS-Pfads von 1 auf 255 steigen. Da sich die Länge nun drastisch erhöht hat, wird dieser spezielle Pfad für die Route nicht gewählt. Indem er den AS-Pfad ändert, der verschiedenen Peers bekannt gegeben wird, kann ein Betreiber den Traffic in seinem Netzwerk steuern.

Leider hat das Prepending einen Haken: Damit es der entscheidende Faktor ist, müssen alle anderen Attribute gleich sein. Das ist selten der Fall, insbesondere in großen Netzwerken, die aus vielen möglichen Routen zu einem Ziel wählen können.

Business Policy Engine

BGP wird umgangssprachlich auch als Business Policy Engine bezeichnet: Es wählt nicht den besten Pfad nach Performance-Gesichtspunkten aus, sondern – und das ist häufiger der Fall – den besten Pfad nach geschäftlichen Gesichtspunkten. Die geschäftlichen Kriterien können alles Mögliche sein, von der Effizienz der Investitionen (Ports) bis hin zu höheren Einnahmen und mehr. Das mag seltsam klingen, aber ob Sie es glauben oder nicht, genau dafür ist BGP gedacht! Die Stärke (und Komplexität) von BGP besteht darin, dass es einem Netzwerkbetreiber ermöglicht, Entscheidungen entsprechend den Bedürfnissen, Verträgen und Richtlinien des Betreibers zu treffen, wobei viele dieser Entscheidungen nicht mit herkömmlichen Vorstellungen von technischer Performance vereinbar sind.

Unterschiedliche lokale Präferenzen

Viele Netzwerke (einschließlich Cloudflare) weisen eine lokale Präferenz zu, die von der Art der Verbindung abhängt, über die uns die Routen übermittelt werden. Ein höherer Wert bedeutet eine höhere Präferenz. Zum Beispiel erhalten Routen, die von Transitnetzverbindungen gelernt wurden, eine niedrigere lokale Präferenz von 100, denn sie sind in der Nutzung am teuersten; Backbone-Routen, die von Backbone-Verbindungen gelernt wurden, erhalten 150, Internet Exchange (IX)-Routen 200 und schließlich Private Interconnection (PNI)-Routen 250. Das bedeutet, dass das Cloudflare-Netzwerk für ausgehenden Traffic standardmäßig eine PNI-Route bevorzugt, selbst wenn ein kürzerer AS-Pfad über einen IX- oder Transit-Nachbarn verfügbar ist.

Ein Grund, warum wir eine PNI gegenüber einer IX bevorzugen, ist die Zuverlässigkeit, es involviert nämlich keine Drittanbieter-Switching-Plattform, die sich unserer Kontrolle entzieht. Das ist wichtig, denn wir gehen davon aus, dass jede Hardware irgendwann kaputt gehen kann und auch kaputt gehen wird. Ein weiterer Grund liegt in der Effizienz der Ports. Hier wird die Effizienz durch die Kosten pro übertragenem Megabit an jedem Port definiert. Grob gesagt, werden die Kosten wie folgt berechnet:

((Preis_pro_Switch / Port_Anzahl) + Transceiver_Kosten)

die mit den Cross-Connect-Kosten kombiniert werden (dies können monatlich wiederkehrende Kosten (MRC) oder eine einmalige Gebühr sein). PNI ist vorzuziehen, es trägt zur Wertoptimierung bei, indem es die Gesamtkosten pro übertragenem Megabit senkt, da der Unit-Preis mit höherer Auslastung des Ports sinkt.

Diese Argumentation gilt auch für viele andere Netzwerke und ist in Transitnetzwerken weit verbreitet. Bei BGP geht es mindestens genauso sehr um Kosten und Geschäftspolitik wie um Performance.

Lokale Präferenz für den Transit

Der Einfachheit halber beziehe ich mich bei Transit auf die traditionellen Transitnetze der Stufe 1. Aufgrund der Beschaffenheit dieser Netze gibt es zwei verschiedene Gruppen von Netzwerk-Peers:

1. Kunden (wie Cloudflare)
2. Settlement-Free-Peers (wie andere Netzwerke der Stufe 1)

Unter normalen Umständen erhalten Transitkunden eine höhere lokale Präferenz zugewiesen als die lokale Präferenz für ihre Settlement-Free-Peers. Das bedeutet, dass der Traffic, wenn er in dieses Transitnetzwerk gelangt, immer auf Ihrer Interconnection mit diesem Transitnetzwerk landet und nicht auf einen anderen Peer verlagert wird, ganz gleich, wie viel Sie einem Präfix voranstellen.

Ein Prepend kann immer noch verwendet werden, und zwar wenn Sie Traffic von einer einzelnen Verbindung mit einem Transit verlagern/auslagern möchten, wenn Sie mehrere unterschiedliche Verbindungen mit diesen haben, oder wenn die Quelle des Traffics hinter mehreren Transits multihomed ist (und sie nicht ihr eigenes lokales Präferenz-Playbook haben, das einen Transit gegenüber einem anderen bevorzugt). Wenn Sie den eingehenden Traffic von einem Transit-Port auf einen anderen umleiten, indem Sie den AS-Pfad vorangestellt haben, ist der Nutzen jedoch sehr gering: Wenn Sie einmal über drei Prepends hinaus sind, wird sich wahrscheinlich nicht mehr viel ändern, wenn überhaupt.

Beispiel

Im obigen Szenario wird der Traffic unabhängig von der Anpassung, die Cloudflare in seinem AS-Pfad in Richtung AS 64496 vornimmt, weiterhin durch die Interconnection Transit B <> Cloudflare fließen, obwohl der Pfad Ursprung A → Transit B → Transit A → Cloudflare aus Sicht des AS-Pfads kürzer ist.

In diesem Szenario hat sich nicht viel geändert, aber Ursprung A ist jetzt hinter den beiden Transit-Providern multi-homed. In diesem Fall war das AS-Pfad-Prepending wirksam, da die Pfade auf der Seite von Ursprung A sowohl der Prepended- als auch der Non-Prepended-Pfad sind. Solange Ursprung A kein Egress-Traffic-Engineering vornimmt und beide Transitnetzwerke gleich behandelt, lautet der gewählte Pfad Ursprung A → Transit A → Cloudflare.

Communitybasiertes Traffic-Engineering

Damit haben wir nun ein ziemlich kritisches Problem innerhalb des Internetökosystems für Betreiber identifiziert: Mit den oben erwähnten Tools ist es nicht immer möglich (manche würden sogar sagen völlig unmöglich), die Pfade, über die Traffic in Ihr eigenes Netzwerk eindringen kann, genau zu bestimmen, das reduziert die Kontrolle eines autonomen Systems über sein eigenes Netzwerk. Glücklicherweise gibt es eine Lösung für dieses Problem: communitybasierte lokale Präferenzen.

Einige Transit-Provider erlauben ihren Kunden, die lokale Präferenz im Transitnetzwerk mit Hilfe von BGP-Communities zu beeinflussen. BGP-Communities sind ein optionales transitives Attribut für eine Routenanzeige. Die Communities können informativ sein („Ich habe dieses Präfix in Rom gelernt“), aber sie können auch dazu verwendet werden, Aktionen auf der empfangenden Seite auszulösen. Cogent veröffentlicht zum Beispiel die folgenden Aktions-Communities:

Wenn Sie wissen, dass Cogent in seinem Netzwerk die folgenden lokalen Standardeinstellungen verwendet:

Peers → Lokale Präferenz 100
Kunden → Lokale Präferenz 130

ist es leicht zu erkennen, wie wir die verwendeten Routen mit Hilfe der bereitgestellten Communities ändern können. Da wir die lokale Präferenz einer Route nicht auf 100 (oder 130) setzen können, ist das Prepending von AS-Pfaden jedoch weitgehend irrelevant, da die lokale Präferenz niemals gleich sein wird.

Nehmen Sie zum Beispiel die folgende Konfiguration:

term ADV-SITELOCAL {
    from {
        prefix-list SITE-LOCAL;
        route-type internal;
    }
    then {
        as-path-prepend "13335 13335";
        accept;
    }
}

Wir haben bei der ASN von Cloudflare zweimal das Prepending ausgeführt, was zu einem AS-Pfad von insgesamt drei führt, aber es kam immer noch viel (zu viel) Traffic auf unserem Cogent-Link an. An diesem Punkt könnte ein Entwickler ein weiteres Prepend hinzufügen, aber für ein gut vernetztes Netzwerk wie Cloudflare bringen zwei Prepends nicht viel, ebenso wenig wie drei, und vier oder fünf bringen auch nicht. Stattdessen können wir die oben dokumentierten Cogent-Communities nutzen, um das Routing innerhalb von Cogent zu ändern:

term ADV-SITELOCAL {
    from {
        prefix-list SITE-LOCAL;
        route-type internal;
    }
    then {
        community add COGENT_LPREF70;
        accept;
    }
}

Die obige Konfiguration ändert den Traffic-Fluss wie folgt:

Genau das haben wir uns gewünscht!

Fazit

Das Prepending von AS-Pfaden ist nach wie vor nützlich und hat seine Berechtigung als Teil der Toolchain für Betreiber, die Traffic Engineering vornehmen, aber es sollte sparsam eingesetzt werden. Übermäßiges Prepending öffnet ein Netzwerk für weit verbreitete Routen-Hijacks, diese sollten Sie unter allen Umständen vermeiden. Daher ist die Verwendung von communitybasiertem Ingress-Traffic-Engineering sehr zu bevorzugen (und zu empfehlen). In Fällen, in denen Communities nicht zur Verfügung stehen (oder nicht in der Lage sind, den Traffic der Kunden zu lenken), können Prepends eingesetzt werden, aber ich empfehle den Betreibern, die Auswirkungen aktiv zu überwachen und sie zurückzunehmen, sollten sie unwirksam sein.

Nebenbei bemerkt haben P. Marcos et al. ein interessantes Paper über das Prepending von AS-Pfaden veröffentlicht und gehen auf einige Trends ein, die im Zusammenhang mit dem Prepending zu beobachten sind. Ich kann die Lektüre sehr ans Herz legen: https://www.caida.org/catalog/papers/2020_aspath_prepending/aspath_prepending.pdf