Traffic Exchange Point: von den Anfängen bis zur Erstellung eines eigenen IX

«Wir haben eine Telefonverbindung zwischen uns und den Kollegen bei SRI hergestellt…», sagte Kleinrock in einem Interview:
«Wir tippten das L und fragten am Telefon: ‚Seht ihr das L?‘»
«Ja, wir sehen das L,» kam die Antwort.
«Wir tippten das O und fragten: ‚Seht ihr das O?‘»
«Ja, wir sehen das O.»
«Dann tippten wir das G, und das System stürzte ab»…

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 Internet Exchange Points (IXP): was ihrer Entstehung vorausging, welche Aufgaben sie lösen und wie sie gebaut werden. Außerdem werde ich das Prinzip der Funktionsweise von IXPs anhand der Plattform EVE-NG und des Software-Routers BIRD demonstrieren, um das Verständnis zu vermitteln, wie das „unter der Haube“ funktioniert.

Ein wenig Geschichte

Wenn man sich anschaut hierhin, ist zu erkennen, dass das explosive Wachstum der Anzahl der Traffic-Austauschpunkte 1993 begann. Dies hängt damit zusammen, dass der Großteil des Traffics der zu diesem Zeitpunkt bestehenden Telekommunikationsanbieter über das Backbone-Netz der USA lief. So gelangte beispielsweise der Verkehr von einem Anbieter in Frankreich zu einem Anbieter in Deutschland zuerst in die USA und dann von dort nach Deutschland. In diesem Fall fungierte das Backbone-Netz als Transit zwischen Frankreich und Deutschland. Selbst der Verkehr innerhalb eines Landes verlief häufig nicht direkt, sondern über die Backbone-Netze amerikanischer Anbieter.

Diese Situation wirkte sich nicht nur auf die Kosten für den Transport von Transit-Traffic aus, sondern auch auf die Qualität der Kanäle und die Verzögerung. Die Anzahl der Internetnutzer wuchs, neue Betreiber traten auf, das Verkehrsvolumen nahm zu, das Internet reifte. Betreiber auf der ganzen Welt begannen zu verstehen, dass ein rationalerer Ansatz für die Organisation der Interconnection zwischen den Betreibern erforderlich war. "Warum soll ich, Betreiber A, für Transit durch ein anderes Land bezahlen, um Traffic zu Betreiber B zu bringen, der sich auf der benachbarten Straße befindet?". Eine ähnliche Frage stellten sich die Kommunikationsanbieter zu dieser Zeit. So begannen in verschiedenen Teilen der Welt an den Knotenpunkten der Betreiber Punkte für den Traffic-Austausch 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 von autonomen Systemen (autonomous system, AS) dar und zahlreiche Verbindungen zwischen ihnen, sowohl physische als auch logische, die den Weg des Verkehrs von einem AS zum anderen bestimmen.

AS werden in der Regel von Betreibern, Internetanbietern, CDN, Rechenzentren und Unternehmen des Enterprise-Segments gebildet. AS organisieren logische Verbindungen (Peering) untereinander meist mithilfe des BGP-Protokolls.

Wie autonome Systeme diese Verbindungen organisieren, hängt von einer Reihe von Faktoren ab:

• geografischen,
• wirtschaftlichen,
• politischen,
• Vereinbarungen und gemeinsamen Interessen zwischen den AS-Besitzern.
• 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 von lokalen Internetanbietern (Tier-3) in der Regel normale Benutzer sind, sind bei Tier-1-Betreibern beispielsweise andere Betreiber die Kunden. Tier-3-Betreiber aggregieren den Traffic ihrer Endbenutzer, Tier-2-Anbieter aggregieren wiederum den Traffic der Tier-3-Betreiber, während Tier-1 den gesamten Internet-Traffic aggregiert.

Schematically, this can be represented as follows:

Auf diesem Bild ist zu sehen, dass der Traffic von unten nach oben aggregiert wird, d.h. von den Endbenutzern zu den Tier-1-Betreibern. Zudem gibt es horizontale Traffic-Austausche zwischen etwa gleichwertigen AS.

Ein wesentlicher Bestandteil, aber gleichzeitig ein Nachteil dieses Schemas ist eine gewisse Unordnung der Verbindungen zwischen den autonomen Systemen, die näher am Endbenutzer liegen, innerhalb der geografischen Zone. Betrachten wir das Bild unten:

Nehmen wir an, in einer großen Stadt gibt es 5 Telekommunikationsanbieter, deren Peering aus verschiedenen Gründen wie oben dargestellt organisiert ist.

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

Wie kann die Anzahl der Transit-AS, die der Datenverkehr passieren muss, reduziert werden? Richtig – durch einen Peering-Punkt.

Heutzutage entstehen neue IXPs aus den gleichen Bedürfnissen wie in den frühen 90er und 2000er Jahren, jedoch in kleinerem Maßstab, als Reaktion auf die wachsende Anzahl von Kommunikationsanbietern, Nutzern und Traffic, sowie auf die zunehmende Menge an Inhalten, die von CDN-Netzwerken und Rechenzentren generiert werden.

Was ist ein Internet-Austauschnetzwerk?

Ein Internet-Austauschnetzwerk ist ein Ort mit spezieller Netzwerkinfrastruktur, an dem Teilnehmer, die an einem gegenseitigen Traffic-Austausch interessiert sind, gegenseitigen Peering organisieren. Die Hauptakteure an Internet-Austauschnetzwerken sind Telekommunikationsanbieter, Internetdienstanbieter, Content-Anbieter und Rechenzentren. An diesen Knotenpunkten verbinden sich die Teilnehmer direkt miteinander. Dadurch lassen sich folgende Ziele erreichen:

• die Latenz reduzieren,
• die Menge des Transit-Traffics verringern,
• die Routing-Optimierung zwischen AS.

Da IXPs in vielen großen Städten weltweit vorhanden sind, hat dies auch positive Auswirkungen auf das Internet insgesamt.

Wenn die oben beschriebene Situation mit Peter mittels IXPs gelöst wird, dann sieht das ungefähr so aus:

Wie funktioniert ein Internet-Austauschnetzwerk?

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

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

Elemente des IXPs

• SCS. Hier gibt es nichts Ungewöhnliches: Racks, optische Verbindungsstellen, Patchpanel.
• Switches – die Grundlage des IXPs. Der Switch-Port ist der Einstiegspunkt ins IXP-Netzwerk. Auch übernehmen Switches einige Sicherheitsfunktionen, indem sie unerwünschten Datenverkehr filtern, der im IXP-Netz nicht vorhanden sein sollte. In der Regel werden Switches basierend auf den Funktionsanforderungen ausgewählt – Zuverlässigkeit, unterstützte Portgeschwindigkeiten, Sicherheitsfunktionen, Unterstützung von sFlow usw.
• Route-Server (RS) – ein unverzichtbarer und notwendiger Bestandteil jedes modernen Traffic Exchange Point. In seiner Funktionsweise ähnelt es stark einem Route Reflector in iBGP oder einem Designated Router in OSPF und löst dieselben Probleme. Mit der Zunahme der Teilnehmer an einem Traffic Exchange Point steigt die Anzahl der BGP-Sitzungen, die jeder Teilnehmer aufrechterhalten muss, was einer klassischen Full-Mesh-Topologie in iBGP ähnelt. Der Route Server (RS) löst das Problem folgendermaßen: Er stellt eine BGP-Sitzung mit jedem interessierten Teilnehmer des IXP her, und dieser wird ein Kunde des RS. Sobald der RS ein BGP-Update von einem seiner Kunden erhält, verteilt er dieses Update an alle anderen Kunden, selbstverständlich mit Ausnahme desjenigen, von dem dieses Update stammte. Auf diese Weise beseitigt der RS die Notwendigkeit, ein Full-Mesh zwischen allen Teilnehmern des IXP zu etablieren, und löst elegant das Skalierbarkeitsproblem. Es ist auch erwähnenswert, dass der Route Server Routen transparent von einem AS zu einem anderen überträgt, ohne Änderungen an den übermittelten BGP-Attributen vorzunehmen, zum Beispiel fügt er seine eigene AS-Nummer nicht zum AS-Pfad hinzu. Zudem findet auf dem RS eine grundlegende Filterung der Routen statt: Beispielsweise akzeptiert der RS keine Martian-Netze und Präfixe des IXP selbst.

  Als Lösung wird oft ein Open-Source-Software-Router – BIRD (Bird Internet Routing Daemon) – verwendet. Er hat den Vorteil, dass er kostenlos ist, schnell auf den meisten Linux-Distributionen bereitgestellt werden kann, ein flexibles System zur Konfiguration von Routing-/Filterrichtlinien bietet und keine hohen Anforderungen an die Rechenressourcen stellt. Auch ein Hardware-/Virtueller Router von Cisco, Juniper usw. kann als RS gewählt werden.

• Sicherheit. Da das IXP-Netzwerk eine Konzentration von vielen AS darstellt, müssen auch die Sicherheitsrichtlinien, denen alle Teilnehmer folgen sollten, gut definiert sein. In der Regel kommen die gleichen Mechanismen zum Einsatz, die auch beim Aufbau von BGP-Nachbarschaften zwischen zwei separaten BGP-Peers außerhalb des IXP verwendet werden, und es werden zusätzliche Schutzmaßnahmen eingesetzt.

  Eine gute Praxis ist es beispielsweise, den Datenverkehr nur von einer bestimmten MAC-Adresse eines IXP-Teilnehmers zuzulassen, die im Voraus vereinbart wird. Der Datenverkehr mit Ethertype-Feldern, die von 0x0800 (IPv4), 0x08dd (IPv6), 0x0806 (ARP) abweichen, wird blockiert; dies dient dazu, den Datenverkehr herauszufiltern, der beim BGP-Peering keinen Platz hat. Zusätzlich können Mechanismen wie GTSM, RPKI usw. angewendet werden.

Das oben Genannte sind wahrscheinlich die grundlegenden Komponenten eines jeden IXPs, unabhängig von deren Größe. Natürlich können bei großen IXPs zusätzliche Technologien und Lösungen zum Einsatz kommen.
Es kommt vor, dass IXPs ihren Teilnehmern zusätzliche Dienste anbieten:

• Platzierung von TLD-DNS-Servern auf dem IXP,
• Installation von Hardware-NTP-Servern, die es den Teilnehmern ermöglichen, die Zeit genau zu synchronisieren,
• Bereitstellung von DDoS-Schutz usw.

Funktionsweise

Wir werden die Funktionsweise eines Austauschpunkts anhand eines einfachen IXP, modelliert mit EVE-NG, untersuchen und anschließend die Grundkonfiguration des Software-Routers BIRD betrachten. Zur Vereinfachung der Darstellung lassen wir wichtige Aspekte wie Redundanz und Fehlertoleranz außen vor.

Die Netzwerk-Topology ist im folgenden Bild dargestellt.

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

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

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

50.50.50.254 ist die IP-Adresse, die auf dem Interface des Route-Servers konfiguriert ist; mit dieser IP werden die Kunden eine BGP-Sitzung für das Peering über den RS einrichten.

Für das Peering über den RS haben wir zudem eine einfache Routing-Politik auf Basis von BGP-Communities entwickelt, die es den Teilnehmern des IXP ermöglicht, zu regulieren, wem und welche Routen zugeteilt werden:

BGP-Community
Beschreibung

LOCAL_AS:PEER_AS
Übertragung der Präfixe nur an PEER_AS

LOCAL_AS:IXP_AS
Übertragung der Präfixe an alle Teilnehmer des IXP

Drei Kunden möchten sich mit unserem IXP verbinden und Traffic austauschen; nehmen wir an, dies sind Internet-Service-Provider. Alle möchten Peering über den Route-Server einrichten. Im Folgenden sind das Schema mit den Verbindungsparametern der Kunden dargestellt:

Kunde
Kundennummer AS
Von dem Kunden angekündigte Präfixe
IP-Adresse, die dem Kunden zur 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 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

Es ist wichtig, die Einstellung no bgp enforce-first-as zu beachten. Standardmäßig erfordert BGP, dass die Nummer des AS (Autonomous System) des BGP-Peers, von dem das Update empfangen wurde, im as-path des empfangenen BGP-Updates vorhanden ist. Da der Route-Server jedoch keine Änderungen am as-path vornimmt, wird seine Nummer im as-path fehlen, und das Update wird abgelehnt. Diese Einstellung ermöglicht es dem Router, diese Regel zu ignorieren.

Wir sehen auch, dass der Kunde die BGP-Community 555:555 für dieses Präfix festgelegt 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, mit Ausnahme ihrer einzigartigen Parameter.

Beispiel für die 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 keine Martian-Präfixe sowie die Präfixe der IXP 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 zuvor beschriebene Routing-Policy.

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 einem Route-Server als gute Praxis gilt, Routen von verschiedenen Peers in unterschiedliche RIBs zu speichern. BIRD ermöglicht dies. In unserem Beispiel werden zur Vereinfachung alle Updates, die von allen Clients empfangen werden, in einer gemeinsamen RIB gesammelt.

Lassen Sie uns also überprüfen, was wir erreicht haben.

Auf dem Route-Server sehen wir, dass eine BGP-Sitzung mit allen drei Clients 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 Route-Server Präfixe sowohl von AS 200 als auch von AS 300 erhalten, wobei die BGP-Attribute unverändert bleiben, als ob das Peering zwischen den Clients direkt erfolgt wäre:

So sehen wir, dass die Anwesenheit eines Route-Servers das Peering an einem IXP erheblich vereinfacht.

Ich hoffe, dass diese Demonstration Ihnen geholfen hat, ein besseres Verständnis dafür zu entwickeln, wie Internet Exchange Points funktionieren und wie die Arbeit des Route-Servers am IXP umgesetzt wird.

Linxdatacenter IX

Bei Linxdatacenter haben wir unsere eigene IXP auf der Grundlage einer ausfallsicheren Infrastruktur mit 2 Switches und 2 Route-Servern aufgebaut. Derzeit läuft unsere IXP im Testmodus, und wir laden alle Interessierten ein, sich mit Linxdatacenter IX zu verbinden und am Testen teilzunehmen. Bei der Verbindung erhalten Sie einen Port mit einer Bandbreite von 1 Gbit/s, die Möglichkeit zum Peering über unsere Route-Server sowie Zugang zu Ihrem IX-Portal, das unter der Adresse ix.linxdatacenter.com.

Schreiben Sie in die Kommentare oder persönliche Nachrichten, um Zugang zum Testen zu erhalten.

Fazit

Traffic exchange points emerged at the dawn of the internet as a tool to address the issue of suboptimal traffic routing between communication operators. Today, with the rise of new global services and the increasing amount of CDN traffic, exchange points continue to optimize the functioning of the global network. The growth of IXPs around the world benefits both end users of services and operators, content providers, etc. For IXP participants, the advantages manifest as reduced costs for organizing external peering, diminished traffic charges owed to upstream operators, optimized routing, and the ability to have a direct connection with content providers.

Nützliche Links

• Sehen Sie die Karte der Standorte von Traffic-Austauschpunkten: www.internetexchangemap.com
• Sehen Sie detaillierte Statistiken zu BGP-Peering, einschließlich der Präsenz an IXPs: www.peeringdb.com

Quelle: habr.com