6. BGPのエラー処理 このセクションは、BGPのメッセージ処理において発生するエラーを検知したときの処 理について記述します。 6.2 OPENメッセージエラーハンドリング すべてのエラーは、NOTIFICATIONメッセージのエラーコードがOPEN Messeage Errorで ある送信によって指摘されるOPENメッセージの処理過程によって検出されます。エラー のSubCodeはエラー性質の定義によって作り出されます。 もし、受信したOPENメッセージのVersionフィールドにあるバージョン番号がサポート されていなければ、エラーのSubCodeはUnsupported Version Numberがセットさせます。 データフィールドは、リモートのBGP Peerから（受信したOPENメッセージで指摘される） 送られてきたバージョンを超えない、ローカルにサポートされる最大のバージョン番号 が２オクテットのunsigned integerです。 もし、OPENメッセージのAutonomous NumberフィールドがAcceptできないのであれば、 エラーのSubCodeはBad Peer ASにセットされます。AcceptするAS番号の決定は、この プロトコルの範疇外です。 もし、OPENメッセージのHold TimeフィールドがAcceptできないのであれば、必ず エラーのSubCodeをUnacceptable Hold Timeをセットしなくてはなりません。インプリ メンテーションは１秒または２秒の値のHold Timerを必ず拒否しなくてはなりません。 あるインプリメンテーションは、幾つかのHold Timeの提案を拒否するでしょう。 Hold TimeをAcceptするあるインプリメンテーションは、必ずHold Timeについて交渉 された値を使います。 もし、OPENメッセージのBGP Identifierフィールドが文法的に正しくなければ、エラー のSubCodeにはBad BGP Idetifierがセットされます。文法的に正しいということは、BGP Identifierフィールドが正しいIPアドレスが表現されているということを意味します。 もし、OPENメッセージの中のオプションパラメータの一つが認証されなければ、エラー のSubCodeにはUnsupported Optional Parametersがセットされます。 もし、OPENメッセージが（オプションパラメータとして）認証情報を転送してきたな らば、相当する認証手続きが呼び出されます。もし、（認証コードと認証データを基本 とした）認証手続きが失敗したならば、エラーのSubCodeはAuthentication Failureに セットされます。 6.3 UPDATEメッセージエラーハンドリング 全てのエラーは、NOTIFICATIONメッセージのエラーコードがUPDATE Message Errorで ある送信によって指摘されるUPDATEメッセージの処理仮定によって検出されます。エラー のSubCodeはエラー性質の定義によってつくり出されます。 UPDATEメッセージのエラー処理は、PATH Attributeの検査によって開始されます。もし、 Unfeasible Route Length、または、Total Attribute Lengthが大き過ぎる場合(Unfeasible Route Length + Total Attribute Length + 23の値がメッセージ長を越える場合など)は、 エラーのSubCodeにはMalformed Attribute Listがセットされます。 もし、いくつかの認められた属性がAttribute Type Codeと矛盾したAttribute Lengthを 持つならば、エラーのSubCodeにはAttribute Flag Errorがセットされます。データフィー ルドは、誤りの属性(Type,Lengthそして、その値)を含みます。 もし、いくつかの認められた属性が(Attribute Type Codeを基として、)Expected Length と矛盾したAttribute Lengthを持つならば、エラーのSubCodeにはAttribute Length Error がセットされます。データフィールドは、誤りの属性(Type,Lenghtそして、その値)を含み ます。 もし、命令のWell-Known属性のいづれかが提供されない場合、エラーのSubCodeには、 Missing well-known Attributeがセットされます。データフィールドは、提供されていない well-known属性の属性Type Codeを含みます。 もし、命令のWell-Known属性のいづれかが認められない場合、エラーのSubCodeには、 Unrecognized Well-known Attributeがセットされます。データフィールドは、認められない 属性(Type,Lenghtそして、その値)が含まれます。 もし、ORIGIN属性が未定義の値であれば、エラーのSubCodeはInvalid Origin Attribute がセットされます。データフィールドは、認められない属性(Type,Lengthそして、その値) が含まれます。 もし、NEXT_HOP属性フィールドが文法的に適正でなければ、エラーのSubCodeにはInvalid NEXT_HOP Attributeがセットされます。データフィールドは、適正でない属性(Type,Length そして、その値)が含まれます。適正な文法とは、NEXT_HOP属性が正当なIP Addressを提供 していると言う事を意味します。適正という意味に関しては、外部へのBGPリンクにのみ適用 します。それは、受信したBGP SpeakerのIP Addressではない、そして、受信したBGP Speakerと共通のsubnetを共有するNEXT_HOP属性で定義されるようなIP Addressと結び付く インターフェースであると言う事を意味します。もし、NEXT_HOP属性が不適正を意味して いるのであれば、エラーはログに出力され、そして、その経路は無視されるでしょう。 この様な場合、NOTIFICATIONメッセージは送信されないでしょう。 AS_PATH属性は、文法的適正さをチェックされます。もし、pathが文法的に正しく不適正 であれば、エラーのSubCodeにはMalformed AS_PATHがセットされます。 もし、付加的な属性が認められる場合は、この属性の値はチェックされます。もし、エ ラーが検出されれば、属性は捨てられ、そして、エラーのSubCodeにはOptional Attribute Errorがセットされます。データフィールドは、属性(Type,Lengthそして、その値)を含み ます。 もし、いづれかの属性がUPDATEメッセージの中でもう一度出現した場合、エラーのSubCode には、Malformed Attribute Listがセットされます。 UPDATEメッセージ中のNLRIフィールドは、文法的な適正がチェックされます。もし、 フィールドが文法的に不適正であれば、エラーのSubCodeはInvalid Network Fieldをセッ トします。 6.4 NOTIFICATIONメッセージエラーハンドリング もし、PeerがNOTIFICATIONメッセージを送信し、そのメッセージにエラーが存在する場合 は、このエラーを通して後のNOTIFICATIONメッセージをレポートする事は不適当であり意味 はありません。いくつかのそのようなエラー、そのような認められないエラーコードまた は、エラーのSubCodeは、警告し、ログに出力され、そして、peerの管理に警告を促します。 この行動の意味は、しかしながら、このドキュメントの範疇ではありません。 6.5 Hold Timer時間切れエラーハンドリング もし、システムがOPENメッセージのHold Timerフィールドで定義される期間内に NOTIFICATION、UPDATE、KEEPALIVEのいづれかのメッセージが正常に受信しなければ、 Hole Timer Expiredのエラーコードを持った、NOTIFICATIONメッセージを送信し、BGPセッ ションを閉じなくてはなりません。 6.6 状態遷移機構エラーハンドリング BGP状態遷移機構によるいづれかのエラー(例えば、期待しないイベントの受信など)は、 エラーコードがFinite State Machine ErrorのNOTIFICATIONメッセージを送信することに よって指摘されます。 6.7 事例 (このセクションで指摘されている)いづれかの致命的エラーの欠如がある場合において、 BGP Peerは、エラーコードの事象のNOTIFICATIONメッセージを送信することにより、与えら れているどの時間においてもそのBGPセッションを閉じる事を選択するでしょう。しかしな がら、NOTIFICATIONメッセージの事象は、致命的エラーがこのセクションが存在することに よって検出される時には利用してはなりません。 6.8 Connection Collision Detection もし、１対のBGP Peerが互いのTCP接続を同時に確立させようとした場合、このSpeaker のペアの間の２つの並行した接続は旨く形成される事になります。我々はこの状況を接続 衝突(Connection Collision)と呼びます。明確には、それらの接続の一つは閉じられなく てはなりません。 BGP Identifierの値を基本とする慣例は、衝突が発生する時に維持されているBGP接続 の検出の為に確立(Establish)される。この慣例は、大きいBGP-IDによって開始された接 続のみを維持し、そして、衝突を含むPeerのBGP-IDを比較する事です。 OPENメッセージを受け取る上で、ローカルシステムはOpenConfirm状態においてそれら 全ての接続を検査しなくてはなりません。BGP Speakerが、もし、プロトコルの範疇外で PeerのBGP-IDを知っているのであれば、OpenSend状態においても接続の検索を行った方が よいでしょう。もし、これらの接続の中にリモートのBGP Speakerとの接続におけるBGP-ID とOPENメッセージに含まれるそれと同一の物があれば、ローカルシステムは書きに示す 衝突解決処理を実行します。 1.ローカルシステムのBGP-IDは(OPENメッセージで定義される)リモートシステムのBGP-ID と比較されます。 2.もし、ローカルのBGP-IDの値が、リモートの値より小さいならば、ローカルシステム は、(すでにOpenConfirm状態である)すでに存在しているBGP接続を閉じ、そして、 リモートシステムによって開始されるBGP接続を承認します。 3.別の方法としては、ローカルシステムは、新しく作成したBGP接続(新しく受信した OPENメッセージと結び付いたもの)を閉じ、(既に存在しているOpenConfirm状態の である)存在しているものを使い続けます。 比較対象のBGP-IDは(４オクテットの)符号無し整数で扱うものによって行われます。 BGP接続の存在に伴う接続衝突は、Established状態において、新しく作成された接続の 無条件切断が起こります。接続衝突において注意が必要なことは、Idle、Connectおよび Active状態の接続状態では検出できないと言う事です。 (衝突解決処理の結果によって)BGP接続を閉じるのは、その事象のエラーコード を伴うNOTIFICATIONメッセージを送る事によって成し遂げられます。 7. BGPバージョンネゴシエーション BGP Speakerは、BGP接続を開く事を多様に試みることによってプロトコルのバージョン を調整し、互いにサポートする一番大きいバージョンによって開始します。もし、オープ ンの試みがエラーコードがOPEN Message Errorで失敗するか、エラーのSubCodeが Unsupported Version Numberである場合には、BGP Speakerは存在するバージョンで試み 、そのPeerのバージョン番号で試み、NOTIFICATIONメッセージでのそのPeerによってパス されるバージョン番号、そして、そこでサポートするバージョン番号を試みます。もし、 ２つのPeerが１つ以上のバージョンをサポートする場合、一番大きい共通のバージョンを 迅速に決定する事が可能でしょう。BGPのバージョンネゴシエーションをサポートする為 に、BGPの将来のバージョンはOPENとNOTIFICATIONメッセージのフォーマットを維持しな くてはなりません。 8. BGP 状態遷移機構 このセクションは、状態遷移機構(FSM)の条件に関するBGPオペレーションを定義します。 下記に、このFSMによって決定される状態によるBGPオペレーションの概略と簡単な要約を 示します。BGP FSMの簡潔化されたバージョンはAppendix 1をご覧ください。 BGPの開始はIDLE状態です。 IDLE 状態: この状態では、到着するすべてのBGP接続は拒否されます。peerに対してアロケート されているリソースは存在しません。STARTイベントに対する応答（互いのシステム または、オペレータによって開始されます。）では、ローカルシステムは、すべての BGPリソースの初期化、ConnectRetry Timerの開始、他のBGP Peerに対するtransport レイヤでの接続を開始を行い、リモートのBGP Peerによって開始される接続に対する 待ち受けを行い、そして、CONNECT状態に繊維します。ConnectRetry Timerの正しい 値は、ローカルな要因ですが、TCPの初期化をするために十分な値にするべきでしょ う。 もし、BGP Speakerがエラーを発見した場合、コネクションをシャットダウンし、そ して、IDLE状態に状態を変更します。IDLE状態から出るということは、STARTイベン トの発生を要求します。もし、そのようなイベントが自動的に発生させられたのなら ば、持続するBGPエラーはSpeakerの持続するflappingの結果でしょう。このような状 態から逃れるには、STARTイベントを一つのエラーによって直前にIDLE状態へ状態遷 移したpeerに対して直接発生させないようにする事です。直前にエラーによってIDLE 状態に遷移したpeerに対して、もし、そのようなイベントが自動的に発生されるので あれば、Startイベントの発生が連続する時間は指数関数的に増大するでしょう。 Initial Timerの値は60秒にするべきでしょう。この時間は、互いの連続するリトライ に対して二倍にされるでしょう。 IDLE状態での他のイベントの受信は無視されます。 CONNECT 状態: この状態では、BGPはトランスポートレイヤの接続が完了するのを待っています。 もし、トランスポートレイヤの接続が成功したならば、ローカルシステムは、 ConnectRetry Timerをクリアし、初期化を終了させ、接続したPeerに対してOPENメッ セージを送信します、そして、OPENSENT状態に状態を遷移させます。 もし、トランスポートレイヤの接続が失敗したならば（例えば、再送タイムアウトな ど）、ローカルシステムは、ConnectRetry Timerを再スタートさせ、リモートのBGP Peerによって開始されるであろう接続に対する待ち受けを続けます、そして、ACTIVE 状態に状態を遷移させます。 ConnectRetry Timer Expierdのイベントが発生した場合、ローカルシステムは、 ConnectRetry Timerを再スタートさせ、他のBGP Peerに対するトランスポートレイヤ の接続を開始し、リモートのBGP Peerによって開始されるであろう接続に対する待ち 受けを続けます、そして、CONNECT状態に遷移します。 STARTイベントはACTIVE状態においては、無視されます。 他のいづれかのイベントが発生した場合（どちらかのシステムまたは、オペレータによ って開始されるようなもの）、ローカルシステムは、この接続に関連するすべてのBGP リソースを開放し、そして、IDLE状態に遷移します。 ACTIVE 状態: この状態では、BGPは、トランスポートレイヤの接続の開始によるPeerの取得を試みま す。 もし、トランスポートレイヤの接続に成功したならば、ローカルシステムは、 ConnectRetry Timerをクリアし、初期化を完了し、そのPeerにOPENメッセージを送信 します、また、それに対し大きい値のHold Timerを設定します、そして、OPENSENT状 態に遷移します。４分のHold Timerが提案されています。 ConnectRetry Timer Expierdのイベントが発生した場合、ローカルシステムは、 ConnectRetry Timerを再スタートさせ、他のBGP Peerに対するトランスポートレイヤ の接続を開始し、リモートのBGP Peerによって開始されるであろう接続に対する待ち 受けを続けます、そして、CONNECT状態に遷移します。 もし、ローカルシステムが、リモートpeerがそれに対するBGP接続の確立を試みており、 そして、リモートpeerのIPアドレスが期待するものではないことを検出したならば、 ローカルシステムは、ConnectRetry Timerを再スタートさせ、試行中の接続は破棄し、 リモートのBGP Peerによって開始されるであろう接続に対する待ち受けを続けます、 そして、状態はACTIVE状態に留まります。 STARTイベントは、ACTIVE状態では無視されます。 他のいづれかのイベントが発生した場合（どちらかのシステムまたは、オペレータによ って開始されるようなもの）、ローカルシステムは、この接続に関するすべてのBGPリ ソースを開放し、そして、IDLE状態に遷移します。 OPENSENT 状態: この状態では、BGPは、PeerからのOPENメッセージを待ちます。OPENメッセージが受信 されたとき、すべてのフィールドは正しいかどうか確認されます。もし、BGPメッセー ジヘッダチェック、または、OPENメッセージのチェックにおいてエラーが検出された場 合（Section 6.2を参照）、もしくは、接続が衝突(Connection Collision)（Section 6.8を参照）した場合には、ローカルシステムは、NOTIFICATIONメッセージを送信し、 そして、IDLE状態に遷移します。 もし、これらのOPENメッセージでのエラーが発生しない場合、BGPはKEEPALIVEメッセー ジを送信し、KeepAlive Timerをセットします。もともと大きい値に設定されている Hold Timer（前述）は、ネゴシエート時に与えられるHold Timerの値に置き換えられま す（Section 4.2を参照）。もし、ネゴシエート時に与えられるHold Timerが０の場合、 Hold TimeタイマとKeepAliveタイマは開始されません。もしAutonomous Systemフィー ルドの値が、ローカルなAutonomous System番号と同じの場合、その接続は"Internel" な接続となります。その他の場合は、"External"となります。（これは、後述する UPDATE処理に影響します。）最後に、この状態はOPENCONFIRM状態に遷移します。 もし、切断通知(Dissconnect Notification)が下層のトランスポートレイヤから受信さ れた場合、ローカルシステムはBGP接続を閉じ、ConnectRetry Timerを開始させ、リモ ートのBGP Peerによって開始されるであろう接続に対する待ち受けを行い、状態を AVTIVEに変更します。 もし、Hold Timerが時間切れとなった場合、ローカルシステムはHold Timer Expierdの エラーコードと一緒にNOTIFICATIONメッセージを送信し、状態をIDLE状態に遷移しま す。 STOPイベントの発生（どちらかのシステムまたはオペレータによって与えられます。） では、ローカルシステムは、発生したエラーコードと共にNOTIFICATIONメッセージを送 信します。そして、IDLE状態に遷移します。 STARTイベントは、OPENSENT状態では無視されます。 他のイベントが発生において、ローカルシステムは状態遷移機構(FSM)エラーのエラー コードと共にNOTIFICATIONメッセージを送信します。そして、IDLE状態に遷移します。 BGPは、OPENSENTからIDLEに状態遷移をするときはいつも、BGP接続を閉じ（トランス ポートレイヤでの切断も行う）、すべての接続に関するリソースを開放します。 OPENCONFIRM 状態: この状態では、BGPはKEEPALIVEとNOTIFICATIONメッセージを待ちます。 もし、ローカルシステムがKEEPALIVEメッセージを受信した場合、ESTABLISH状態に遷移 します。 もし、KEEPALIVEメッセージを受信する前にHold Timerが時間切れになった場合、ロー カルシステムは、Hold Timerが時間切れになったというエラーコードと共に NOTIFICATIONメッセージを送信し、IDLE状態に遷移します。 もし、ローカルシステムがNOTIFICATIONメッセージを受信した場合、IDLE状態に遷移し ます。 もし、KeepAlive Timerが時間切れになった場合、ローカルシステムは、KEEPALIVEメッ セージを送信し、KeepAlive Timerを再スタートさせます。 もし、切断通知が下層のトランスポートレイヤから受信されたとき、ローカルシステム は、IDLE状態に遷移します。 STOPイベントの発生（どちらかのシステムまたは、オペレータによって与えられま す。）では、ローカルシステムは、発生したエラーコードと共にNOTIFICATIONメッ セージを送信し、そして、IDLE状態に遷移します。 STARTイベントはOPENCONFIRM状態では無視されます。 他のイベントの発生においては、ローカルシステムは、状態遷移機構(FSM)エラーのエラ ーコードと共にNOTIFICATIONメッセージを送信し、IDLE状態に遷移します。 BGPはOPENCONFIRMからIDLE状態に遷移するときはいつも、そのBGP接続を閉じ（トランス ポートレイヤの切断も行う）、そして、すべての接続に関するリソースを開放します。 ESTABLISHED 状態: ESTABLISHED状態において、BGPはそのPeerに対してUPDATE、NOTIFICATION、KEEPALIVE メッセージの交換を行うことができます。 もし、ローカルシステムがUPDATEまたは、KEEPALIVEメッセージを受信した場合、ネゴ シエートされたHold Timerの値が０でなければ、Hold Timerを再スタートさせます。 もし、ローカルシステムがNOTIFICATIONメッセージを受信した場合は、IDLE状態に遷移 します。 もし、ローカルシステムがUPDATEメッセージを受信し、そして、UPDATEメッセージのエ ラー処理においてエラーが発生した場合には（Section 6.3を参照）、ローカルシステム は、NOTIFICATIONメッセージを送信し、IDLE状態に遷移します。 もし、切断通知を下層のトランスポートレイヤから受信された場合には、ローカルシス テムは、IDLE状態に遷移します。 もし、Hold Timerが時間切れになった場合、ローカルシステムは、Hold Timerが時間切 れになったことを示すエラーコードと共にNOTIFICATIONメッセージを送信し、IDLE状態 に遷移します。 もし、KeepAlive timerが時間切れになった場合、ローカルシステムは、KEEPALIVEメッ セージを送信し、KeepAlive Timerを再スタートさせます。 ローカルシステムがKEEPALIVEまたは、UPDATEメッセージをそれぞれ送信したとき、ネゴ シエートされたHold Timerの値が０でなければ、KeepAlive Timerを再スタートさせま す。 STOPイベントが発生（どちらかのシステムまたは、オペレータによって与えられま す。） においては、ローカルシステムは、発生したエラーコードと共にNOTIFICATIONメッ セージを送信し、IDLE状態に遷移します。 STARTイベントは、ESTABLISHED状態では無視されます。 他のイベントの発生においては、ローカルシステムは、状態遷移機構(FSM)エラーの エラーコードと共にNOTIFICATIONメッセージを送信し、IDLE状態に遷移します。 BGPはESTABLISHEDからIDLE状態に遷移するときにはいつも、BGP接続を閉じ（トランス ポートレイヤの接続も切断する）、すべての接続に関するリソースを開放し、また、 その接続から得られたすべての経路を削除します。