Einleitung
In diesem Dokument wird beschrieben, wie Sie die Ursache von BGP-Nachbarn (Border Gateway Protocol) ermitteln, die durch MTU verursacht werden.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
- BGP-Konfiguration
- Maximum Transmission Unit (MTU)
Bevor Sie die in diesem Dokument beschriebenen Schritte durchführen, müssen Sie auf beiden BGP-Routern folgende Schritte durchführen:
- Überprüfen der BGP-Konfiguration
- Stellen Sie sicher, dass der BGP-Nachbar über das Internet Control Message Protocol (ICMP) erreichbar ist und keine Unterbrechungen festgestellt werden.
- Vergewissern Sie sich, dass die für das Peer-BGP verwendete Schnittstelle nicht überbelegt ist und keine Eingabe-/Ausgabelücken oder -fehler aufweist.
- Überprüfen der CPU- und Speichernutzung
Verwendete Komponenten
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Problem
Es bilden sich BGP-Nachbarn. Beim Präfixaustausch wird der BGP-Status jedoch gelöscht, und die Protokolle generieren fehlende BGP Hello-Keepalives, oder der andere Peer beendet die Sitzung.
Gehen Sie wie folgt vor, um zu bestimmen, ob die MTU zu Flapping für die BGP-Nachbarn führt:
- Mit den nächsten Befehlen können Sie überprüfen, welcher Nachbar betroffen ist und welche Schnittstelle an beiden BGP-Routern angeschlossen ist. Wenn die Peering-Adresse eine Loopback-Adresse ist, überprüfen Sie die verbundene Schnittstelle, über die der Loopback erreichbar ist. Überprüfen Sie außerdem, ob BGP OutQ auf beiden Peering-Routern vorhanden ist. Der konsistente OutQ ungleich null ist ein starkes Indiz dafür, dass Updates den Peer aufgrund eines MTU-Problems im Pfad nicht erreichen.
Router#show ip bgp summ | in InQ|10.10.10.2
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.10.2 4 3 64 62 3 0 0 00:00:3 2
Router#show ip route 10.10.10.2
Routing entry for 10.10.10.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet1/0
Route metric is 0, traffic share count is 1
- Überprüfen Sie die Schnittstellen-MTU auf beiden Seiten:
Router#show ip int g1/0 | i MTU
MTU is 1500 bytes
Router#
- Bestätigen Sie das vereinbarte maximale TCP-Datensegment für beide BGP-Router:
Router#show ip bgp neigh 10.20.20.2 | inc segment
Datagrams (max data segment is 1460 bytes):
Router#
Im obigen Beispiel ist 1460 richtig, da dem TCP-Header 20 Byte und dem IP-Header weitere 20 Byte zugewiesen werden.
- Vergewissern Sie sich, ob path-mtu vom BGP aktiviert ist:
Router#show ip bgp neigh 10.10.10.2 | in tcp
Transport(tcp) path-mtu-discovery is enabled
Router#
- Pingen des BGP-Peers mit max. Schnittstellen-MTU- und DF-Bitsatz (nicht fragmentieren):
Router#ping 10.10.10.2 size 1500 df
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)
- Verringern Sie den ICMP-Größenwert, um die maximal verwendbare MTU-Größe zu bestimmen:
ping 10.10.10.2 size 1300 df
Lösung
Hier einige mögliche Ursachen:
- Die Schnittstellen-MTU auf beiden Routern stimmt nicht überein.
- Die Schnittstellen-MTU auf beiden Routern stimmt überein, aber die Layer-2-Domäne, über die die BGP-Sitzung gebildet wird, stimmt nicht überein.
- Die MTU-Pfaderkennung hat die falsche maximale Datengröße für die TCP-BGP-Sitzung ermittelt.
- Die PMTUD (Maximum Transmission Unit Discovery) des BGP-Pfads kann aufgrund blockierter PMTUD-ICMP-Pakete (Firewall oder ACL) fehlschlagen.
Es gibt folgende Möglichkeiten, MTU-Probleme zu beheben:
- Die MTU-Größe der Schnittstelle auf beiden Routern muss identisch sein. Führen Sie den Befehl show ip int aus. | im MTU-Befehl, um die aktuellen MTU-Einstellungen zu überprüfen.
- Wenn die Schnittstellen-MTU auf beiden Routern korrekt ist (z. B. 1500), die Ping-Tests mit festgelegtem DF-Bit jedoch 1300 nicht überschreiten, kann die Layer-2-Domäne, auf der die betroffene BGP-Sitzung gebildet wird, inkonsistente MTU-Konfigurationen enthalten. Überprüfen Sie jede Layer-2-Schnittstellen-MTU. Korrigieren Sie die MTU der Layer 2-Schnittstelle, um das Problem zu beheben.
- Wenn Sie die Layer-2-Domäne nicht überprüfen/ändern können, können Sie den globalen Befehl ip tcp mss auf einen kleineren Wert wie 1000 festlegen, wodurch alle lokalen TCP-Datensegmentsitzungen (einschließlich BGP) auf 1000 festgelegt werden können. Weitere Informationen zu diesem Befehl finden Sie im Abschnitt ip tcp mss der Cisco IOS® IP Application Services Command Reference.
Darüber hinaus können Sie den Befehl ip tcp adjust-mss verwenden, um die Fehlerbehebung fortzusetzen. Dieser Befehl wird auf Schnittstellenebene konfiguriert und wirkt sich auf alle TCP-Sitzungen aus. Weitere Informationen zu diesem Befehl finden Sie im Abschnitt ip tcp adjust-mss der Cisco IOS IP Application Services Command Reference.
- (Optional) Die BGP Path Maximum Transmission Unit Discovery (PMTUD) kann nicht die richtige maximale Datengröße generieren. Sie können die Funktion global oder pro Nachbar deaktivieren, um zu überprüfen, ob dies die Ursache ist. Wenn die BGP PMTUD deaktiviert ist, beträgt die BGP Maximum Segment Size (MSS) standardmäßig 536, wie in RFC 879 definiert.
Weitere Informationen zum Deaktivieren der PMTUD finden Sie im Abschnitt Configuring BGP Support for TCP Path MTU Discovery per Session im Cisco IOS BGP Configuration Guide.
Weitere Informationen zur PMTUD finden Sie unter Lösen von IPv4-Fragmentierung, MTU, MSS und PMTUD-Problemen mit GRE und IPsec.
Zugehörige Informationen
Feedback