はじめに
この記事は BBSakura Networks Advent Calendar 2025 の 20 日目の記事です。
こんにちは！ BBSakura で基盤となるネットワークを開発している酒井です。
一昨年 と昨年 の BBSakura Advent Caleder でも BGP 関連技術について書いていました。今年はアドベントカレンダーとしては大遅刻してしまいましたが、懲りずに BGP ネタで書いていこうと思います。
今年の BGP ネタとしては、 BGP Role を選びました。 BGP Role は RFC 9234 で定義されており、私はこの APNIC のブログ記事 ① ② を読んで知りました。
本記事は、私が当該 RFC を読み、実際にパケットキャプチャをして中身を眺めて学習した内容をまとめたものになります。
BGP について
まず、 BGP の概要と BGP Role が必要な理由について簡単に説明します。
BGP は異なるネットワーク間を接続するために使用されるプロトコルであり、インターネットを構成する各組織間の接続にも用いられています。
インターネットがどのように BGP を用いて構成されているのかは、JPNIC のインターネット 10 分講座 や 過去の JANOG のチュートリアル などが参考になります。
インターネットでは BGP によって各組織間の接続性を確保しているわけですが、過去には度々 BGP の設定ミスによるインターネットの通信障害が発生しています。
具体的な通信障害としては、2017年8月のインターネット接続障害 や 2024年7月の1.1.1.1への到達性障害 などがあります。
これらの通信障害はいずれも BGP Route Leak と呼ばれる意図しない BGP 経路広報が原因です。BGP Route Leak 自体も RFC 7908 で定義されています。インターネットは各組織間の相互努力によって維持されており、どうしても BGP の設定ミスをゼロにはできず、ミスによる影響が発生してしまいます。
これらの設定ミスやそれによる影響を最小限にするため、インターネットを構成する各組織はルーティングセキュリティを実行することが推奨されています。具体例として MANRS と呼ばれる BGP におけるルーティングセキュリティを確保するための活動などがあります。 MANRS については JPNIC の解説 でも説明されています。
BGP Role はこのルーティングセキュリティに関する技術と言えます。一文で表すと、 BGP Role は組織間 (AS 間)の隣接関係を構成する BGP スピーカーに役割を与えることで、役割通りの経路交換を強制し、意図しない経路交換 (BGP Route Leak) を防ぐ技術 と言えるかと思います。
では、この BGP Role の具体的な内容を RFC から学習していきましょう。
RFC 9234
RFC 9234 は 2022 年に発行された比較的新しい RFC です。
導入部分であるセクション 1 では、 BGP Route Leak の防止手段としては BGP 経路フィルタが一般的ではあるものの、経路フィルタの適用を AS 間の eBGP セッションで互いに強制と確認ができないため不十分であると書かれています。これらを補うために、 BGP Role は BGP OPEN メッセージで AS 間の役割を eBGP セッション確立時に明確にし、その役割に基づいて eBGP セッションにルーティングセキュリティを実装する技術になります。
以降ではこの RFC の中心である BGP Role Capability と OTC Attribute に分けて説明します。
BGP Role Capability
BGP Role Capability は eBGP セッションを確立する時にお互いの役割を決定・確認するために用いられます。
セクション 3 では AS 間の直接的な eBGP セッションであるピアリングに基づいて役割について定義しています。そして、セクション 4 ではそれらの役割に対応させる形で BGP Role の BGP Capability の値が次の表のように定義されています。
Value
Role name
0
Provider
1
RS (Route Server)
2
RS-Client
3
Customer
4
Peer
5~255
未割り当て
eBGP セッション確立時に、 BGP スピーカーはその eBGP セッションにおける自身の役割を OPEN メッセージ内の BGP Role Capability で相手に知らせます。
続けて、 1 つの eBGP セッションにおける 2 つの BGP スピーカーの役割の組み合わせ、つまり、 BGP スピーカーの関係が次のいずれかと一致する必要があると決められています。
Local AS Role
Remote AS Role
Provider
Customer
Customer
Provider
RS
RS-Client
RS-Client
RS
Peer
Peer
つまり、片方の BGP スピーカーが Provider であれば、もう片方は Customer でなければ関係が成立しません。両方が Provider、両方が Customer であることはありえません。 RS・RS-Client も同様です。 Peer は対等な関係ですので、お互いに Peer の役割である必要があります。もし、 2 つの BGP スピーカーの役割の組み合わせが上記の表のいずれにも一致しなかった場合は、 Role Mismatch Notification として eBGP セッションの接続は拒否されセッションが確立しません。
BGP Role Capability 組み合わせ
なお、BGP Role Capability を自身は送信したものの相手から受信できなかった場合、つまり、相手方の BGP スピーカー (Remote AS) が BGP Role に対応していない場合は、そのまま eBGP セッションの確立を進めることを推奨しています。逆に、 BGP Role Capability の受信をお互いに必須とする strict mode というものもあります。
BGP Only to Customer (OTC) Attribute
OTC Attribute は eBGP セッションで経路を広報・受信する時に交換される経路が Route Leak されたものであるかどうかを判断するために用いられます。
この OTC Attribute は実際の経路交換時に送られる UPDATE メッセージへ付与される Path Attribute です。この Attribute 長は 4 オクテット (バイト) になり、 AS 番号が値として入ります。この Attribute は Optional Transitive なので、 BGP スピーカーはこの Arttribute は無視できますが他の BGP スピーカーにも Attribute をつけた状態で広報する必要がああります。
OTC Attribute が付与された経路 (Prefix) は、 Customer に対してのみ広報でき、それ以外の役割の BGP スピーカーへは広報できません。これにより、 BGP Route Leak を防ぎます。
具体的には BGP による経路受信時・広報時にそれぞれ次の手順によって OTC Attribute の処理が行われます。
[経路受信時]
OTC Attribute が付与された経路を Customer または RS-Client から受信した場合に、その経路は Route Leak されたものであり不適切な経路として扱わなければならない
OTC Attribute が付与された経路を Peer から受信し、かつ、 Attribute の値が Remote AS の AS 番号と一致しない場合は、その経路は Route Leak されたものであり不適切な経路として扱わなければならない
Provider ・ Peer ・ RS から受信した経路に OTC Attribute が付与されていない場合に、その経路に Remote AS の AS 番号を OTC Attribute として付与しなければならない
[経路広報時]
Customer・Peer・RS-Client へ経路を広報しようとしており、かつ、 OTC Attribute がその経路に付与されていない場合は、その経路の広報時に自身の AS (local AS) の AS 番号を OTC Attribute へ付与しなければならない
経路にすでに OTC Attribute が付与されている場合に、その経路を Provider・Peer・RS に広報してはならない
これらの手順によって、 BGP Route Leak な経路交換を送信側・受信側のどちらでも防止できます。
経路受信時の 3 の手順のように、 Remote AS が BGP Role に非対応であったとしても自 AS (Local AS) で OTC Attribute を付与できるため、インターネットの各 AS が一斉に BGP Role を導入しなくても良く、段階的な導入が可能です。
わかりやすいように AS A と B の役割によって AS B から A への経路広報がそれぞれどのように変化するかを図示しました。 RS・RS-Client の Role については割愛しています。
AS B が AS A の Customer の場合
AS B が AS A と Peer の場合
AS B が AS A の Provider の場合
なお、 OTC Attrbute は IPv4 Unicast (AFI1・SAFI1) と IPv6 Unicast (AFI2・SAFI1) でのみ適用され、それ以外のアドレスファミリでは適用してはならないとされています。
また、セクション 6 の Additional Consideration では、複雑なピアリング関係の eBGP セッションでは BGP Role は使用してはならないと書かれています。この複雑なピアリング関係というのは Partial Transit などが該当するのではないかと私は考えていますが、詳しい方がいたら教えてください。
パケットキャプチャ
ここまで RFC 9234 の内容について説明してきました。ここからは実際の BGP Role の動作をパケットキャプチャしながら見ていきます。
今回は BGP スピーカーとして FRRouting (FRR) を使用します。 FRR は バージョン 8.4 から RFC 9234 をサポートしています。
Implement Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages rfc9234
BGP Role Capability を見てみる
まずは、 BGP OPEN メッセージの BGP Role Capability を見たいので下の図のようにシンプルな 1 対 1 の構成を作成します。 FRRouting の BGP Role の設定は 公式ドキュメント に記載されています。
1 対 1 環境構成図
ここでは eBGP セッションが確立する必要最低限の FRR の設定を用意します。
[frr-01]
router bgp 65001
neighbor 192.168.100.2 remote-as 65002
neighbor 192.168.100.2 local-role provider
exit
[frr-2]
router bgp 65002
neighbor 192.168.100.1 remote-as 65001
neighbor 192.168.100.1 local-role customer
exit
これで 2 台の FRR 間で eBGP セッションが確立します。ちゃんと BGP Role 設定も反映されていそうです。
frr-01:/# vtysh -c 'show bgp neighbor' | grep 'Role'
Local Role: provider
Remote Role: customer
Role: advertised and received
frr-02:/# vtysh -c 'show bgp neighbor' | grep 'Role'
Local Role: customer
Remote Role: provider
Role: advertised and received
BGP OPEN メッセージをキャプチャしたところ、 BGP Role の Capability が見えました。この OPEN メッセージは frr-01 から frr-02 へ送られているものなので、 Provider (0) が埋め込まれています。
BGP Role Capability
続けて、 frr-01 の BGP Role を Provider から Customer へ変更してみます。これにより両方の BGP Role が Customer となります。
[frr-01]
router bgp 65001
neighbor 192.168.100.2 remote-as 65002
neighbor 192.168.100.2 local-role customer
exit
そうすると、 OPEN メッセージのやり取り後に "Role Mismatch Notification" が送信されており、 eBGP セッションは確立しませんでした。
Role Mismatch Notification
RFC 通りの動作です！
OTC Attribute を見てみる
さて、最後に BGP Role に合わせて経路が広報されたりされなかったりするのかを確認します。
OTC Attribute と経路広報確認のための構成図
上の構成図にある通り、 frr-03 (AS65003) と frr-04 (AS65004) から frr-02 (AS65002) へ経路を広報し、それらの経路が frr-02 から frr-01 (AS65001) へ広報 (Transit) されるかどうかを見てみましょう。
各 FRR の設定は次の通りです。
[frr-01]
router bgp 65001
no bgp ebgp-requires-policy
neighbor 192.168.100.2 remote-as 65002
neighbor 192.168.100.2 local-role peer
exit
[frr-02]
router bgp 65002
no bgp ebgp-requires-policy
neighbor 192.168.100.1 remote-as 65001
neighbor 192.168.100.1 local-role peer
neighbor 192.168.110.2 remote-as 65003
neighbor 192.168.110.2 local-role peer
neighbor 192.168.120.2 remote-as 65004
neighbor 192.168.120.2 local-role provider
exit
[frr-03]
interface lo
ip address 192.0.2.3/32
exit
!
router bgp 65003
no bgp ebgp-requires-policy
neighbor 192.168.110.1 remote-as 65002
neighbor 192.168.110.1 local-role peer
!
address-family ipv4 unicast
network 192.0.2.3/32
exit-address-family
exit
[frr-04]
interface lo
ip address 192.0.2.4/32
exit
!
router bgp 65004
no bgp ebgp-requires-policy
neighbor 192.168.120.1 remote-as 65002
neighbor 192.168.120.1 local-role customer
!
address-family ipv4 unicast
network 192.0.2.4/32
exit-address-family
exit
BGP UPDATE メッセージのキャプチャを確認します。まず、 frr-03 から frr-02 への経路広報です。
BGP Role Peer での広報]
BGP Role は Peer の経路広報なので OTC Attribute として 65003 の値が入っています。
次に frr-04 から frr-2 への経路広報です。
BGP Role Customer での広報
BGP Role が Customer から Provider への経路広報なので OTC Attribute は設定されません。
最後に frr-02 から frr-01 への経路広報です。
BGP Role Peer へのトランジット広報
BGP Role が Peer の経路広報になるため、 Customer から受信した経路に自身の AS 番号である 65002 を値とした OTC Attribute を設定しています。
この状態で frr-02 から frr-01 への経路広報状況を確認したところ、 Customer である frr-04 (AS65004) から受信した 192.0.2.4/32 のみを広報しており、 Peer である frr-03 から受信した 192.0.2.4/32 は広報していませんでした。
frr-02# show ip bgp neighbors 192.168.100.1 advertised-routes
BGP table version is 6, local router ID is 192.168.120.1, vrf id 0
Default local pref 100, local AS 65002
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 192.0.2.4/32 0.0.0.0 0 65004 i
Total number of prefixes 1
つまり、 192.0.2.4/32 は Route Leak 扱いになっており、 RFC 通りの動作と言えそうです。
おわりに
今回の記事では BGP Role について書きました。 シンプルな設定でルーティングセキュリティを実装できるのがとても良いと思いました！インターネットで BGP Role を実装している AS が増えてくるかもしれませんね。
BBSakura Networks Advent Calendar 2025 の他のブログ記事もぜひお読みください。
