Zum Inhalt

Problembehandlung des IX bei Ausfall der BGP-Sitzung

Wenn Ihr Internetknoten (IX, Internet Exchange) ausgefallen ist, liegt wahrscheinlich ein Problem mit Ihrer Border Gateway Protocol (BGP)-Sitzung vor. Gehen Sie die folgenden Schritte zur Problembehandlung durch, um festzustellen, ob Ihre BGP-Sitzung die Ursache für die IX-Probleme ist.

Tipp

Megaport betreibt ein öffentliches, über das Internet zugängliches MegaIX Looking Glass, mit dem Peers und Netzbetreiber den aktuellen Status des Routings untersuchen können. Hier können Sie sowohl den primären als auch den redundanten Routeserver nach aktuellen BGP-Daten abfragen: MegaIX Looking Glass.

Maßnahmen zur Problembehandlung

Aktion Schritte
Gerät auf Schnittstellen- oder CRC-Fehler und auf Paketverluste überprüfen Mithilfe von Schnittstellenstatistiken und -protokollen lässt sich feststellen, welches Ende der Querverbindung (Cross-Connect) den Fehler verursacht hat und wie die entsprechende Lösung des Problems aussehen könnte. Beispielsweise schließt eine zunehmende Anzahl von Eingangsfehlern an einer Netzwerkschnittstelle in der Regel dieses spezielle SFP (Small Form Factor Pluggable) aus und deutet auf ein mögliches Problem mit anderen Komponenten des IX hin.

Wichtig zu beachten:

Schnittstellentyp, SFP-Typ und Kabeltyp
  • 1 Gbit/s 1000BASE-LX [10 km; Duplex auf Singlemode-Glasfaser (SMOF)]
  • 10 Gbit/s 10GBASE-LR [10 km; Duplex auf Singlemode-Lichtwellenleiter (SMOF)]
  • 100 Gbit/s 100GBASE-LR4 [10 km; Duplex auf Singlemode-Glasfaser (SMOF)]
MTU (Maximum Ethernet Frame Size)
  • 9.100 Byte für VXCs zwischen Kundenports.
  • MCR und MVE unterstützen eine Standard-MTU von 1.500 Byte.
  • IX und viele CSP-Ports unterstützen keine Jumbo-Frames, aber alle unterstützen die Standard-MTU von 1.500 Bytes.
LAG (Link Aggregation Group)
  • Protokoll: LACP
  • Schnittstelle: 10GBASE-LR (10 Gbit/s) oder 100GBASE-LR4 (100 Gbit/s). 1-Gbit/s-Ports werden nicht unterstützt.
  • Die maximale Anzahl von Schnittstellen in einer einzelnen LAG: 8
  • Multi-Chassis Link Aggregation (MC-LAG) über mehrere Geräte hinweg wird nicht unterstützt.
Bevorzugtes A-Ende-VLAN (VXC/IX)
  • Untag (aktiviert) – Damit wird der A-Ende-Port auf einen einzigen Dienst beschränkt. Nur ein VXC/IX pro Port, gleichbedeutend mit einem geräteseitigen Zugangsport.
  • Untag (deaktiviert) – Geben Sie 802.1q-VLAN-Nummer auf dem A-Ende-Port an. Jeder VXC wird als separates VLAN auf dem Port bereitgestellt. Dies muss eine eindeutige VLAN-ID auf dem 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-Nummer an. Wenn Sie die VLAN-ID leer lassen, weist das System nach dem Zufallsprinzip eine VLAN-Nummer zu, die einem Trunk-Port mit zulässigen VLANs auf Ihrer Geräteseite entspricht.
802.1Q-Tunneling (Q-in-Q) IEEE 802.1ad (Azure-VXC)
  • Für den Zugriff auf Microsoft Azure ExpressRoute ist Q-in-Q (IEEE 802.1ad) erforderlich. Je nach gewählter Methode können Ihre Gerätekonfigurationen variieren, entweder Q-in-Q, Q-in-Q-Breakout, nicht getaggter VXC oder MCR.
Überprüfen, ob Schnittstelle, SFP, Kabel und Verkabelung korrekt sind
  • Überprüfen Sie, ob Auto-Negotiation (Auto-Geschwindigkeit und Auto-Duplex) auf Gigabit-Schnittstellen verwendet wird.
  • Überprüfen Sie, ob das Querverbindungskabel an beiden Enden an den korrekten Port angeschlossen ist.
  • Überprüfen Sie, ob die Leistungspegel der SFP-Optik (Tx und Rx) an beiden Enden eine gute Lichtstärke aufweisen.
Layer 2-Konfigurationen überprüfen
  • Überprüfen Sie, ob die MTU-Größe korrekt ist.
  • Überprüfen Sie, ob die LACP-Konfiguration korrekt ist, wenn LAG verwendet wird. MC-LAG wird nicht unterstützt.
  • Überprüfen Sie, ob Ihre Geräte im Megaport Portal als „Bevorzugtes A-Ende-VLAN“ konfiguriert sind.
  • Wenn ein VLAN verwendet wird, überprüfen Sie, ob auf Ihrer Geräteseite die korrekte VLAN-Nummer konfiguriert ist.
  • Wenn Azure-VXC verwendet wird, überprüfen Sie, ob Ihre Geräte mit einer der Q-in-Q-Methoden konfiguriert sind.
Layer 3-Konfigurationen überprüfen
  • Überprüfen Sie, ob die IP-Adresse der Schnittstelle und die Subnetzadresse korrekt konfiguriert sind.
  • Überprüfen Sie, ob die Routing-Protokollkonfigurationen (EIGRP/OSPF/BGP) korrekt sind.
  • Führen Sie einen Ping-Test zwischen Layer 3-Netzwerkgeräten durch (z. B. Edge-Router, BGP-Peers).
  • Führen Sie einen Ping-Test zwischen Quellhost und Zielhost durch (End-to-End-Konnektivitätstest).
  • Wenn der Ping-Test fehlschlägt, überprüfen Sie die ARP-Tabelle und die Routing-Tabelle an beiden Enden.
  • Wenn der Ping-Test fehlschlägt und es kein Problem mit der Routing-Tabelle an beiden Enden gibt, erstellen Sie Traceroute-Protokolle von beiden Enden.

Optische Leistung am Gerät überprüfen Die optischen Lichtmesswerte des Terminals helfen zu verstehen, ob die Messwerte innerhalb des Schwellenbereichs liegen. Überprüfen Sie die Geräte- und Portdiagramm auf Fehler, und prüfen Sie den Verlauf der Megaport-Optikdiagramme in der Historie an. Die Diagramme werden alle fünf Minuten aktualisiert. Wenn also Instabilität (Flapping) selten ist, erfassen die Diagramme möglicherweise keinen Rückgang der optischen Leistung. Stellen Sie sicher, dass der Optikmesswert innerhalb der Spezifikationen liegt.
Ping-Test zu Routeservern innerhalb des IX-Netzwerks und/oder bilateralen Peers ausführen Ein Ping-Test sendet Datenpakete an eine bestimmte IP-Adresse und bestätigt oder verneint die Konnektivität zwischen Geräten in IP-Netzwerken. Bei Bestätigung der Konnektivität wird auch die Latenz (die Antwortzeit) der Verbindung angegeben.

Layer 2-Konnektivität (ARP) zu Routeservern und/oder bilateralen Peers prüfen Layer 2 steuert den Datenfluss zwischen Knoten auf WAN- oder LAN-Segmenten und ist auch für die Erkennung und ggf. Korrektur von Layer 1-Fehlern zuständig. Layer 2-Konnektivitätsprobleme können die Funktionalität der VXCs beeinträchtigen, die mit Ihrem MCR verbunden sind. Wenn Sie eine Verbindung zu einem Cloud Service Provider (CSP) herstellen, stellen Sie sicher, dass die VLAN-Konfigurationsdetails korrekt sind. Seien Sie besonders vorsichtig, wenn Sie eine Verbindung zu Azure herstellen, da Sie Q-in-Q verwenden werden.

Layer 2-Konnektivitätsprobleme können auch Ihre IX-Dienste beeinträchtigen. MAC-Adressen werden verwendet, um Ihre Geräte bei der Nutzung von IX-Diensten mit Megaport zu authentifizieren. Abhängig von Ihrem Netzwerkdesign müssen Sie beim Peering mit Megaport oder anderen Organisationen sicherstellen, dass Sie die korrekte MAC-Adresse im Megaport Portal angegeben haben.
    Führen Sie folgende Prüfungen durch, bevor Sie eine Supportanfrage stellen:

  1. Prüfen Sie den Status Ihres IX-Dienstes mit dem Looking Glass-Tool. Sie können sowohl den primären als auch den redundanten Routeserver nach Live-BGP-Daten abfragen. Layer 2-Probleme können schwieriger zu diagnostizieren sein als Probleme des physikalischen Layer 1. Durch Bereitstellung von Megaport-Details zur Layer 2-Konnektivität kann das Problem eingegrenzt werden.
  2. Wenn Sie kein direktes Peering mit Megaport betreiben, überprüfen Sie alle Konfigurationsänderungen mit dem Unternehmen, mit dem Sie Peering betreiben.
  3. Führen Sie einen Ping-Test durch, um zu überprüfen, ob Sie mit Layer 2 verbunden sind.
  4. Prüfen Sie die ARP-Tabellen, und überprüfen Sie, ob die MAC-Adresse im Megaport Portal angezeigt wird.
  5. Überprüfen Sie, ob die Konfiguration mit den Technischen Spezifikationen von Megaport übereinstimmt.

    Wenn Sie zusätzliche Unterstützung benötigen, wenden Sie sich an Ihren Kundenbetreuer mit der Bitte um ein Treffen mit einem Megaport Solution Architect.
BGP-Konfiguration überprüfen
  • Schnittstelleneinstellungen, einschließlich VLAN-Nummer
  • BGP-IP-Adresse und Subnetzmaske
  • BGP-AS-Nummer
  • BGP-Netzwerkadressen, die angekündigt werden sollen
  • BGP-Nachbar-IP-Adresse und Subnetzmaske
  • BGP-Nachbar-AS-Nummer
  • BGP-Nachbar-Netzwerkadressen, die empfangen werden sollen
  • BGP-Authentifizierung zwischen BGP-Peers
  • BGP-Routenfilterung und -manipulation, falls zutreffend
    Nach BGP-Fehlermeldungen suchen Das BGP-Protokoll sendet eine Benachrichtigung, wenn in der BGP-Sitzung ein Fehler festgestellt wird, z. B. ein ablaufender Haltezeitgeber, eine Änderung der Nachbarschaftsfunktionen oder eine Anfrage zum Zurücksetzen einer BGP-Sitzung. Wenn ein Fehler festgestellt wird, wird die BGP-Sitzung geschlossen.

    Beispiel: Geben Sie show log %BGP-xxxxx ein.

    Details finden Sie unter Übersicht zu Internetknoten (IX).

    Nächste Schritte

    Wenn durch die Maßnahmen zur Fehlerbehebung Ihr Problem nicht gelöst wird, wenden Sie sich an den Support. Bevor Sie Unterstützung anfordern, legen Sie folgende Informationen bereit:

    Ergebnisse der Problembehandlung

    • Beschreiben Sie detailliert alle Schritte, die Sie zur Problembehandlung unternommen haben. Wenn z. B. Loopbacks platziert wurden, notieren Sie deren Position und Richtung.

    Auszüge aus den Konfigurationen der Netzwerkgeräte

    • Schnittstellen-Konfigurationen
    • Konfigurationen von statischen Routen und Routing-Protokollen (EIGRP/OSPF/BGP)
    • Firewall-Regeln und ACL-Konfigurationen für den Datenfluss, bei dem das Problem auftritt

    BGP-Befehlsausgabe und Packet Capture-Informationen

    • Routing-Tabelle (show IP route <ip-address>) an beiden Enden
    • Routing-Protokollstatus und die Tabellen an beiden Enden, z. B. die BGP-Nachbar-Tabelle, die den BGP-Status (show ip bgp summary) und BGP-Nachbar-Details (show ip bgp neighbors <neighbor-ip-address>) enthält.
    • BGP-Routing-Tabelleneinträge, die BGP-Routing-Probleme anzeigen (Ausgabe des Befehls show IP BGP)
    • Angekündigte BGP-Routen (show IP BGP neighbors <neighbor-ip-address> advertised-routes)
    • Empfangene BGP-Routen (Ausgabe des Befehls show IP BGP neighbors <neighbor-ip-address> routes)- Routing-Tabelle (show IP route <ip-address>)
    • Traceroute-Protokolle zwischen Quell- und Zielhost
    • Packet Capture-Protokolle, wenn möglich (Dateigröße kann bis 10 MB sein)

    Letztes Update: 2022-02-11