ポーリングではなくプッシュ
唯一こちらへ来てくれる情報源と、それによって「信じてよいこと」が変わる二つの点
Michel Wijnberg
このシリーズでここまで登場した情報源はどれも、Osprey が出向いて尋ねるものでした。GRE レコーダーが エリアに加わってデータベースを求める。SNMP ウォークがデバイスにテーブルを求める。尋ね、待ち、 受け取り、また繰り返す。
BMP だけが自分からやって来ます。ルーターが監視ステーションへ TCP セッションを開いて話し始め、話す ことがあるかぎり話し続けます (RFC 7854)。誰も何もポーリングしません。
これは端的に優れているように聞こえますし、ある一つの軸ではそのとおりです。しかし別の二つの軸では、 あなたが結論づけてよいことが変わります。そしてその二つのほうが、速さより面白いのです。
自分から来てくれることで得られるもの
ポーリングにはサンプリング間隔があり、サンプリング間隔にはサンプリング間隔のあらゆる性質が あります。1 周期のうちに起きて元に戻ったことは、あなたのデータにとって起きていません。二回のウォーク のあいだに 2 度フラップした経路は、一度も動かなかった経路に見えます。
プッシュされるストリームに周期はありません。撤回が届くのは撤回が起きたからであり、そこに載っている 時刻はルーターのものであって、ポーラーのものではありません。
BGP にとってこれは他のたいていのものより重要です。BGP はトポロジよりはるかに頻繁に変わるからです。 フルテーブルを 5 分ごとにウォークするのは、莫大に高価であると同時に、短命なものに対しては盲目です。 「このプレフィックスはいつ変わったのか」という問いに信頼に足る答えがあるのは、プッシュモデルだけ です。
代償その一: 沈黙が何も意味しなくなる
ここからが、ポーリングがただで手に入れているものです。
尋ねて何も返ってこなかったポーラーは、何が起きたかを正確に知っています。尋ねて、何も返ってこな かったのです。その不在自体が時刻つきの観測であり、再試行もできます。
何も聞こえない聞き手には、その贅沢がありません。ネットワークが静かなのか、セッションが消えたのか、 線の上では沈黙は同じです。そして後者は、他の何かが教えてくれるまで前者と区別がつきません。
その具体的な危険は名前をつけておく価値があります。あなたが手を伸ばしたくなる指標を、それは反転させ るからです。落ちたセッションを「変化がない」として扱えば、もう何も聞こえなくなったピアが、 レポート上で最も安定したピアになります。 画面上でいちばん静かな行こそ、あなたが失った相手です。 チャーンで並べ替えるランキングはどれも、あなたの盲点を最上位に置き、最も健全な関係というラベルを 貼ります。
第 12 回は、Osprey がそれに対して何をするか、すなわちセッション 断を大量撤回ではなく監視の空白として記録することを扱っており、ここでは繰り返しません。このシリーズ にとっての要点はもっと狭いものです。プッシュは、沈黙を解釈する負担をプロトコルからあなたへ移し ます。 ポーリングモデルはその答えを渡してくれていたので、あなたは考えずに済んでいたのです。
代償その二: あなたは他人の会話を読んでいる
二つ目の代償はもっと微妙で、実際のパーサーのバグを生みます。
BMP は BGP セッションをくれるのではありません。他人のセッション上のメッセージのコピーを、包んで 転送してくれるのです。あなたは交渉の場にいませんでしたし、BGP メッセージは自己記述的ではありま せん。UPDATE をどうデコードするかは、両ピアが OPEN で何に合意したかに依存します。
素直な方法は文脈を再構成することです。Peer Up は両方の OPEN メッセージを運ぶので、何が交渉された かを読み、セッションのあいだ覚えておけます。Osprey はそうしています。
そのうえで、以降の各メッセージのピア別ヘッダには A フラグ があり、内包された PDU が旧来の 2 バイト AS_PATH 形式を使っているかどうかを示します (RFC 7854 §4.2)。これはメッセージ単位なので、 パーサーは Peer Up の文脈から形式を仮定するのではなく、そのメッセージをこのフラグに従ってデコード します。
この二つは食い違いえます。食い違ったとき、Osprey はフラグに従ってデコードし、その不一致を黙って 解消するのではなく記録します。この理屈は一般化するので述べておく価値があります。ケイパビリティは 2 台のルーターが何をすると合意したかを記録し、フラグはこのエクスポータがこのメッセージに何をしたか を記述します。合意についての証拠と、いま手元にあるバイト列についての証拠が衝突するとき、パースされ ているのは手元のバイト列のほうです。
Add-Path についても対応する機微があり、形は同じです。内包された NLRI がパス識別子を運ぶかどうかは 方向性のある交渉に依存し、どちらの方向が当てはまるかは、どの RIB が監視されているかに依存します。 既定の Adj-RIB-In か、RFC 8671 が追加し同じピア別ヘッダの別のフラグで示される Adj-RIB-Out かです。 だからパーサーはまずそのフラグを読み、そこからどちらの交渉を信じるかを選びます。同じフィールド、 二通りの読み、そしてそれを選ぶのは、あなたがそのセッションの当事者なら参照しないビットです。
デバイスをポーリングするとき、こうしたことは何も起きません。あなたは自分が一級の当事者である プロトコルで、あるデバイスにそのデバイス自身のことを尋ねています。BMP はルーター自身の見え方を 渡し、それが交渉された文脈を取り去ります。そして、その文脈を再構成するどのフィールドも、荷重を 担っています。
ふたつの取得方式がひとつの表に落ちてきていて、違いは 2 つの列に出ています。BMP の行の最終確認は 1 日前ですが、これは異常ではありません。それらのセッションには何も変化がなく、プッシュ型の 情報源は変化がないときには黙るからです。SNMP の行がたった今と言うのは、こちらから出向いて 尋ねたからです。主張は同じでも、それを信じる根拠はまったく別で、沈黙が情報になるのは一方だけ です。
頼まなければ決して来ないレポート
最後にもう一つ。いちばん小さく、いちばん腹立たしいものです。
BMP は Statistics Report を定義しています。ピアごとの定期カウンタで、そのピアのポリシーが何を捨てて いるかを教える拒否数や treat-as-withdraw 数も含まれます。素晴らしいデータです。スコアカードに欲しい ものそのものです。
それは届きません。
パーサーのバグのせいでも、エクスポータが壊れているせいでもありません。IOS はレポート周期を指示され
ないかぎり Statistics Report を単に送らず、既定値もないのです。BMP サーバー設定の下に
stats-reporting-period がなければ、そのメッセージ種別は線の上に一度も現れず、ピアごとの統計
フィールドはどこにもエラーが出ないまま永遠に空のままになります。
ラボはしばらくその状態で動いていました。そして空の列の誠実な読み方は「このピアは何も拒否していない」 ではありませんでした。「このルーターに言えと誰も指示したことがない」でした。修正は 6 台のルーターに 設定行を 1 行、しかもリロードが測定を静かに巻き戻さないよう startup-config へ書き込むことでした。
これは小さな運用上の細部ですが、一般的な形をしています。プッシュ型の情報源は、送るよう設定された ことしかあなたに伝えられません。 ポーリングでは、いつ問いを発するかをあなたが制御します。プッシュ では、エクスポータが出すよう設定されたものだけを観測し、送られなかったメッセージは、そもそも生成 されなかったメッセージと区別がつきません。
要点
プッシュは優れており、ただではありません。
BGP のように速く変わるものについて、信頼に足る唯一の時間軸を得る代わりに、ポーリングでは考えずに 済んでいた二つを手放します。沈黙がかつては観測だったこと、そして自分が読んでいる会話の当事者で かつてはあったこと。
その二つはどちらも、このコードベースでは小さく具体的な気配りとして現れます。ギャップとして記録 されるセッション断。ケイパビリティではなくフラグから取られる AS_PATH の幅。空のままで、その理由を 知っている統計列。どれも巧妙ではありません。すべて同じ告白です。すなわち、自分からやって来る メッセージは、自分自身の不在について、あなたが自分で発した問いよりも少ないことしか語らない、と。
これでこのシリーズは終わりです。通底するものがあるとすれば、この製品のどの答えも、それがどのように 得られたかについて示せる説明の分だけの価値しかない、ということです。