要約

  • Michael Takeuchiは2026年5月のBKNIX Peering Forumで使った発表資料で、接続相手のポートが限られて混雑した一方、自分のポートは混雑していなかったと説明した。
  • 相手側の監視画面や基本的なトラフィック統計が見えなければ、自社の正常なグラフだけでは原因に届かない。

顧客から遅いと連絡が来る。自社のポートを調べる。空いている。TakeuchiがBKNIXの会場に持ち込んだのは、この居心地の悪い順番だった。RAPIDNETの技術・運用責任者であり、APJIIでIndonesia Internet Exchangeとデータセンター部門の副責任者でもある彼は、別のピアのポート数が限られるために混雑した例を挙げた。自社側には輻輳が見えず、相手の監視情報もない。これでどうやって相手側を調べるのか、と問うた。

Peering Asiaの原資料には、RAPID NetworksがジャカルタのIIX、EPIX、OpenIXP/NiCE、JKT-IX、CXC、CDIXに接続するとある。BKNIXの資料では、あるISPが同市の12のIXに接続する例と、同一プレフィックスが五つのIXから11本のBGPセッションを通じて届く例も示す。彼が挙げた事例であり、インドネシア全体の集計ではない。接続を増やすほど、設定と連絡先の数も増える。

資料には、looking glassを出すネットワークもあれば、基本的なテレメトリーすら示さないネットワークもあると書かれている。ルートサーバーの構成、フィルター、BGPコミュニティーの扱いもIXごとに異なる。あるIXではコミュニティーによる経路制御ができず、混雑を避けるには手作業で接続相手を選ぶことになるという。経路の選択肢は豊富でも、詰まった場所を示す窓は足りない。

公開資料には、問題のピアの名前とポートのカウンターがない。この一件の規模と継続時間を確定するには、その記録が要る。ただ、構造的なねじれは見える。顧客に説明する会社と、原因を示す数字を持つ会社が別なのだ。