0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

BGP Best-path Selection 【CCIEメモ_20250919-28】

Posted at

久々だ!
環境新しくしたり悲しいことがあったりした。

参考資料・時間

資料:
CCIE Enterprise Infrastructure Foundation lab
BGP lab 11

勉強時間:
20250919 : 約2.5時間
20250920 : 約3時間
20250921 : 約2.5時間
20250923 : 約2時間
20250924 : 約2.5時間
20250925 : 約2.5時間
20250926 : 約1時間
20250927 : 約4時間

学習内容

BGP Best-Path Selection

最適パスを選択する優先順位について。
基本的にこすり倒されてる内容なので要点だけ。

優先順位

以下の順位で優先となる。
値の大小によって優先値が異なるため、何を以て優先となるか記載。

Attribute 優先
Weight
Local Preference
Originated -
AS-PATH
Origin Code IGP
MED
Path-Learned eBGP
IGP Nexthop
Multi-path ※1 -
Oldest -
BGP Router-ID
Cluster-List ※2
Peer's nexthop

※1 maximum-paths が有効な場合のみ
※2 Route-Reflectorが有効な場合のみ

優先度が同値の場合次の優先度を使って最適経路を決定する。
Weightが同値であればLocal-Preference…という形。

Weight

同じルートを複数のルータから学習した際、特定のルータで送出するかを決定する際に使用する。

特徴

自身がnetwork, redistribute, aggregate-addressコマンドで生成したルートに付与される。

隣接ルータへはアドバタイズされない。
そのため設定を行う際はin方向にのみ設定可能。

明示的にWeight値を変更するには
特定のルータから学習するルートを優先する際は
neighbor [ip] weight [0-65535]

プレフィックス毎に優先度を変更する場合は
route-map WEIGHT permit
set weight [0-65535]
で作成したroute-mapをin側で設定する。
※out側に設定しても正常に動作しない。


設定例

・前提

R2#sh ip bgp 110.19.1.1
BGP routing table entry for 110.19.1.1/32, version 46
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     1          2          3
  Refresh Epoch 2
  200 100
    200.2.16.16 from 200.2.16.16 (16.16.16.16)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  100
    200.2.20.20 from 200.2.20.20 (20.20.20.20)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

・設定

R2#sh run | sec ip prefix-list|route-map|router bgp 312

ip prefix-list 1 seq 5 permit 110.19.1.1/32

route-map WEIGHT permit 10
 match ip address prefix-list 1
 set weight 100
route-map WEIGHT permit 20

router bgp 312
 bgp router-id 2.2.2.2
 neighbor 200.2.10.10 remote-as 400
 neighbor 200.2.16.16 remote-as 200
 neighbor 200.2.16.16 route-map WEIGHT in
 neighbor 200.2.20.20 remote-as 100

・結果

R2#sh ip bgp 110.19.1.1
BGP routing table entry for 110.19.1.1/32, version 88
Paths: (3 available, best #2, table default)
  Advertised to update-groups:
     1          2          3
  Refresh Epoch 5
  200 100
    200.2.16.16 from 200.2.16.16 (16.16.16.16)
      Origin IGP, localpref 100, weight 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 3
  100
    200.2.20.20 from 200.2.20.20 (20.20.20.20)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

Local Preference

特定のルートに対し、どのルータから送出するかを指定する。
iBGP内の出口を固定化するイメージ。

特徴
Weightが他のルータにWeight属性を通知しないのに対し、Local PreferenceはiBGPにのみLocal Preferenceを通知する。
これにより、iBGP内全体で特定のルートを一つのルータ(出口)で送出するよう設定できる。

・コンフェデレーション機能を使用する際、コンフェデレーション識別子(外部から見たAS番号)が同じであれば、eBGP接続の場合もLocal-Preferenceの通知を行う。


Originated

自身がBGPテーブルに挿入したパスを優先する。
ここでいうBGPテーブルに挿入というのは、インターフェースを自身で持っている…という事に限定しない。

IGPによって学習した経路をredistributeしたものや、aggregate-addressで集約した経路も対象に含まれる。

つまり、network・redistribute・aggregate-addressコマンドでBGPテーブルに挿入したルートが対象となる。

また、自身がBGPテーブルに挿入したルータはデフォルトでWeight値が最大で設定される。
そのため、Originatedが比較として使われるのは意図的にWeight値を0にした状況となる。


AS-PATH

eBGPによって通過したASの数が少ない経路を優先する。

特徴

AS-PATHはeBGPにてアドバタイズされる際に自身のASを先頭に追加する形となる。
そのため、自身の持つインターフェースをBGPテーブルに挿入し、iBGPでアドバタイズされる際にはAS-PATHは空白で送信することになる。

Path attributes
    Path Attribute - ORIGIN: IGP
    Path Attribute - AS_PATH: empty
    Path Attribute - NEXT_HOP: 15.15.15.15 
    Path Attribute - MULTI_EXIT_DISC: 0
    Path Attribute - LOCAL_PREF: 100

AS-PATHは推移属性であり、基本的に途中で書き換えられる事はない。
(remove-private-as等で削除されることもある)

AS-PATHは短いものが優先される。
コンフェデレーションBGPを使用する際はコンフェデレーション内のBGP-PATHは無視される。
※()内の数字がコンフェデレーションBGP内のASパス長となる。
ループ防止機構としてのAS-PATHのため利用される感じ。

以下ではIGPから学習したmetricが低い方(11)がbestとなる。

R4#sh ip bgp 110.19.1.1
BGP routing table entry for 110.19.1.1/32, version 142
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     3          4
  Refresh Epoch 1
  (336 312) 100
    3.3.3.3 (metric 11) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, confed-external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  (312) 100
    2.2.2.2 (metric 21) from 1.1.1.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      rx pathid: 0, tx pathid: 0

AS-PATHの優先順位を変更するには、AS-PATHシーケンス(100 200 iみたいな情報)の先頭にダミーのAS情報を付与することで、特定のルートの優先度を下げることしかできない。
方法はroute-mapでset as-path prependを設定後、インバウンドまたはアウトバウンドでneighborに適用する。

AS-Path prependにて追加するAS-Pathは自身のローカルASを追加する事が一般的だが、外部ASを追加することも可能。
iBGPのみで接続されたルータで自身のローカルASを設定すると、隣接ルータは自身のASが通知されるためループと扱うためDenyされる。
逆にeBGPで外部ASを追加した場合、追加した外部ASを持つ機器がそのupdateを受け取った際にループと扱うことでDenyされる。

もしAS-PATHでのベストパス選択を無効にしたい場合は以下の隠しコマンドで無効にできる。
ただし、AS-PATHのループ防止機能は無効化できない。

bgp bestpath as-path ignore

Origin Code

Origin CodeはBGPテーブルにルートが挿入された際に、どのように挿入されたかを示す。
Origin Codeの種類はIGP・EGP・?(incomplete)の三種類であり、IGP > EGP > ?の順で優先される。

IGPはnetwork, aggregaet-addressで生成されたルートに付与される。
EGPはレガシーなルータで利用されているため現状ではほぼ見かけることはない。
?はredistributeで生成されたルートが対象となる。

Origin Codeは推移属性であり、特に設定が無ければ他のルータで書き換えられる事はない。
route-mapを使用することで、IGPとincompleteに書き換えは可能。

サンプルは以下の例。AS-PATHシーケンスの左がiだとIGP。?はincomplete

 *>i  130.7.1.1/32     10.10.10.10              0    100      0 300 i
 *>i  134.16.1.1/32    10.10.10.10              0    100      0 300 100 ?

MED

BGPにおけるメトリック。
小さい方が優先度が高いのだが、初期値は0となっている。

基本的にはiBGPのみに通知され、eBGPには出ていかないのだが
例外的にeBGPに通知されることもある。

MED値はIGP(RIP, OSPF, EIGRP等)で学習したルートをnetworkコマンドでBGPテーブルに挿入した場合、IGPのメトリックがBGPのメトリックとなる。

例) metricが41になっている。

R2#sh ip bgp 130.7.1.1
BGP routing table entry for 130.7.1.1/32, version 117
Paths: (2 available, best #1, table default, RIB-failure(17))
  Advertised to update-groups:
     5          7
  Refresh Epoch 3
  (336 345 378)
    3.3.3.3 (metric 11) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, confed-external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 2
  (345 378)
    7.7.7.7 (metric 41) from 1.1.1.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, confed-internal
      rx pathid: 0, tx pathid: 0


R2#conf t
R2(config)#router bgp 312
R2(config-router)#network 130.7.1.1 mask 255.255.255.255


R2#sh ip bgp 130.7.1.1
BGP routing table entry for 130.7.1.1/32, version 119
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     5          6          7
  Refresh Epoch 1
  Local
    30.2.3.3 from 0.0.0.0 (2.2.2.2)
      Origin IGP, metric 41, localpref 100, weight 32768, valid, sourced, local, best
      rx pathid: 0, tx pathid: 0x0

MED値はroute-map等で意図的に増減させない限り、変更されることはない。
OSPFであればルータを通過するごとにコストが増加するが、MED値はiBGP内で複数のルータを通過しても変更されない。
ただし、eBGPへの通知の際に削除されることがある。

〇eBGPで送出するプレフィックスにMED値が通知されるのは、以下の条件を満たす場合となる。

・発信元のASから別のASに通知される。

・出口となるルータでMED値が設定されたルートがbestになっている。

例としては、
例) AS100 --- AS200 --- AS300

AS100内のエッジルータにMED値が設定されており、そのルートがbestになっている場合、
AS200には通知されるが、AS300には通知されない。

ただしAS100から通知されたルートをAS200が受け取り、AS200内でMED値を変更している場合はAS300に通知を行う。

また、eBGPによってルートに設定されていたMED値が欠落することがある。
※Bestになっていないルートを通知する場合など

その際は受信したエッジルータはMED値を0にする。
だが、コマンドによって欠落したMED値を最大(優先度を最低)にすることも可能。
以下のコマンドを実行することで、MED値が最大(4294967295)になる。

bgp bestpath med missing-as-worst

また、MED値は同じASから受け取った複数のプレフィックスに関しては評価できるが、
別々ののASから受け取ったMED値に関しては評価できない。

例えば、
Metric: 10, AS-Path: 200 100 i と
Metric: 20, AS-Path: 200 100 i は比較可能だが、

Metric: 10, AS-Path: 200 100 iと
Metric: 10, AS-Path: 300 100 iは比較不可。
MED値での比較を無視し、次の優先度の情報で比較を行う。

AS-Pathの違いがあってもMED値評価を有効にするには、以下のコマンドを実行する。

bgp always-compare-med

また、MED値が与えられたASが異なる場合、グループ化して比較することも可能。
そのためには以下のコマンドを実行する。

bgpdeterministic-med

例えば、以下の順序でルートを学習したとする。
Metric: 20, AS-Path: 200 100 i
Metric: 5, AS-Path: 300 100 i
Metric: 10, AS-Path: 200 100 i
Metric: 20, AS-Path: 300 100 i

AS200 100 iのグループはMED値10,
AS300 100 iのグループはMED値5となるが、
先に学習されたAS200 100 iのグループを優先するため、
Metric: 10, AS-Path: 200 100 i がbestとなる。


Path-Learned

同じパスを複数の経路で学習した場合、
iBGPよりもeBGPで学習した経路を優先する。

理由としては、iBGPで学習した経路は複数の内部ルータを通過し他の経路へと通信が行われるが、
eBGPの場合は隣接のeBGPへと送信するため、経路的に近いだろう…という理由。

コンフェデレーションBGPを利用している場合、
confed-externalとconfed-internalは同じくiBGPパスとして扱われる。
要するに、コンフェデレーションBGP内はiBGPだよという考え。


IGP Nexthop

iBGPはスプリットホライズンの動作として隣接パスから受け取ったルートを他のルータに広報しないのでAS内部でのルーティングに使用しづらい。
そのため、OSPF等のIGPを使うことでネクストホップを広報することが多い。

ネクストホップのメトリックの小さい方を優先しようというのがIGP Nexthopとなる。


R7#sh ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *    140.15.1.1/32    3.3.3.3                  0    100      0 (345 336) 400 i
 *>i                   6.6.6.6                  0    100      0 (336) 400 i


R7#sh ip route ospf

      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/31] via 30.7.8.8, 10:24:33, Ethernet0/0.78
      6.0.0.0/32 is subnetted, 1 subnets
O        6.6.6.6 [110/21] via 30.7.8.8, 10:24:33, Ethernet0/0.78


R7#sh ip bgp 140.15.1.1
BGP routing table entry for 140.15.1.1/32, version 94
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     4
  Refresh Epoch 1
  (345 336) 400
    3.3.3.3 (metric 31) from 5.5.5.5 (5.5.5.5)
      Origin IGP, metric 0, localpref 100, valid, confed-external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  (336) 400
    6.6.6.6 (metric 21) from 8.8.8.8 (8.8.8.8)
      Origin IGP, metric 0, localpref 100, valid, confed-internal, best
      rx pathid: 0, tx pathid: 0x0

以上の結果、IGPのnexthop3.3.3.3(metric 31)よりも
nexthop 6.6.6.6(metric 21)が優先となる。


Multi-path

負荷分散のために複数のパスを利用できるようにした際、優先度がどこまで同じ場合に複数のパスを有効にするか。

なので、Multi-Pathは優先度決定として使われるわけではなく、
「ここまで一緒ならmultipathを有効にしますよ」というラインとなる。

なお、負荷分散の方法は以下のコマンドで実施する。

maximum-paths [パス数]: externalパスのみを複数有効にする。

maximum-paths ibgp [パス数]: internalパスのみを複数有効にする。

maximum-paths eibgp [パス数]: internalとexternalを指定したパス数ずつ有効にする。

Oldest

複数のルートを学習した際、最初に学習したルートを優先する。
これにより、Nexthopのフラッピングを防ぐ。

特徴

適用されるパスはeBGPで学習したパスのみ。
iBGPで学習したパスは対象外となる。(コンフェデレーションBGP内のconfed_externalも対象外)

以下の条件に当てはまらないこと
 ・学習したパスのルータIDが複数のパスで同じ場合
 ・bestとなるパスが存在しない場合
 ・"bgp best-path compare-routerid"が有効になっている場合


BGP Router-ID

ルータIDが低いものを優先する。
ルータIDは以下の方法と順序で決定する

 1.bgp router-idコマンドで設定する。(手動)
 2.Loopbackアドレスがある場合、最も大きいIPアドレスがルータIDになる(自動)
 3.非shutdownインターフェースのうち、最も大きいIPアドレスがルータIDになる(自動)

もしルートリフレクタによってORIGINATOR_IDが設定された場合、
ORIGINATOR_IDをルータIDとして扱う。

通常はoldestまでにパスの優先度が決定されるが、oldestでの決定を無視し、router-idの大小で優先度を決定することもできる。
設定には以下のコマンドを実行する。

bgp bestpath comrare-routerid

Cluster-List

ルートリフレクタを使用している場合のみ、Cluster-Listによって優先度を決定する。

殆どの場合はrouter-idの大小で優先度が決定されるが、
ルートリフレクタを使用する場合は同じrouter-idのパスが複数の経路を通過してルータに到着することもある。
この場合、Cluster-listの長短によって優先度を決定する。

R14#show ip bgp 120.18.1.1
BGP routing table entry for 120.18.1.1/32, version 274
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Refresh Epoch 1
  200
    10.10.10.10 (metric 31) from 13.13.13.13 (13.13.13.13)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 1.10.10.10, Cluster list: 13.13.13.13, 12.12.12.12
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  200
    10.10.10.10 (metric 31) from 20.20.20.20 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 1.10.10.10, Cluster list: 11.11.11.11
      rx pathid: 0, tx pathid: 0x0

上のルートは Cluster list: 13.13.13.13, 12.12.12.12だが、
下のルートは Cluster list: 11.11.11.11
と短いため、下が優先される。

また、

R14#show ip bgp 130.7.1.1
BGP routing table entry for 130.7.1.1/32, version 215
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Refresh Epoch 1
  300
    11.11.11.11 (metric 11) from 13.13.13.13 (13.13.13.13)
      Origin IGP, metric 21, localpref 100, valid, internal
      Originator: 11.11.11.11, Cluster list: 13.13.13.13, 12.12.12.12
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  300
    20.20.20.20 (metric 11) from 20.20.20.20 (11.11.11.11)
      Origin IGP, metric 21, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

下のルートはルートリフレクタを経由してないルートであるため、
Cluster-List長が0と扱われる。
そのため、下のルートが優先となる。


Peer's nexthop

ネクストホップのIPが小さいものを優先する。

R14#show ip bgp 120.18.1.1
BGP routing table entry for 120.18.1.1/32, version 280
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  200
    9.9.9.9 (metric 31) from 13.13.13.13 (13.13.13.13)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 9.9.9.9, Cluster list: 13.13.13.13, 12.12.12.12
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  200
    9.9.9.9 (metric 31) from 20.20.20.20 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 9.9.9.9, Cluster list: 11.11.11.11, 12.12.12.12
      rx pathid: 0, tx pathid: 0

ルータIDはOriginator属性を見るのでどちらも9.9.9.9。
Cluster-List長も同じなので、
Nexthopが20.20.20.20より小さい13.13.13.13を優先する。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?