Fehlerbehebung bei ausgefallener IX-BGP-Sitzung

Wenn Ihr Internet Exchange (IX) ausgefallen ist, liegt wahrscheinlich ein Problem mit Ihrer Border Gateway Protocol (BGP)-Sitzung vor. Gehen Sie diese Schritte zur Fehlerbehebung durch, um zu bestätigen, ob Ihre BGP-Sitzung die Hauptursache der IX-Probleme ist.

Tipp

Megaport betreibt ein öffentliches, webbasiertes MegaIX Looking Glass für Peers und Netzbetreiber, um den aktuellen Routing-Status zu untersuchen. Sie können hier sowohl den primären als auch den redundanten Route-Server nach Live-BGP-Daten abfragen: MegaIX Looking Glass.

Maßnahmen zur Fehlerbehebung

Aktion	Schritte
Schnittstelle oder CRCZyklische Redundanzprüfung. Eine Art Fehlererkennungscode, der zum Erkennen von Übertragungsfehlern in Daten verwendet wird. -Fehler und Paketverluste auf dem Gerät prüfen	Schnittstellenstatistiken und Protokolle können helfen zu identifizieren, welches Ende des Cross-Connects den Fehler verursacht, sowie die potenzielle Lösung. Beispielsweise schließt eine zunehmende Anzahl eingehender Fehler auf einer Netzwerkschnittstelle in der Regel dieses spezifische SFPEin Small Form-factor Pluggable (SFP) ist ein hot-plug-fähiger Transceiver, der in Datenkommunikations- und Telekommunikationsnetzen verwendet wird, um die Datenübertragung zwischen zwei Geräten zu ermöglichen. aus und weist auf ein potenzielles Problem mit anderen Komponenten des IX hin. Wichtig zu beachten: Schnittstellentyp, SFP-Typ und Kabeltyp 1 Gbps 1000BASE-LX [10km; Duplex auf SMOFEin optisches Glasfaserkabel mit kleinem Kerndurchmesser, das zu jedem Zeitpunkt nur einen einzigen Modus bzw. Lichtpfad unterstützt. Das Glasfaserkabel hat nur einen Ausbreitungsmodus: eine einzelne Wellenlänge des Lichts im Faserkern. Multimode-Glasfaser (MMOF) ist kostengünstiger, kann jedoch nur über kürzere Entfernungen ohne Signalverschlechterung betrieben werden. ] 10 Gbps 10GBASE-LR [10km; Duplex auf SMOF] 100 Gbps 100GBASE-LR4 [10km; Duplex auf SMOF] MTU (Maximale Ethernet-Frame-Größe) 9100 Bytes für VXCs zwischen Kunden-Ports. MCR und MVE unterstützen die Standard-MTU von 1500 Bytes. IX und viele CSP-Ports unterstützen keine Jumbo-Frames, aber alle unterstützen die Standard-MTU von 1500 Bytes. LAGBeschreibt verschiedene Methoden zur Nutzung mehrerer paralleler Netzwerkverbindungen, um den Durchsatz über das Limit hinaus zu erhöhen, das ein einzelner Link (eine Verbindung) erreichen kann. Im Allgemeinen gilt für Link Aggregation, dass physische Ports sich auf einem einzelnen Switch/Router befinden müssen. Protokoll: LACP Schnittstelle: 10GBASE-LR (10 Gbps) oder 100GBASE-LR4 (100 Gbps). 1 Gbps Ports werden nicht unterstützt. Maximale Anzahl von Schnittstellen in einem einzelnen LAG: 8 Multi-Chassis Link Aggregation (MC-LAG) über mehrere Geräte wird nicht unterstützt. Preferred A-End VLAN (Bevorzugtes A-Ende-VLAN) (VXC/IX) Untag (Aktiviert) – Dies beschränkt den A-End-Port auf einen einzelnen Service. Nur ein VXC/IX pro Port, entspricht einem Access-Port auf Ihrer Geräteseite. Untag (Deaktiviert) – Geben Sie die 802.1q-VLAN-Nummer am A-End-Port an. Jeder VXC wird als separates VLAN auf dem Port bereitgestellt. Dies muss eine eindeutige VLAN-ID auf dem Port sein und kann von 2 bis 4093 reichen. Wenn Sie eine bereits verwendete VLAN-ID angeben, zeigt das System die nächste verfügbare VLAN-Nummer an. Das System weist zufällig eine VLAN-Nummer zu, was einem Trunk-Port mit erlaubten VLANs auf Ihrer Geräteseite entspricht, wenn Sie die VLAN-ID leer lassen. 802.1Q Tunneling (Q-in-Q802.1Q Tunneling (auch bekannt als Q-in-Q oder 802.1ad) ist eine von OSI-Layer-2-Providern für Kunden eingesetzte Technik. 802.1ad sieht sowohl ein inneres als auch ein äußeres Tag vor, wobei das äußere (manchmal als S-Tag für Service Provider bezeichnet) entfernt werden kann, um die inneren (C-Tag oder Kunden-Tag) Tags freizulegen, die die Daten segmentieren. ) IEEE 802.1ad (Azure VXC) Zum 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, untagged VXC oder MCR.
Überprüfen, ob Schnittstelle, SFP, Kabel und Verkabelung korrekt sind	Verifizieren Sie, dass bei Gigabit-Schnittstellen Auto-Negotiation (speed auto und duplex auto) verwendet wird. Verifizieren Sie, dass das Cross-Connect-Kabel an beiden Enden mit dem richtigen Port verbunden ist. Verifizieren Sie, dass die optischen SFP-Leistungspegel (Tx und Rx) an beiden Enden ausreichendes Licht anzeigen.
Layer-2-Konfigurationen überprüfen	Verifizieren Sie, dass die MTU-Größe korrekt ist. Verifizieren Sie, dass die LACP-Konfiguration korrekt ist, wenn LAG verwendet wird. MC-LAG wird nicht unterstützt. Verifizieren Sie, dass Ihre Geräte gemäß „Preferred A-End VLAN (Bevorzugtes A-Ende-VLAN)“ im Megaport Portal konfiguriert sind. Wenn ein VLAN verwendet wird, bestätigen Sie, dass auf Ihrer Geräteseite die richtige VLAN-Nummer konfiguriert ist. Wenn Azure VXC verwendet wird, verifizieren Sie, dass Ihre Geräte eine der Q-in-Q-Methoden verwenden.
Layer-3-Konfigurationen überprüfen	Verifizieren Sie, dass die IP-Adresse der Schnittstelle und die Subnetzadresse korrekt konfiguriert sind. Verifizieren Sie, dass die Konfigurationen der Routing-Protokolle (EIGRP/OSPF/BGP) korrekt sind. Führen Sie einen Ping-Test zwischen Layer-3-Netzwerkgeräten durch (zum Beispiel Edge-Routern, BGP-Peers). Führen Sie einen Ping-Test zwischen Quell-Host und Ziel-Host durch (Ende-zu-Ende-Konnektivitätstest). Wenn der Ping-Test fehlschlägt, prüfen Sie die ARPDie Routing-Tabelle des Address Resolution Protocol (ARP) enthält eine Liste von Zuordnungen von MAC-Adressen (Layer 2) zu IP-Adressen (Layer 3). -Tabelle und die Routing-Tabelle an beiden Enden. Wenn der Ping-Test fehlschlägt und es an beiden Enden kein Problem in der Routing-Tabelle gibt, nehmen Sie dann TracerouteEin Diagnosetool, das untersucht, wie sich Datenpakete durch das Internet bewegen, um festzustellen, ob ein Ziel erreichbar ist. -Protokolle von beiden Enden auf.
Optische Leistungspegel auf dem Gerät überprüfen	Optische Lichtmesswerte vom Terminal helfen zu verstehen, ob die Werte innerhalb des Schwellenbereichs liegen. Prüfen Sie die Geräte- und Port-Diagramme auf Fehler und sehen Sie sich die Megaport optic graphs history an. Die Diagramme werden alle fünf Minuten aktualisiert; wenn Flapping selten ist, erfassen die Diagramme möglicherweise keinen Abfall des optischen Lichts. Stellen Sie sicher, dass der optische Messwert innerhalb der Spezifikationen liegt.
Führen Sie einen Ping-Test zu Route-Servern innerhalb des IX-Netzwerks und/oder bilateralen Peers durch	Ein Ping-Test sendet Datenpakete an eine bestimmte IP-Adresse und bestätigt oder verneint, ob Konnektivität zwischen IP-vernetzten Geräten besteht. Eine Bestätigung umfasst die Latenz (die Antwortzeit) der Verbindung.
Layer-2-Konnektivität (ARP) zu Route-Servern und/oder bilateralen Peers überprüfen	Layer 2 steuert den Datenfluss zwischen Knoten auf WAN- oder LAN-Segmenten und ist außerdem für das Erkennen und ggf. Korrigieren von Layer-1-Fehlern verantwortlich. Probleme mit der Layer-2-Konnektivität können die Funktionalität Ihrer VXCs beeinträchtigen, die mit Ihrem MCR verbunden sind. Beim Herstellen einer Verbindung zu einem Megaport Cloud-Konnektivität Übersicht, stellen Sie sicher, dass die VLAN-Konfigurationsdetails korrekt sind. Seien Sie besonders vorsichtig bei der Verbindung zu Azure, da Sie Q-in-Q verwenden werden. Layer-2-Konnektivitätsprobleme können auch Ihre IX-Services beeinträchtigen. MAC-Adressen werden verwendet, um Ihre Geräte bei der Nutzung von IX-Services mit Megaport zu authentifizieren. Abhängig von Ihrem Netzwerkdesign, wenn Sie mit Megaport oder anderen Organisationen Peering betreiben, stellen Sie sicher, dass Sie die korrekte MAC-Adresse im Megaport Portal angegeben haben. Führen Sie diese Prüfungen durch, bevor Sie eine Support-Anfrage einreichen: Prüfen Sie den Status Ihres IX-Services mit dem Looking Glass tool. Sie können Informationen sowohl für die primären als auch die redundanten Route-Server für Live-BGP-Daten abrufen. Layer-2-Probleme können schwieriger zu diagnostizieren sein als physische Layer-1-Probleme. Wenn Sie Megaport Details zur Layer-2-Konnektivität bereitstellen, hilft dies bei der Eingrenzung des Problems. Wenn Sie nicht direkt mit Megaport peeren, bestätigen Sie alle Konfigurationsänderungen mit dem Unternehmen, mit dem Sie Peering betreiben. Führen Sie einen Ping-Test durch, um zu verifizieren, ob Sie mit Layer 2 verbunden sind. Prüfen Sie die ARP-Tabellen und bestätigen Sie, dass die MAC-Adresse im Megaport Portal sichtbar ist. Bestätigen Sie, dass die Konfiguration den Megaport Technischen Spezifikationen entspricht. Für zusätzliche Unterstützung wenden Sie sich an Ihren Account Manager und bitten Sie um ein Meeting mit einem Megaport Solution Architect.
BGP-Konfiguration überprüfen	Schnittstelleneinstellungen, einschließlich VLAN-Nummer BGP-IP-Adresse und Subnetzmaske BGP-ASEin Autonomes System (AS) ist eine Sammlung verbundener Internet Protocol (IP)-Routing-Präfixe, die unter der Kontrolle eines oder mehrerer Netzbetreiber im Auftrag einer einzelnen administrativen Einheit oder Domäne steht. ASN steht für Autonomous System Number (AS-Nummer) und ist eine eindeutige numerische ID, die jedem AS für die Verwendung im BGP-Routing zugewiesen wird. -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 es einen Fehler bei der BGP-Sitzung erkennt, wie beispielsweise einen ablaufenden Hold-Timer, eine Änderung der Nachbarfähigkeiten oder die Anforderung zum Zurücksetzen einer BGP-Sitzung. Wenn ein Fehler erkannt wird, wird die BGP-Sitzung geschlossen. Geben Sie beispielsweise show log %BGP-xxxxx ein. Weitere Informationen finden Sie unter Internet Exchange – Übersicht.

Nächste Schritte

Wenn die Maßnahmen zur Fehlerbehebung Ihr Problem nicht lösen, wenden Sie sich an den Support. Bevor Sie Unterstützung anfordern, sammeln Sie die folgenden Informationen:

Ergebnisse der Fehlerbehebung

Geben Sie alle durchgeführten Schritte der Fehlerbehebung detailliert an. Wenn beispielsweise Loops gesetzt wurden, vermerken Sie deren Standort und in welche Richtung sie ausgerichtet waren.

Auszüge aus Netzwerkgeräte-Konfigurationen

Schnittstellenkonfigurationen
Statische Routen und Routing-Protokollkonfigurationen (EIGRP/OSPF/BGP)
Firewall-Regeln und ACL-Konfigurationen für den betroffenen Datenfluss

BGP-Befehlsausgaben und Packet-Capture-Informationen

Routing-Tabelle (show IP route <ip-address>) an beiden Enden.
Status der Routing-Protokolle und die Tabellen an beiden Enden, z. B. die BGP-Nachbartabelle, die den BGP-Status anzeigt (show ip bgp summary), und BGP-Nachbardetails (show ip bgp neighbors <neighbor-ip-address>).
BGP-Routingtabelleneinträge mit BGP-Routingproblemen (Ausgabe des Befehls show IP BGP).
BGP annoncierte Routen (show IP BGP neighbors <neighbor-ip-address> advertised-routes).
BGP empfangene Routen (Ausgabe des show IP BGP neighbors <neighbor-ip-address> routes Befehls- Routing-Tabelle (show IP route <ip-address>)).
Traceroute-Protokolle zwischen Quell- und Ziel-Host.
Packet-Capture-Protokolle, wenn möglich (Dateigröße bis zu 10 M).

Hinweis

Weitere Informationen darüber, wann ein Field-Service-Techniker vor Ort im Rechenzentrum benötigt wird, finden Sie unter Kundendienstleistungen vor Ort.