Summary

  • RIPE 92の会議ネットワークは、ASPAで無効と判定された経路を破棄し始めた。その後、CZ.NICへIPv6で到達できないとの報告をOndřej Caletkaが受けた。単一の上流が通知した最良経路が、まさに破棄対象だった。
  • CZ.NIC側がAS6939をASPAの提供者リストに追加すると、約10分で経路情報に反映されたとCaletkaは述べた。会場で争点になったのは、最後の出口でどこまでフィルタリングすべきかだった。

設定どおりに動く機械ほど、障害の報告書を読ませることがある。Ondřej CaletkaはRIPE 92の金曜全体会議で、そんな実験結果を隠さず語った。会議ネットワークは自分たちのASNについてASPAオブジェクトを署名し、無効な経路の受け入れを止めた。ところがCZ.NICの関係者から、会場からそのネットワークへIPv6で届かないと連絡が入る。セキュリティーの設定は働いていた。通信は止まった。

RIPEの公式議事録にある構成は単純だ。上流は一社、受け取るのはBGPの全経路表、デフォルト経路はない。CZ.NICへ向かう最良経路にはAS6939、Hurricane Electricが含まれていた。同社は無料のIPv6トランジットを提供していたが、関係するASPAの提供者リストには載っていなかった。検証結果は無効。会議側のルーターはその経路を捨てた。上流が渡したのは最良経路だけで、ほかの有効な経路が上流側にあっても会議ネットワークからは見えない。見えている唯一の道を閉じれば、地図から目的地が消える。

CZ.NICの運用者はAS6939をASPAの提供者に加えた。Caletkaによれば、変更がルーティング情報ベースに届くまで約10分。RIPE NCCの運用文書は、この署名を維持する側の仕事を明記している。ダッシュボードは実際の上流関係を自動で教えてくれない。ピアでありながらトランジットも担う相手はリストに入れ、接続関係の変化に合わせて更新する必要がある。無料かどうかは、経路が担う役割を変えない。

会場の反応は一枚岩ではなかった。Job Snijdersは、宛先側の認可かトランジット関係を直すべきで、検証を問題視する説明には慎重だった。Caletkaは単一上流の顧客側から、通知されない代替経路は選べないと応じた。Gert Doeringは、最後の上流からの経路を受け入れ、ピア接続側でフィルタリングする案を出した。やり取りの記録を読むと、正しい経路判定と、判定をどこで適用するかが別々の運用判断だと分かる。

CaletkaはRIPE NCCで研修用ラボを運用している。公式職員紹介によると、実習環境づくりが仕事の一部だ。RIPE 93のASPA講習には、ルーター設定と障害の切り分けが含まれる。エディンバラで得た実例は良い一問目になる。フィルターの前に、上流はいくつの道を見せてくれるのか。