RFCによるBGP通知の解析

送信データのヘッダー形式を知ることは重要ですか？ ネットワークに関する多くのトレーニングコースは、プロトコルヘッダーの解析に多少の時間を要しますが、通常、それなしではできません。 説明的な性質のため、彼らの研究はしばしば退屈であり、自動解析の利用可能性は状況を改善しません。 タイトルに興味深いアプローチが含まれていることもありますが、ほとんどの場合、タイトルはすべて1つの原則に適合し、次の新しい形式は通常驚くべきことではありません。 最も興味深いのは、もちろん、機能に影響を与えるこれらのオプションのあらゆる種類の組み合わせですが、どのオプションをどの順序でヘッダーに収めるかを覚えておく価値はありますか？

私はそれを覚えているとは言えませんが、それが私の仕事に干渉しているとは言えません。 原則として、syslogまたはコンソール上のメッセージは既に一貫した英語の文に再フォーマットされているため、ヘッダーを生の形式で表示する必要があるとは言えません。 しかし、時には、もっと深く見なければならないこともあります。たとえば、今年はそのようなメッセージに対して実り多いものでした。

エリクソンSmartEdge

notification msg sent (nbr 192.0.2.1, context 0x40030044 32 bytes, repeated 89 times, code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 0003 02ed 5bdc 3f01 

シスコ、一方で同じ

 NOTIFICATION received from 192.0.2.2 (External AS 64496): code 3 (Update Message Error) subcode 4 (attribute flags error), Data: e0 07 08 00 03 02 ed 5b dc 3f 01 

RFC4271で書かれているように、私たちの手でそれを作ろうとします。 理由を探すのではなく、ヘッダーを解析するだけです。 多くの引用があり、おそらくそれを行う方法を既に知っている人にとっては新しいことはほとんどないでしょう。 残りについては、読み進めてください。

多様性を追加するために、1つの投稿に限定するのではなく、GitHub FRRoutingでこの問題を見てみましょう。

 %NOTIFICATION: received from neighbor 192.168.0.1 3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes 50 02 0c de 02 ff 00 00 0c b9 00 00 00 ae 00 04 00 3e 00 04 00 3e 00 04 00 35 00 04 00 35 ...    00 04 00 35 

何が読めますか？ メッセージの種類、その意味と意味、近隣のIPアドレス（既に知っている）、および理解できない16進数の文字列が表示されます。

RFC4271へのリンクを持つすべての必要なコードがあるIANAサイトの主要なものから始めましょう。 強みを獲得し、RFCを最初から最後まで読むと、すべてが明確になるはずですが、動作の側面に影響を与えることなく、2つのメッセージの形式のみを理解しようとします。

解析通知

コンテンツから、名前で、 4.5通知メッセージ形式が私たちに適しています。 必要な見出しの形式と関連するセクションへのリンクを含むすべてのコードのリストを実際に見つけたものを開きました（ネタバレの下にすべての引用符を非表示にします）。

  0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error code | Error subcode | Data (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Code: This 1-octet unsigned integer indicates the type of NOTIFICATION. The following Error Codes have been defined: Error Code Symbolic Name Reference 1 Message Header Error Section 6.1 2 OPEN Message Error Section 6.2 3 UPDATE Message Error Section 6.3 4 Hold Timer Expired Section 6.5 5 Finite State Machine Error Section 6.6 6 Cease Section 6.7 

セクション6.3は、エラーコード3のUPDATEメッセージエラーです。すべてのメッセージに、修飾コードとともに表示されます。

code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 0003 02ed 5bdc 3f01

code 3 (Update Message Error) subcode 4 (attribute flags error), Data: e0 07 08 00 03 02 ed 5b dc 3f 01

3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes 50 02 0c de 02 ff 00 00 0c b9 00 00 00 ae 00 04 00 3e 00 04 00 3e 00 04 00 35 00 04 00 35 ... 00 04 00 35

ここにはタブレットがないので、数ページのテキストを読みます。 各段落では、さまざまな状況での動作について説明します。各状況は、独自のエラーコードによって特徴付けられます。

私たちの場合、使用されるフラグはこの属性で使用できません：

 If any recognized attribute has Attribute Flags that conflict with the Attribute Type Code, then the Error Subcode MUST be set to Attribute Flags Error. The Data field MUST contain the erroneous attribute (type, length, and value). 

および-属性の実際の長さが予想と一致しません：

 If any recognized attribute has an Attribute Length that conflicts with the expected length (based on the attribute type code), then the Error Subcode MUST be set to Attribute Length Error. The Data field MUST contain the erroneous attribute (type, length, and value). 

ここに書かれている最も重要なことは、エラーコードに加えて、メッセージがTLV形式（タイプ、長さ、値）のデータフィールドのUPDATEメッセージからのエラー属性を含まなければならないということです。 まだ解釈できない同じ16進数の文字列。 ただし、このフィールドの識別にはまだ問題があり、現在はログのログを表示するためにデバイスメーカーによって採用されているさまざまな規則に関連付けられています。

シスコの例では、開始は「データ」という言葉で明確に示されています。
code 3 (Update Message Error) subcode 4 (attribute flags error), Data : e0 07 08 00 03 02 ed 5b dc 3f 01

他の場合、そのようなバインディングはありません。 同時に、エリクソンとの行にはシスコよりもはるかに多くのデータが含まれていますが、これらのメッセージは同一であることがわかります。 したがって、 NOTIFICATIONの説明に戻り、完全に逆アセンブルされていることがわかります。可変長のデータフィールドはメッセージの最後です。

階層を上って、 セクション4.1の最初から読み始めましょう。

  0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | Marker | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

各メッセージはフィールドで始まります：

 This 16-octet field is included for compatibility; it MUST be set to all ones. 

16バイト長で、すべてのユニットで構成されますff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff エリクソンのログにも同じパターンがあります。
code 3/4 (update: attribute flags error) - 0000 0000 0020 0303 04e0 0708 0003 02ed 5bdc 3f01 code 3/4 (update: attribute flags error) - 0000 0000 （ ffff ffff ffff ffff ffff ffff ffff ffff ） 0020 0303 04e0 0708 0003 02ed 5bdc 3f01

次に、2バイトの長さフィールド：
code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0303 04e0 0708 0003 02ed 5bdc 3f01 code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff （ 0020 ） 0303 04e0 0708 0003 02ed 5bdc 3f01 、値は10進数32で、これnotification msg sent (nbr 192.0.2.1, context 0x40030044れたnotification msg sent (nbr 192.0.2.1, context 0x40030044からの復号化と一致しnotification msg sent (nbr 192.0.2.1, context 0x40030044 32 bytes 、さらに：

 This 1-octet unsigned integer indicates the type code of the message. This document defines the following type codes: 1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE 

そして、私たちはそれが番号3であることを知っていcode 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 ： code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 03 04e0 0708 0003 02ed 5bdc 3f01 code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 （ 03 ） 03 04e0 0708 0003 02ed 5bdc 3f01

次に、メッセージ自体と認識した内容（ セクション4.5 ）03 04-エラーのタイプとサブタイプ： code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 03 （ 03 04 ） e0 0708 0003 02ed 5bdc 3f01

エリクソンは、 e0で始まるデータフィールドだけでなく、生成されたメッセージ全体を繰り返しました。 Ciscoログでは、バイトシーケンスはそれで始まります。 FRRoutingログには、完全に復号化されたNOTIFICATIONメッセージのBGPヘッダーも含まれ、その後にデータフィールドが続きます。このフィールドはデコードに戻ります。

取得している内容を正確に把握するために、属性形式の説明を見つけることが期待されるため、 UPDATE形式の説明に進みます。 UPDATEには多くのフィールドが含まれ、属性は可変長フィールドのパス属性に設定されます。

 A variable-length sequence of path attributes is present in every UPDATE message, except for an UPDATE message that carries only the withdrawn routes. Each path attribute is a triple <attribute type, attribute length, attribute value> of variable length. 

2つのシングルバイト部分で構成されるTypeフィールドの値から始めましょう。

  Attribute Type is a two-octet field that consists of the Attribute Flags octet, followed by the Attribute Type Code octet. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attr. Flags |Attr. Type Code| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

ここでも、すべてが実線で囲まれているため、すべてを連続して読む必要があります。 その結果、フラグフィールドは0〜3の最初の4ビットを使用し、2番目のバイトは属性自体を定義します。 これらすべてをテーブルに入れましょう：

ビット4〜7は、送信時には0であり、受信時には無視される必要があります。それらに注意を払っていません。 ビット3は、TLVの長さフィールドのサイズを決定します。

 The fourth high-order bit (bit 3) of the Attribute Flags octet is the Extended Length bit. It defines whether the Attribute Length is one octet (if set to 0) or two octets (if set to 1). 

特に興味深いのは、 部分的なフラグです。これは、推移的なオプション属性に設定できます。 フラグの説明は、RFC全体のいくつかの場所に散らばっています。 次の使用状況が発生します。

1. 属性が認識されない場合、このフラグが設定され、属性自体が渡されます- セクション9 ：
   
   メッセージ処理を更新する

    If an optional transitive attribute is unrecognized, the Partial bit (the third high-order bit) in the attribute flags octet is set to 1, and the attribute is retained for propagation to other BGP speakers. 

2. 属性が次のスピーカーによって認識される場合、フラグはまだリセットされません- セクション5 ：
   
   パス属性

    Paths with unrecognized transitive optional attributes SHOULD be accepted. If a path with an unrecognized transitive optional attribute is accepted and passed to other BGP peers, then the unrecognized transitive optional attribute of that path MUST be passed, along with the path, to other BGP peers with the Partial bit in the Attribute Flags octet set to 1. If a path with a recognized, transitive optional attribute is accepted and passed along to other BGP peers and the Partial bit in the Attribute Flags octet is set to 1 by some previous AS, it MUST NOT be set back to 0 by the current AS. 

3. 元のスピーカーが推移的な属性を追加したくない場合は、フラグも設定されます。
   
   （同上）

    New, transitive optional attributes MAY be attached to the path by the originator or by any other BGP speaker in the path. If they are not attached by the originator, the Partial bit in the Attribute Flags octet is set to 1. 

UPDATEに取りかかりましょう

最初のケースのフラグフィールドe0： code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04 0708 0003 02ed 5bdc 3f01 code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04 （ e0 ） 0708 0003 02ed 5bdc 3f01 -in binary 1110 0708 0003 02ed 5bdc 3f01オプション、推移的部分フラグによって設定され、長さフィールドは1バイトで指定されます。

code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 （ 07 ） 08 0003 02ed 5bdc 3f01属性コード7-AGGREGATOR

データサイズ8バイト： code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 07 （ 08 ） 0003 02ed 5bdc 3f01

2番目の場合-既知の属性（50-0101 0000）、フィールドのサイズは2バイト長、AS_PATH（02）、3294バイト（0c de）： 3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes （ 50 02 0c de ） 02 ff 00 00 0c b9 00 00 00 ae 00 04 00 3e 00 04 00 3e 00 04 00 35 00 04 00 35 ... 00 04 00 35

行の残りは、属性自体のデータフィールドです。 これを行うには、 セクション4.3に進みます。

 AGGREGATOR is an optional transitive attribute of length 6. The attribute contains the last AS number that formed the aggregate route (encoded as 2 octets), followed by the IP address of the BGP speaker that formed the aggregate route (encoded as 4 octets). This SHOULD be the same address as the one used for the BGP Identifier of the speaker. 

次の結果を得るには、32ビットASn RFC6793を使用することを考慮する必要があります。

4バイトはAS197357です： code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 -0000 code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 （ 0003 02ed ） 5bdc 3f01 、

および4バイトのIPアドレス91.220.63.1： code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 0003 02ed -0000 code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 0003 02ed （ 5bdc 3f01 ） -示されているように合計8バイト長さフィールド。

2番目の場合、AS_PATH、TLV自体：

 The path segment type is a 1-octet length field with the following values defined: Value Segment Type 1 AS_SET: unordered set of ASes a route in the UPDATE message has traversed 2 AS_SEQUENCE: ordered set of ASes a route in the UPDATE message has traversed The path segment length is a 1-octet length field, containing the number of ASes (not the number of octets) in the path segment value field. 

1バイトサイズのタイプおよび長さフィールド。

タイプ2、データサイズ（ff-255 ASn）： 3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes 50 02 0c de （ 02 ff ） 00 00 0c b9 00 00 00 ae 00 04 00 3e 00 04 00 3e 00 04 00 35 00 04 00 35 ... 00 04 00 35

データ自体は、それぞれ4バイトのAS番号です： 3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes 50 02 0c de 02 ff （ 00 00 0c b9 ） （ 00 00 00 ae ） （ 00 04 00 3e ） （ 00 04 00 3e ） （ 00 04 00 35 ） （ 00 04 00 35 ） ... 00 04 00 35 -AS3257、AS174、AS262206 AS262206、AS262197、AS262197、AS262197、AS262197 ...

終わりました。 それは難しくないように見えましたか？..しかし、退屈です。 もちろん、これで問題を理解することはできませんでした。ほとんど触れていないドキュメントのほとんどは、形式ではなく、必要な動作について説明しているからです。 しかし、少なくともソースへの方向はわかっています。

残念ながら、あるいはそうではないかもしれません-RFCは読みやすいものではありません。データが表形式で表示される場所もあれば、まったく同じ場合にテキストに直接書き込まれる場所もあり、構造を理解するには多くを読む必要があります。 しかし、それらが存在し、メーカーがそれらを読んで実装できるようになったことを嬉しく思います。

PS FRRoutingの場合、問題がフォーマットにないことを示唆するパッチがあります。

最初のケースでは、明らかにパッチも必要です。AGGREGATOR属性のフラグを共有する際に正式に問題は見られなかったため、おそらく誰かが見たからです。