NEXT_HOPとは
NEXT_HOP（Type code 3）は、その経路へパケットを送るときに次に渡すルータのIPアドレスを表すwell-known mandatoryのパス属性です（BGPパス属性とベストパス選択）。
NEXT_HOPは「経路を広告してきたルータのアドレス」とは限りません。あくまでパケットの転送先で、両者がずれる場面がthird-party next hop（後述）です。
| 項目 | 内容 |
|---|---|
| Type code | 3 |
| 分類 | Well-known mandatory（すべての実装が理解でき、UPDATEに必ず入る） |
| 値 | IPv4アドレス4バイト（IPv6ではMP_REACH_NLRI内のNext hopフィールド） |
| 定義 | RFC 4271 5.1.3節 |
NEXT_HOPが設定される規則
広告する側が、広告先のピアごとに値を決めます（RFC 4271 5.1.3）。
| 広告先 | 経路 | 動作 |
|---|---|---|
| iBGPピア | 他のピアから学んだ経路 | NEXT_HOPを書き換えない（受け取った値をそのまま渡す） |
| iBGPピア | 自分が生成した経路 | そのネットワークへ到達するインタフェースのアドレスを使う。直結している場合（または相手自身のアドレスになる場合）は自分のアドレス |
| eBGPピア | — | 既定ではNEXT_HOPを自分のアドレスにする（そのピアとの接続に使っているインタフェースのアドレス） |
学んだ経路をiBGPで書き換えないのは、AS内では出口までの経路をIGPが知っている前提だからです。これが原因で起きる到達性の問題はBGP next-hop-selfで解説しています。
eBGPピアへの値は4つの場合分けで決まり、上の「自分のアドレス」はどれにも当たらないときの既定です。 残りの3つはいずれも、広告先のピアと共通のサブネットを持つアドレスを使えるという規定で、次のthird-party next hopがこれにあたります。
複数ホップ先のeBGPピア（multihop eBGP）の場合は既定で自分のアドレスを使い、設定により受け取ったNEXT_HOPをそのまま伝播させることもできます（RFC 4271 5.1.3の3）。IXのルートサーバーが使う形ですが、この記事の検証では扱っていません。
共有セグメントでのthird-party next hop
RFC 4271 5.1.3は、eBGPピアへ広告する際に広告先ピアと同じサブネット上に転送先のルータがいれば、そのアドレスをNEXT_HOPにしてよいとしています。これがthird-party next hopで、3台以上が1つのL2セグメントを共有し、そのうち2組だけがBGPピアのときに現れます。規定は2つに分かれていて、この記事で扱うのは後者です。
| 元の経路 | NEXT_HOPに使えるアドレス |
|---|---|
| iBGPピアから学んだ経路、または自分が生成した経路 | そのネットワークへ到達する内部ルータのインタフェースアドレス |
| eBGPピアから学んだ経路 | 受け取ったNEXT_HOPから知っている隣接ルータのアドレス |
- R1・R2・R3が同じセグメント上にいる
- BGPピアはR1 - R2とR2 - R3の2組だけ（R1とR3はピアではない）
- R3が広告した経路をR2がR1へ中継する
R2がNEXT_HOPを自分に書き換えると、R1からのパケットは同じセグメントを2回通ります。そこでR2はNEXT_HOPをR3のアドレスのまま渡し、R1が直接R3へ送れるようにします。
NEXT_HOPの値 | R1から見たパケットの流れ |
|---|---|
| R2のアドレス | R1 → R2 → R3（同じセグメントを2回通る） |
| R3のアドレス（third-party） | R1 → R3（1回で済む） |
同じ5.1.3は、自分が生成した経路を相手自身のアドレスをNEXT_HOPにして広告してはならないこと、ルータは自分自身をネクストホップにする経路を入れてはならないことも定めています。IOS XRは受け取った経路でも、NEXT_HOPが広告先ピア自身のアドレスになる場合は自分のアドレスに置き換えます（R1発の経路をR1へ返すときなど）。
ピアごとに判断するので、同じ経路でも渡す相手によってNEXT_HOPが変わります。
同じ5.1.3は、third-party next hopの広告を無効にできることを実装の必須要件としています（“MUST be able to support the disabling advertisement of third party NEXT_HOP attributes”）。ブリッジが完全でない媒体に対応するためで、後述のnext-hop-selfがこの手段にあたります。
再帰的ルックアップとNEXT_HOPの到達性
BGPの経路は、NEXT_HOPをルーティングテーブルで引けて初めて使えます（再帰的ルックアップ、RFC 4271 5.1.3）。引けなければ無効で、show bgpでは>が消え、詳細表示に(inaccessible)が付きます。引けたときに実際の転送先になるのは、そのエントリが直結サブネットでネクストホップを持たなければNEXT_HOP自身、ネクストホップを持つならそのアドレスです。等コストの経路が複数あれば1つが選ばれます。
third-party next hopは共有セグメント上の直結アドレスなので受け取ったルータは解決できますが、iBGPでAS内へ配るとAS内の他のルータからも共有セグメントへ到達できる必要があります。検証ではR4がOSPFでその経路を持っています。
NEXT_HOPを書き換える2つの方法
IOS XRでNEXT_HOPを明示的に制御する方法は2つあり、適用する単位が違います。
| 方法 | 単位 | 用途 |
|---|---|---|
next-hop-self | ネイバー単位 | そのピアへ広告するすべての経路のNEXT_HOPを自分のアドレスにする |
ルートポリシーのset next-hop | プレフィックス単位 | 条件に一致した経路だけNEXT_HOPを指定した値にする |
router bgp <AS番号>
neighbor <ピアのアドレス>
address-family ipv4 unicast
next-hop-selfprefix-set <プレフィックスセット名>
<プレフィックス>
end-set
!
route-policy <ポリシー名>
if destination in <プレフィックスセット名> then
set next-hop <アドレス>
endif
pass
end-policy
!
router bgp <AS番号>
neighbor <ピアのアドレス>
address-family ipv4 unicast
route-policy <ポリシー名> out意図的に自分を経由させたい場合（計測やフィルタなど）は、これらでthird-party next hopを打ち消します。
実機での検証
XRd 26.1.1を4台とL2スイッチ1台で、次を確認します。
- 共有セグメント上でthird-party next hopが発生する
- 同じ経路でも広告先のピアによって
NEXT_HOPが変わる next-hop-selfで打ち消せる（ネイバー単位）- ルートポリシーの
set next-hopでも打ち消せる（プレフィックス単位）
- R1・R2・R3が共有セグメント
10.0.123.0/24に接続しています - eBGPピアはR1 - R2とR2 - R3の2組だけで、R1とR3はピアではありません
- R3が
192.168.3.0/24を広告し、R2経由でR1へ届くときのNEXT_HOPを追います - AS 65001のR4はR1とiBGP・OSPFで接続し、AS内への伝わり方を見ます
| ルータ | AS | 共有セグメント側のアドレス | 広告するネットワーク |
|---|---|---|---|
| R1 | 65001 | 10.0.123.1 | 192.168.1.0/24 |
| R2 | 65002 | 10.0.123.2 | 192.168.2.0/24 |
| R3 | 65003 | 10.0.123.3 | 192.168.3.0/24 |
| R4 | 65001 | （接続なし。R1とP2P） | 192.168.4.0/24 |
| STEP | 操作 | 確かめること |
|---|---|---|
| 0 | 初期状態（ポリシーはpassのみ） | third-party next hopが出る（R1の192.168.3.0/24のNEXT_HOPが10.0.123.3）。R1からR3へは1ホップで届く。R4では自分発の192.168.1.0/24だけNEXT_HOPがR1のLo0になっている |
| 1 | R2のR1向けにnext-hop-self | third-partyを打ち消せる（RFCが実装の必須要件としている無効化）。R1からR3への経路にR2が1ホップ入る。 |
| 2 | next-hop-selfを撤去 | third-partyに戻る |
| 3 | R2のR1向けにset next-hop（192.168.3.0/24だけ） | プレフィックス単位で打ち消せる。192.168.2.0/24は変わらない |
| 4 | ルートポリシーの中身をpassに戻す | 戻る |
| 5 | R1のR4向けにnext-hop-self（iBGP側） | AS内へ配るNEXT_HOPをR1のLo0にできる |
| 6 | R1で共有セグメントをOSPFから外す | next-hop-selfがあるのでR4は影響を受けない |
| 7 | R1のnext-hop-selfを撤去 | R4がNEXT_HOPを解決できなくなる。(inaccessible)になり、転送が止まる |
| 8 | R1のnext-hop-selfを戻す（最終状態） | 復旧する |
各STEPでR1 - スイッチ間・R2 - スイッチ間・R3 - スイッチ間・R1 - R4間の4区間のキャプチャーを取っています。
STEP 0：共有セグメントでthird-party next hopが出る
R2がR1へ広告する2経路のうち、R3発の192.168.3.0/24だけNext HopがR3のアドレスです。R2自身の192.168.2.0/24はR2のアドレスです。
RP/0/RP0/CPU0:R2#show bgp neighbors 10.0.123.1 advertised-routes
<snip>
Network Next Hop From AS Path
192.168.2.0/24 10.0.123.2 Local 65002i
192.168.3.0/24 10.0.123.3 10.0.123.3 65002 65003i
<snip>
Processed 2 prefixes, 2 paths受け取ったR1側でも同じで、192.168.3.0/24のNEXT_HOPは10.0.123.3、広告してきたのは10.0.123.2です。この2つがずれているのがthird-party next hopです。
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
Path #1: Received by speaker 0
<snip>
65002 65003, (received & used)
10.0.123.3 from 10.0.123.2 (10.0.0.2)
Origin IGP, localpref 100, valid, external, best, group-bestR1からR3へのパケットは共有セグメントを1回通るだけで届きます。
RP/0/RP0/CPU0:R1#traceroute 192.168.3.1 source 192.168.1.1 probe 3 timeout 1 maxttl 5
<snip>
Type escape sequence to abort.
Tracing the route to 192.168.3.1
<snip>
1 10.0.123.3 8 msec * 8 msec AS内のR4にもNEXT_HOPはそのまま伝わります。一方、R1が自分で広告している192.168.1.0/24はR1のLoopback0（10.0.0.1）に書き換わっています。iBGPでも、自分が生成した経路ではNEXT_HOPが自分のアドレスになります。
RP/0/RP0/CPU0:R4#show bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
*>i192.168.1.0/24 10.0.0.1 0 100 0 i
*>i192.168.2.0/24 10.0.123.2 0 100 0 65002 i
*>i192.168.3.0/24 10.0.123.3 100 0 65002 65003 i
<snip>
Processed 4 prefixes, 4 pathsRP/0/RP0/CPU0:R4#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
Path #1: Received by speaker 0
<snip>
65002 65003, (received & used)
10.0.123.3 (metric 2) from 10.0.0.1 (10.0.0.1)
Origin IGP, localpref 100, valid, internal, best, group-bestRP/0/RP0/CPU0:R4#show bgp 192.168.1.0/24
<snip>
Paths: (1 available, best #1)
<snip>
Path #1: Received by speaker 0
<snip>
Local, (received & used)
10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
Origin IGP, metric 0, localpref 100, valid, internal, best, group-bestNEXT_HOPは再帰的に解決されます。R4は10.0.123.3をOSPFで学んだ共有セグメントの経路から引きます。
RP/0/RP0/CPU0:R4#show cef 192.168.3.0/24
<snip>
192.168.3.0/24, version 12, internal 0x5000001 0x40 (ptr 0x8851b4d0) [1], 0x0 (0x0), 0x0 (0x0)
<snip>
via 10.0.123.3/32, 3 dependencies, recursive [flags 0x6000]
<snip>
next hop 10.0.123.3/32 via 10.0.123.0/24パケットで確認する
1つのフレームの中で、R2は2つのプレフィックスを別々のNEXT_HOPで広告しています。 192.168.3.0/24は10.0.123.3（R3）、自分の192.168.2.0/24は10.0.123.2です。
STEP 0のキャプチャーにはこのUPDATEが入っていません（セッションがSTEP 0の開始前に確立しており、広告はそれより前に終わっていたためです）。下はSTEP 2でnext-hop-selfを外して再広告されたときのもので、NEXT_HOPはSTEP 0と同じです。
Border Gateway Protocol - UPDATE Message
<snip>
Path Attribute - MP_REACH_NLRI
<snip>
Next hop: 10.0.123.3
<snip>
MP Reach NLRI IPv4 prefix: 192.168.3.0
<snip>
Path Attribute - AS_PATH: 65002 65003 STEP 1：next-hop-selfで自分のアドレスに固定する
R2のR1向けネイバーにnext-hop-selfを入れます。RFC 4271 5.1.3が「third-party next hopの広告を無効にできること」を実装の必須要件としている、その手段です。
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Sun Oct 4 13:12:02.032 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65002
neighbor 10.0.123.1
address-family ipv4 unicast
next-hop-self
!
!
!
end192.168.3.0/24のNEXT_HOPがR2のアドレスに変わります。
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
Path #1: Received by speaker 0
<snip>
65002 65003, (received & used)
10.0.123.2 from 10.0.123.2 (10.0.0.2)
Origin IGP, localpref 100, valid, external, best, group-best転送も変わり、R1からR3へのパケットはR2を経由して共有セグメントを2回通ります。
RP/0/RP0/CPU0:R1#traceroute 192.168.3.1 source 192.168.1.1 probe 3 timeout 1 maxttl 5
<snip>
Type escape sequence to abort.
Tracing the route to 192.168.3.1
<snip>
1 10.0.123.2 59 msec 7 msec 6 msec
2 10.0.123.3 9 msec * 9 msec STEP 2：next-hop-selfを外す
設定をSTEP 0と同じ状態に戻すと、NEXT_HOPもthird-partyに戻ります。
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Sun Oct 4 13:17:47.074 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65002
neighbor 10.0.123.1
address-family ipv4 unicast
no next-hop-self
!
!
!
endRP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
Path #1: Received by speaker 0
<snip>
65002 65003, (received & used)
10.0.123.3 from 10.0.123.2 (10.0.0.2)
Origin IGP, localpref 100, valid, external, best, group-bestSTEP 3：ルートポリシーでプレフィックス単位に書き換える
prefix-setで192.168.3.0/24だけを選び、set next-hopでR2のアドレスにします。
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Sun Oct 4 13:23:32.337 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
prefix-set NH-TARGET
192.168.3.0/24
end-set
!
route-policy TO-R1
if destination in NH-TARGET then
set next-hop 10.0.123.2
endif
pass
end-policy
!
end結果はnext-hop-selfと同じですが、効く範囲がポリシーの条件に一致した経路だけという違いがあります。From列を見ると、192.168.3.0/24はR3から受け取った経路のままNext HopがR2になっています。
RP/0/RP0/CPU0:R2#show bgp neighbors 10.0.123.1 advertised-routes
<snip>
Network Next Hop From AS Path
192.168.2.0/24 10.0.123.2 Local 65002i
192.168.3.0/24 10.0.123.2 10.0.123.3 65002 65003i
<snip>
Processed 2 prefixes, 2 pathsこの構成でthird-partyになる経路は192.168.3.0/24だけなので、他の経路が変わらないことは出力では見えません（192.168.2.0/24はR2自身の経路で、どちらの方法でもNEXT_HOPはR2のアドレスです）。プレフィックス単位であることは上のprefix-setの条件から読みます。
STEP 4：ルートポリシーを外す
ポリシーの中身をpassに戻すと、third-partyに戻ります。
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Sun Oct 4 13:29:17.233 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy TO-R1
pass
end-policy
!
endRP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
Path #1: Received by speaker 0
<snip>
65002 65003, (received & used)
10.0.123.3 from 10.0.123.2 (10.0.0.2)
Origin IGP, localpref 100, valid, external, best, group-bestSTEP 5：iBGP側でthird-partyを打ち消す
ここまではR2 - R1間（eBGP）の話です。AS内へ配るときのNEXT_HOPはR1が決めます。 R1のR4向けネイバーにnext-hop-selfを入れます。
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Sun Oct 4 13:35:03.446 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
neighbor 10.0.0.4
address-family ipv4 unicast
next-hop-self
!
!
!
endR1自身が見ているNEXT_HOPは10.0.123.3のままで、R4が受け取る値だけがR1のLoopback0になります。
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
Path #1: Received by speaker 0
<snip>
65002 65003, (received & used)
10.0.123.3 from 10.0.123.2 (10.0.0.2)
Origin IGP, localpref 100, valid, external, best, group-bestRP/0/RP0/CPU0:R4#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
Path #1: Received by speaker 0
<snip>
65002 65003, (received & used)
10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
Origin IGP, localpref 100, valid, internal, best, group-bestSTEP 6：共有セグメントをOSPFから外す
R1の共有セグメント側インタフェースをOSPFから外します。これでAS内の他のルータは10.0.123.0/24を知らなくなります。
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Sun Oct 4 13:40:43.318 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router ospf 1
area 0
no interface GigabitEthernet0/0/0/0
!
!
endnext-hop-selfが入っているので、R4は影響を受けません。 受け取るNEXT_HOPはR1のLoopback0で、これはOSPFで引けます。
RP/0/RP0/CPU0:R4#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
Path #1: Received by speaker 0
<snip>
65002 65003, (received & used)
10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
Origin IGP, localpref 100, valid, internal, best, group-bestRP/0/RP0/CPU0:R4#ping 192.168.3.1 source 192.168.4.1 count 50 timeout 1
<snip>
Type escape sequence to abort.
<snip>
Success rate is 100 percent (50/50), round-trip min/avg/max = 7/8/26 msSTEP 7：next-hop-selfを外すと経路が使えなくなる
R1のnext-hop-selfを外します。R4が受け取るNEXT_HOPはthird-partyの10.0.123.3に戻りますが、共有セグメントがOSPFに無いのでR4はこれを解決できません。
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Sun Oct 4 13:46:25.158 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
neighbor 10.0.0.4
address-family ipv4 unicast
no next-hop-self
!
!
!
end経路は(inaccessible)になり、ベストパスから外れます。
RP/0/RP0/CPU0:R4#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, no best path)
<snip>
Path #1: Received by speaker 0
<snip>
65002 65003, (received & used)
10.0.123.3 (inaccessible) from 10.0.0.1 (10.0.0.1)
Origin IGP, localpref 100, valid, internal転送も止まります。
RP/0/RP0/CPU0:R4#ping 192.168.3.1 source 192.168.4.1 count 50 timeout 1
<snip>
Type escape sequence to abort.
<snip>
Success rate is 0 percent (0/50)これが、複数のeBGPピアが同じセグメントを共有する構成（IXなど）でnext-hop-selfを使う理由です。 third-partyのNEXT_HOPはそのセグメント上のアドレスなので、AS内の全ルータがそのセグメントへの経路を持っていなければ使えません。next-hop-selfで自分のアドレスに置き換えれば、AS内はIGPで解決できるアドレスだけを見ることになります。
STEP 8：next-hop-selfを戻す
戻すと解決できるようになり、転送も復旧します。これが最終状態です。
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Sun Oct 4 13:53:44.515 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
neighbor 10.0.0.4
address-family ipv4 unicast
next-hop-self
!
!
!
endRP/0/RP0/CPU0:R4#show bgp 192.168.3.0/24
<snip>
Paths: (1 available, best #1)
<snip>
Path #1: Received by speaker 0
<snip>
65002 65003, (received & used)
10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
Origin IGP, localpref 100, valid, internal, best, group-bestRP/0/RP0/CPU0:R4#ping 192.168.3.1 source 192.168.4.1 count 50 timeout 1
<snip>
Type escape sequence to abort.
<snip>
Success rate is 100 percent (50/50), round-trip min/avg/max = 7/10/49 ms検証Configおよびshow結果
各STEPで4台すべてから、次の種類をルータごとに分けて取得しています。検証Configはこの..._run.txtです（最終状態は最後のSTEPのもの）。
| ファイル | 内容 |
|---|---|
..._show.txt | show version / show interface description / show route と、BGP・OSPFの状態一式（show bgp nexthops、ネイバーごとのadvertised-routes / routes / received routes、show cefを含む） |
..._log.txt | そのSTEPの範囲だけに絞ったshow logging |
..._run.txt | そのSTEP時点のshow running-config（＝そのSTEPの検証Config） |
..._ping.txt | そのSTEPのpingとtracerouteの結果 |
..._trace.txt | show bgp trace neighbor / show bgp trace error |
..._commit.cfg | そのSTEPで実際にcommitされた設定だけ（設定を変えたルータのみ） |
STEP 0：初期状態（ポリシーはpassのみ）
| ルータ | show出力 | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | ping | trace | — |
| R2 | show | log | run | — | trace | — |
| R3 | show | log | run | ping | trace | — |
| R4 | show | log | run | ping | trace | — |
STEP 1：R2のR1向けにnext-hop-self
| ルータ | show出力 | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | ping | trace | — |
| R2 | show | log | run | — | trace | commit |
| R3 | show | log | run | ping | trace | — |
| R4 | show | log | run | ping | trace | — |
STEP 2：next-hop-selfを撤去（設定はSTEP 0と同一に戻る）
| ルータ | show出力 | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | ping | trace | — |
| R2 | show | log | run | — | trace | commit |
| R3 | show | log | run | ping | trace | — |
| R4 | show | log | run | ping | trace | — |
STEP 3：R2のR1向けにset next-hop（192.168.3.0/24だけ）
| ルータ | show出力 | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | ping | trace | — |
| R2 | show | log | run | — | trace | commit |
| R3 | show | log | run | ping | trace | — |
| R4 | show | log | run | ping | trace | — |
STEP 4：ルートポリシーの中身をpassに戻す
| ルータ | show出力 | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | ping | trace | — |
| R2 | show | log | run | — | trace | commit |
| R3 | show | log | run | ping | trace | — |
| R4 | show | log | run | ping | trace | — |
STEP 5：R1のR4向けにnext-hop-self（iBGP側）
| ルータ | show出力 | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | ping | trace | commit |
| R2 | show | log | run | — | trace | — |
| R3 | show | log | run | ping | trace | — |
| R4 | show | log | run | ping | trace | — |
STEP 6：R1で共有セグメントをOSPFから外す
| ルータ | show出力 | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | ping | trace | commit |
| R2 | show | log | run | — | trace | — |
| R3 | show | log | run | ping | trace | — |
| R4 | show | log | run | ping | trace | — |
STEP 7：R1のnext-hop-selfを撤去（NEXT_HOPが解決できなくなる）
| ルータ | show出力 | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | ping | trace | commit |
| R2 | show | log | run | — | trace | — |
| R3 | show | log | run | ping | trace | — |
| R4 | show | log | run | ping | trace | — |
STEP 8：R1のnext-hop-selfを戻す（最終状態）
| ルータ | show出力 | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | ping | trace | commit |
| R2 | show | log | run | — | trace | — |
| R3 | show | log | run | ping | trace | — |
| R4 | show | log | run | ping | trace | — |
パケットキャプチャーはSTEPごとに4区間で取得しています。
| STEP | R1 - SW間 | R2 - SW間 | R3 - SW間 | R1 - R4間 |
|---|---|---|---|---|
| 0 | pcap | pcap | pcap | pcap |
| 1 | pcap | pcap | pcap | pcap |
| 2 | pcap | pcap | pcap | pcap |
| 3 | pcap | pcap | pcap | pcap |
| 4 | pcap | pcap | pcap | pcap |
| 5 | pcap | pcap | pcap | pcap |
| 6 | pcap | pcap | pcap | pcap |
| 7 | pcap | pcap | pcap | pcap |
| 8 | pcap | pcap | pcap | pcap |
参考
- RFC 4271 - A Border Gateway Protocol 4 (BGP-4) 5.1.3（
NEXT_HOPの決め方、third-party next hop、再帰的ルックアップ）
関連記事
- BGP（Border Gateway Protocol）
- BGPメッセージ
- BGPネイバーの状態遷移
- iBGPとeBGPの違い
- BGP next-hop-self
- BGPルートリフレクタ
- BGPパス属性とベストパス選択
- BGP ORIGIN属性
- BGP AS_PATH属性
- BGP NEXT_HOP属性
- BGP LOCAL_PREF属性
- BGP MED属性
- BGP WEIGHT属性
- BGP COMMUNITY属性
- BGP経路集約（aggregate-address）
- MP-BGP（マルチプロトコル拡張）
- BGP Extended Community（拡張コミュニティ）
- BGPマルチパス（maximum-paths）
- BGPの4バイトAS番号（RFC 6793）
- BGPのプライベートAS番号の除去（remove-private-AS）
- BGPのADD-PATH（RFC 7911）
- BGP PIC（Prefix Independent Convergence）
- BGP Best External（ベストでない外部経路の広告）