BGP AS パスプリペンド（AS-Path Prepending）がピアに拒否される原因と対策：BIRD/FRR 設定例
AS パスプリペンド（AS-Path Prepending）は、マルチホーム BGP 環境で着信トラフィックを制御する定番の手法です。特定の上流向けの広報で自 ASN を繰り返し付加し、その経路を長く見せて優先度を下げます。しかし設定後にBGP の AS-Path Prepending がピアに拒否される、つまりその上流からプレフィックスが消えたりプリペンドが効かなかったりするケースは少なくありません。本記事では、パス長制限、AS パスフィルター、IRR/RPKI 検証といった主な原因と、BIRD 2・FRRouting の正しい設定例を紹介します（Debian/Ubuntu、CentOS/Rocky/AlmaLinux 対応）。例ではローカル ASN 64500、上流 203.0.113.1（AS64496）、プレフィックス 198.51.100.0/24 を使用していますので、実際の値に置き換えてください。
ステップ1：AS-Path Prepending が拒否されている現象を確認
まず自ルーターがプリペンド後のパスで実際に広報しているか確認し、ログで NOTIFICATION やセッションリセットの有無を調べます。あわせて公開 Looking Glass で世界から見える AS パスを確認します。自分の送信内容は正しいのに、その上流経由のパスが外部から全く見えない場合は、上流またはその先でフィルタリングされています。
# BIRD 2
birdc show route 198.51.100.0/24 export upstream1 all
journalctl -u bird --since "1 hour ago" --no-pager
# FRRouting
vtysh -c "show bgp ipv4 unicast neighbors 203.0.113.1 advertised-routes"
vtysh -c "show bgp ipv4 unicast neighbors 203.0.113.1" | grep -iE "state|prefix|notification"curl -s "https://stat.ripe.net/data/looking-glass/data.json?resource=198.51.100.0/24" | grep -o '"as_path":"[^"]*"' | sort | uniq -cステップ2：プリペンドには自 ASN のみを使用する
最も多い誤りは、上流や他社の ASN をプリペンドしたり、パスの末尾に別の ASN を挿入してオリジン AS を変えてしまうことです。上流は通常、先頭 ASN がネイバー ASN と一致することを確認し、as-set でオリジンを検証します。無関係な ASN が含まれると経路ハイジャックとみなされ破棄されます。プライベート ASN（64512–65534）もよくフィルターされます。BIRD 2 の正しい設定は以下の通りで、eBGP エクスポート時に自 ASN がもう一度自動付加されます。
# /etc/bird/bird.conf (BIRD 2)
filter export_upstream1 {
if net = 198.51.100.0/24 then {
bgp_path.prepend(64500); # own ASN only
bgp_path.prepend(64500);
accept;
}
reject;
}
protocol bgp upstream1 {
local as 64500;
neighbor 203.0.113.1 as 64496;
ipv4 {
import none;
export filter export_upstream1;
};
}
birdc configureステップ3：FRRouting で AS パスプリペンドを設定
FRR では送信方向の route-map でプリペンドを行います。変更後は soft out で再広報すれば、セッションを切らずに反映できます。
vtysh
configure terminal
ip prefix-list MY-NETS seq 10 permit 198.51.100.0/24
route-map UPSTREAM-OUT permit 10
match ip address prefix-list MY-NETS
set as-path prepend 64500 64500
exit
route-map UPSTREAM-OUT deny 100
exit
router bgp 64500
address-family ipv4 unicast
neighbor 203.0.113.1 route-map UPSTREAM-OUT out
exit-address-family
end
write memory
clear bgp ipv4 unicast 203.0.113.1 soft outステップ4：AS パス長を抑えて長さ制限を回避
AS パスが長すぎる経路を破棄するネットワークは多く、同一 ASN の連続回数を制限している場合もあります。経路選択に影響を与えるには 1～3 回で十分で、5 回を超えても効果はほぼなく、フィルターされるリスクだけが高まります。また、上流の AS パスフィルターが ^64500$ のように厳しすぎると、「64500 64500 64500」は拒否されます。その場合は ^(64500_)+$ のようなルールへの変更を上流に依頼してください。
実際に送信している AS パスは次のように確認できます。
birdc show route 198.51.100.0/24 export upstream1 all | grep BGP.as_path
vtysh -c "show bgp ipv4 unicast 198.51.100.0/24"ステップ5：IRR route オブジェクトと RPKI/ROA を確認
プリペンド自体はオリジン AS を変えませんが、IRR の route オブジェクトがない、上流に登録した as-set に含まれていない、ROA のオリジン ASN や最大プレフィックス長が一致しない、といった場合も上流で拒否されます。以下で確認できます。
whois -h whois.radb.net -- '-i origin AS64500'
whois -h whois.ripe.net -- '-T route 198.51.100.0/24'
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64500&prefix=198.51.100.0/24"RPKI の状態は valid が理想です。invalid の場合はまず ROA を修正してください。上流のフィルターは通常しばらくすると自動更新されますが、手動更新を依頼することもできます。
よくある質問
プリペンドしたのにトラフィックが変わらない
相手のネットワークが AS パス長より優先される Local Preference で経路を選んでいる可能性があります。上流のコミュニティを使うか、広報するプレフィックスの粒度を調整してください。
上流の ASN をプリペンドしてもいいですか？
いいえ。繰り返してよいのは自 ASN のみです。他の ASN を加えるとパスの真正性が損なわれ、多くのネットワークで破棄されます。
IMIDC でプリペンド設定を手伝ってもらえますか？
IMIDC のサーバーから自社 IP やレンタル IP を広報している場合は、チケットで要件をお知らせください。セッション、フィルター、IRR/ROA の状態を確認します。
解決しない場合は、チケットを送信して IMIDC の 24 時間 365 日サポートにお問い合わせください。