Summary

  • IETFに提出された個人草案は、UPDATE、KEEPALIVE、NOTIFICATION、ROUTE-REFRESH、全BGP PDUについて、受信と送信を分けた計十種類のBMP統計を提案する。数える単位は経路やプレフィックスではなくメッセージだ。
  • Peer Downを出しただけでは累積値を消してはならない。プロセス再起動、隣接設定の削除、手動クリア、ルーティングプロセッサの切り替えは計数を断絶させ得るため、収集側は区別しなければならない。

経路表の大きさは最後に残った量を示す。そこへ至るまでの忙しさは示さない。同じプレフィックスが取り消され、再び広告されれば、表の件数は元へ戻ってもUPDATEは増える。RFC 7854のBMPは経路の観測、隣接の上下、統計報告を運ぶ。従来の統計にはRIBの占有量や特定のUPDATE処理結果があるが、各種BGPメッセージ全体の数はない。

10月29日更新のIETF記録によれば、この文書は個人提出のInternet-Draftだ。UPDATEと全PDUは64ビット、KEEPALIVE、NOTIFICATION、ROUTE-REFRESHは32ビットの双方向カウンターを設ける。既存のBMP経路情報と同じ監視経路で、制御プレーンの仕事量を見せる狙いがある。ただしPDU数を経路数へ読み替えてはいけない。ひとつのUPDATEが複数のNLRIを含み、Route Monitoringも装置が出す経路ビューによって件数が変わる。

草案が強く線を引くのはセッションが落ちた瞬間だ。Peer Downだけで提案中のカウンターをリセットしてはならない。隣接が再確立した後もNOTIFICATIONの累計が残り、個別の切断通知を見逃した収集装置にも過去の量が伝わる。切断通知は一回の終了理由、カウンターは複数セッションにまたがる総量を受け持つ。再接続のたびに監視画面がゼロから書き直せば、残すべき履歴を自ら捨てる。

一方、装置のプロセス再起動、隣接の削除、運用者によるクリア、ルーティングプロセッサの切り替えでは値が戻り得る。新しいBMP Initiationは計数の断絶として扱う必要があるが、Peer DownからPeer Upへの移行だけでは断絶ではない。前回より数値が下がったかを見るだけでも足りない。リセット後の忙しい隣接は次の報告までに旧値を追い越せる。草案には断絶時刻を示す統計項目がなく、報告から抜けた統計はゼロではなく未記載だ。

IANAのBMP登録表には既存の統計と未割当領域が載る。提案中の十種類はまだTBDで、正式な番号はない。実装を評価するなら、対象装置を特定し、普通のセッション断、装置再起動、連続するBMP報告、リセットの別記録をそろえる必要がある。