メインコンテンツまでスキップ

6. BGP Error Handling (BGPエラー処理)

  1. BGP Error Handling (BGPエラー処理)

    本セクションでは、BGPメッセージの処理中にエラーが検出された場合に実行すべきアクションについて説明します。

    ここで説明する条件のいずれかが検出された場合、指定されたError Code、Error Subcode、およびDataフィールドを含むNOTIFICATIONメッセージが送信され、BGP接続が閉じられます（NOTIFICATIONメッセージを送信せず、BGP接続を閉じないことが明示的に記載されている場合を除く）。Error Subcodeが指定されていない場合は、0を使用しなければなりません (MUST)。

    「BGP接続が閉じられる」という表現は、TCP接続が閉じられ、関連するAdj-RIB-Inがクリアされ、そのBGP接続のすべてのリソースが解放されることを意味します。リモートピアに関連するLoc-RIB内のエントリは無効とマークされます。ローカルシステムは、無効とマークされたルートの宛先に対する最良ルートを再計算します。無効なルートがシステムから削除される前に、無効とマークされたルートの撤退、または新しい最良ルートのいずれかをピアにアドバタイズします。

    明示的に指定されていない限り、エラーを示すために送信されるNOTIFICATIONメッセージのDataフィールドは空です。

6.1. Message Header Error Handling (メッセージヘッダーエラー処理)

Message Headerの処理中に検出されたすべてのエラーは、Error Code Message Header ErrorのNOTIFICATIONメッセージを送信することによって示さなければなりません (MUST)。Error Subcodeはエラーの具体的な性質を詳しく説明します。

メッセージヘッダーのMarkerフィールドの期待値はすべて1です。メッセージヘッダーのMarkerフィールドが期待どおりでない場合、同期エラーが発生しており、Error SubcodeをConnection Not Synchronizedに設定しなければなりません (MUST)。

以下の少なくとも1つが真である場合:

  • メッセージヘッダーのLengthフィールドが19未満または4096を超える場合、または

  • OPENメッセージのLengthフィールドがOPENメッセージの最小長未満である場合、または

  • UPDATEメッセージのLengthフィールドがUPDATEメッセージの最小長未満である場合、または

  • KEEPALIVEメッセージのLengthフィールドが19でない場合、または

  • NOTIFICATIONメッセージのLengthフィールドがNOTIFICATIONメッセージの最小長未満である場合、

Error SubcodeをBad Message Lengthに設定しなければなりません (MUST)。Dataフィールドには、誤ったLengthフィールドを含めなければなりません (MUST)。

メッセージヘッダーのTypeフィールドが認識されない場合、Error SubcodeをBad Message Typeに設定しなければなりません (MUST)。Dataフィールドには、誤ったTypeフィールドを含めなければなりません (MUST)。

6.2. OPEN Message Error Handling (OPENメッセージエラー処理)

OPENメッセージの処理中に検出されたすべてのエラーは、Error Code OPEN Message ErrorのNOTIFICATIONメッセージを送信することによって示さなければなりません (MUST)。Error Subcodeはエラーの具体的な性質を詳しく説明します。

受信したOPENメッセージのVersionフィールドのバージョン番号がサポートされていない場合、Error SubcodeをUnsupported Version Numberに設定しなければなりません (MUST)。Dataフィールドは2オクテットの符号なし整数であり、リモートBGPピアが提示したバージョン（受信したOPENメッセージに示されている）よりも小さい、ローカルでサポートされている最大のバージョン番号を示します。または、ローカルでサポートされている最小のバージョン番号がリモートBGPピアが提示したバージョンよりも大きい場合は、ローカルでサポートされている最小のバージョン番号を示します。

OPENメッセージのAutonomous Systemフィールドが受け入れられない場合、Error SubcodeをBad Peer ASに設定しなければなりません (MUST)。受け入れ可能なAutonomous System番号の決定は、このプロトコルの範囲外です。

OPENメッセージのHold Timeフィールドが受け入れられない場合、Error SubcodeをUnacceptable Hold Timeに設定しなければなりません (MUST)。実装は、1秒または2秒のHold Time値を拒否しなければなりません (MUST)。実装は、提案されたHold Timeを拒否してもかまいません (MAY)。Hold Timeを受け入れる実装は、Hold Timeに交渉された値を使用しなければなりません (MUST)。

OPENメッセージのBGP Identifierフィールドが構文的に正しくない場合、Error SubcodeをBad BGP Identifierに設定しなければなりません (MUST)。構文的正しさとは、BGP IdentifierフィールドがユニキャストIPホストアドレスを表すことを意味します。

OPENメッセージ内のOptional Parametersの1つが認識されない場合、Error SubcodeをUnsupported Optional Parametersに設定しなければなりません (MUST)。

OPENメッセージ内のOptional Parametersの1つが認識されるが、不正な形式である場合、Error Subcodeを0 (Unspecific) に設定しなければなりません (MUST)。

6.3. UPDATE Message Error Handling (UPDATEメッセージエラー処理)

UPDATEメッセージの処理中に検出されたすべてのエラーは、Error Code UPDATE Message ErrorのNOTIFICATIONメッセージを送信することによって示さなければなりません (MUST)。Error Subcodeはエラーの具体的な性質を詳しく説明します。

UPDATEメッセージのエラーチェックは、パス属性を調べることから始まります。Withdrawn Routes LengthまたはTotal Attribute Lengthが大きすぎる場合（つまり、Withdrawn Routes Length + Total Attribute Length + 23がメッセージLengthを超える場合）、Error SubcodeをMalformed Attribute Listに設定しなければなりません (MUST)。

認識された属性にAttribute Type Codeと競合するAttribute Flagsがある場合、Error SubcodeをAttribute Flags Errorに設定しなければなりません (MUST)。Dataフィールドには、誤った属性（type、length、およびvalue）を含めなければなりません (MUST)。

認識された属性に、期待される長さ（属性タイプコードに基づく）と競合するAttribute Lengthがある場合、Error SubcodeをAttribute Length Errorに設定しなければなりません (MUST)。Dataフィールドには、誤った属性（type、length、およびvalue）を含めなければなりません (MUST)。

既知の必須属性のいずれかが存在しない場合、Error SubcodeをMissing Well-known Attributeに設定しなければなりません (MUST)。Dataフィールドには、欠落している既知の属性のAttribute Type Codeを含めなければなりません (MUST)。

既知の必須属性のいずれかが認識されない場合、Error SubcodeをUnrecognized Well-known Attributeに設定しなければなりません (MUST)。Dataフィールドには、認識されない属性（type、length、およびvalue）を含めなければなりません (MUST)。

ORIGIN属性に未定義の値がある場合、Error SubcodeをInvalid Origin Attributeに設定しなければなりません (MUST)。Dataフィールドには、認識されない属性（type、length、およびvalue）を含めなければなりません (MUST)。

NEXT_HOP属性フィールドが構文的に正しくない場合、Error SubcodeをInvalid NEXT_HOP Attributeに設定しなければなりません (MUST)。Dataフィールドには、正しくない属性（type、length、およびvalue）を含めなければなりません (MUST)。構文的正しさとは、NEXT_HOP属性が有効なIPホストアドレスを表すことを意味します。

NEXT_HOP内のIPアドレスは、意味的に正しいと見なされるために、次の基準を満たさなければなりません (MUST):

a) 受信スピーカーのIPアドレスであってはなりません (MUST NOT)。

b) EBGPの場合、送信者と受信者が互いに1 IPホップ離れている場合、NEXT_HOP内のIPアドレスは、BGP接続を確立するために使用される送信者のIPアドレスであるか、またはNEXT_HOP IPアドレスに関連するインターフェイスが、受信BGPスピーカーと共通のサブネットを共有していなければなりません (MUST)。

NEXT_HOP属性が意味的に正しくない場合、エラーをログに記録すべきであり (SHOULD)、ルートを無視すべきです (SHOULD)。この場合、NOTIFICATIONメッセージを送信すべきではなく (SHOULD NOT)、接続を閉じるべきではありません (SHOULD NOT)。

AS_PATH属性は構文的正しさがチェックされます。パスが構文的に正しくない場合、Error SubcodeをMalformed AS_PATHに設定しなければなりません (MUST)。

UPDATEメッセージが外部ピアから受信された場合、ローカルシステムは、AS_PATH属性の最も左側（プロトコルメッセージ内のオクテットの位置に関して）のASが、メッセージを送信したピアの自律システム番号と等しいかどうかをチェックしてもかまいません (MAY)。チェックでこれが該当しないと判断された場合、Error SubcodeをMalformed AS_PATHに設定しなければなりません (MUST)。

オプション属性が認識される場合、この属性の値をチェックしなければなりません (MUST)。エラーが検出された場合、属性を破棄しなければならず (MUST)、Error SubcodeをOptional Attribute Errorに設定しなければなりません (MUST)。Dataフィールドには、属性（type、length、およびvalue）を含めなければなりません (MUST)。

UPDATEメッセージに同じ属性が複数回出現する場合、Error SubcodeをMalformed Attribute Listに設定しなければなりません (MUST)。

UPDATEメッセージ内のNLRIフィールドは、構文的妥当性がチェックされます。フィールドが構文的に正しくない場合、Error SubcodeをInvalid Network Fieldに設定しなければなりません (MUST)。

NLRIフィールド内のプレフィックスが意味的に正しくない場合（例: 予期しないマルチキャストIPアドレス）、エラーをローカルでログに記録すべきであり (SHOULD)、プレフィックスを無視すべきです (SHOULD)。

正しいパス属性を含むが、NLRIを含まないUPDATEメッセージは、有効なUPDATEメッセージとして扱われなければなりません (SHALL)。

6.4. NOTIFICATION Message Error Handling (NOTIFICATIONメッセージエラー処理)

ピアがNOTIFICATIONメッセージを送信し、メッセージの受信者がそのメッセージ内でエラーを検出した場合、受信者はこのエラーをピアに報告するためにNOTIFICATIONメッセージを使用できません。そのようなエラー（例: 認識されないError CodeまたはError Subcode）は、認識され、ローカルでログに記録され、ピアの管理者の注意を喚起すべきです (SHOULD)。ただし、これを行う手段は、この文書の範囲外です。

6.5. Hold Timer Expired Error Handling (Hold Timerの期限切れエラー処理)

システムが、OPENメッセージのHold Timeフィールドで指定された期間内に、連続するKEEPALIVE、UPDATE、および/またはNOTIFICATIONメッセージを受信しない場合、Hold Timer Expired Error CodeのNOTIFICATIONメッセージが送信され、BGP接続が閉じられます。

6.6. Finite State Machine Error Handling (有限状態機械エラー処理)

BGP有限状態機械によって検出されたエラー（例: 予期しないイベントの受信）は、Error Code Finite State Machine ErrorのNOTIFICATIONメッセージを送信することによって示されます。

6.7. Cease (中止)

致命的なエラー（このセクションで示されている）がない場合、BGPピアは、いつでも、Error Code CeaseのNOTIFICATIONメッセージを送信することによって、そのBGP接続を閉じることを選択してもかまいません (MAY)。ただし、このセクションで示されている致命的なエラーが存在する場合、Cease NOTIFICATIONメッセージを使用してはなりません (MUST NOT)。

BGPスピーカーは、ネイバーから受け入れる意思があるアドレスプレフィックスの数にローカルで設定された上限を課す機能をサポートしてもかまいません (MAY)。上限に達した場合、スピーカーは、ローカル設定の制御下で、(a) ネイバーからの新しいアドレスプレフィックスを破棄する（ネイバーとのBGP接続を維持しながら）、または (b) ネイバーとのBGP接続を終了します。BGPスピーカーが、ネイバーから受信したアドレスプレフィックスの数がローカルで設定された上限を超えたためにネイバーとのBGP接続を終了することを決定した場合、スピーカーは、ネイバーにError Code CeaseのNOTIFICATIONメッセージを送信しなければなりません (MUST)。スピーカーはこれをローカルでログに記録してもかまいません (MAY)。

6.8. BGP Connection Collision Detection (BGP接続の衝突検出)

BGPスピーカーのペアが同時に互いにBGP接続を確立しようとすると、2つの並列接続が形成されます。これらの接続の1つで使用されるソースIPアドレスが、もう一方で使用される宛先IPアドレスと同じであり、最初の接続で使用される宛先IPアドレスが、もう一方で使用されるソースIPアドレスと同じである場合、接続の衝突が発生しています。接続の衝突の場合、接続の1つを閉じなければなりません (MUST)。

BGP識別子の値に基づいて、衝突が発生したときに保持されるBGP接続を検出するための慣例が確立されます。慣例は、衝突に関与するピアのBGP識別子を比較し、より高い値のBGP識別子を持つBGPスピーカーによって開始された接続のみを保持することです。

OPENメッセージを受信すると、ローカルシステムは、OpenConfirm状態にあるすべての接続を調べなければなりません (MUST)。BGPスピーカーは、プロトコル外の手段でピアのBGP識別子を知っている場合、OpenSent状態の接続も調べてもかまいません (MAY)。これらの接続の中に、BGP識別子がOPENメッセージ内のものと等しいリモートBGPスピーカーへの接続があり、この接続がOPENメッセージが受信された接続と衝突する場合、ローカルシステムは次の衝突解決手順を実行します:

  1. ローカルシステムのBGP識別子は、リモートシステムのBGP識別子（OPENメッセージで指定されている）と比較されます。BGP識別子の比較は、ホストバイトオーダーに変換し、4オクテットの符号なし整数として扱うことによって行われます。

  2. ローカルBGP識別子の値がリモートの値よりも小さい場合、ローカルシステムは、既に存在するBGP接続（既にOpenConfirm状態にあるもの）を閉じ、リモートシステムによって開始されたBGP接続を受け入れます。

  3. それ以外の場合、ローカルシステムは、新しく作成されたBGP接続（新しく受信したOPENメッセージに関連付けられているもの）を閉じ、既存のもの（既にOpenConfirm状態にあるもの）を引き続き使用します。

設定で許可されていない限り、Established状態にある既存のBGP接続との接続の衝突により、新しく作成された接続が閉じられます。

接続の衝突は、Idle、Connect、またはActive状態にある接続では検出できないことに注意してください。

（衝突解決手順から生じる）BGP接続の閉鎖は、Error Code CeaseのNOTIFICATIONメッセージを送信することによって達成されます。

に最終更新