Übersicht zu Internetknoten (IX)

Megaport besitzt und betreibt eine Reihe von Internet Peering Exchanges (IXs) in den meisten unserer globalen Netzwerke. IXs sorgen für mehr Effizienz zwischen den Netzwerken und ermöglichen den direkten Austausch von Datenverkehr, wodurch Latenz und Bandbreitennutzung von Client-Internetverbindungen reduziert werden.

Es gibt zwei Haupttypen von IX-Peering-Verbindungen: multilaterale und bilaterale. Multilaterales Peering ist der Standard, wenn Sie sich mit MegaIX verbinden. Bei multilateralem Peering verwenden Sie BGP, um die Peering-Verbindung mit beiden Routeservern (RS1 und RS2) für einen IX-Markt herzustellen. Sie kündigen Ihre Routen bei den Routeservern an, und alle verfügbaren Routen von allen anderen multilateralen Peering-Verbindungen werden Ihrem Peer von den Routeservern angekündigt. Die zweite Art von Peering ist das bilaterale Peering. Diese Methode ist für Peers erforderlich, die nicht am multilateralen Peering über die Routeserver teilnehmen und eine direkte Peering-Beziehung mit einer anderen Entität auf dem IX einrichten. Sie können sowohl an multilateralem als auch bilateralem Peering über die gesamte Megaport-IX-Infrastruktur teilnehmen.

Wenn Sie eine Verbindung zu einem AMS-IX-Standort herstellen, finden Sie unter AMS-IX-Konnektivität weitere Informationen.

So verbinden Sie sich mit Internetknoten (IX) an Megaport- und MegaIX-Standorten

  1. Öffnen Sie im Megaport Portal die Seite Services (Dienste), und wählen Sie den gewünschten Port aus.
    Falls Sie noch keinen Port erstellt haben, finden Sie weitere Informationen unter Anlegen eines Ports.
  2. Fügen Sie dem Port eine IX-Verbindung hinzu.
    Klicken Sie auf +Connection (Neue Verbindung). Klicken Sie auf „Internet Exchange“ (Internetknoten) und dann auf Next (Weiter).
    IX-Verbindung hinzufügen

  3. Wählen Sie den IX-Standort aus, und klicken Sie auf Next (Weiter).
    IX-Standort

  4. Geben Sie die folgenden Verbindungsdetails an:

    • Name your connection (Name der Verbindung) – Der Name der VXC, der im Megaport Portal angezeigt werden soll.

    • Invoice Reference (Rechnungsreferenz) – Dies ist ein optionales Feld für die Rechnungsreferenz. Es kann ein beliebiger Text sein, z. B. eine Bestellnummer oder eine Rechnungsnummer.

    • Rate Limit (Übertragungsratenlimit) – Dies ist die Geschwindigkeit Ihrer Verbindung in Mbit/s. Das Übertragungsratenlimit für einen IX ist bei Metro-Verbindungen die aggregierte Portgeschwindigkeit und bei Nicht-Metro-Verbindungen 10 Gbit/s.
      Verbindungsdetails

  5. Klicken Sie auf Next (Weiter).

  6. Geben Sie diese IX-Details an:

    • Preferred VLAN (Bevorzugtes VLAN) – Geben Sie optional eine nicht verwendete VLAN-ID für diese Verbindung an. Die VLAN-ID muss eine eindeutige ID auf diesem Port im Bereich von 2 bis 4093 sein. Wenn Sie eine VLAN-ID angeben, die bereits verwendet wird, zeigt das System die nächste verfügbare VLAN-ID an. Megaport validiert die VLAN-ID, bevor die Bestellung bearbeitet wird. Wenn Sie keinen Wert angeben, weist Megaport einen zu. Sie können auch das Umschaltfeld auswählen, um für diese Verbindung Untag (Tags entfernen) einzustellen. Diese Auswahl hebt das VLAN-Tagging für diese Verbindung auf, allerdings kann auf diesem Port dann nur eine IX (oder VXC) verwendet werden.

    • ASN – Die Autonomous System Number (ASN) Ihres Netzwerks. Die ASN kann entweder ein 16-Bit- oder 32-Bit- ASN (2 oder 4 Byte) sein, muss aber eine öffentliche ASN sein. Sie können die ASN nach der Bereitstellung nicht mehr ändern.

    • MAC Address – Die MAC-Adresse des Layer 3-Gerätes, das die BGP-Peering-Sitzung mit dem IX aufbauen wird. Verbindungen zum IX auf dieser VXC werden aus Sicherheitsgründen für diese Adresse gesperrt. Wenn Sie zum Zeitpunkt der Bestellung nicht die korrekte MAC-Adresse zur Verfügung haben, geben Sie eine Platzhalter-MAC ein (z. B. 00:01:00:01:12:34), da dieses Feld nach der Bereitstellung bearbeitbar bleibt.

    • BGP Password (BGP-Kennwort)– Fügen Sie optional ein BGP-Kennwort für die VXC-Verbindung hinzu. Dieses Feld kann leer gelassen werden. Sie können das BGP-Kennwort nach der Bereitstellung nicht mehr ändern.

    • Graph Visibility (Diagrammsichtbarkeit) – Legen Sie fest, wie Ihre Datenverkehrsdiagramme im MegaIX Looking Glass-Tool des Megaport Portal angezeigt werden sollen. Mit „Public“ (Öffentlich) können andere Clients Ihren IX-Durchsatz sehen. Mit „Private“ haben andere Clients keinen Zugriff auf diese Informationen.

    • Peer Macro (Peer-Makro) – Ein optionales Feld, das nur bei ECIX-Verbindungen angezeigt wird. Der Peer-Makro-Wert definiert den AS-Makro-Filter für den Peer. Megaport verwendet diesen Wert, um eine Liste von Präfixen zu generieren, die von diesem AS verwendet werden kann, und diese Liste filtert Ankündigungen durch den Routeserver.

      Ein anderer Name für dieses Feld ist AS-MACRO (oder AS-SET), da es eine Liste von AS-Nummern enthält, die zu diesem Peer gehören.

      Wenn Sie kein Peer-Makro haben, können Sie in diesem Feld Ihre ASN eingeben. (Sie können nur Routen senden, die aus Ihrem eigenen AS stammen.) Ungültige Präfixe werden vom Routeserver nicht angekündigt, und eine falsche Konfiguration führt dazu, dass der Routeserver alle Ihre Präfixe ablehnt.

      Wenn nicht angegeben, wird Ihre eigene ASN im Filter verwendet, und Sie können nur Routen senden, die von Ihrem eigenen AS und den in diesem AS registrierten Präfixen stammen.

    • Invoice Reference (Rechnungsreferenz) – Dies ist ein optionales Feld. Der Inhalt kann ein beliebiger Text sein, wie z. B. eine Auftragsnummer oder eine Rechnungsnummer.
      Details zum IX-Dienst

  7. Klicken Sie auf Next (Weiter).
    Es wird eine Übersichtsseite mit den monatlichen Kosten angezeigt. Klicken Sie auf Back (Zurück), um Änderungen vorzunehmen, oder auf Add IX (IX hinzufügen), um diese Konfiguration Ihrem Warenkorb hinzuzufügen und mit dem Bestellvorgang fortzufahren.

    Nach der Bereitstellung sendet Megaport eine E-Mail an Ihre registrierte E-Mail-Adresse mit zusätzlichen Informationen, die zur Fertigstellung der BGP-Konfiguration erforderlich sind.

Best Practices für IXs

Standardmäßige BGP-Implementierungen verlangen, dass die erste ASN im Pfad mit der ASN des Peers übereinstimmt. Bei einem multilateralen Peering ist die erste ASN jedoch nicht die des Peers (RS), sondern die des Routeservers, der die Routen bereitstellt. Dies ist ein erwartetes Verhalten und wird benötigt, um die AS-Pfadlängen für korrekte Routing-Entscheidungen zu reduzieren. Um multilaterales Peering zu ermöglichen, konfigurieren Sie Ihre Geräte so, dass die Anforderung an das erste AS im Pfad nicht erzwungen wird. Auf einem Cisco-Router lautet der Befehl zum Beispiel no bgp enforce-first-as.

Um zu verhindern, dass Kunden alle Internet-Routen an Megaport senden, begrenzen wir die Anzahl der maximalen Präfixe (MaxPFX), die an uns gesendet werden können. Die Standardbegrenzung ist 1.000 IPv4-Routen und 100 IPv6-Routen. Ein Überschreiten dieses Wertes führt zur Beendigung der Sitzung. Dies kann jedoch durch Kontaktaufnahme mit dem Megaport Support-Team über den Online-Chat zurückgesetzt werden.

Alle an den Internetknoten weitergeleiteten Frames müssen folgende Eigenschaften haben:

  • dieselbe MAC-Quelladresse
  • Ethernet II (DIX)-Frames, mit Ethertypes, die entweder ARP, IPv4 oder IPv6 entsprechen

Die folgenden Frames sind für Internetknoten nicht erlaubt:

Multicast und Broadcast, mit Ausnahme von ARP und IPv6 Neighbor Discovery Sie können nur Unicast-Routen über Ihre BGP-Sitzungen in den Peering-LANs austauschen. Multicast-Datenverkehr ist in (Unicast-)Peering-LANs nicht erlaubt.

Frames aus Proxy-ARP Der Peering-VLAN-Datenverkehr wird auf der Grundlage von BGP-Routen ausgetauscht. Daher ist es nicht erforderlich, ARP-Anfragen für IP-Adressen zu beantworten, die nicht auf Ihrer ECIX-Schnittstelle konfiguriert wurden. Einige Hersteller aktivieren Proxy-ARP standardmäßig, was zu unerwünschtem Datenverkehr in Ihrem Netzwerk führen kann. Wenn Sie das Proxy-ARP am ECIX aktiviert haben, müssen Sie davon ausgehen, dass es wahrscheinlich auch an anderen Peering-Punkten aktiviert ist, was es Parteien auf beiden Seiten ermöglicht, Sie als Transit zu nutzen.

802.2-LLC/SNAP-Frames

  • Lokale Layer 2-Steuer- und Link-Protokolle wie z. B.:
    • Alle Formen des Spanning Tree-Protokolls (STP) - Geräte, die an den ECIX-Port angeschlossen sind, dürfen nicht als L2-Brücken sichtbar sein. Das bedeutet, dass sie weder STP noch ein anderes (proprietäres) L2-spezifisches Protokoll verarbeiten sollten.
    • Hersteller-Erkennungsprotokolle (CDP, EDP, FDP, MNDP) - Verschiedene Hersteller (z. B. Extreme, Cisco) neigen dazu, ihre Boxen als sehr auskunftsfreudige Geräte auszuliefern, die standardmäßig über alle Schnittstellen ihre Existenz kundtun und dann versuchen, verwandte Teilnehmer zu finden. CDP (Cisco) und EDP (Extreme) sind Beispiele dafür, aber es gibt noch weitere. Der einzige Grund für die Ausführung von Erkennungsprotokollen ist die Unterstützung bestimmter Typen der automatischen Konfiguration. Die automatische Konfiguration bei einem Internetknoten (IX) sollte unbedingt vermieden werden. Es absolut keinen Grund, Erkennungsprotokolle auf Ihrer ECIX-Schnittstelle auszuführen. Erkennungsprotokolle verursachen typischerweise unerwünschten Broadcast- oder Multicast-Datenverkehr.
    • UDLD
    • DHCP
    • PIM
    • Layer 2-„Keep-Alives“ - Standardmäßig testen Cisco-Router und -Switches periodisch ihre (Fast-)Ethernet-Verbindungen, indem sie an sich selbst adressierte Loopback-Frames (Ethertyp 0x9000) aussenden, sogenannte „L2 Self-Pings“. In einer Switch-Umgebung können diese verwendet werden, um die Funktionalität des Switches zu testen und/oder die MAC-Adresse des Routers in der Adresstabelle des Switches zu behalten. In der ECIX-Umgebung ist dies nicht sinnvoll, da hier MAC-Timeouts verwenden werden, die größer sind als die typischen BGP- und/oder ARP-Timeouts.
    • Interne Routing-Protokolle (wie OSPF, EIGRP, RIP und IS-IS) - Das einzige auf den Peering-VLANs zulässige Routing-Protokoll ist BGP. Es gibt keinen triftigen Grund, dass interne Routing-Protokolle auf dem freigegebenen Medium ausgeführt werden. Diese Protokolle verursachen nur unnötigen Multicast- und Broadcast-Datenverkehr.

Nicht-Unicast-IPv6: IPv6 ND-RA IPv6-Router-Ankündigungen generieren eine Menge unnötigen Datenverkehrs, da IPv6-Hosts auf dem ECIX nicht automatisch konfiguriert werden, und außerdem möchten Sie nicht der Standard-Router für das gesamte Peering-VLAN sein.

  • ICMP-Umleitungen

Mehrere MAC-Adressen Da ECIX nach dem Prinzip „ein Router pro Port pro VLAN“ arbeitet, sollte hinter jedem Port in jedem VLAN nur eine MAC-Adresse sichtbar sein. Einige Teilnehmer verbinden sich über zwischengeschaltete Switches oder verwenden ein L2/L3-Hybridgerät. Wenn diese Geräte nicht korrekt konfiguriert sind, können sie Weiterleitungsschleifen, STP-Instabilität und viel unerwünschten Datenverkehr am IX verursachen. Es gibt keine Entschuldigung dafür, dass diese Geräte Datenverkehr offenlegen, und es gibt keine Notwendigkeit, STP auf dem Link zum ECIX zu verwenden. Durch Erzwingen der Regel, nur eine MAC-Adresse zu verwenden, werden also auch diese Punkte durchgesetzt.

Nicht-Unicast-IPv4: IGMP, DHCP, TFTP Im ECIX-Peering-VLAN ist die ARP-Abfrage der einzige erlaubte Nicht-Unicast-Datenverkehr. Manchmal gibt es Geräte, die versuchen, eine Konfiguration über Broadcast-TFTP zu erhalten oder sich über DHCP zu konfigurieren. Wir überlassen es dem Leser zu überlegen, warum dies eine schlechte Idee ist. Bei anderen Geräten ist IGMP standardmäßig (oder versehentlich) aktiviert. Das Peering-LAN ist nur für Unicast-IP-Datenverkehr gedacht, daher ist es nicht sinnvoll, Multicast auf der ECIX-Schnittstelle zu konfigurieren.

Verschiedene Nicht-IP: DEC MOP, usw. Einige Hersteller aktivieren standardmäßig andere Protokolle als IP. Cisco beispielsweise liefert bestimmte Versionen von IOS mit standardmäßig aktiviertem DEC MOP aus. Dieser Nicht-IP-Datenverkehr hat am ECIX nichts zu suchen.

MegaIX-Routeserver beachten nicht das bekannte BGP-Community-Attribut no-export. Dieses Community-Attribut wird transparent an die anderen mit dem Routeserver verbundenen Peers weitergegeben.

Die MED-Werte (Multiple Exit Discriminator) werden in den Regeln für die Routenauswahl nur dann berücksichtigt, wenn die Ankündigungs-ASN für die Kandidatenrouten gleich ist. MED-Werte werden von den Routeservern nicht verändert. Werte, die den Routeservern angekündigt werden, werden unverändert an andere Peers weitergegeben.

Alle Routen auf dem IX werden von den Routeservern lokal gleich behandelt. Die Routeserver vergleichen für die Auswahl der besten Route nicht die BGP-Router-ID, sondern bevorzugen die älteste Route, wenn alle anderen Attribute gleich sind.

Best Practices

  • Konfigurieren Sie weder „network 194.146.118.0/24“ noch eines der anderen Peering-LANs in der BGP-Konfiguration Ihres Routers.

Looking Glass

Megaport bietet ein öffentliches, über das Internet zugängliches MegaIX Looking Glass-Tool, mit dem Peers und Netzwerkbetreiber den aktuellen Routing-Status untersuchen können. Sie können sowohl den primären als auch den redundanten Routeserver nach Live-BGP-Daten abfragen. Das MegaIX Looking Glass-Tool steht unter https://lg.megaport.com zur Verfügung.

Weitere Informationen


Letztes Update: