はじめに
この検証を実施するに至った経緯ですが、「eBGPピアを確立したルータは、HSRPで冗長できるんだっけ？」という疑問がきっかけです。CCNAやCCNPで扱うポピュラーな技術ですが、BGPピアを行うルータをHSRPで冗長する構成が問題に出ることもなく、調査してもそれらしい情報もでてこなかったので、それなら検証してみるかー！となった次第です。
結果から申し上げると、「BGPピアを行うルータの両方でHSRPで冗長している場合、BGPピアを確立できない」ということになります。両方？ということは、片方はOK？ということになりますが、検証してみたところ片方だけなら大丈夫みたいですね。（その話は別の場所で）
※とはいえ、今回はGNS3で検証しています。検証できるルータの種類には限りもありますので、実装する予定がある方は是非とも実際に使用する機器で検証してみてください。結果は保証はできないです。
構築環境
GNS3で検証をしています。また、ルータはCisco2600シリーズのIOSを使用して検証をしています。
構成図
構成と検証内容について
・PC１とPC２はルーティングを入れないと疎通できないことを想定しています（デフォルトルートは使用しない）。疎通できない状態からR1とR2、R3とR4にBGP設定を入れることで、R1とR2は192.168.20.0/24を学習し、R3とR4は192.168.0.0/24を学習します。結果、それぞれのルータにルーティングを入れなくてもPC同士が疎通できるようになる想定。
・R1とR2およびR3とR4はそれぞれHSRPを使用して冗長しています。
R1とR2はPC１にとってデフォルトルートゲートウェイになり、R3とR4はPC2のデフォルトゲートウェイになります。
config
HSRPおよびBGPに必要なconfigを入れます。本検証のポイントは「BGPのneighborで指定した対抗のIPアドレスが、HSRPで冗長されたVIPである」ということです。
R1のBGP設定では「neighbor 192.168.10.110 remote-as 65001」と設定しています。これはR3とR4のVIPとなります。
一方で、R3のBGP設定では「neighbor 192.168.10.10 remote-as 65000」と設定していて、R1とR2のVIPを指定しています。
果たして疎通できるのか？というところを見ます。
R1
R1#show run
Building configuration...
Current configuration : 1376 bytes
!
version 12.4
…
!
track 1 interface Ethernet0/0 line-protocol
delay down 1 up 15
!
track 2 interface FastEthernet1/0 line-protocol
delay down 1 up 15
!
interface Ethernet0/0
ip address 192.168.0.1 255.255.255.0
half-duplex
standby 1 ip 192.168.0.10
standby 1 priority 110
standby 1 preempt
standby 1 track 2 decrement 20
!
interface FastEthernet1/0
ip address 192.168.10.1 255.255.255.0
duplex auto
speed auto
standby 2 ip 192.168.10.10
standby 2 priority 110
standby 2 preempt
standby 2 track 1 decrement 20
!
router bgp 65000
no synchronization
bgp log-neighbor-changes
network 192.168.0.0
neighbor 192.168.10.110 remote-as 65001
no auto-summary
!
…R2
R2#show run
Building configuration...
Current configuration : 1328 bytes
!
version 12.4
…
!
track 1 interface Ethernet0/0 line-protocol
delay down 1 up 15
!
track 2 interface FastEthernet1/0 line-protocol
delay down 1 up 15
!
interface Ethernet0/0
ip address 192.168.0.2 255.255.255.0
half-duplex
standby 1 ip 192.168.0.10
standby 1 preempt
standby 1 track 2 decrement 20
!
interface FastEthernet1/0
ip address 192.168.10.2 255.255.255.0
duplex auto
speed auto
standby 2 ip 192.168.10.10
standby 2 preempt
standby 2 track 1 decrement 20
!
router bgp 65000
no synchronization
bgp log-neighbor-changes
network 192.168.0.0
neighbor 192.168.10.110 remote-as 65001
no auto-summary
!
…R3
R3#show run
Building configuration...
Current configuration : 1431 bytes
!
version 12.4
…
!
track 1 interface Ethernet0/0 line-protocol
delay down 1 up 15
!
track 2 interface FastEthernet1/0 line-protocol
delay down 1 up 15
!
interface Ethernet0/0
ip address 192.168.10.101 255.255.255.0
half-duplex
standby 3 ip 192.168.10.110
standby 3 priority 110
standby 3 preempt
standby 3 track 2 decrement 20
!
interface FastEthernet1/0
ip address 192.168.20.1 255.255.255.0
duplex auto
speed auto
standby 4 ip 192.168.20.10
standby 4 priority 110
standby 4 preempt
standby 4 track 1 decrement 20
!
router bgp 65001
no synchronization
bgp log-neighbor-changes
network 192.168.20.0
neighbor 192.168.10.10 remote-as 65000
no auto-summary
!
…R4
R4#show run
Building configuration...
Current configuration : 1333 bytes
!
version 12.4
…
track 1 interface Ethernet0/0 line-protocol
delay down 1 up 15
!
track 2 interface FastEthernet1/0 line-protocol
delay down 1 up 15
!
interface Ethernet0/0
ip address 192.168.10.102 255.255.255.0
half-duplex
standby 3 ip 192.168.10.110
standby 3 preempt
standby 3 track 2 decrement 20
!
interface FastEthernet1/0
ip address 192.168.20.2 255.255.255.0
duplex auto
speed auto
standby 4 ip 192.168.20.10
standby 4 preempt
standby 4 track 1 decrement 20
!
router bgp 65001
no synchronization
bgp log-neighbor-changes
network 192.168.20.0
neighbor 192.168.10.10 remote-as 65000
no auto-summary
!
…PC1-> PC2で pingを実行してみる
先に結論を書いていたので分かっていることでしたが、疎通はできないです。
原因は何？
原因は、BGPピアが確立できないからです。ではなぜBGPピアが確立できないのか。ちなみに、「show ip bgp 」の結果を見た結果は以下。
R1#show ip bgp
BGP table version is 4, local router ID is 192.168.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.0.0 0.0.0.0 0 32768 i確かにピアを確立できていないです…。
R1 -> R3のpingはできるのに、どうしてBGPピアは確立できないのでしょう？
debug してみる
「できない！？なんで？」と黙っていてもコンソールには何も情報が出てきません。
サーバーでもCisco機器でも、原因がわからないならlogを見ることでその原因らしきものが見えてきます。「debug ip bgp」で出力を行います。
R1#debug ip bgp
BGP debugging is on for address family: IPv4 Unicast
*Mar 1 01:56:24.016: BGP: 192.168.10.110 open active, local address 192.168.10.1
*Mar 1 01:56:24.277: BGP: 192.168.10.110 open failed: Connection refused by remote host, open active delayed 29199ms (35000ms max, 28% jitter)
R1#ちなみに、しばらく出力を見守っていても、このメッセージが永遠に出力され続けます。程よいタイミングで「no debug ip bgp」を実行しましょう。R3でもdebugをしてみます。
R3#debug ip bgp
BGP debugging is on for address family: IPv4 Unicast
*Mar 1 02:31:39.492: BGP: 192.168.10.10 open active, local address 192.168.10.101
*Mar 1 02:31:39.548: BGP: 192.168.10.10 open failed: Connection refused by remote host, open active delayed 29904ms (35000ms max, 28% jitter)
R3#debug結果を見る
R1のログを見る限り、neighborのIPアドレスである192.168.10.110にopenメッセージを送っているように見えます。ただし、送信元(local address)が192.168.10.1となっています。R3のBGP設定ではneighborのIPアドレスは192.168.10.10(R1のVIP)となっているので、R3からすると知らないアドレスからピアを確立しに来ていることになります。
R3のログも同様に、neighborのIPアドレスである192.168.10.10へopenメッセージを送っているように見えますが、送信元のIPアドレスがVIPではなく192.168.10.101から送信しています。
つまり、ピアが確立できないのはBGPメッセージを送る際のIPアドレスは出力するインターフェースのIPアドレスになることが原因ということになります。
送信元のIPアドレスは変えられない？
「loopbackインターフェースのIPアドレスをBGPメッセージの送信元IPアドレスにしたい。その時の設定方法は…」という話は結構ポピュラーです。「もしかしてVIPにできる？」と思いコマンドを漁ってみました。
R1(config-router)#neighbor 192.168.10.110 update-source ?
Async Async interface
BVI Bridge-Group Virtual Interface
CDMA-Ix CDMA Ix interface
CTunnel CTunnel interface
Dialer Dialer interface
Ethernet IEEE 802.3
FastEthernet FastEthernet IEEE 802.3
Lex Lex interface
Loopback Loopback interface
MFR Multilink Frame Relay bundle interface
Multilink Multilink-group interface
Null Null interface
Port-channel Ethernet Channel of interfaces
Tunnel Tunnel interface
Vif PGM Multicast Host interface
Virtual-PPP Virtual PPP interface
Virtual-Template Virtual Template interface
Virtual-TokenRing Virtual TokenRing
vmi Virtual Multipoint Interface残念ながら今回検証した機器ではそれらしき選択肢はなさそうです。（他のバージョンならいける？わかりませんが…。）
片方が冗長している場合について
今回はHSRPで冗長しようとするとどうなるかを検証してみました。「できなかったけど、どうして？」ということを考えると、「そもそもBGPは何を見てピアを確立しようとするのか？」といった基本的な部分を再認識できました。個人的には検証の楽しみってこういうところにあるなーとおもったりします。
今回の構成で、R1、R2はそのまま冗長させておき、R4をなくしてR3だけにした場合はどうなるのでしょうか。こちらも検証しましたが、思った以上に長くなったので別でまとめることにします。
