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が同じである必要があります。現在のMTU設定を確認するには、show ip int | in 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の問題の解決』を参照してください。

関連情報

• シスコのテクニカルサポートとダウンロード