Start typing to search across invoices, services, domains, tickets, and more...
IMIDC からリースした IPv4 / IPv6 アドレスを、自社のデータセンターや他社回線で自社 ASN から BGP 広報したい場合、通常は3つが必要です。アドレス保有者が発行する LOA(委任状)、IRR の route / route6 オブジェクト、そして RPKI の ROA です。本記事では、LOA とは何か、申請時に必要な情報、IRR と ROA の関係、上流のフィルタ、bgp.tools・bgp.he.net・RIPEstat での伝播確認までを解説します。すでに ASN を持ち、上流と BGP セッションを確立しているネットワーク運用者向けです。
LOA(Letter of Authorization)は、アドレス保有者が「ASxxx が当該プレフィックスを広報することを許可する」と記した書面です。多くのトランジット事業者や IX は、お客様のプレフィックスを受け入れる前に、そのアドレスの保有者と広報権限を確認します。現在は LOA だけでなく IRR と RPKI も自動でチェックされることが多いため、LOA・IRR route オブジェクト・ROA の3つを一致させておく必要があります。
チケットで LOA を申請し、次の情報をご用意ください。情報がそろっているほど処理が早くなります。
Prefix(es): 203.0.113.0/24 2001:db8:1000::/48
Origin ASN: AS64500
Company / holder: Example Networks Ltd
Upstream(s): AS64510 (Transit Provider A), AS64520 (IX route server)
Announce from: 2026-10-10
IRR source: RIPE / RADB
Technical contact: [email protected]
IRR(Internet Routing Registry)は経路登録データベースで、多くの上流がこれを元にプレフィックスフィルタを自動生成します。RIPE 地域のアドレスは RIPE データベースに route オブジェクトを作成し、アドレス保有者の承認が必要なため、通常は IMIDC が作成または承認します。RIPE 以外のアドレスでは RADB がよく使われます。書き方は「IRR route オブジェクトの作成」の記事を参照し、作成後は whois で確認します。
# install whois: Debian/Ubuntu
apt install -y whois
# CentOS/Rocky/AlmaLinux
dnf install -y whois
# route object in the RIPE database
whois -h whois.ripe.net -T route 203.0.113.0/24
whois -h whois.ripe.net -T route6 2001:db8:1000::/48
# route object mirrored / registered in RADB
whois -h whois.radb.net 203.0.113.0/24
出力の origin が自社 ASN になっていることを確認してください。
RPKI Invalid の経路を破棄するネットワークは年々増えています。そのアドレスに別の ASN を許可する ROA が既にあると、広報は Invalid と判定されます。チケットで自社 ASN 向けの ROA 発行を依頼し、maxLength が実際に広報するプレフィックス長をカバーしていることを確認してください。RIPEstat で状態を確認できます。
# RPKI status of origin AS64500 for the prefix (RIPEstat API)
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64500&prefix=203.0.113.0/24" | python3 -m json.tool | grep -E '"status"|"validating_roas"' -A2
valid なら正常、unknown は ROA なし(多くのネットワークでは受け入れられます)、invalid は広報前に必ず修正が必要です。
上流は通常、ASN や as-set を元に IRR からプレフィックスリストを生成します。毎日自動更新するところもあれば、LOA を添えてチケットで依頼が必要なところもあります。上流の確認が取れたら、自社ルーターでプレフィックスを広報します。BIRD 2 の例:
# BIRD 2 example (see the "BGP session" guide for the full config)
protocol static announce_v4 {
ipv4;
route 203.0.113.0/24 blackhole;
}
filter export_upstream {
if net = 203.0.113.0/24 then accept;
reject;
}
# reload and check
birdc configure
birdc show route export upstream_v4
広報後、通常は数分でグローバル経路表に現れます。bgp.tools や bgp.he.net でプレフィックスを検索すると、オリジン ASN、上流経路、RPKI 状態を確認できます。RIPEstat(stat.ripe.net)の Routing Status では、何台の RIS コレクターが経路を見ているかがわかります。コマンドラインでも確認できます。
# who sees the prefix and with which origin (RIPEstat)
curl -s "https://stat.ripe.net/data/routing-status/data.json?resource=203.0.113.0/24" | python3 -m json.tool | head -40
# how many RIS peers see it
curl -s "https://stat.ripe.net/data/visibility/data.json?resource=203.0.113.0/24" | python3 -m json.tool | grep -E '"ris_peers_seeing"|"total_ris_peers"'
# from your router: is the session up and the route exported?
birdc show protocols
# test reachability of an address in the prefix from outside
mtr -rwc 20 203.0.113.1
一般的なスケジュール:必要情報がそろってから LOA と IRR/ROA の準備までは通常数営業日程度(情報の完全性や審査状況によります)、上流のフィルタ更新は自動化の度合いにより数時間〜数日、経路そのものの伝播は数分です。一部の位置情報データベースはさらに時間がかかります(「Geofeed」の記事を参照)。
BGP セッションが Established か、ルーターで実際にエクスポートしているか、上流がフィルタを更新済みか(上流の Looking Glass で確認)、RPKI が invalid になっていないかを順に確認してください。
IPv4 で /24 より長いプレフィックスはインターネット上で広くフィルタされるため推奨しません。/24 の内部で自由にサブネット分割し、外部には /24 全体を広報してください。
ASN を変更する場合は LOA の再発行と IRR route オブジェクト・ROA の更新が必要です。上流だけを変更する場合は新しい上流にフィルタ更新を依頼すれば済むことが多いですが、新しい LOA を求められることもあります。
解決しない場合は、チケットから IMIDC の 24 時間 365 日テクニカルサポートへご連絡ください:https://www.imidc.com/submitticket.php