Ich habe den Begriff "Routenserver" und "Spiegel" hier herumgeworfen gehört. Was sind sie und warum sollte es mich interessieren?

— John Jensen
quelle

(Beachten Sie, dass diese beiden Begriffe häufig synonym verwendet werden, was zu Verwirrung führen kann.)

Spiegel

Ein Spiegel ist in der Regel eine Website (meistens CGI), die mit Routern kommuniziert, die einem einzelnen ISP oder einem anderen Netzwerkbetreiber gehören und von diesem betrieben werden. Meistens sind diese öffentlich zugänglich, aber es kann Fälle geben, in denen dies nicht der Fall ist. Der Spiegel bietet einen Blick (in Form einer Website) auf eine BGP-Tabelle eines bestimmten Routers im Netzwerk eines Betreibers. Häufig umfassen Look-Glass-Implementierungen auch andere Dienstprogramme, z. B. die Möglichkeit, eine Traceroute zu einem Ziel so auszuführen, als würde sie vom Router des Netzwerkbetreibers selbst ausgeführt. Spiegel sind nützlich, weil sie eine Perspektive in die BGP-Tabelle eines Upstreams bieten. Level3, ein bekannter Tier-One-Carrier in den USA, hat hier einen Spiegel. Dies sind weit verbreitete Tools zur Fehlerbehebung.

Server weiterleiten

Der Begriff "Routenserver" hat sich zu zwei verschiedenen Dingen entwickelt, die beide erklärt werden. Ich definiere hier zwei Route Server "Subtypen", die die Unterscheidung klarer machen sollen. Diese Definitionen sind meine eigenen und werden nur verwendet, um mögliche Verwirrungen zu beseitigen. In der Realität wird der öffentliche Routenserver im Allgemeinen auch als "Routensammler" oder "Route-Views-Server" bezeichnet (letzterer stammt aus dem Route Views-Projekt der Universität von Oregon ).

Öffentlicher Routenserver

Dies sind Systeme (normalerweise Router, aber es gibt einige, die Open-Source-Routing-Daemons ausführen), die öffentlich zugänglich sind, häufig über Telnet, und man kann auch Pings, Traceroutes und "show ip bgp" ausführen (es gibt auch ein paar Juniper routen Sie die Server da draußen, keine Sorge!) Befehle. Der Unterschied zwischen einem öffentlichen Routenserver und einem Spiegel (abgesehen von einem LG mit einem raffinierten CGI) besteht darin, dass eine Vielzahl von Netzwerken (einschließlich einiger Tier-1-Carrier) mit einem Routenserver vergleichbar sind, sodass sich ein "allgemeines" Gesamtbild ergibt Welche Präfixe kommen von welchen Lieferavisen? Die Befehlsautorisierungsrichtlinie variiert von Routenserver zu Routenserver. Hier ist eine Liste von IPv4-Routerservern . Sie haben auch eine separate Seite mit IPv6-Routerservern.Beim Routenserver kann man sich das Spiegelbild als Frontend eines Routenservers vorstellen, unabhängig davon, ob der Routenserver selbst öffentlich oder privat zugänglich ist.

Kannst du nicht ein Spiegelbild auf einem öffentlichen Routenserver laufen lassen?

Sie können es, aber normalerweise können es sich die Leute leisten, auf denen eine Brille läuft, die Server zu betreiben und zu warten, auf denen die Brille läuft. Mit einem öffentlichen Routenserver benötigen Sie lediglich einen Router (oder einen Server, auf dem ein Open Source-Routing-Daemon ausgeführt wird), eine gute AAA-Richtlinie und einige Leute, die bereit sind, Ihnen BGP-Feeds zu geben. Es ist auch wichtig zu beachten, dass einige Netzwerkbetreiber auch öffentlich zugängliche Routenserver hosten, und dass Sie möglicherweise sogar auf einige Betreiber stoßen, die zusätzlich zu einem Spiegel einen Routenserver betreiben.

IXP Route Server

Diese Version des Route Servers ist etwas anders. Bei Shared Peering Fabrics bei IXP ist die Eintrittsbarriere für ein Unternehmen, mit dem Peering zu beginnen, geringer. Sie haben einen einzelnen Port (den der IXP an Sie verkauft), der mit dem IXP-Peering-LAN verbunden ist, und Sie erhalten vom IXP eine IP-Adresse. Jetzt können Sie mit anderen Personen auf dem Stoff spähen. Vergleichen Sie dies mit einer PNI, die eine separate dedizierte physische Verbindung zwischen Ihnen und einer anderen Entität beinhaltet. Bei einer Verbindung zu einem IXP-Peering-LAN müssen Sie, abgesehen von Ihrem einzigen Port als Engpass, eBGP-Sitzungen manuell konfigurieren, mit wem auch immer Sie einen Peer-Vorgang durchführen möchten. Dies nennt man bilaterale Zusammenschaltung- Es gibt eine Sitzung zwischen Ihnen und dem Peer, und nur Sie und der Peer tauschen Ankündigungen aus. Wenn die IXP viele Mitglieder hat, kann dies umständlich werden. In diesem Fall wird in der Regel ein Routenserver am IXP bereitgestellt, um als "One-Stop-Shop" für eine Organisation eine eBGP-Sitzung einzurichten und Präfixe von Personen zu erhalten, die mit dem Routenserver in Verbindung stehen. Dies nennt man multilaterale Zusammenschaltung . Eine BGP-Sitzung zwischen Ihnen und dem Routenserver, und Sie erhalten alle anderen Ankündigungen, die auch mit dem Routenserver identisch sind.

Einige Organisationen verlassen sich auf die Route Server-eBGP-Sitzung (en), während andere diese als Backup für ihre vorhandenen eBGP-Peerings auf der IXP-Fabric verwenden. Die meisten IXPs verfügen über redundante Routenserver und schlagen vor, dass Organisationen mit beiden zusammenarbeiten, wenn sie überhaupt mit den Routenservern zusammenarbeiten.

Was ist mit BGP?

Multilaterales Peering mit Routenservern stellt die BGP vor interessante Herausforderungen. Ein Routenserver selbst ist ein eBGP-Sprecher, es müssen jedoch bestimmte Überlegungen für einen Routenserver und ein multilaterales BGP-Peering getroffen werden. Einige dieser Regeln werden an die Reflexion der iBGP-Route erinnern, und es gibt in der Tat viele Ähnlichkeiten. In jüngster Zeit wurde daran gearbeitet , das Verhalten eines Routenservers in Bezug auf diese spezifischen Funktionen zu standardisieren. Die folgenden Vorsichtsmaßnahmen sind hier erwähnenswert:

NEXT_HOP-Attribut - Dieses Attribut muss unverändert zwischen dem Routenserver und seinen Clients weitergegeben werden. Die Routenserver-Implementierung selbst ändert dieses Attribut zwar nicht, es wird jedoch empfohlen, in eBGP-Sitzungen von Ihrem Router zu einem Routenserver "next-hop-self" festzulegen.
AS_PATH-Attribut - Auch hier darf die Route Server-Implementierung dieses Attribut nicht ändern, da der Route Server transparent sein und nicht an Routingentscheidungen teilnehmen soll. Eine Änderung dieses Attributs kann sich auf den Entscheidungsprozess für den besten Pfad der Route Server-Clients auswirken. Darüber hinaus sendet der Routenserver bei BGP-Aktualisierungen keinen eigenen ASN an seine Clients. Daher muss auf dem Client-Router "no bgp enforce-first-as" (Cisco-spezifisch) festgelegt werden, damit die eBGP-Sitzung ausgeführt werden kann Formular zwischen dem Client und dem Routenserver.
MULTI_EXIT_DISC-Attribut - MED ist ein weiteres Attribut, das an Routing- Server-Clients weitergegeben werden sollte, ohne vom Routing- Server geändert zu werden, da es auch verwendet werden kann, um den Auswahlprozess für den besten Pfad zu beeinflussen.
Communitys-Attribute - Diese sollten vom Routenserver nicht geändert werden, es sei denn, die Community (oder Communitys) sind für die Verarbeitung durch den Routenserver selbst vorgesehen. In der Regel werden Communitys von IXP-Routenserverimplementierungen verwendet, damit die Peers des Routenservers Routingaktualisierungen für andere Routenserver-Peers bearbeiten können.

Bei der Implementierung des IXP-Routenservers müssen zwei Unterschiede beachtet werden:

Der Routenserver nimmt an keinem Routing oder Forwarding teil. Es soll so transparent wie möglich sein.
Routenserver-Clients sind vom Routenserver abhängig, um ihre ausgehende Filterung für sie durchzuführen.

Implementierungsoptionen für IXP Route Server

In der Regel stellen IXP-Betreiber Open-Source-Routing-Dämonen als Routing-Server bereit. Es gibt drei beliebte Optionen:

Quagga, speziell bgpd . Läuft unter Linux und BSD. Es ist schon am längsten und hat wahrscheinlich die meisten Informationen zur Verfügung. Im Laufe der Jahre gab es mehrere Quagga-Gabeln, darunter einen von EuroIX gesponserten Zug , einen von der Open Source Routing Group entwickelten Zug (der mehr auf die Verbesserung der IGP-Funktionalität mit OSPF und ISIS abzielt) und den Quagga-RE (Release) Engineering) Zug, der experimentelle Eigenschaften hat. Google hat auch eine eigene Gabelung von Quagga erstellt. Quagga bgpd unterstützt sowohl IPv6 als auch IPv4. Die meisten IXP-Betreiber (und sogar einige Quagga-Betreuer) raten jedoch davon ab, den Quagga-Hauptzug für den Betrieb eines Routenservers an einem IXP zu verwenden.
VOGEL . Läuft unter Linux und BSD. BIRD hat aufgrund seiner Stabilität und leistungsstarken Filtersprache und -fähigkeiten sowie seines sehr guten Planungssystems einiges an Popularität gewonnen. Es wurden einige Vergleiche und Skalentests zwischen Quagga und BIRD veröffentlicht. Insgesamt ist BIRD tendenziell stabiler und weniger anfällig für CPU- und Speicherabwanderung als Quagga. Sowohl BIRD als auch Quagga sind jedoch Singlethreads, was jedoch beabsichtigt ist. Obwohl BIRD sowohl IPv4 als auch IPv6 unterstützt, sind zwei verschiedene Prozesse (kompilierte Binärdateien) für IPv4 und IPv6 erforderlich.
OpenBGPD . Nur BSD . OpenBGPD ist der einzige verfügbare Open-Source-BGP-Daemon mit mehreren Threads. Es ist bekannt, dass es unter Last ziemlich stabil ist, aber die TCP-MD5-Unterstützung ist etwas schlecht.

Neben Open-Source-Daemons bietet Cisco auch eine Route-Server-Implementierung für IOS-XE an , die auf der ASR-Plattform ausgeführt wird. Zum Zeitpunkt des Schreibens dieses Dokuments bietet Juniper keine Route Server-Implementierung auf seiner Hardware oder seinem Betriebssystem an. Dies kann sich jedoch in Zukunft ändern.

In Bezug auf die Bewertung eines Open-Source-Routing-Daemons in Bezug auf die Speicherbehandlung und -architektur kann man mit Sicherheit davon ausgehen, dass BIRD> OpenBGPD> Quagga, die ASR-Plattform und IOS-XE jedoch im Vergleich zur Open-Source-Plattform auch wesentlich leistungsfähiger sind Optionen für den Quelldämon verfügbar.

Ich hoffe, dass dies etwas Licht auf Routenserver / Spiegel im Allgemeinen wirft.