Der Austauschpunkt für den Datenverkehr: Von den Anfängen zur Gründung eines eigenen IX

„Wir haben eine Telefonverbindung zwischen uns und den Jungs von SRI hergestellt…“, sagte Kleinrock in einem Interview:
„Wir haben das L eingegeben und am Telefon gefragt: ‚Sehen Sie das L?‘“
„Ja, wir sehen das L“, kam die Antwort.
„Wir haben das O eingegeben 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 zusammen!

Mein Name ist Alexander, ich bin Netzwerkingenieur bei Linxdatacenter. In diesem Artikel geht es um Punkte für den Austausch von Datenverkehr (Internet Exchange Point, IXP): Was ihrer Entstehung vorausging, welche Aufgaben sie erfüllen und wie sie aufgebaut sind. Außerdem werde ich in diesem Artikel das Prinzip der Funktionsweise von IXPs anhand der Plattform EVE-NG und des Software-Routers BIRD demonstrieren, um ein Verständnis dafür zu schaffen, wie es 'unter der Haube' funktioniert.

Ein wenig Geschichte

Wenn man sich das ansieht hier, kann man feststellen, dass das explosive Wachstum der Anzahl von Austauschpunkten für Datenverkehr im Jahr 1993 begann. Dies hängt damit zusammen, dass der Großteil des Datenverkehrs der zu diesem Zeitpunkt bestehenden Telekommunikationsbetreiber über das Backbone-Netz der USA lief. Beispielsweise lief der Datenverkehr von einem Betreiber in Frankreich zu einem Betreiber in Deutschland zuerst in die USA, und erst dann von dort nach Deutschland. Das Backbone-Netz fungierte in diesem Fall als Transit zwischen Frankreich und Deutschland. Sogar der Datenverkehr innerhalb eines Landes verlief oft nicht direkt, sondern über die Backbone-Netze amerikanischer Betreiber.

Diese Situation wirkte sich nicht nur auf die Kosten für die Lieferung von Transitdatenverkehr aus, sondern auch auf die Qualität der Verbindungen und die Latenz. Die Anzahl der Internetnutzer nahm zu, neue Betreiber traten auf, das Datenvolumen wuchs, das Internet entwickelte sich weiter. Betreiber weltweit begannen zu erkennen, dass ein rationalerer Ansatz für die Organisation der Zusammenarbeit zwischen den Betreibern erforderlich war. „Warum sollte ich, Betreiber A, für den Transit über ein anderes Land zahlen, um Datenverkehr an Betreiber B zu liefern, der sich um die Ecke befindet?“. Solche Fragen stellten sich die Telekommunikationsbetreiber zu dieser Zeit. So begannen in verschiedenen Teilen der Welt an den Konzentrationspunkten der Betreiber Austauschpunkte für Datenverkehr zu entstehen:

• 1994 – LINX in London,
• 1995 – DE-CIX in Frankfurt,
• 1995 – MSK-IX in Moskau usw.

Das Internet und unsere Tage

Konzeptionell stellt die Architektur des modernen Internets eine Vielzahl autonomer Systeme (autonomous system, AS) und eine Vielzahl von Verbindungen zwischen ihnen dar, sowohl physischer als auch logischer Natur, die den Weg des Datenverkehrs von einem AS zum anderen bestimmen.

In der Regel fungieren Kommunikationsanbieter, Internetdienstanbieter, CDN, Rechenzentren und Unternehmen des Unternehmenssegments als AS. AS organisieren logische Verbindungen (Peering) miteinander, häufig unter Verwendung des BGP-Protokolls.

Wie autonome Systeme diese Verbindungen organisieren, wird durch eine Reihe von Faktoren bestimmt:

• geografische,
• ökonomische,
• politische,
• Vereinbarungen und gemeinsame Interessen zwischen den Besitzern von AS,
• usw.

Natürlich gibt es in diesem Schema eine bestimmte Struktur und Hierarchie. So werden Betreiber in tier-1, tier-2 und tier-3 unterteilt; während die Kunden für lokale Internetanbieter (tier-3) in der Regel Endbenutzer sind, sind die Kunden für tier-1-Anbieter beispielsweise andere Anbieter. Tier-3-Anbieter aggregieren den Datenverkehr ihrer Abonnenten, während tier-2-Anbieter den Datenverkehr von tier-3-Anbietern aggregieren, und tier-1 aggregiert den gesamten Internetverkehr.

Schematisch kann man es so darstellen:

Auf dem Bild ist zu sehen, dass der Datenverkehr von unten nach oben aggregiert wird, d.h. von den Endbenutzern zu den tier-1-Anbietern. Es gibt auch einen horizontalen Austausch von Datenverkehr zwischen annähernd gleichwertigen AS.

Ein unerlässlicher Teil und gleichzeitig ein Nachteil dieses Schemas ist eine gewisse Unordnung in den Verbindungen zwischen den autonomen Systemen, die näher am Endbenutzer liegen, innerhalb geografischer Zonen. Betrachten wir das Bild unten:

Angenommen, in einer großen Stadt gibt es 5 Kommunikationsanbieter, deren Peering aus bestimmten Gründen wie oben gezeigt organisiert ist.

Wenn der Benutzer Petya, der mit dem Internetanbieter Go verbunden ist, auf einen Server zugreifen möchte, der mit dem Anbieter ASM verbunden ist, muss der Datenverkehr zwischen ihnen durch 5 autonome Systeme geleitet werden. Dadurch erhöht sich die Latenz, da sich die Anzahl der Netzwerkgeräte, durch die der Datenverkehr fließt, erhöht, sowie das Volumen des Transitverkehrs zwischen Go und ASM.

Wie kann man die Anzahl der Transit-AS, die der Verkehr durchlaufen muss, reduzieren? Richtig – durch einen Internet Exchange Point.

Heutzutage werden neue IXPs durch dieselben Bedürfnisse angetrieben wie in den frühen 90ern bis 2000er Jahren, jedoch im kleineren Maßstab, als Antwort auf die wachsende Anzahl von Telekommunikationsanbietern, Nutzern und Verkehr sowie die zunehmende Menge an Inhalten, die von CDN-Netzen und Rechenzentren generiert werden.

Was ist ein Internet Exchange Point?

Ein Internet Exchange Point ist ein Ort mit einer speziellen Netzwerkinfrastruktur, an dem Teilnehmer, die an gegenseitigem Verkehrsausgleich interessiert sind, gegenseitiges Peering organisieren. Die Hauptteilnehmer an Internet Exchange Points sind Telekommunikationsanbieter, Internetdienstanbieter, Content-Anbieter und Rechenzentren. An Internet Exchange Points verbinden sich die Teilnehmer direkt miteinander. Dies ermöglicht die Lösung folgender Aufgaben:

• die Latenz zu verringern,
• die Menge des Transitverkehrs zu reduzieren,
• die Routenoptimierung zwischen den AS zu verbessern.

Da IXPs in vielen großen Städten der Welt vorhanden sind, wirkt sich dies insgesamt positiv auf das Internet aus.

Wenn man die oben beschriebene Situation mit Petja mithilfe eines IXPs löst, sieht das ungefähr so aus:

Wie funktioniert ein Internet Exchange Point?

In der Regel ist ein IXP ein separates AS mit einem eigenen Block öffentlicher IPv4/IPv6-Adressen.

Das Netzwerk eines IXPs ist meist ein durchgehendes L2-Domain. Manchmal handelt es sich einfach um ein VLAN, in dem alle Kunden des IXPs untergebracht sind. Bei größeren, geografisch verteilten IXPs können Technologien wie MPLS, VXLAN usw. zur Organisation einer L2-Domain verwendet werden.

Elemente eines IXPs

• SKS. Hier ist nichts Ungewöhnliches: Racks, optische Kreuzstellen, Patch-Panels.
• Switches sind das Herzstück eines IXPs. Der Port eines Switches ist der Zugangspunkt zum Netzwerk des IXPs. Außerdem übernehmen Switches einen Teil der Sicherheitsfunktionen – sie filtern den Müllverkehr, der im Netzwerk des IXPs nicht vorhanden sein sollte. In der Regel werden Switches nach den Anforderungen an die Funktionalität ausgewählt – Zuverlässigkeit, unterstützte Portgeschwindigkeit, Sicherheitsfunktionen, Unterstützung für sFlow usw.
• Route Server (RS) ist ein unverzichtbarer und notwendiger Bestandteil jeder modernen Verkehrs-Austauschstelle. In seiner Funktionsweise ähnelt er stark einem Route-Reflektor in iBGP oder einem designated router in OSPF und löst dieselben Probleme. Mit zunehmender Teilnehmerzahl an der Verkehrs-Austauschstelle steigt die Anzahl der zu unterstützenden BGP-Sitzungen für jeden Teilnehmer, was der klassischen Full-Mesh-Topologie in iBGP ähnelt. Der RS löst das Problem folgendermassen: Er installiert eine BGP-Sitzung mit jedem interessierten Teilnehmer der IXP, der dann zum Kunden des RS wird. Nachdem der RS ein BGP-Update von einem seiner Kunden erhalten hat, verteilt er dieses Update an alle anderen Kunden, mit Ausnahme desjenigen, von dem das Update empfangen wurde. Auf diese Weise befreit der RS von der Notwendigkeit, ein Full-Mesh zwischen allen Teilnehmern der IXP zu installieren und löst elegant das Skalierbarkeitsproblem. Es ist erwähnenswert, dass der Routenserver Routen von einem AS zu einem anderen transparent überträgt, ohne Änderungen an den übermittelten BGP-Attributen vorzunehmen, zum Beispiel wird die AS-Nummer nicht zum AS-Pfad hinzugefügt. Auch findet beim RS eine grundlegende Filterung von Routen statt: Zum Beispiel akzeptiert der RS keine Martian-Netzwerke und die Präfixe der IXP selbst.

  Als Lösung wird häufig ein softwarebasierter Router mit Open-Source-Code – BIRD (bird internet routing daemon) – verwendet. Er hat den Vorteil, dass er kostenlos, schnell auf den meisten Linux-Distributionen einsatzbereit und mit einem flexiblen Mechanismus zur Konfiguration von Routing-/Filterrichtlinien ausgestattet ist und dabei wenig Rechenressourcen benötigt. Alternativ kann auch ein Hardware-/virtueller Router von Cisco, Juniper usw. als RS ausgewählt werden.

• Sicherheit. Da das IXP-Netzwerk eine Konzentration vieler AS darstellt, sollte die Sicherheitsrichtlinie, der alle Teilnehmer folgen müssen, gut definiert sein. In der Regel kommen dieselben Mechanismen, die bei der Herstellung von BGP-Nachbarschaften zwischen zwei einzelnen BGP-Peers außerhalb des IXP angewendet werden, auch hier zum Einsatz, zusätzlich werden einige weitere Schutzmaßnahmen verwendet.

  Zum Beispiel ist es eine gute Praxis, den Verkehr nur von einer bestimmten MAC-Adresse eines IXP-Teilnehmers zuzulassen, die im Voraus vereinbart wird. Der Verkehr mit Ethertype-Feldern, die sich von 0x0800 (IPv4), 0x08dd (IPv6), 0x0806 (ARP) unterscheiden, wird blockiert; dies geschieht, um den Verkehr herauszufiltern, für den bei BGP-Peering kein Platz ist. Es können auch Mechanismen wie GTSM, RPKI usw. angewendet werden.

Nun, das oben Genannte sind die grundlegendsten Bestandteile eines jeden IXP, unabhängig von seiner Größe. Natürlich können große IXPs zusätzliche Technologien und Lösungen verwenden.
Es kommt vor, dass IXPs ihren Teilnehmern zusätzliche Dienste anbieten:

• DNS-Server für TLDs auf dem IXP hosten,
• Hardware-NTP-Server installieren, um den Teilnehmern die genaue Zeit-Synchronisation zu ermöglichen,
• Schutz vor DDoS-Angriffen anbieten usw.

Funktionsweise

Lassen Sie uns den Arbeitsprinzip einer Traffic-Exchange-Point am Beispiel eines einfachsten IXPs betrachten, das mit EVE-NG simuliert wurde, und danach die grundlegende Konfiguration des Software-Routers BIRD untersuchen. Um das Schema zu vereinfachen, lassen wir so wichtige Dinge wie Redundanz und Fehlertoleranz weg.

Die Topologie des Netzwerks ist in der folgenden Abbildung dargestellt.

Angenommen, wir verwalten einen kleinen Traffic-Exchange-Point und bieten folgende Peering-Varianten an:

• öffentliches Peering,
• privates Peering,
• Peering über einen Route-Server.

Unsere AS-Nummer ist 555, wir besitzen einen Block von IPv4-Adressen – 50.50.50.0/24, aus dem wir IP-Adressen für Interessierte vergeben, die sich mit unserem Netzwerk verbinden möchten.

50.50.50.254 ist die IP-Adresse, die auf die Schnittstelle des Route-Servers eingestellt ist; mit dieser IP werden die Kunden eine BGP-Sitzung im Falle des Peerings über RS aufbauen.

Für das Peering über RS haben wir auch eine einfache Routing-Politik auf der Grundlage von BGP-Communities entwickelt, die es den IXP-Teilnehmern ermöglicht, zu steuern, an wen und welche Routen gesendet werden:

BGP-Community
Beschreibung

LOCAL_AS:PEER_AS
Nur die Präfixe an PEER_AS übermitteln

LOCAL_AS:IXP_AS
Alle Präfixe an die IXP-Teilnehmer übermitteln

Drei Kunden möchten sich mit unserem IXP verbinden und den Verkehr austauschen; nehmen wir an, dies sind Internetanbieter. Alle möchten das Peering über den Route-Server organisieren. Im Folgenden wird eine Abbildung mit den Verbindungsparametern der Kunden präsentiert:

den Kunden zurückzuführen sind, nicht verfügbar ist.
AS-Nummer des Kunden
Von dem Kunden angekündigte Präfixe
IP-Adresse, die dem Kunden für die Verbindung mit dem IXP zugewiesen wurde

ISP #1
AS 100
1.1.0.0/16
50.50.50.10/24

ISP #2
AS 200
2.2.0.0/16
50.50.50.20/24

ISP #3
AS 300
3.3.0.0/16
50.50.50.30/24

Grundkonfiguration von BGP auf dem Router des Kunden:

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

Hier ist es wichtig, die Einstellung no bgp enforce-first-as zu beachten. Standardmäßig verlangt BGP, dass die AS-Nummer des BGP-Peers, von dem das Update empfangen wurde, im AS-Pfad des empfangenen BGP-Updates vorhanden ist. Da der Routenserver jedoch keine Änderungen am AS-Pfad vornimmt, wird seine Nummer im AS-Pfad fehlen, und das Update wird verworfen. Diese Einstellung wird angewendet, damit der Router diese Regel ignoriert.

Wir sehen auch, dass der Kunde die BGP-Community 555:555 für dieses Präfix eingerichtet hat, was gemäß unserer Richtlinie bedeutet, dass der Kunde dieses Präfix an alle anderen Teilnehmer ankündigen möchte.

Für die Router der anderen Kunden wird die Konfiguration ähnlich sein, abgesehen von ihren einzigartigen Parametern.

Beispielkonfiguration BIRD:

define ixp_as = 555;
define ixp_prefixes = [ 50.50.50.0/24+ ];

template bgp RS_CLIENT {
  local as ixp_as;
  rs client;
}

Hier wird ein Filter beschrieben, der Martian-Präfixe und die Präfixe selbst der IXP nicht 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-Politik, 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 das Peering und wenden die entsprechenden 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 wichtig zu beachten, dass es auf dem Routenserver gute Sitte ist, die Routen von verschiedenen Peers in unterschiedliche RIBs zu legen. BIRD ermöglicht dies. In unserem Beispiel werden zur Vereinfachung alle Updates, die von allen Kunden empfangen werden, in eine allgemeine RIB eingelegt.

Also, überprüfen wir, was wir erreicht haben.

Auf dem Route-Server sehen wir, dass mit allen drei Clients eine BGP-Sitzung eingerichtet ist:

Wir sehen, dass wir Präfixe von allen Clients erhalten:

Auf dem Router AS 100 sehen wir, dass wir bei nur einer BGP-Sitzung mit dem Routen-Server sowohl Präfixe von AS 200 als auch von AS 300 erhalten, dabei haben sich die BGP-Attribute nicht geändert, als ob das Peering zwischen den Clients direkt erfolgen würde:

Somit sehen wir, dass das Vorhandensein eines Routen-Servers das Peering am IXP erheblich vereinfacht.

Ich hoffe, diese Demonstration hat Ihnen geholfen, besser zu verstehen, wie die Internet-Austauschpunkte funktionieren und wie der Routen-Server am IXP implementiert ist.

Linxdatacenter IX

Im Linxdatacenter haben wir unseren eigenen IXP auf der Grundlage einer ausfallsicheren Infrastruktur aus 2 Switches und 2 Routen-Servern aufgebaut. Unser IXP ist derzeit im Testbetrieb und wir laden alle Interessierten ein, sich mit Linxdatacenter IX zu verbinden und am Test teilzunehmen. Bei der Verbindung erhalten Sie einen Port mit einer Bandbreite von 1 Gbit/s, die Möglichkeit des Peerings über unsere Routen-Server sowie Zugang zu Ihrem persönlichen IX-Portal, erreichbar unter ix.linxdatacenter.com.

Schreiben Sie in die Kommentare oder persönlichen Nachrichten, um Zugang zu den Tests zu erhalten.

Ausgabe

Die Internet-Austauschpunkte entstanden zu Beginn des Internets als Instrument zur Lösung des Problems des suboptimalen Datenverkehrs zwischen Telekommunikationsanbietern. Mit dem Aufkommen neuer globaler Dienste und der Zunahme von CDN-Verkehr optimieren die Austauschpunkte weiterhin die Funktionsweise des globalen Netzwerks. Die Zunahme der IXPs weltweit kommt sowohl den Endnutzern der Dienste als auch den Telekommunikationsanbietern, Content-Anbietern usw. zugute. Für die Teilnehmer an IXPs äußert sich der Vorteil in der Reduzierung der Kosten für die Organisation externer Peering-Verbindungen, der Verringerung des Verkehrsvolumens, für das an übergeordnete Anbieter gezahlt werden muss, der Optimierung der Routenführung und der Möglichkeit, einen direkten Anschluss an Content-Anbieter zu haben.

Nützliche Links

• Karte der Standorte der Internet-Austauschpunkte ansehen: www.internetexchangemap.com
• Detaillierte Statistiken zum BGP-Peering, einschließlich der Präsenz an IXPs, einsehen: www.peeringdb.com

Quelle: habr.com