BGPマルチホーミング&相互再配送の環境における経路学習問題

Toshiaki Kasakake · ‎2012-11-09

以下ではよくお問い合わせ頂く事例として、eBGP マルチホーミングと相互再配送の環境での BGP 経路学習の問題を紹介します。

ここでは下記の構成を想定します。

【構成図】

【問題の概要】

あるLAN環境に BGP にて外部ネットワークと接続している構成を想定します。

ここで Gateway Router (R1/R2) は上図のように冗長化されており、それぞれがBGP-IGPの相互再配送を行います。

ここでどちらかの eBGP neighbor が down した場合、R1/R2 にて eBGP 経路がベストパスとして選ばれない事象が発生し得ます。

【事象詳細】

正常時において、AD値=20 の eBGP 経路がベストパスとして Routing Table に学習されているため、下記の赤線のようなパスが選ばれます。

(Metric調整で LAN 内では R1 からの経路を優先するとします)

このときの R1 の Routing/BGP Table は下記のようになります。

R1#show ip route 
      10.0.0.0/32 is subnetted, 1 subnets
B        10.1.1.1 [20/0] via 172.16.0.3, 00:07:15
R1#show ip bgp 
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.1/32      172.16.0.3               0             0 65001 i
*> 192.168.1.0      0.0.0.0                  0         32768 ?

ここで、例えばR1 eBGP の障害発生により neighbor down が発生しても、LAN Network 内のデバイスは R2 経由で BGP Network へ到達可能です。

このときの R1 の Routing/BGP Table は下記のようになります。

(R2 からの OSPF 経由の経路を学習し、それを BGP へ再配送している状況です)

R1#show ip route 
      10.0.0.0/32 is subnetted, 1 subnets
O E2     10.1.1.1 [110/200] via 192.168.1.2, 00:09:39, FastEthernet1/0
R1#show ip bgp 
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.1/32      192.168.1.2            200         32768 ?
*> 192.168.1.0      0.0.0.0                  0         32768 ?

その後 R1のBGP障害が復旧した場合、意図しない IGP 経路が R1 Routing Table に残り続ける状況がありえます。この場合、Backup 側となる R2 のパスが使用され続ける状況となります。

事象発生時の R1 Routing/BGP Table は下記のようになります。

優先すべき eBGP パスが Routing Table にのらず、IGP 経路が学習され続ける状態となります。この際、BGP Table では eBGP 経路も学習されておりますが、もうひとつの OSPF からの再配送で学習した Path (Nexthop:192.168.1.2) が優先されている状況が確認できます。

R1#show ip route 
      10.0.0.0/32 is subnetted, 1 subnets
O E2     10.1.1.1 [110/200] via 192.168.1.2, 00:10:54, FastEthernet1/0
R1#show ip bgp  
   Network          Next Hop            Metric LocPrf Weight Path
*  10.1.1.1/32      172.16.0.3               0             0 65001 i
*>                  192.168.1.2            200         32768 ?
*> 192.168.1.0      0.0.0.0                  0         32768 ?

この BGP Table 上でのベストパス計算結果は BGP best path selection のルールにおける期待動作となり、再配送による Local 生成の Prefix の方が

Weight値が高いために Best Path として選ばれてしまいます。このため、eBGP からの Prefix が選ばれず、IGP 経路 (この例では AD値=110のOSPF経路) がベストパスとして Routing Table に学習され続ける状況が見られます。

【回避策】

回避策としては、eBGP からの経路をより高いWeight値となるよう調整することで、BGP復旧後も eBGP からの経路を優先させることができます。

設定例は例えば下記のようになります。

1. Neighbor へ直接設定する方法

router bgp 65000

neighbor 172.16.0.3 weight xxxxx

(xxxxxは32768より高い値を設定)

または

2. Route-map により Neighbor へ設定する方法

route-map WEIGHT permit 10

set weight xxxxx

router bgp 65000

neighbor 172.16.0.3 route-map WEIGHT in

または

相互再配送となりますので、3. BGP 網からの経路を IGP -> BGP の再配送時に BGP Network Prefix を Filter する のも有効です。