MTUによるBGPネイバーフラップのトラブルシューティング

はじめに

このドキュメントでは、内部または外部のBorder Gateway Protocol（BGP；ボーダーゲートウェイプロトコル）ネイバーフラップの原因がMTUによって引き起こされていることを判別する方法について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• BGPの設定
• 最大伝送ユニット（MTU）

両方の BGP ルータに対して以下のタスクを実行してから、このドキュメントに記載されている手順を実行してください。

• BGP の設定を確認します。
• Internet Control Message Protocol（ICMP）経由で BGP ネイバーにアクセスでき、ドロップが検出されていないことを検証します。
• ピア BGP に使用されている接続インターフェイスがオーバーサブスクライブされていないこと、および入出力ドロップやエラーが存在しないことを検証します。
• CPU およびメモリの使用率を確認します。

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

問題

BGPネイバーが形成されますが、プレフィクス交換時にBGPステートがドロップし、ログにBGP helloキープアライブの欠落が生成されるか、もう一方のピアがセッションを終了します。

MTU が原因で BGP ネイバーがフラップしているかどうかを判断するために、次の手順を実行します。

1. 次のコマンドを使用して、影響を受けているネイバーと、両方のBGPルータで接続されているインターフェイスを確認します。ピアリング アドレスがループバック アドレスの場合は、ループバックで到達可能な接続インターフェイスを確認します。また、両方のピアリング ルータ上の BGP OutQ を確認します。OutQ が一貫してゼロ以外の場合、パス内の MTU の問題が原因で、更新がピアに到達できない可能性が高いです。

   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

2. 両サイドのインターフェイス MTU を確認します。

   Router#show ip int g1/0 | i MTU
     MTU is 1500 bytes
   Router#

3. TCP で認められている両方の BGP スピーカーの最大データ セグメントを確認します。

   Router#show ip bgp neigh 10.20.20.2 | inc segment
   Datagrams (max data segment is 1460 bytes):
   Router#

   前述の例では、20 バイトが TCP ヘッダーに割り当てられ、別の 20 バイトが IP ヘッダーに割り当てられるため、1,460 が正しいことになります。
   
   

4. BGP が使用されている（path-mtu が有効）かどうか確認します。

   Router#show ip bgp neigh 10.10.10.2 | in tcp
     Transport(tcp) path-mtu-discovery is enabled
   Router#

5. 最大インターフェイスMTU(Do not Fragment)ビットとDF(Do not Fragment)ビットが設定されたBGPピアに対してpingを実行します。

   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)

6. ICMP サイズの値を減らして、使用できる最大 MTU サイズを判断します。

   ping 10.10.10.2 size 1300 df 

解決方法

考えられる原因を次に示します。

• 両方のルータのインターフェイス MTU が一致していない。
• 両方のルータのインターフェイス MTU は一致しているが、BGP セッションが形成されているレイヤ 2 ドメインが一致していない。
• パス MTU ディスカバリにより、TCP BGP セッションの最大データサイズが正しくないと判断されている。
• PMTUD ICMPパケット（ファイアウォールまたはACL）がブロックされているため、BGPパス最大伝送ユニット検出(PMTUD)が失敗する可能性があります

この MTU の問題を解決する方法を次に示します。

1. 両方のルータのインターフェイスMTUは同じである必要があります。show ip int | （MTU コマンド）を実行して、現在の MTU の設定を確認します。
   
   
2. 両方のルータのインターフェイスMTUは正しいが（たとえば、1500）、DFビットが設定されたpingテストが1300を超えない場合、影響を受けたBGPセッションが形成されるレイヤ2ドメインに矛盾したMTU設定が含まれていることがあります。各レイヤ 2 インターフェイス MTU を確認し、レイヤ 2 インターフェイス MTU を修正して、問題を解決します。
   
   
3. レイヤ2ドメインを確認または変更できない場合は、ip tcp mssグローバルコマンドを1000などの小さい値に設定できます。これにより、ローカルで発信されるすべてのTCP最大データセグメントセッション（BGPを含む）が1000に強制されます。このコマンドの詳細については、『Cisco IOS® IPアプリケーションサービスコマンドリファレンス』の「ip tcp mss」セクションを参照してください。
   
   さらに、ip tcp adjust-mssコマンドを使用して、さらにトラブルシューティングを行うこともできます。このコマンドはインターフェイスレベルで設定され、すべてのTCPセッションに影響を与えます。このコマンドの詳細については、『Cisco IOS IP アプリケーション サービスのコマンド リファレンス』の「ip tcp adjust-mss」の項を参照してください。
   
   
4. (オプション)BGP Path Maximum Transmission Unit Discovery(PMTUD)は、正しい最大データサイズを生成できません。BGP PMTUD をグローバルに、またはネイバーごとに無効にして、BGP PMTUD が原因なのかどうか確認します。BGP PMTUD を無効にすると、BGP Maximum Segment Size（MSS）は、RFC 879 の定義に従い、デフォルトの 536 になります。
   
   PMTUD を無効にする方法の詳細については、『Cisco IOS BGP 構成ガイド』の「セッションごとの TCP パス MTU ディスカバリに対する BGP サポートの設定」の項を参照してください。
   
   PMTUDの詳細については、『GREおよびIPSecによるIPv4フラグメンテーション、MTU、MSS、およびPMTUDの問題の解決』を参照してください。

関連情報

• シスコテクニカルサポートおよびダウンロード