BGP（Border Gateway Protocol）の運用において、大規模なネットワークでのスケーラビリティの問題を解決するために欠かせないのがルートリフレクタ（Route Reflector）です。
通常、iBGPピアはフルメッシュ構成が求められ、ネットワークが大きくなるほど複雑さが増しますが、ルートリフレクタを用いることでこの課題を効果的に克服できます。
本記事では、Ciscoルータを使ったルートリフレクタの設定方法や動作の仕組みを解説します。具体的なコマンド例やBGPの属性に関する詳細な解説を交えながら、EBGPピアリングやループ防止メカニズムも含めたトラブルシューティングまでを解説します。
ルートリフレクタの概要
BGPにおいて、ルートリフレクタ（RR: Route Reflector）はiBGPにおけるスケーラビリティの課題を解決するためのメカニズムです。
通常、iBGPピア間ではフルメッシュ構成が必要ですが、大規模なネットワークでは構成の複雑さが増します。ルートリフレクタを使用すると、特定のルータが他のiBGPピアに対してルートを反射（リフレクト）する役割を果たし、フルメッシュ構成を不要にします。
以下の図は、ルートリフレクタがR1、R2、R3にルートを反映する様子。R1から送信されたルート（1.1.1.1/32）がRRを介してR2とR3にアドバタイズされています。
ルートリフレクタは、以下のルールに基づいてルートを転送します:
- EBGPネイバーから学習したルート: 他のEBGPネイバー、iBGPクライアント、非クライアントに転送できます。
- クライアントから学習したルート: 他のEBGPネイバー、iBGPクライアント、非クライアントに転送できます。
- 非クライアントから学習したルート: 他のEBGPネイバーやiBGPクライアントには転送されますが、非クライアントには転送されません。
ルートリフレクタの設定
次に、ルートリフレクタをCiscoルータで設定する手順を示します。例として、R5をルートリフレクタ、R2とR3をそのクライアントとして設定します。なお、R2とR3間の直接的なiBGPネイバー設定は削除します。
R2とR3は通常の iBGP設定と同じです。追加でルートリフレクタ側で、neighborコマンドのオプションに、route-reflector-clientを設定します。
R5(config)#router bgp 235 R5(config-router)#neighbor 192.168.25.2 remote-as 235 R5(config-router)#neighbor 192.168.25.2 route-reflector-client *Apr 26 08:21:49.868: %BGP-5-ADJCHANGE: neighbor 192.168.25.2 Down RR client config change *Apr 26 08:21:49.868: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.25.2 IPv4 Unicast topology base removed from session RR client config change *Apr 26 08:21:50.172: %BGP-5-ADJCHANGE: neighbor 192.168.25.2 Up R5(config-router)#neighbor 192.168.35.3 remote-as 235 R5(config-router)#neighbor 192.168.35.3 route-reflector-client *Apr 26 08:22:24.137: %BGP-5-ADJCHANGE: neighbor 192.168.35.3 Down RR client config change *Apr 26 08:22:24.137: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.35.3 IPv4 Unicast topology base removed from session RR client config change *Apr 26 08:22:25.162: %BGP-5-ADJCHANGE: neighbor 192.168.35.3 Up
R2は、ループバックアドレスをアドバタイズする設定を行います。
R2(config)#router bgp 235 R2(config-router)#network 2.2.2.2 mask 255.255.255.255
その後、R3のBGPテーブルでルート（2.2.2.2/32）が学習されているか確認します。
R3#sh ip bgp
BGP table version is 4, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
* i 2.2.2.2/32 192.168.25.2 0 100 0 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
ただし、2.2.2.2/32はベストパスではありません。これはR3がネクストホップ（192.168.25.2）に到達できないためです。R2、R3、R5でEIGRPを設定し、各ルータ間の到達性を確保します。
R5(config)#router eigrp 100 R5(config-router)#network 192.168.25.0 0.0.0.255 R5(config-router)#network 192.168.35.0 0.0.0.255 R2(config)#router eigrp 100 R2(config-router)#network 192.168.25.0 0.0.0.255 R3(config)#router eigrp 100 R3(config-router)#network 192.168.35.0 0.0.0.255
これで、R3は2.2.2.2/32をベストパスと見なします
R3#sh ip bgp
BGP table version is 5, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 2.2.2.2/32 192.168.25.2 0 100 0 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
外部ASからのルート挿入
このセクションでは、R1（AS1）とR2（AS235）をEBGPでピアリングし、外部ASからのルートをiBGP経由で他のルータにアドバタイズする方法を解説します。この手順では、R1がAS1内でループバックアドレス（1.1.1.1/32）をアドバタイズし、それをR2が受信してBGPテーブルに登録します。最終的に、このルートがルートリフレクタ（R5）およびR3に反映される過程を確認します。
ステップ1: R1とR2のEBGPピアリング設定
まず、R1とR2でEBGPピアリングを確立し、R1のループバックアドレス（1.1.1.1/32）をアドバタイズします。
R1(config)#router bgp 1 R1(config-router)#neighbor 192.168.12.2 remote-as 235 R1(config-router)#network 1.1.1.1 mask 255.255.255.255
R2(config)#router bgp 235 R2(config-router)#neighbor 192.168.12.1 remote-as 1
この設定により、R1とR2の間でEBGPセッションが確立されます。しばらくすると、ネイバーがアップします。ピアリングが成功すると、R2のBGPテーブルにR1から受信したルート（1.1.1.1/32）が表示されます。
R1# *Apr 26 08:41:04.808: %BGP-5-ADJCHANGE: neighbor 192.168.12.2 Up
ステップ2: R2のBGPテーブル確認
R2のBGPテーブルで、1.1.1.1/32のエントリが正しく登録されているかを確認します。
R2#sh ip bgp
BGP table version is 6, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 192.168.12.1 0 0 1 i
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*>i 3.3.3.3/32 192.168.35.3 0 100 0 i
この出力から、R2が1.1.1.1/32のルートをネクストホップ192.168.12.1で学習していることがわかります。このルートはeBGPで学習された経路のため、iBGPピアにも転送されるはずです。
ステップ3: R5でのBGPテーブル確認
次に、ルートリフレクタであるR5のBGPテーブルを確認します。R5は、R2から学習した1.1.1.1/32のルートを保持しているものの、最初はベストパスとして選定されていません。以下の出力を参照してください。
R5#sh ip bgp
BGP table version is 7, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
* i 1.1.1.1/32 192.168.12.1 0 100 0 1 i
*>i 2.2.2.2/32 192.168.25.2 0 100 0 i
*>i 3.3.3.3/32 192.168.35.3 0 100 0 i
R3#sh ip bgp 1.1.1.1 % Network not in table
この時点では、R5が1.1.1.1/32へのネクストホップである192.168.12.1に到達できないため、R5はこのルートをベストパスと見なしていません。BGPでは、ベストパスでないルートは他のピアにアドバタイズされないため、R3にこのルートが転送されません。
ステップ4: EIGRPでネクストホップ到達性を確保
1.1.1.1/32がR3にも反映されるようにするため、R2でEIGRPを設定し、192.168.12.0/24をアドバタイズします。これにより、R5が192.168.12.1への到達性を確保し、1.1.1.1/32がベストパスとして選定されます。
R2でのEIGRP設定
R2(config)#router eigrp 100 R2(config-router)#network 192.168.12.0 0.0.0.255
このEIGRP設定により、R5は192.168.12.0/24への到達性を持つようになり、1.1.1.1/32がベストパスとして選ばれます。R5のBGPテーブルを再度確認すると、以下のようになります。
R5#sh ip bgp
BGP table version is 8, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 192.168.12.1 0 100 0 1 i
*>i 2.2.2.2/32 192.168.25.2 0 100 0 i
*>i 3.3.3.3/32 192.168.35.3 0 100 0 i
R5が1.1.1.1/32をベストパスとして選定したため、R3に対してもこのルートがアドバタイズされるようになります。
ステップ5: R3でのBGPテーブル確認
最終的に、R3でも1.1.1.1/32がBGPテーブルに登録され、ベストパスとして選ばれることを確認します。
R3#sh ip bgp
BGP table version is 6, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 192.168.12.1 0 100 0 1 i
*>i 2.2.2.2/32 192.168.25.2 0 100 0 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
1.1.1.1/32がR3のBGPテーブルにもベストパスとして登録されていることが確認できます。これにより、外部ASからのルートがiBGP経由で内部ネットワーク全体に伝播されたことが確認できました。
属性（Originator、Cluster-list）
BGPルートリフレクタ（RR: Route Reflector）を利用すると、通常のiBGPルールでは発生しないループが発生する可能性があります。そのため、ルートリフレクタでは、ループ防止のために追加のBGP属性であるOriginatorとCluster-listが使用されます。これらの属性は、ルートがリフレクトされる過程でループを検知し、適切にフィルタリングする役割を担います。
R5で、受信した1.1.1.1/32のルート情報の詳細を見てみます
R5#sh ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 8
Paths: (1 available, best #1, table default)
Advertised to update-groups:
2
Refresh Epoch 1
1, (Received from a RR-client)
192.168.12.1 (metric 307200) from 192.168.25.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
ルートリフレクタクライアントから受信したルートだとわかります。（Received from a RR-client）
そのため、このルートをクライアントであるR3にアドバタイズします
R5#show ip bgp neighbors 192.168.35.3 advertised-routes
BGP table version is 8, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.1/32 192.168.12.1 0 100 0 1 i
*>i 2.2.2.2/32 192.168.25.2 0 100 0 i
*>i 3.3.3.3/32 192.168.35.3 0 100 0 i
Total number of prefixes 3
R3では、1.1.1.1/32がどのように見えるのか確認します。
R3#show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 6
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 2
1
192.168.12.1 (metric 332800) from 192.168.35.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 2.2.2.2, Cluster list: 5.5.5.5
rx pathid: 0, tx pathid: 0x0
すると、以下２つの新しいフィールドが現れています。
- Originator: 2.2.2.2
- Cluster list: 5.5.5.5
Originator
Originatorは、ルートの発生元を示す属性で、ルートリフレクタがクライアントから受信した際に付加されます。この属性には、ルートを最初に発生させたルータのルータIDが記録されます。ルートが再び同じOriginatorに戻ると、このルートは拒否され、BGPループを防止する仕組みです。
R3での1.1.1.1/32のルート情報の確認
R3#show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 6
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 2
1
192.168.12.1 (metric 332800) from 192.168.35.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 2.2.2.2, Cluster list: 5.5.5.5
rx pathid: 0, tx pathid: 0x0
上記の出力にあるOriginatorフィールドには「2.2.2.2」と表示されており、これはR2のルータIDです。このことから、R5がこのルートをR2から受信したことが確認できます。R2がこのルートを再び受信すると、OriginatorのIDが一致するため、ルートが拒否され、ループが防止されます。
Cluster-list
Cluster-listは、ルートリフレクタ間でのループを防止するための属性です。ルートリフレクタがルートをリフレクトする際に、自身のルータIDをCluster-listに追加します。もし別のルートリフレクタがこのCluster-listに自分のIDを発見すると、ルートが拒否されます。これにより、複数のルートリフレクタを通過するルートであってもループが防止されます。
R3での1.1.1.1/32のルート情報の確認
R3#show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 6
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 2
1
192.168.12.1 (metric 332800) from 192.168.35.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 2.2.2.2, Cluster list: 5.5.5.5
rx pathid: 0, tx pathid: 0x0
この出力では、1.1.1.1/32のルートにOriginatorとして「2.2.2.2」、Cluster-listとして「5.5.5.5」が含まれていることがわかります。これにより、R3がルートを学習する際に、どのルータを経由しているのかが明確になり、ループを防止することができます。
ループ防止の具体的なメカニズム
BGPは通常、同一AS内のルータ間では受信したルートを他のiBGPピアにアドバタイズしません。このルールによって、ループの発生が防がれます。しかし、ルートリフレクタはこの制限を取り払うことでiBGPのスケーラビリティを向上させます。そこで、ループ防止のために新たに設けられた仕組みが、OriginatorとCluster-listです。これらの属性は、以下のように動作します。
Originator属性:
- クライアントから受信したルートには、最初の発生元のルータIDが付加されます。
- 他のルートリフレクタやクライアントにルートがリフレクトされる際、このOriginator IDを含むルートは、再度発生元のルータで拒否されます。
- これにより、同じルートが再び発生元に戻るループが防止されます。
Cluster-list属性:
- ルートリフレクタがルートを反映する際、自身のルータIDをCluster-listに追加します。
- 他のルートリフレクタがこのCluster-listに自分のIDを発見した場合、そのルートを拒否することで、ループを防止します。
- この仕組みは、特に複数のルートリフレクタを持つ複雑なネットワーク環境で効果的です。
まとめ
BGPルートリフレクタは、大規模なiBGPネットワークにおいて、フルメッシュ構成の複雑さを解消する有効なソリューションです。本記事では、Ciscoルータを使用したルートリフレクタの基本設定から、EBGPによる外部ASからのルート挿入、そしてOriginatorやCluster-list属性によるループ防止の仕組みを解説しました。iBGPのスケーラビリティを向上させつつ、ルーティングループを回避することができます。
その他 BGP関連記事は >> ルーティングプロトコル（BGP）まとめ << より参照できます。
コメント