↓ メインコンテンツへスキップ
KAZULOG.INFO
  1. ネットワーク 記事一覧/
  2. MPLS記事一覧/

LDPのラベル配布モードとラベルスペース

目次

LDPのラベル配布モードとラベルスペース

RFC 5036はLDPの動作について3組の選択肢を定義しています。ラベルをいつ配るか、受け取ったラベルをどこまで持っておくか、上流へ配る順序をどうするかの3つです。このうち実装で選べるのは1組だけで、残りは固定されています。本記事では3組の違いとラベルスペースの考え方を解説し、IOS XR（XRd）のラボで確かめます。LDPの基本はLDPとはで解説しています。

3組の選択肢

組RFC 5036選択肢何が変わるか
ラベル広告2.6.3節Downstream Unsolicited / Downstream on Demand要求を待ってから配るかどうか
ラベル保持2.6.2節liberal / conservative次ホップ以外から受けたラベルを捨てるかどうか
ラベル配布制御2.6.1節independent / ordered下流からラベルを受け取る前に上流へ配ってよいか

3組とも下流のLSRがラベルを決めて上流へ渡すという前提は共通です。MPLSではパケットを受け取る側がラベルを決めるため、宛先に近いLSRが「私に送るときはこのラベルを付けてください」と伝える形になります。

ラベル広告：DUとDoD

Downstream Unsolicitedは、セッションが上がったら持っているプレフィックスの分だけLabel Mappingを送ります。相手が使うかどうかは考えません。Downstream on Demandは、上流からLabel Requestを受け取ってから該当するFECのLabel Mappingを返します。

DoDはATMのようにラベル資源が限られる環境のために用意されました。イーサネットが前提の現代のルータではラベルが枯渇しないため、既定はDUです。

IOS XRではmpls ldp配下のsession downstream-on-demand with <ACL>で、DoDにする相手をACLで指定します。両端のルータに設定しないとDoDになりません。片側だけではDUのままです。

ラベル保持：liberalとconservative

LDPはセッションを張った相手全員からLabel Mappingを受け取ります。そのうち実際に使うのは、IGPが選んだ次ホップから受け取った分だけです。

liberalは使わない分も保持します。ラベルを覚えておく分メモリを使いますが、経路が変わって次ホップが入れ替わったとき、すでに持っているラベルをそのまま使えます。conservativeは次ホップの分だけ保持し、経路が変われば改めてラベルを要求します。資源を節約できる代わりに収束が遅くなります。

ラベル配布制御：independentとordered

independentは、下流からラベルを受け取る前でも上流へ自分のラベルを配ってよい方式です。orderedは、下流からラベルを受け取るまで上流へ配りません。出口LSRだけは配る相手が自分なので例外です。

orderedはLSPが端から端までつながってからラベルが配られるため、途中で切れたLSPへパケットが流れ込むことを避けられます。independentはその保証がない代わりに収束が速くなります。

実装ではどれが選べるか

選べるのはラベル広告だけです。残る2組は実装ごとに固定されています。

実装ラベル広告ラベル保持ラベル配布制御
IOS XRDU / DoDを選択可liberal固定independent固定
IOS XEDU / DoDを選択可liberal固定independent固定
JunosDU / DoDを選択可liberal固定ordered固定

ラベル保持は3社ともliberalです。ラベル配布制御はCiscoとJuniperで逆になっています。Juniperのドキュメント（Supported LDP Standards）は「Ordered mode is supported, but not Independent mode.」「Liberal mode is supported, but not Conservative mode.」と明記しています。

IOS XEにはmpls ldp atm control-modeがありorderedとindependentを選べますが、これはLC-ATMインタフェース専用です。イーサネットでは使えません。RFCが2択で定義したのはATMを含む幅広い実装を想定していたためで、ルータの実装はliberalとindependent、またはliberalとorderedに収束しています。

混在環境で配布制御が揃わなくても、LDPのメッセージ交換そのものは変わりません。LSPが完成するまでの順序が違うだけです。

本記事のラボで確かめるのはラベル広告とラベル保持だけです。ラベル配布制御は設定できないため、実機では観測していません。

ラベルスペース

ラベルスペースは、LSRがラベルの値を管理する単位です（RFC 5036の2.2.1節）。

種類意味使う場面
per-platform装置全体で1つのラベル空間を持つイーサネットなど、ラベルの値に制約がない
per-interfaceインタフェースごとに別のラベル空間を持つATMのVPI/VCIのように、リンクがラベル資源を握る

どちらかはLDP識別子の後半2オクテットに現れます（2.2.2節）。per-platformなら常に0です。3.3.3.3:0と表示されていればper-platformです。

per-platformだと、どのリンクから届いたパケットでも同じラベル値で同じ転送先に解決されます。だからこそリンクを複数持っていてもLDPセッションは1本で済みます。

実機での検証

検証環境

CE1 — PE1 — P1 — P2 — PE2 — CE2 を直列につなぎ、P1とPE2の間にP3を通る迂回路を足しています。AS 65001のPE1 / P1 / P2 / P3 / PE2がMPLSネットワークで、OSPF（area 0、全リンクnetwork point-to-point）で経路を、LDPでラベルを配っています。CE1とCE2はPEとeBGPで、PE1とPE2はLoopback0間のiBGP（next-hop-self）でつながります。全台XRdです。

迂回路（P1 - P3 - PE2）はOSPFのコストを50にしてあるため、初期状態の経路はP2経由です。

動的ラベルの範囲を装置ごとに分けています。 既定のままだとP2とP3が同じ値を割り当てることがあり、経路が変わっても「どの装置のラベルを使っているか」が読み取れなくなるためです。

ルータLo0動的ラベルの範囲役割
CE11.1.1.1/32—顧客側（AS 65101、192.168.1.0/24）
PE12.2.2.2/3230000〜39999入口 / 出口LSR
P13.3.3.3/3240000〜49999観測の中心。3ピアからラベルを受け取る
P24.4.4.4/3250000〜59999中継（初期の最短経路）
P35.5.5.5/3260000〜69999中継（迂回路、コスト50）
PE26.6.6.6/3270000〜79999入口 / 出口LSR
CE27.7.7.7/32—顧客側（AS 65102、192.168.2.0/24）

観測の対象はP1から見た6.6.6.6/32（PE2のLoopback0）です。キャプチャーはPE1 - P1、P1 - P2、P1 - P3の3区間をSTEPごとに取得しています。

検証のSTEP

STEP操作確かめること
0初期状態既定がDUであること。LDP識別子が:0（per-platform）であること。3ピアからラベルを受け取り、使うのは次ホップの分だけであること
1P1 - P2のコストを100にする経路が迂回路へ移り、保持していたP3のラベルへ切り替わること。LDPのやりとりが起きないこと
2コストを戻すSTEP 0と同じに戻ること
3PE1にだけDoDを設定片側だけではDUのままであること
4P1にも設定両端そろってDoDになり、Label Requestが流れること。P1の他のセッションはDUのままであること
5DoDを削除（最終状態）STEP 0と同じに戻ること

ラベルはセッションを張った全員に配られる

P1は3つのピアとセッションを持っています。

P1 show mpls ldp neighbor brief（STEP 0）
RP/0/RP0/CPU0:P1#show mpls ldp neighbor brief
Mon Sep 28 05:03:04.612 UTC

Peer               GR  NSR  Up Time     Discovery   Addresses     Labels
                                        ipv4  ipv6  ipv4  ipv6  ipv4   ipv6
-----------------  --  ---  ----------  ----------  ----------  ------------
2.2.2.2:0          N   N    00:07:51    1     0     3     0     11     0
4.4.4.4:0          N   N    00:07:40    1     0     3     0     10     0
5.5.5.5:0          N   N    00:07:37    1     0     3     0     10     0

6.6.6.6/32のバインディングには、その3つすべてからのラベルが入っています。装置ごとに範囲を分けているので、どのピアが配った値かが読み取れます。

P1 show mpls ldp bindings 6.6.6.6/32（STEP 0）
RP/0/RP0/CPU0:P1#show mpls ldp bindings 6.6.6.6/32
Mon Sep 28 05:03:07.257 UTC
6.6.6.6/32, rev 20
	Local binding: label: 40005
	Remote bindings: (3 peers)
	    Peer                Label
	    -----------------   ---------
	    2.2.2.2:0           30006
	    4.4.4.4:0           50006
	    5.5.5.5:0           60006

Downstream-Unsolicitedなので、相手が使うかどうかに関係なく配られます。PE1（2.2.2.2）はP1から見て上流で、6.6.6.6/32へ向かうときに通る相手ではありませんが、それでもラベルが届いています。

P1 show mpls ldp neighbor detail（STEP 0、先頭8行）
RP/0/RP0/CPU0:P1#show mpls ldp neighbor detail
Mon Sep 28 05:03:04.968 UTC

Peer LDP Identifier: 2.2.2.2:0
  TCP connection: 2.2.2.2:646 - 3.3.3.3:34682
  Graceful Restart: No
  Session Holdtime: 180 sec
  State: Oper; Msgs sent/rcvd: 21/23; Downstream-Unsolicited

使わないラベルも保持する（liberal）

実際に転送で使うのは、IGPが選んだ次ホップから受け取ったラベルだけです。P1の6.6.6.6/32の次ホップはP2（10.3.4.4）です。

P1 show route 6.6.6.6/32（STEP 0）
RP/0/RP0/CPU0:P1#show route 6.6.6.6/32
Mon Sep 28 05:03:07.697 UTC

Routing entry for 6.6.6.6/32
  Known via "ospf 1", distance 110, metric 3, type intra area
  Installed Sep 28 04:55:32.577 for 00:07:35
  Routing Descriptor Blocks
    10.3.4.4, from 6.6.6.6, via GigabitEthernet0/0/0/1
      Route metric is 3
  No advertising protos.

転送表には、P2が配った50006だけが出方向のラベルとして入っています。

P1 show mpls forwarding prefix 6.6.6.6/32（STEP 0）
RP/0/RP0/CPU0:P1#show mpls forwarding prefix 6.6.6.6/32
Mon Sep 28 05:03:09.123 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
40005  50006       6.6.6.6/32         Gi0/0/0/1    10.3.4.4        23798

それでもバインディングからPE1とP3のラベルは消えません（前掲のshow mpls ldp bindings）。これがliberalです。conservativeなら、次ホップから受け取った1件だけを残して他は捨てます。

経路が変わると、保持していたラベルへ切り替わる

P1 - P2のコストを100に上げます（両端）。

STEP 1 P1にcommitした設定
RP/0/RP0/CPU0:P1#show configuration commit changes last 1
Mon Sep 28 05:05:32.668 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router ospf 1
 area 0
  interface GigabitEthernet0/0/0/1
   cost 100
  !
 !
!
end
STEP 1 P2にcommitした設定
RP/0/RP0/CPU0:P2#show configuration commit changes last 1
Mon Sep 28 05:05:39.694 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router ospf 1
 area 0
  interface GigabitEthernet0/0/0/0
   cost 100
  !
 !
!
end

経路が迂回路（P3経由）へ移りました。

P1 show route 6.6.6.6/32（STEP 1）
RP/0/RP0/CPU0:P1#show route 6.6.6.6/32
Mon Sep 28 05:10:14.118 UTC

Routing entry for 6.6.6.6/32
  Known via "ospf 1", distance 110, metric 101, type intra area
  Installed Sep 28 05:05:32.044 for 00:04:42
  Routing Descriptor Blocks
    10.3.5.5, from 6.6.6.6, via GigabitEthernet0/0/0/2
      Route metric is 101
  No advertising protos.

転送表の出方向のラベルは、P2の50006からP3の60006へ変わります。入方向のラベル（40005）は変わりません。

P1 show mpls forwarding prefix 6.6.6.6/32（STEP 0）
RP/0/RP0/CPU0:P1#show mpls forwarding prefix 6.6.6.6/32
Mon Sep 28 05:03:09.123 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
40005  50006       6.6.6.6/32         Gi0/0/0/1    10.3.4.4        23798
P1 show mpls forwarding prefix 6.6.6.6/32（STEP 1）
RP/0/RP0/CPU0:P1#show mpls forwarding prefix 6.6.6.6/32
Mon Sep 28 05:10:15.561 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
40005  60006       6.6.6.6/32         Gi0/0/0/2    10.3.5.5        23798
P1 show mpls forwarding prefix 6.6.6.6/32（STEP 2）
RP/0/RP0/CPU0:P1#show mpls forwarding prefix 6.6.6.6/32
Mon Sep 28 05:17:21.757 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
40005  50006       6.6.6.6/32         Gi0/0/0/1    10.3.4.4        23798

バインディングはSTEP 0から変わっていません。すでに持っていたラベルを使うだけなので、切り替えのときにLDPは何もしません。迂回路（P1 - P3）のキャプチャーに流れているのはKeepAliveだけです。

STEP 1 P1 - P3間のLDPメッセージ（TCP上のもの）
$ tshark -r - -Y 'ldp && tcp' -T fields -e frame.number -e frame.time_relative -e _ws.col.info \
    < mpls-ldp-modes-step1-p1p3.pcap
7	8.061757000	Keep Alive Message
77	15.590830000	Keep Alive Message
160	57.677007000	Keep Alive Message
169	69.295474000	Keep Alive Message

CE1からのtracerouteでも、2ホップ目以降のラベルが変わります。疎通は50発すべて成功したままです。

CE1 traceroute（STEP 0）
RP/0/RP0/CPU0:CE1#traceroute 192.168.2.1 source 192.168.1.1 timeout 1 probe 2 maxttl 7
Mon Sep 28 05:01:09.909 UTC

Type escape sequence to abort.
Tracing the route to 192.168.2.1

 1  10.1.2.2 7 msec  4 msec
 2  10.2.3.3 [MPLS: Label 40005 Exp 0] 11 msec  10 msec
 3  10.3.4.4 [MPLS: Label 50006 Exp 0] 10 msec  9 msec
 4  10.4.6.6 20 msec  11 msec
 5  10.6.7.7 14 msec  *
CE1 traceroute（STEP 1）
RP/0/RP0/CPU0:CE1#traceroute 192.168.2.1 source 192.168.1.1 timeout 1 probe 2 maxttl 7
Mon Sep 28 05:08:16.288 UTC

Type escape sequence to abort.
Tracing the route to 192.168.2.1

 1  10.1.2.2 6 msec  5 msec
 2  10.2.3.3 [MPLS: Label 40005 Exp 0] 67 msec  12 msec
 3  10.3.5.5 [MPLS: Label 60006 Exp 0] 16 msec  13 msec
 4  10.5.6.6 17 msec  14 msec
 5  10.6.7.7 20 msec  *

これがliberalの利点です。conservativeなら、経路が変わってから改めてラベルを要求するため、切り替えに時間がかかります。

Downstream on Demand：片側だけでは変わらない

PE1にだけ、相手を指定するACLとsession downstream-on-demandを入れます。

STEP 3 PE1にcommitした設定
RP/0/RP0/CPU0:PE1#show configuration commit changes last 1
Mon Sep 28 05:19:45.396 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
ipv4 access-list DOD-PEERS
 10 permit ipv4 host 3.3.3.3 any
!
mpls ldp
 session downstream-on-demand with DOD-PEERS
!
end

設定するとセッションは張り直されますが、モードはDownstream-Unsolicitedのままです。

STEP 3 PE1 show mpls ldp neighbor detail（先頭8行）
RP/0/RP0/CPU0:PE1#show mpls ldp neighbor detail
Mon Sep 28 05:23:11.375 UTC

Peer LDP Identifier: 3.3.3.3:0
  TCP connection: 3.3.3.3:59177 - 2.2.2.2:646
  Graceful Restart: No
  Session Holdtime: 180 sec
  State: Oper; Msgs sent/rcvd: 17/17; Downstream-Unsolicited

両端そろうとLabel Requestが流れる

P1にも同じ設定を入れます。

STEP 4 P1にcommitした設定
RP/0/RP0/CPU0:P1#show configuration commit changes last 1
Mon Sep 28 05:26:54.620 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
ipv4 access-list DOD-PEERS
 10 permit ipv4 host 2.2.2.2 any
!
mpls ldp
 session downstream-on-demand with DOD-PEERS
!
end

PE1の表示がDownstream-on-Demandに変わります。

STEP 4 PE1 show mpls ldp neighbor detail（先頭8行）
RP/0/RP0/CPU0:PE1#show mpls ldp neighbor detail
Mon Sep 28 05:30:21.354 UTC

Peer LDP Identifier: 3.3.3.3:0
  TCP connection: 3.3.3.3:26491 - 2.2.2.2:646
  Graceful Restart: No
  Session Holdtime: 180 sec
  State: Oper; Msgs sent/rcvd: 15/15; Downstream-on-Demand

配布モードはセッション単位です。P1はPE1とはDoDですが、P2とP3とはDUのままです。show mpls ldp neighbor briefのLabels欄を見ると、DoDにしたPE1（2.2.2.2）からのラベルだけが減っています。要求したものしか配られないためです。

STEP 4 P1 show mpls ldp neighbor brief
RP/0/RP0/CPU0:P1#show mpls ldp neighbor brief
Mon Sep 28 05:31:38.657 UTC

Peer               GR  NSR  Up Time     Discovery   Addresses     Labels
                                        ipv4  ipv6  ipv4  ipv6  ipv4   ipv6
-----------------  --  ---  ----------  ----------  ----------  ------------
4.4.4.4:0          N   N    00:36:14    1     0     3     0     10     0
5.5.5.5:0          N   N    00:36:11    1     0     3     0     10     0
2.2.2.2:0          N   N    00:04:38    1     0     3     0     1      0

キャプチャーには、DUでは流れないLabel Requestが現れます。Initialization → KeepAlive → Address のあとにRequestが入り、Label Mappingが返ります。

STEP 4 PE1 - P1間のLDPメッセージ（TCP上のもの）
$ tshark -r - -Y 'ldp && tcp' -T fields -e frame.number -e frame.time_relative -e ip.src -e _ws.col.info \
    < mpls-ldp-modes-step4-pe1p1.pcap
1	0.000000000	3.3.3.3	Keep Alive Message
159	11.189700000	3.3.3.3	Initialization Message
171	15.830506000	3.3.3.3	Initialization Message
172	15.850426000	2.2.2.2	Initialization Message Keep Alive Message
173	15.854649000	3.3.3.3	Keep Alive Message
174	15.858092000	2.2.2.2	Address Message
175	15.860655000	3.3.3.3	Address Message
179	16.494015000	3.3.3.3	Label Request Message [Malformed Packet]
180	16.497699000	2.2.2.2	Label Mapping Message

No.179はP1がPE1へ送ったLabel Requestです。どのFECのラベルが欲しいかをPrefix FECで示します。

STEP 4 No.179 Label Request（P1 → PE1）tshark -V 抜粋
Label Distribution Protocol
    Version: 1
    PDU Length: 26
    LSR ID: 3.3.3.3
    Label Space ID: 0
    Label Request Message
        0... .... = U bit: Unknown bit not set
        Message Type: Label Request Message (0x401)
        Message Length: 16
        Message ID: 0x000000a4
        FEC
            00.. .... = TLV Unknown bits: Known TLV, do not Forward (0x0)
            TLV Type: FEC (0x100)
            TLV Length: 8
上のtshark出力のパケット（No.179 Label Request）のpcapをダウンロード

tsharkはこのパケットに[Malformed Packet]を付けますが、中身はRFC 5036のとおりで欠けはありません。FEC TLV（0x0100）の長さは8で、続く8バイトがPrefix FEC要素（種別02、アドレスファミリ0001、プレフィックス長20＝32、値02 02 02 02＝2.2.2.2）です。

STEP 4 No.179 のバイト列（tshark -x の末尾）
0040  04 01 00 10 00 00 00 a4 01 00 00 08 02 00 01 20   ...............
0050  02 02 02 02                                       ....

Wireshark側がLabel Requestを解釈しきれないだけで、ルータは正しく処理してLabel Mappingを返しています（前掲のNo.28）。

ラベルスペースはper-platform

LDP識別子の後半2オクテットが:0であることは、装置全体で1つのラベル空間を使っていることを表します。P1のパラメータにもラベルスペースごとの区別は現れません。

P1 show mpls ldp parameters（STEP 0、先頭10行）
RP/0/RP0/CPU0:P1#show mpls ldp parameters
Mon Sep 28 05:03:03.796 UTC

LDP Parameters:
  Role: Active
  Protocol Version: 1
  Router ID: 3.3.3.3
  Null Label:
    IPv4: Implicit
  Session:

per-interfaceを使うのはLC-ATMのようにリンクがラベル資源を握る構成で、イーサネットのラボでは選べません。この検証で見えるのはper-platform側だけです。

疎通

配布モードや経路が変わっても、CE1からCE2への疎通はどのSTEPでも保たれています。

CE1 → CE2（STEP 0）
RP/0/RP0/CPU0:CE1#ping 192.168.2.1 source 192.168.1.1 count 50 timeout 1
Mon Sep 28 05:01:08.111 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.2.1 timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 13/16/36 ms

切り替えの間に落ちたパケット

上の疎通は、設定を変えて収束したあとに測ったものです。切り替えの最中に何発落ちたかは、設定変更の前に流し始めて変更をまたいだpingで測っています（count 150 interval 100 timeout 1）。

STEP操作切り替えをまたいだping
1P1 - P2のコストを100にする150/150（ロスなし）
2コストを戻す150/150（ロスなし）
3PE1にだけDoDを設定145/150（ロス5発）
4P1にも設定143/150（ロス7発）
5DoDを削除（最終状態）143/150（ロス7発）
経路を切り替えたSTEP 1と、戻したSTEP 2は1発も落ちていません。 Downstream Unsolicitedであらかじめ全ピアからラベルを受け取っているため、経路が変わっても保持しているラベルに差し替えるだけで済み、LDPのやりとりを待つ必要がないからです。配布モードを切り替えるSTEP 3〜5では数発落ちますが、これはセッションを張り直すためです。

検証Configおよびshow結果

各STEPで7台すべてから、次の種類をルータごとに分けて取得しています。検証Configはこの..._run.txtです（最終状態はSTEP 5のもの）。各STEPは「カウンタのクリア → ping → show」の順に採っています。

ファイル内容
..._clear.txtそのSTEPの最初にクリアしたカウンタ（clear counters interfaceとclear mpls forwarding counters）
..._ping.txtping（50発）とtraceroute。CE1 - CE2とPE1 - PE2（Loopback0間）
..._show.txtshow version / show interface description / show route / OSPF と、LDPの一式（parameters / summary / discovery / neighbor / bindings / forwarding / statistics msg-counters）、MPLS転送、PEはBGP
..._log.txtそのSTEPの範囲だけに絞ったshow logging
..._run.txtそのSTEP時点のshow running-config（＝そのSTEPの検証Config）
..._trace.txtコア5台のみ。show mpls ldp trace peer / bindingとshow mpls lsd trace
..._commit.cfgそのSTEPで実際にcommitされた設定（変更したルータのみ）

STEP 0：初期状態

ルータshow出力pingclearsyslogrunning-configtrace投入した設定断の測定
CE1showpingclearlogrun———
PE1showpingclearlogruntrace——
P1show—clearlogruntrace——
P2show—clearlogruntrace——
P3show—clearlogruntrace——
PE2showpingclearlogruntrace——
CE2showpingclearlogrun———

STEP 1：P1 - P2のコストを100にする

ルータshow出力pingclearsyslogrunning-configtrace投入した設定断の測定
CE1showpingclearlogrun——outage
PE1showpingclearlogruntrace——
P1show—clearlogruntracecfg—
P2show—clearlogruntracecfg—
P3show—clearlogruntrace——
PE2showpingclearlogruntrace——
CE2showpingclearlogrun———

STEP 2：コストを戻す

ルータshow出力pingclearsyslogrunning-configtrace投入した設定断の測定
CE1showpingclearlogrun——outage
PE1showpingclearlogruntrace——
P1show—clearlogruntracecfg—
P2show—clearlogruntracecfg—
P3show—clearlogruntrace——
PE2showpingclearlogruntrace——
CE2showpingclearlogrun———

STEP 3：PE1にだけDoDを設定

ルータshow出力pingclearsyslogrunning-configtrace投入した設定断の測定
CE1showpingclearlogrun——outage
PE1showpingclearlogruntracecfg—
P1show—clearlogruntrace——
P2show—clearlogruntrace——
P3show—clearlogruntrace——
PE2showpingclearlogruntrace——
CE2showpingclearlogrun———

STEP 4：P1にも設定

ルータshow出力pingclearsyslogrunning-configtrace投入した設定断の測定
CE1showpingclearlogrun——outage
PE1showpingclearlogruntrace——
P1show—clearlogruntracecfg—
P2show—clearlogruntrace——
P3show—clearlogruntrace——
PE2showpingclearlogruntrace——
CE2showpingclearlogrun———

STEP 5：DoDを削除（最終状態）

ルータshow出力pingclearsyslogrunning-configtrace投入した設定断の測定
CE1showpingclearlogrun——outage
PE1showpingclearlogruntracecfg—
P1show—clearlogruntracecfg—
P2show—clearlogruntrace——
P3show—clearlogruntrace——
PE2showpingclearlogruntrace——
CE2showpingclearlogrun———

パケットキャプチャーはSTEPごとに、3つの区間で取得しています。

STEPPE1 - P1間P1 - P2間P1 - P3間
0pcappcappcap
1pcappcappcap
2pcappcappcap
3pcappcappcap
4pcappcappcap
5pcappcappcap

参考

RFCタイトル概要
RFC 5036LDP Specificationラベル配布制御（2.6.1節 Label Distribution Control Mode）、ラベル保持（2.6.2節 Label Retention Mode）、ラベル広告（2.6.3節 Label Advertisement Mode）、ラベルスペース（2.2.1節）、LDP識別子との関係（2.2.2節）。

実装の対応表はSupported LDP Standards（Juniper Networks）を参照しました（2026-09-23に確認）。

書籍: Luc De Ghein『MPLS Fundamentals』（Cisco Press, 2006）Chapter 2, 4

関連記事