要約

  • 10月26日のRIPE 93で、RIPE NCCのOndřej CaletkaはBIRDのASPA判定に自分のASNを加えた例を示した。
  • スライド57には、ピア接続で同じ操作をすると上り方向の検証が壊れるという警告がある。

一つ増えたASNは、隣席の監査人のようだ。顧客の申告漏れにも、自社が上流を記載し忘れた場合にも気づく。ところがピアとの席にまで連れていくと、相手を上流プロバイダーとして扱う質問を始める。相手は席を間違えていない。間違えたのは質問表だ。

RIPE 93の公式日程に載る講習で、Caletkaは原版スライドに具体的なBIRD設定を示した。上流から届いた経路に対し、aspa_check(aspas, bgp_path.prepend(2121), false)を呼ぶ。2121は例の自AS番号で、falseは下り方向の検証を選ぶ。例では無効と判定した経路を拒否するが、まず表示して調べるためのコメントも添えられている。

受信したAS経路は通常、BGPの隣接先で終わる。輸出時に加わる自AS番号は、受信側の計算にはまだ入っていない。スライド57が挙げる見落としは二つ。顧客が自社をプロバイダーとして登録していない場合と、自社が上流を登録していない場合だ。検証用の経路に自ASを足せば、この端の関係も確認できる。受信した告知を事後的に書き換える話ではない。

ピアは別だ。横の接続先は、通常の上流プロバイダーではない。BIRD開発陣による解説は、顧客や上流の検証では自ASを足し、ピアでは足さないと明記する。さらに、この方法はBIRD側の実装判断であり、IETFのASPA検証草案が求める手順そのものではないとも説明する。草案ではローカルな関係を別に確認する。

RIPE NCCのASPA案内も、プロバイダーと通常のピアを分けている。登録時に守った区別をルーターの共通フィルターで消してしまえば、設定の統一は単なる間違いの量産になる。美しいテンプレートほど、その失敗は見つけにくい。

原資料