「ダウンBGP」接続のトラブルシューティング

昨日、BGPルートの1つが短時間停止したときに、ネットワークが短時間停止しました。ありがたいことに、数分後に接続がセカンダリBGPルートにフェイルオーバーし、ISP側でシャット/ノーシャット後にプライマリルートが動作可能になりました。

iOS 12.2 58を実行する2つのスタック（バックプレーン）Cisco 3750eスイッチを実行しています。

ISPとの会話で、彼らは原因に対する明確な答えを出すことができませんでした。この問題を将来回避するために、私たちの目的を特定するためにできることはありますか？

エラー発生時のログ

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

ISPが側でBGPをリセットするためにshut / no shutを実行したときにログに記録します

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

BGP接続が最終的にアイドルからアップになったときにログを記録します

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

終端のBGPインターフェイス（注：CRC、ドロップ、コリジョンの報告なし...）

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：5月6日14:43:06：％BGP-3-NOTIFICATION：送信されたネイバーxxx.xxx.12.34 4/0（有効期限が切れた）0バイト

これは通常、接続の反対側がホールドタイマー内のキープアライブに応答しなかったことを意味します（デフォルトは180秒）。これを引き起こす可能性のあるさまざまな問題があります。通常、layer3の到達可能性の問題です。再び発生する場合は、pingおよびtelnet（ポート179へのtelnet、応答するかどうかを確認）を介してピアに対してテストすることにより、layer3の問題を除外する必要があります。

レイヤ3の到達可能性の問題ではない場合、隣接関係の一方の端に問題がありました（この場合は、おそらく向こう側）。

この問題を単に「根本原因」にしたい場合：

プロバイダーに、これが発生する直前に構成変更が行われたかどうかを尋ねることができます。片方が「mpls-ip」および/または「mtu」を含む「route-map」を削除して再追加すると、BGPセッションがフラップするCiscoルータのインスタンスがありますBGPピアリングの設定。この種のメンテナンスはピアリングセッションで問題を引き起こすことはありませんが、この出来事の話を聞いたことがあります。

また、インターフェイスを削除して問題を「修正」するために元に戻すまで、彼らが必要とするかどうかはわかりません。ピアリングセッションをリセットするだけで十分だと思いますが、障害時に通過するトラフィックがなかった場合、インターフェイスをドロップして問題が再び発生することは問題ではないと主張することができます。

MTUの問題である可能性があります。これは少し前にありました。正常に起動しますが、多数のルートを含むUPDATEを受信すると、MTUの不一致により失われます。また、2つのルーター間にL2デバイス（スイッチ？メディアコンバーター？）がある場合、インターフェイスがダウンせずに接続が中断される可能性があります。

私が見ているものからではありません。ISPのルーターは、ルーターからのhelloメッセージへの応答を停止します。これが、BGP接続を失った理由です。また、ルーターがISPからのhelloメッセージを聞くのをやめることもありますが、問題を特定するのに役立つメッセージには明らかなものは見当たりません。ISPトラックにもっと焦点を合わせた誰かがコメントして、光を当てることができるかもしれません。