BGP はトランスポートに TCP（ポート179）を使います。OSPF のように隣接ルータとマルチキャストでやり取りするプロトコルと違い、相手のアドレスに TCP で届けばよいので、仕組みのうえではネイバーが直接接続されている必要はありません。ただし eBGP は、Cisco ではデフォルトで直接接続の相手としかピアを張りません。
この記事では、ループバックインタフェース同士で BGP ピアを張るために必要な update-source と ebgp-multihop を、eBGP と iBGP の両方で設定し、ネイバーが Up するまでの動きを確認します。
update-sourceでループバックを送信元にして eBGP を設定する- 相手のループバックへの経路を用意する
ebgp-multihopを設定し、eBGP ネイバーを Up させる- iBGP をループバック同士で設定する
ループバックでピアリングする理由
物理インタフェースのアドレスでピアを張ると、そのインタフェースがダウンした時点で BGP セッションも切れます。ループバックインタフェースは物理的な障害でダウンしないので、ループバック同士でピアを張り、ループバックへの経路を複数の経路（IGP など）で用意しておけば、1本のリンクが切れても別の経路でセッションを維持できます。iBGP では、この理由からループバック同士のピアリングが一般的です。
ループバックでピアを張るときは、update-source で BGP の TCP セッションの送信元をループバックにします。これがないと、ルータは出力インタフェースのアドレス（ここでは 192.168.12.1 など）を送信元にして接続します。相手は neighbor に設定したアドレス（ループバック）以外からの接続をネイバーとして受け付けないので、セッションが確立しません。
eBGP での送信元インタフェース変更
ループバックを送信元にして eBGP を設定する
まず、外部BGP（eBGP）のピアリングでループバックアドレスを使う設定を見ていきます。neighbor に相手のループバックアドレスを指定し、update-source loopback 0 で自分の送信元をループバックにします。
R1
R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 remote-as 23
R1(config-router)#neighbor 2.2.2.2 update-source loopback 0
R2
R2(config)#router bgp 23
R2(config-router)#neighbor 1.1.1.1 remote-as 1
R2(config-router)#neighbor 1.1.1.1 update-source loopback 0
これで R1 と R2 のループバックを送信元にしてピアリングする設定になりましたが、このままではネイバーは Up しません。各ルータが、相手のループバックアドレスへの経路を持っていないためです。
R1#sh ip bgp summary
BGP router identifier 1.1.1.1, local AS number 1
BGP table version is 3, main routing table version 3
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 23 0 0 1 0 0 never Idle
| 表示 | 意味 |
|---|---|
| Neighbor 2.2.2.2 | ネイバーとして設定した R2 のループバックアドレス |
| MsgRcvd / MsgSent 0 | BGP メッセージを一度も送受信していない |
| Up/Down never | 一度も Established になったことがない |
| State/PfxRcd Idle | 接続を始められない状態。Established になると、ここに受信したプレフィックス数が表示される |
相手のループバックへの経路を用意する
それぞれのルータに、相手のループバックへのスタティックルートを設定します。
R1
R1(config)#ip route 2.2.2.2 255.255.255.255 192.168.12.2
R2
R2(config)#ip route 1.1.1.1 255.255.255.255 192.168.12.1
これで相手のループバックに到達できるようになりましたが、まだネイバーは Up しません。
ebgp-multihop を設定する
原因は、eBGP のデフォルトの動作にあります。Cisco の eBGP は、BGP パケットを TTL=1 で送り、さらにネイバーのアドレスが直結のネットワーク上にあるかどうかをチェックします（直結チェック）。相手のループバックは直結のネットワーク上にないので、このチェックで止まり、接続が始まりません。
ebgp-multihop を設定すると、TTL が大きくなり、直結チェックも行われなくなります。ループバックのように直結でないアドレスと eBGP を張るときに使います。
R1
R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 ebgp-multihop
R1 にこの設定を加えると、R1 から R2 の TCP 179番ポートへ接続を試み始めます。しかし R2 側にはまだ ebgp-multihop がないので、R2 にとって 1.1.1.1 は直結チェックを満たさないネイバーのままです。R2 は R1 からの接続を受け付けず、TCP RST（リセット）を返すため、セッションは確立しません。
この記事の画面は、実際の画面ではなく、検証時の画面から見るポイントを抜き出して描いたイメージです。バージョンによって、項目の並びや表記は変わります。
| No. | Source | Destination | Protocol | Length | Info |
|---|---|---|---|---|---|
| 12 | 1.1.1.1 | 2.2.2.2 | TCP | 64 | 61439 → 179 [SYN] Seq=0 Win=16384 Len=0 MSS=1460 |
| 23 | 2.2.2.2 | 1.1.1.1 | TCP | 64 | 179 → 61439 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 |
| No. | 表示 | 意味 |
|---|---|---|
| 1 | 61439 → 179 [SYN] | R1 のループバック（1.1.1.1）から R2 のループバック（2.2.2.2）の179番ポートへ接続を試みている。update-source の設定どおり、送信元がループバックになっている |
| 2 | 179 → 61439 [RST, ACK] | R2 が接続を拒否している。R2 ではまだ 1.1.1.1 とのピアを張れる状態になっていない |
R2 にも同じ設定を行います。
R2
R2(config)#router bgp 23
R2(config-router)#neighbor 1.1.1.1 ebgp-multihop
これで BGP セッションが確立し、ネイバーが Up します。
R1#
*Apr 26 06:35:00.613: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
Wireshark でパケットを確認すると、TTL がデフォルトの 1 から 255 に変わっています。
| No. | Source | Destination | Protocol | Length | Info |
|---|---|---|---|---|---|
| 8 | 1.1.1.1 | 2.2.2.2 | BGP | 77 | KEEPALIVE Message |
| 9 | 2.2.2.2 | 1.1.1.1 | TCP | 64 | 27661 → 179 [ACK] … |
| 10 | 2.2.2.2 | 1.1.1.1 | BGP | 77 | KEEPALIVE Message |
| 11 | 1.1.1.1 | 2.2.2.2 | TCP | 64 | 179 → 27661 [ACK] … |
▸ 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 121▾ Internet Protocol Version 4, Src: 1.1.1.1, Dst: 2.2.2.2 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) ▸ Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT) Total Length: 59 Identification: 0xc84b (51275) ▸ Flags: 0x4000, Don't fragment2 Time to live: 255 Protocol: TCP (6)
| No. | 表示 | 意味 |
|---|---|---|
| 1 | Src: 1.1.1.1, Dst: 2.2.2.2 | ループバック同士で BGP のメッセージ（KEEPALIVE）をやり取りしている |
| 2 | Time to live: 255 | TTL が 1 から 255 になった。ebgp-multihop で TTL の値を省略すると 255 になる |
- 今回の R1 と R2 は直結なので、ループバック宛てのパケットも途中のルータで転送されることはなく、TTL=1 でも相手に届きます。止まっていた原因は TTL ではなく直結チェックです。
- そのため、直結のルータ同士でループバックを使う場合は、
neighbor 2.2.2.2 ebgp-multihop 2のように必要なホップ数だけ指定するか、neighbor 2.2.2.2 disable-connected-checkで直結チェックだけを外す方法もあります。
iBGP での送信元インタフェース変更
iBGP をループバック同士で設定する
次に、内部BGP（iBGP）でループバックアドレスを送信元にする設定を確認します。iBGP はデフォルトで TTL=255 で送り、eBGP のような直結チェックもないので、ebgp-multihop のような設定は必要ありません。
R2
R2(config)#router bgp 23
R2(config-router)#neighbor 3.3.3.3 remote-as 23
R2(config-router)#neighbor 3.3.3.3 update-source loopback 0
R3
R3(config)#router bgp 23
R3(config-router)#neighbor 2.2.2.2 remote-as 23
R3(config-router)#neighbor 2.2.2.2 update-source loopback 0
必要なのは、お互いのループバックアドレスへの経路です。ここではスタティックルートを追加します。
R2
R2(config)#ip route 3.3.3.3 255.255.255.255 192.168.23.3
R3
R3(config)#ip route 2.2.2.2 255.255.255.255 192.168.23.2
数秒後、ネイバーが Up します。
R2#
*Apr 26 06:49:50.618: %BGP-5-ADJCHANGE: neighbor 3.3.3.3 Up
この検証ではスタティックルートを使いましたが、本番の iBGP では一般に、AS 内の IGP（OSPF など）で各ルータのループバックを広告します。IGP がリンク障害時に別の経路へ切り替えるので、ループバック同士の BGP セッションも維持できます。
うまくいかないときの切り分け
| 状態 | よくある原因 | 確認すること |
|---|---|---|
| Idle のまま | 相手ループバックへの経路がない。eBGP なら ebgp-multihop（または disable-connected-check）がない | show ip route <相手のループバック>、show ip bgp neighbors |
| Active のまま | TCP 接続が確立しない。相手側の設定不足（update-source、ebgp-multihop）や、相手から自分のループバックへの経路がない | 相手側の設定、ping <相手のループバック> source loopback 0 |
| RST が返る | 相手側で、こちらのアドレスがネイバーとして有効になっていない | 相手の neighbor のアドレスと、こちらの送信元アドレス（update-source）が一致しているか |
まとめ
ループバック同士で BGP ピアを張るときに必要な設定を、eBGP と iBGP で比べます。
| 設定 | eBGP | iBGP |
|---|---|---|
update-source loopback 0 | 必要（両側） | 必要（両側） |
| 相手ループバックへの経路 | 必要 | 必要（本番は IGP で広告） |
ebgp-multihop | 必要（両側）。直結の相手なら disable-connected-check でも可 | 不要（TTL=255、直結チェックなし） |
ループバック同士でピアリングすると、ループバックへの経路が複数あれば、物理インタフェースの障害時にも BGP セッションを維持でき、ネットワーク全体の可用性が上がります。
コメント