Fehlerbehebung bei "Down BGP" -Verbindungen

Unser Netzwerk hatte gestern einen kurzen Ausfall, als eine unserer BGP-Strecken für kurze Zeit ausfiel. Zum Glück sind unsere Verbindungen nach ein paar Minuten auf unsere sekundäre BGP-Route übergegangen, und die primäre Route wurde nach einem Shut / No-Shut auf der ISP-Seite betriebsbereit.

Wir verwenden zwei gestapelte Cisco 3750e-Switches (Backplane) mit iOS 12.2.

In meinem Gespräch mit unserem ISP konnten sie keine endgültigen Antworten auf die Ursache geben. Können wir irgendetwas tun, um die Ursache für unser Ende herauszufinden und dieses Problem in Zukunft zu vermeiden?

Zum Zeitpunkt des Fehlers protokollieren

172258: May  6 14:43:06: %BGP-5-ADJCHANGE: neighbor xxx.xxx.12.34 Down BGP Notification sent
172259: May  6 14:43:06: %BGP-3-NOTIFICATION: sent to neighbor xxx.xxx.12.34 4/0 (hold time expired) 0 bytes
172260: May  6 14:43:06: %BGP_SESSION-5-ADJCHANGE: neighbor xxx.xxx.12.34 IPv4 Multicast topology base removed from session  BGP Notification sent
172261: May  6 14:43:06: %BGP_SESSION-5-ADJCHANGE: neighbor xxx.xxx.12.34 IPv4 Unicast topology base removed from session  BGP Notification sent

Protokollieren Sie, wann der ISP einen Shut / No-Shut-Vorgang durchgeführt hat, um BGP auf seiner Seite zurückzusetzen

172542: May  6 15:04:15: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/49, changed state to down
172543: May  6 15:04:16: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/49, changed state to down
172544: May  6 15:04:16: %PIM-5-NBRCHG: neighbor xxx.xxx.12.34 DOWN on interface GigabitEthernet2/0/49 non DR
172545: May  6 15:04:16: %PIM-5-NBRCHG: neighbor xxx.xxx.12.34 UP on interface GigabitEthernet2/0/49 
172546: May  6 15:04:16: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to xxx.xxx.12.35 on interface GigabitEthernet2/0/49
172547: May  6 15:04:18: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/49, changed state to up
172548: May  6 15:04:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/49, changed state to up

Loggen Sie sich ein, wenn die BGP-Verbindung endlich von Leerlauf auf Hoch ging

172828: May  6 15:27:33: %BGP-5-ADJCHANGE: neighbor xxx.xxx.12.34 Up

BGP-Schnittstelle auf unserer Seite (Hinweis: kein CRC, Stürze, Kollisionen gemeldet ...)

GigabitEthernet2/0/49 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is xxxx.xxxx
Internet address is xxx.xxx.12.35/31
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 3/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseLX SFP
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:09, output 00:00:12, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/52/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 14536000 bits/sec, 1655 packets/sec
5 minute output rate 1010000 bits/sec, 640 packets/sec
413176726 packets input, 428902543141 bytes, 0 no buffer
Received 143495 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 139275 multicast, 0 pause input
0 input packets with dribble condition detected
125748632 packets output, 42915625632 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

172259: 6. Mai, 14:43:06 Uhr:% BGP-3-NOTIFICATION: an Nachbarn gesendet xxx.xxx.12.34 4/0 (Haltezeit abgelaufen) 0 Byte

Das bedeutet im Allgemeinen, dass die andere Seite der Verbindung nicht auf Keepalives innerhalb des Hold-Timers reagiert hat (Standard: 180 Sekunden). Es gibt eine Vielzahl von Problemen, die dies verursacht haben könnten. Normalerweise handelt es sich um ein Problem mit der Erreichbarkeit der Ebene 3. Wenn es wieder vorkommt, sollten Sie das Layer3-Problem ausschließen, indem Sie dem Peer über Ping und Telnet (Telnet an Port 179, prüfen Sie, ob es antwortet) einen Test unterbreiten.

Wenn es sich nicht um ein Problem mit der Erreichbarkeit der Ebene 3 handelt, liegt ein Problem mit einem Ende der Nachbarschaft vor (in diesem Fall eher mit der Gegenseite).

Wenn Sie nur nach der Ursache dieses Problems suchen:

Möglicherweise möchten Sie Ihren Provider fragen, ob unmittelbar vor diesem Ereignis Konfigurationsänderungen an dessen Ende vorgenommen wurden. Es gibt Fälle auf Cisco-Routern (bei denen nicht 100% sicher ist, welcher Code sich gerade dreht), in denen BGP-Sitzungen aufflammen, wenn eine Seite eine "Routenkarte" mit einer "mpls-ip" und / oder einer "mtu" entfernt und erneut hinzufügt "Konfiguration im BGP - Peering. Obwohl diese Art der Wartung keine Probleme mit der Peeringsitzung verursachen sollte, habe ich davon gehört.

Ich bin mir auch nicht sicher, ob sie die Schnittstelle löschen und neu starten müssten, um das Problem zu beheben. Ich denke, ein einfaches Zurücksetzen der Peering-Sitzung hätte ausgereicht, aber wenn zum Zeitpunkt des Ausfalls kein Datenverkehr übertragen wurde, könnte man argumentieren, dass es keine Rolle spielt, dass sie die Schnittstelle fallen lassen, um die Dinge wieder zum Laufen zu bringen.

Es könnte ein MTU-Problem sein. Hatte das vor einer Weile. Startet einwandfrei, aber wenn ein UPDATE mit vielen Routen empfangen wird, geht es aufgrund einer MTU-Nichtübereinstimmung verloren. Auch wenn Sie L2-Geräte (Switch? Media Converter?) Zwischen Ihren beiden Routern haben, kann es sein, dass die Verbindung unterbrochen wird, ohne dass die Schnittstelle ausfällt.

Nicht von dem, was ich sehe. Der Router Ihres Internetdienstanbieters reagiert nicht mehr auf die Begrüßungsnachrichten Ihres Routers, weshalb Sie Ihre BGP-Verbindung verloren haben. Es ist auch möglich, dass Ihr Router die Begrüßungsnachrichten des Internetdienstanbieters nicht mehr abhört. In den Nachrichten wird jedoch nichts angezeigt, was zur Klärung des Problems beitragen könnte. Vielleicht kann jemand, der sich mehr auf die ISP-Spur konzentriert, etwas kommentieren und Licht ins Dunkel bringen?