„Wir haben eine Telefonverbindung zwischen uns und den Jungs von SRI aufgebaut ...“, sagte Kleinrock ... in einem Interview:
„Wir haben das L getippt und am Telefon gefragt: „Sehen Sie das L?“
„Ja, wir sehen das L“, kam die Antwort.
„Wir haben das O getippt und gefragt: „Sehen Sie das O?““
„Ja, wir sehen das O.“
„Dann haben wir das G eingegeben und das System ist abgestürzt“...Doch eine Revolution hatte begonnen ...
Der Beginn des Internets.
Hallo an alle!
Mein Name ist Alexander, ich bin Netzwerktechniker bei Linxdatacenter. Im heutigen Artikel werden wir über Verkehrsaustauschpunkte (Internet Exchange Points, IXP) sprechen: Was ging ihrem Erscheinen voraus, welche Aufgaben lösen sie und wie sind sie aufgebaut? Außerdem werde ich in diesem Artikel das Funktionsprinzip von IXP mit der EVE-NG-Plattform und dem BIRD-Software-Router demonstrieren, damit Sie verstehen, wie es „unter der Haube“ funktioniert.
Ein wenig Geschichte
Wenn du schaust Dann können Sie sehen, dass das rasante Wachstum der Anzahl der Verkehrsknotenpunkte im Jahr 1993 begann. Dies liegt daran, dass der Großteil des Datenverkehrs der damals existierenden Telekommunikationsbetreiber über das US-amerikanische Backbone-Netzwerk lief. Wenn der Verkehr beispielsweise von einem Betreiber in Frankreich zu einem Betreiber in Deutschland ging, ging er zunächst von Frankreich in die USA und dann erst von den USA nach Deutschland. Das Backbone-Netzwerk fungierte in diesem Fall als Transit zwischen Frankreich und Deutschland. Sogar der Verkehr innerhalb eines Landes lief oft nicht direkt, sondern über die Backbone-Netzwerke amerikanischer Betreiber.
Dieser Zustand wirkte sich nicht nur auf die Kosten für die Bereitstellung des Transitverkehrs aus, sondern auch auf die Qualität der Kanäle und Verzögerungen. Die Zahl der Internetnutzer stieg, neue Betreiber erschienen, das Verkehrsaufkommen nahm zu und das Internet entwickelte sich weiter. Betreiber auf der ganzen Welt begannen zu erkennen, dass ein rationalerer Ansatz zur Organisation der Interaktion zwischen Betreibern erforderlich war. „Warum sollte ich, Betreiber A, für den Transit durch ein anderes Land bezahlen, um den Verkehr an Betreiber B weiterzuleiten, der sich in der nächsten Straße befindet?“ Das ist in etwa die Frage, die sich die Telekommunikationsbetreiber damals stellten. So entstanden in verschiedenen Teilen der Welt Verkehrsknotenpunkte an Betreiberkonzentrationspunkten:
- 1994 – LINX in London,
- 1995 – DE-CIX in Frankfurt,
- 1995 – MSK-IX, in Moskau usw.
Internet und unsere Tage
Konzeptionell besteht die Architektur des modernen Internets aus vielen autonomen Systemen (AS) und vielen physischen und logischen Verbindungen zwischen ihnen, die den Weg des Datenverkehrs von einem AS zum anderen bestimmen.
ASs sind in der Regel Telekommunikationsbetreiber, Internetanbieter, CDNs, Rechenzentren und Unternehmen im Unternehmenssegment. ASes organisieren logische Verbindungen (Peering) untereinander, meist über das BGP-Protokoll.
Wie autonome Systeme diese Verbindungen organisieren, wird von einer Reihe von Faktoren bestimmt:
- geographisch,
- wirtschaftlich,
- politisch,
- Vereinbarungen und gemeinsame Interessen zwischen AS-Eigentümern,
- usw.
Natürlich hat dieses Schema eine bestimmte Struktur und Hierarchie. So werden Betreiber in Tier-1, Tier-2 und Tier-3 unterteilt, und wenn die Kunden eines lokalen Internetanbieters (Tier-3) in der Regel normale Benutzer sind, dann beispielsweise für Tier-1 Level-Operatoren sind die Clients andere Operatoren. Tier-3-Betreiber aggregieren den Datenverkehr ihrer Abonnenten, Tier-2-Telekommunikationsbetreiber wiederum aggregieren den Datenverkehr von Tier-3-Betreibern und Tier-1 – den gesamten Internetverkehr.
Schematisch lässt es sich so darstellen:
Dieses Bild zeigt, dass der Verkehr von unten nach oben aggregiert wird, d. h. vom Endbenutzer bis zum Tier-1-Betreiber. Es gibt auch einen horizontalen Verkehrsaustausch zwischen ASs, die einander annähernd gleichwertig sind.
Ein wesentlicher Bestandteil und gleichzeitig ein Nachteil dieses Schemas ist eine gewisse Verwirrung der Verbindungen zwischen autonomen Systemen, die sich näher am Endbenutzer innerhalb eines geografischen Gebiets befinden. Betrachten Sie das Bild unten:
Nehmen wir an, dass es in einer Großstadt fünf Telekommunikationsbetreiber gibt, deren Peering aus dem einen oder anderen Grund wie oben gezeigt organisiert ist.
Wenn der Benutzer Petya, der mit dem Go-ISP verbunden ist, auf einen Server zugreifen möchte, der mit dem ASM-Anbieter verbunden ist, wird der Datenverkehr zwischen ihnen gezwungen, 5 autonome Systeme zu passieren. Dies erhöht die Verzögerung, weil Die Anzahl der Netzwerkgeräte, über die der Datenverkehr geleitet wird, nimmt zu, ebenso wie das Volumen des Transitdatenverkehrs auf autonomen Systemen zwischen Go und ASM.
Wie lässt sich die Anzahl der Transit-ASs reduzieren, die der Verkehr passieren muss? Das ist richtig – Verkehrsknotenpunkt.
Heutzutage wird die Entstehung neuer IXPs durch die gleichen Bedürfnisse vorangetrieben wie in den frühen 90er- und 2000er-Jahren, nur in kleinerem Maßstab, als Reaktion auf die steigende Zahl von Telekommunikationsbetreibern, Nutzern und Datenverkehr sowie die wachsende Menge an Inhalten, die von CDN-Netzwerken generiert werden und Rechenzentren.
Was ist ein Wechselpunkt?
Ein Verkehrsaustauschpunkt ist ein Ort mit einer speziellen Netzwerkinfrastruktur, an dem Teilnehmer, die am gegenseitigen Verkehrsaustausch interessiert sind, gegenseitiges Peering organisieren. Die Hauptteilnehmer von Verkehrsaustauschpunkten: Telekommunikationsbetreiber, Internetanbieter, Inhaltsanbieter und Rechenzentren. An Verkehrsknotenpunkten verbinden sich die Teilnehmer direkt miteinander. Dadurch können Sie folgende Probleme lösen:
- Latenz reduzieren,
- den Transitverkehr reduzieren,
- Optimieren Sie das Routing zwischen AS.
Wenn man bedenkt, dass IXPs in vielen Großstädten auf der ganzen Welt präsent sind, wirkt sich dies alles positiv auf das Internet insgesamt aus.
Wenn die obige Situation mit Petya mithilfe von IXP gelöst wird, wird es in etwa so aussehen:
Wie funktioniert ein Verkehrsknotenpunkt?
In der Regel handelt es sich bei einem IXP um einen separaten AS mit einem eigenen Block öffentlicher IPv4/IPv6-Adressen.
Das IXP-Netzwerk besteht meist aus einer kontinuierlichen L2-Domäne. Manchmal ist dies einfach ein VLAN, das alle IXP-Clients hostet. Bei größeren, geografisch verteilten IXPs können Technologien wie MPLS, VXLAN usw. zur Organisation einer L2-Domäne genutzt werden.
IXP-Elemente
- SKS. Hier gibt es nichts Ungewöhnliches: Racks, optische Cross-Connects, Patchpanels.
- Schalter – die Basis von IXP. Der Switch-Port ist der Einstiegspunkt in das IXP-Netzwerk. Die Switches übernehmen auch einen Teil der Sicherheitsfunktionen – sie filtern Junk-Verkehr, der nicht im IXP-Netzwerk vorhanden sein sollte. In der Regel werden Switches nach funktionalen Anforderungen ausgewählt – Zuverlässigkeit, unterstützte Portgeschwindigkeiten, Sicherheitsfunktionen, sFlow-Unterstützung usw.
- Routenserver (RS) – ein integraler und notwendiger Bestandteil jedes modernen Verkehrsknotenpunktes. Das Funktionsprinzip ist dem Route Reflector in iBGP oder dem Designated Router in OSPF sehr ähnlich und löst die gleichen Probleme. Wenn die Anzahl der Teilnehmer an einem Verkehrsaustauschpunkt wächst, steigt die Anzahl der BGP-Sitzungen, die jeder Teilnehmer unterstützen muss, d. h. Dies erinnert an die klassische Full-Mesh-Topologie in iBGP. RS löst das Problem auf folgende Weise: Es baut eine BGP-Sitzung mit jedem interessierten IXP-Teilnehmer auf und dieser Teilnehmer wird zum RS-Client. Wenn RS ein BGP-Update von einem seiner Clients erhält, sendet es dieses Update natürlich an alle anderen Clients, mit Ausnahme desjenigen, von dem dieses Update empfangen wurde. Somit entfällt durch RS die Notwendigkeit, ein vollständiges Netz zwischen allen IXP-Mitgliedern einzurichten, und das Skalierbarkeitsproblem wird elegant gelöst. Es ist erwähnenswert, dass der Routenserver Routen transparent von einem AS zu einem anderen überträgt, ohne Änderungen an den von BGP übertragenen Attributen vorzunehmen, z. B. fügt er die Nummer in seinem AS nicht zum AS-Pfad hinzu. Auch auf RS gibt es eine grundlegende Filterung von Routen: RS akzeptiert beispielsweise keine Mars-Netzwerke und die Präfixe des IXP selbst.
Als Route-Server-Lösung wird häufig ein Open-Source-Software-Router, BIRD (Bird Internet Routing Daemon), verwendet. Das Gute daran ist, dass es kostenlos ist, sich schnell auf den meisten Linux-Distributionen bereitstellen lässt, über einen flexiblen Mechanismus zum Einrichten von Routing-/Filterrichtlinien verfügt und keine Rechenressourcen beansprucht. Als RS kann auch ein Hardware-/Virtual-Router von Cisco, Juniper etc. ausgewählt werden.
- Sicherheit. Da es sich bei einem IXP-Netzwerk um eine Konzentration einer großen Anzahl von ASes handelt, muss die Sicherheitsrichtlinie, die alle Teilnehmer befolgen müssen, gut geschrieben sein. Im Allgemeinen gelten hier alle gleichen Mechanismen, die beim Einrichten einer BGP-Adjazenz zwischen zwei separaten BGP-Peers außerhalb eines IXP gelten, plus einige zusätzliche Sicherheitsfunktionen.
Beispielsweise empfiehlt es sich, Datenverkehr nur von einer bestimmten Mac-Adresse des IXP-Teilnehmers zuzulassen, die im Voraus ausgehandelt wird. Verweigern von Datenverkehr mit anderen Ethertype-Feldern als 0x0800(IPv4), 0x08dd(IPv6), 0x0806(ARP); Dies geschieht, um Datenverkehr herauszufiltern, der nicht zum BGP-Peering gehört. Es können auch Mechanismen wie GTSM, RPKI usw. verwendet werden.
Vielleicht sind die oben genannten die Hauptkomponenten eines jeden IXP, unabhängig von der Größe. Natürlich verfügen größere IXPs möglicherweise über zusätzliche Technologien und Lösungen.
Es kommt vor, dass IXP seinen Teilnehmern auch zusätzliche Dienstleistungen zur Verfügung stellt:
- auf dem IXP TLD DNS-Server platziert,
- Installieren Sie Hardware-NTP-Server, damit die Teilnehmer ihre Zeit genau synchronisieren können.
- bieten Schutz vor DDoS-Angriffen usw.
Arbeitsprinzip
Schauen wir uns das Funktionsprinzip eines Verkehrsaustauschpunkts am Beispiel eines einfachen IXP an, modelliert mit EVE-NG, und betrachten wir dann den Grundaufbau eines BIRD-Software-Routers. Um das Diagramm zu vereinfachen, lassen wir so wichtige Dinge wie Redundanz und Fehlertoleranz weg.
Die Netzwerktopologie ist in der folgenden Abbildung dargestellt.
Nehmen wir an, dass wir einen kleinen Austauschpunkt verwalten und die folgenden Peering-Optionen bereitstellen:
- öffentliches Peering,
- privates Peering,
- Peering über Routenserver.
Unsere AS-Nummer ist 555, wir besitzen einen Block von IPv4-Adressen – 50.50.50.0/24, von dem wir IP-Adressen für diejenigen vergeben, die sich mit unserem Netzwerk verbinden möchten.
50.50.50.254 – IP-Adresse, die auf der Route-Server-Schnittstelle konfiguriert ist. Mit dieser IP-Adresse richten Clients bei Peering über RS eine BGP-Sitzung ein.
Außerdem haben wir für das Peering über RS eine einfache Routing-Richtlinie auf Basis der BGP-Community entwickelt, die es IXP-Teilnehmern ermöglicht, zu regulieren, an wen und welche Routen gesendet werden sollen:
BGP-Community
Beschreibung
LOCAL_AS:PEER_AS
Präfixe nur an PEER_AS senden
LOCAL_AS:IXP_AS
Präfixe an alle IXP-Teilnehmer übertragen
3 Kunden möchten sich mit unserem IXP verbinden und Datenverkehr austauschen; Nehmen wir an, das sind Internetanbieter. Sie alle möchten das Peering über einen Routenserver organisieren. Unten finden Sie ein Diagramm mit Client-Verbindungsparametern:
Auftraggeber
Kunden-AS-Nummer
Vom Client angekündigte Präfixe
IP-Adresse, die dem Client zur Verbindung mit dem IXP zugewiesen wird
ISP Nr. 1
AS100
1.1.0.0/16
50.50.50.10/24
ISP Nr. 2
AS200
2.2.0.0/16
50.50.50.20/24
ISP Nr. 3
AS300
3.3.0.0/16
50.50.50.30/24
Grundlegende BGP-Einrichtung auf dem Client-Router:
router bgp 100
no bgp enforce-first-as
bgp log-neighbor-changes
neighbor 50.50.50.254 remote-as 555
address-family ipv4
network 1.1.0.0 mask 255.255.0.0
neighbor 50.50.50.254 activate
neighbor 50.50.50.254 send-community both
neighbor 50.50.50.254 soft-reconfiguration inbound
neighbor 50.50.50.254 route-map ixp-out out
exit-address-family
ip prefix-list as100-prefixes seq 5 permit 1.1.0.0/16
route-map bgp-out permit 10
match ip address prefix-list as100-prefixes
set community 555:555
Erwähnenswert ist hier die Einstellung „Kein BGP erzwingen zuerst“. Standardmäßig erfordert BGP, dass der As-Pfad eines empfangenen BGP-Updates die As-BGP-Nummer des Peers enthält, von dem das Update empfangen wurde. Da der Routenserver jedoch keine Änderungen am As-Pfad vornimmt, befindet sich seine Nummer nicht im As-Pfad und die Aktualisierung wird verworfen. Diese Einstellung wird verwendet, um den Router dazu zu bringen, diese Regel zu ignorieren.
Wir sehen auch, dass der Client die BGP-Community 555:555 auf dieses Präfix gesetzt hat, was gemäß unserer Richtlinie bedeutet, dass der Client dieses Präfix allen anderen Teilnehmern bekannt geben möchte.
Für die Router anderer Clients sind die Einstellungen ähnlich, mit Ausnahme ihrer eindeutigen Parameter.
Beispielhafte BIRD-Konfiguration:
define ixp_as = 555;
define ixp_prefixes = [ 50.50.50.0/24+ ];
template bgp RS_CLIENT {
local as ixp_as;
rs client;
}
Im Folgenden wird ein Filter beschrieben, der weder Martians-Präfixe noch die Präfixe des IXP selbst akzeptiert:
function catch_martians_and_ixp()
prefix set martians;
prefix set ixp_prefixes;
{
martians = [
0.0.0.0/8+,
10.0.0.0/8+,
100.64.0.0/10+,
127.0.0.0/8+,
169.254.0.0/16+,
172.16.0.0/12+,
192.0.0.0/24+,
192.0.2.0/24+,
192.168.0.0/16+,
198.18.0.0/15+,
198.51.100.0/24+,
203.0.113.0/24+,
224.0.0.0/4+,
240.0.0.0/4+ ];
if net ~ martians || net ~ ixp_prefixes then return false;
return true;
}
Diese Funktion implementiert die Routing-Richtlinie, die wir zuvor beschrieben haben.
function bgp_ixp_policy(int peer_as)
{
if (ixp_as, ixp_as) ~ bgp_community then return true;
if (ixp_as, peer_as) ~ bgp_community then return true;
return false;
}
filter reject_martians_and_ixp
{
if catch_martians_and_ixp() then reject;
if ( net ~ [0.0.0.0/0{25,32} ] ) then {
reject;
}
accept;
}
Wir konfigurieren Peering, wenden entsprechende Filter und Richtlinien an.
protocol as_100 from RS_CLIENT {
neighbor 50.50.50.10 as 100;
ipv4 {
export where bgp_ixp_policy(100);
import filter reject_martians_and_ixp;
}
}
protocol as_200 from RS_CLIENT {
neighbor 50.50.50.20 as 200;
ipv4 {
export where bgp_ixp_policy(200);
import filter reject_martians_and_ixp;
}
}
protocol as_300 from RS_CLIENT {
neighbor 50.50.50.30 as 300;
ipv4 {
export where bgp_ixp_policy(300);
import filter reject_martians_and_ixp;
}
}
Es ist erwähnenswert, dass es auf einem Routenserver eine gute Praxis ist, Routen von verschiedenen Peers in verschiedene RIBs zu legen. BIRD ermöglicht Ihnen dies. In unserem Beispiel werden der Einfachheit halber alle von allen Clients empfangenen Aktualisierungen in einer gemeinsamen RIB zusammengefasst.
Schauen wir uns also an, was wir haben.
Auf dem Routenserver sehen wir, dass mit allen drei Clients eine BGP-Sitzung aufgebaut wurde:
Wir sehen, dass wir von allen Clients Präfixe erhalten:
Auf dem Router as 100 sehen wir, dass wir bei nur einer BGP-Sitzung mit dem Route-Server Präfixe sowohl von as 200 als auch von 300 erhalten, während sich die BGP-Attribute nicht geändert haben, als ob das Peering zwischen Clients direkt durchgeführt würde:
Wir sehen also, dass das Vorhandensein eines Route-Servers die Organisation des Peerings auf dem IXP erheblich vereinfacht.
Ich hoffe, dass diese Demonstration Ihnen geholfen hat, besser zu verstehen, wie IXPs funktionieren und wie der Routenserver auf einem IXP funktioniert.
Linxdatacenter IX
Bei Linxdatacenter haben wir unser eigenes IXP basierend auf einer fehlertoleranten Infrastruktur aus 2 Switches und 2 Route-Servern aufgebaut. Unser IXP läuft jetzt im Testmodus und wir laden alle ein, sich mit Linxdatacenter IX zu verbinden und an den Tests teilzunehmen. Wenn Sie verbunden sind, erhalten Sie einen Port mit einer Bandbreite von 1 Gbit/s, die Möglichkeit, über unsere Routenserver zu peeren, sowie Zugriff auf Ihr persönliches Konto des IX-Portals, verfügbar unter .
Schreiben Sie Kommentare oder private Nachrichten, um Zugang zum Testen zu erhalten.
Abschluss
Verkehrsaustauschpunkte entstanden zu Beginn des Internets als Instrument zur Lösung des Problems des suboptimalen Verkehrsflusses zwischen Telekommunikationsbetreibern. Mit dem Aufkommen neuer globaler Dienste und einem Anstieg des CDN-Verkehrs optimieren Exchange Points nun weiterhin den Betrieb des globalen Netzwerks. Der Anstieg der Zahl der IXPs weltweit kommt sowohl dem Endnutzer des Dienstes als auch Telekommunikationsbetreibern, Content-Betreibern usw. zugute. Für IXP-Teilnehmer besteht der Vorteil darin, die Kosten für die Organisation von externem Peering zu senken, die Menge an Datenverkehr zu reduzieren, für die höherrangige Betreiber zahlen müssen, das Routing zu optimieren und eine direkte Schnittstelle zu Inhaltsbetreibern zu haben.
Nützliche Links
- Sehen Sie sich eine Karte mit den Standorten der Verkehrsknotenpunkte an:
- Sehen Sie sich detaillierte Statistiken zum BGP-Peering an, einschließlich der Präsenz auf IXP:
Source: habr.com