■iBGPの欠点
ネットワークの規模が大きくなってくるとiBGPで問題が発生することがあります。懸念されるのはAS内部におけるiBGPの完全メッシュ化です。iBGPではでは近隣ルータから学習した経路を別の近隣ルータにアドバタイズすることはありません。フルメッシュが必要となるのはこのためです。小さなネットワークでは問題となることはありませんが、大規模なネットワークほど表面化します。これの問題を解決する、完全メッシュに代わる手段であるのが次のものです。
- ルートリフレクション
- コンフェデレーション
下記ではルートリフレクションについてメモ書きしています。コンフェデレーションについてはBGPの解説本には必ず出てくる技術ですが未だ現場で使用しているのを見たことがなくマイナーな技術で理解しておいてもあまり役立つことがなさそうに思います。
■ルートリフレクション
ルートリフレクションを理解するために以下の構成図を見てみましょう。
上の図のR1から流れてくる経路は次のようになります。
- R1がR2経路を送信します。
- R2は経路を受信してローカルに格納します。
- R2がR3に経路を送信します。
- R3は経路を受信してローカルに格納します。
- R4が経路を受け取ることはありません。
上のような事態をさけるための手段の一つとしてiBGPフルメッシュが必要です。これがルートリフレクションを用いると次のように構成を変更することが可能です。
上の図のR1から流れてくる経路は次のようになります。
- R1がR2経路を送信します。
- R2は経路を受信してローカルに格納します。
- R2がR3に経路を送信します。
- R3は経路を受信してローカルに格納します。
- R3はR4に経路をリフレクトします。
- R4は経路を受信してローカルに格納します。
R2とR4は直接PeerをはらなくてもR3経由でiBGP経路をアドバタイズすることが可能となります。これによりPeerの数を減らし、必要セッション数を減らすことが可能となります。
ルートリフレクタの実際の設定はルートリフレクタのみに設定を実施し、ルートリフレクタクライアントには特に何も設定しなくて大丈夫です。R3の設定は次のようになります。
【 R3 】 router bgp 200 no synchronization neighbor 2.2.2.2 remote-as 200 neighbor 2.2.2.2 route-reflector-client neighbor 4.4.4.4 remote-as 200 neighbor 4.4.4.4 route-reflector-client |
ルートリフレクタであるかの確認は以下のように行います。
# show ip bgp neighbors
BGP neighbor is 2.2.2.2, remote AS 200, internal link
BGP version 4, remote router ID 2.2.2.2
BGP state = Established, up for 00:11:48
Last read 00:00:48, last write 00:00:48, hold time is 180, \
keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 2 2
Notifications: 0 0
Updates: 5 8
Keepalives: 19 19
Route Refresh: 0 0
Total: 26 29
Default minimum time between advertisement runs is 0 seconds
For address family: IPv4 Unicast
BGP table version 21, neighbor version 21/0
Output queue size : 0
Index 2, Offset 0, Mask 0x4
Route-Reflector Client
2 update-group member
|
ルートリフレクションで注意すべきことはルートリフレクタが1台の場合、それがこけると機能しなくなるという点です。これを回避するためにルートリフレクタを複数台設置してクラスター構成を組むことが可能です。その場合、ルートリフレクタには共通のCluster-IDを設定する必要があります。以下、設定例です。
router bgp 200 no synchronization bgp cluster-id 1 neighbor 2.2.2.2 remote-as 200 neighbor 2.2.2.2 route-reflector-client neighbor 4.4.4.4 remote-as 200 neighbor 4.4.4.4 route-reflector-client |
■BGPピアグループ
BGPルータがピアに対して同じ更新ポリシーを適用することは一般的なことです。全ての近隣ルータに同じポリシーを適用するには手順的に大変で人為的な設定ミスも誘発しかねません。これを回避する方法がピアグループと呼ばれるものです。近隣ルータをピアグループと呼ばれる一つのグループにまとめて、そのグループに対して設定を行うことが可能です。
上の図でR1に着眼します。R2-R4に対してiBGPのピアをはり、なおかつR1はルートリフレクタとなります。この場合のR1の設定は以下のようになります。
router bgp 100 no synchronization bgp log-neighbor-changes neighbor peergroup peer-group neighbor peergroup remote-as 100 neighbor peergroup update-source Loopback0 neighbor peergroup route-reflector-client neighbor 2.2.2.2 peer-group peergroup neighbor 3.3.3.3 peer-group peergroup neighbor 4.4.4.4 peer-group peergroup no auto-summary |
ピアグループの確認コマンドは以下です。
R1# show ip bgp peer-group BGP peer-group is peergroup, remote AS 100 BGP version 4 Default minimum time between advertisement runs is 0 seconds For address family: IPv4 Unicast BGP neighbor is peergroup, peer-group internal, members: 2.2.2.2 3.3.3.3 4.4.4.4 Index 0, Offset 0, Mask 0x0 Route-Reflector Client Update messages formatted 0, replicated 0 Number of NLRIs in the update sent: max 0, min 0 |
ピアグループを使うことで大規模BGPネットワークで必要なコンフィグを削除することができます。また同じ情報を含むはずの複数の更新ポリシーを設定しようとする際の発生するエラーも排除することができます。