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

LDP-IGPシンクロナイゼーションとLDPセッション保護

目次

LDP-IGPシンクロナイゼーションとLDPセッション保護

経路を配るIGPとラベルを配るLDPは別々に動きます。そのリンクでLDPが使えないのにIGPがそこを選ぶと、ラベルが無くMPLSのトラフィックだけが落ちます。この穴と、塞ぐ2つの仕組みを解説し、IOS XR（XRd）のラボで測ります。LDPの基本はLDPとはで解説しています。

ラベルが無いリンクが選ばれると何が起きるか

MPLSの転送は、IGPが選んだ次ホップに対してLDPがそのFECのラベルを配り終えていることが前提です。崩れる状況は2つあります。

1つは、そのリンクでLDPが動いていない場合。設定漏れ、ACLやフィルタ、認証の不一致でセッションが張れないと、IGPはそのリンクを選び続け、MPLSのトラフィックだけが恒久的に落ちます。

もう1つはリンクが上がった直後の収束のずれですが、どちらが先になるかはタイマー次第です。IOS XRの既定値では、LDPはHello 5秒でセッションがTCPで即座に張られ、OSPFはHello 10秒でExStart / Exchange / Loadingを経てFULLになります。point-to-pointリンクではLDPのほうが先に上がるのが普通で（後半で実測します）、この場合リンクの復旧でブラックホールは起きません。

落ち方はトラフィックの種類でも変わります。グローバルのIPはラベル無しで送り出され、次のルータがIP経路を持っていれば転送できてしまいます。一方VPN（VPNv4）はトランスポートラベルが必須で、IP転送に落ちる逃げ道がありません。同じ障害でもVPNだけが落ちます。

LDP-IGPシンクロナイゼーション

RFC 5443は、LDPがそのリンクで「fully operational」になるまで、IGPがそのリンクを最大コストで広告するという仕組みを定めています。最大コストなので、他に経路があればそちらが選ばれ、ラベルの無いリンクへトラフィックが流れません。

fully operationalの条件は3つすべてを満たすことです（2節）。

条件内容
1そのリンクにLDPのhello adjacencyがある
2hello adjacencyのLDP Identifierと一致するセッションが相手との間に確立している
3そのセッションですべてのラベルバインディングを交換し終えている

3つ目の条件はルータが確かめられません。RFC 5443の2節は「現時点ではこの条件を一般に検証できないので、推定が必要になる」と述べ、実装としては設定可能なhold-downタイマーを使う方法を挙げています。確かめられるようにする仕組みがRFC 5919のEnd-of-LIB（ラベル広告の完了を通知する）で、これがあればタイマーは不要になります。IOS XRのタイマーはigp sync delay on-session-up <秒>で設定し、show mpls ldp igp syncのSync delayに出ます（後半で実測します）。

広告する最大コストはIGPごとに決まっています。

IGP値補足
OSPF65535（LSInfinity、16ビット）—
IS-IS16777214（2^24−2）2^24−1はリンクをトポロジから消してしまうため使わない

注意点が2つあります。迂回路が無ければ意味がありません。他に経路が無ければ結局そのリンクが選ばれます。RFC 5443の3節も「最適経路を常に選ぶことより、LDPのLSPが使えることのほうが重要な場合」に使う仕組みだと述べています。またブロードキャストリンクではピア単位ではなくリンク全体がコストアウトされます（3節）。TEトンネルを併用している場合、同期を適用するのはIPのリンクコストだけで、TEメトリックには適用しません（4節）。TEトンネルの経路計算まで揺らすと、不要な再経路計算を招くためです。

LDPセッション保護

LDPセッションはLo0間のTCPですが、維持してよいかどうかはhello adjacencyが生きているかで決まります。リンクが落ちてhello adjacencyが全部消えるとセッションも落ち、ラベルバインディングが失われます。戻ったときはHello → TCP → Initialization → ラベル交換をやり直します。

LDPセッション保護はこの間をtargeted helloで埋めます。RFC 5036の2.4.2節が定めるExtended Discoveryのメッセージで、リンクのhello（マルチキャスト）と違い相手のアドレス宛にユニキャストで送ります。リンクが無くなってもIPで届く経路が残っている限りhello adjacencyが残り、セッションもラベルも保持されます。Extended Discoveryは非対称で、片方が送り始め、受け取った側が応答するかを決めます。

セッション保護が変えるのは復旧の速さではなく、セッションとラベルを失うかどうかです。相手にIPで到達できなければ効きません。

実機での検証

検証環境

コアを二重化し、PE1とP1を結ぶリンクを1本だけにしてあります。この1本でDiscoveryを止めれば、PE1とP1の間にLDPセッションが成立しません。

リンクサブネットOSPFコスト役割
PE1 - P110.2.3.0/241試験対象。ここにACLを当てる
PE1 - P210.2.4.0/24100迂回路の入口
P1 - P3 / P2 - P410.3.5.0/24 / 10.4.6.0/241それぞれの面
P3 - PE210.5.7.0/241—
P4 - PE210.6.7.0/24100迂回路の出口
P1 - P2 / P3 - P410.3.4.0/24 / 10.5.6.0/241クロスリンク。セッション保護の迂回路

PE1 → PE2の経路はコスト順にPE1-P1-P3-PE2が3、PE1-P2-P1-P3-PE2が103、PE1-P2-P4-PE2が201です。

CE1とCE2はPEのvrf CUST-A（RD/RT 65001:1）にeBGPで接続し、PE1 - PE2はLo0間のiBGP vpnv4です。 顧客トラフィックは常に2段ラベルなので、IP転送に落ちる逃げ道がありません。

測り方

転送の断は、設定変更をまたいでCE1から流したpingで測ります（count 600 interval 100 timeout 1）。採取の既定の順番（カウンタのクリア → ping → show）では、pingが設定変更と収束待ちの後に走るため定常状態しか見えません。各STEPの..._flap.txtがその記録です。

ロス数から読み取れるのはpingの粒度より粗い時間だけです。 timeout 1では1発落ちると次を送るまで1秒待つので、実際の断が150ミリ秒でも1秒でも「ロス1発」になります。この検証では「ロスが何発出たか」と「どちらのリンクを流れたか」までを事実として扱い、ミリ秒単位の切替時間は求めていません。

XRdはCML上のソフトウェア転送です。数値はこのラボでの相対比較として読んでください。

検証のSTEP

STEP 0〜3でLDP-IGPシンクロナイゼーションを、STEP 9〜12でリンク断をまたぐ測定を行います（STEP 4〜8は同じ操作の1回目で、採取ファイルは残してあります）。

STEP操作確かめること
0初期状態PE1-P1-P3-PE2を通ること。LDPの能力に End-of-LIB が無いこと
1PE1 - P1の両端にACL（UDP 646をdeny）セッションが成立せず、VPNが落ちること。素のIPは通ること
2両端にmpls ldp syncコスト65535で広告され、迂回して復活すること
3ACLを外す同期が完了してコストが戻ること
9同期なし・保護なしでリンク断→復旧断の基準値。LDPとOSPFのどちらが先に上がるか
10同期ありで同じ操作STEP 9との差
11保護を足して同じ操作セッションが残ること。targeted helloが迂回路を通ること
12保護を外し遅延（hold-downタイマー）を入れて同じ操作同期を宣言するまでコストが65535のままになること

LDPが上がらないとVPNだけが落ちる

PE1とP1の両端に、LDPのDiscoveryだけを落とすACLを当てます。TCP 646は塞いでいません。Discoveryが成立しなければセッションも張られないからです。

STEP 1 PE1にcommitした設定
RP/0/RP0/CPU0:PE1#show configuration commit changes last 1
Sun Sep 27 21:52:06.954 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
ipv4 access-list BLOCK-LDP-DISCOVERY
 10 deny udp any any eq ldp
 20 permit ipv4 any any
!
interface GigabitEthernet0/0/0/1
 ipv4 access-group BLOCK-LDP-DISCOVERY ingress
!
end

hold timeの15秒が過ぎるとP1とのセッションが消え、P2とのセッションだけが残ります。

STEP 1 PE1 show mpls ldp neighbor brief
RP/0/RP0/CPU0:PE1#show mpls ldp neighbor brief
Sun Sep 27 21:57:48.699 UTC

Peer               GR  NSR  Up Time     Discovery   Addresses     Labels
                                        ipv4  ipv6  ipv4  ipv6  ipv4   ipv6
-----------------  --  ---  ----------  ----------  ----------  ------------
4.4.4.4:0          N   N    00:17:26    1     0     4     0     14     0

顧客のトラフィックは全部落ちました。tracerouteはPE1から先へ1ホップも進みません。!Nはnetwork unreachableで、PE1自身が返しています。

STEP 1 CE1 traceroute（192.168.2.1 宛）
RP/0/RP0/CPU0:CE1#traceroute 192.168.2.1 source 192.168.1.1 timeout 1 probe 2 maxttl 8
Sun Sep 27 21:55:46.047 UTC

Type escape sequence to abort.
Tracing the route to 192.168.2.1

 1  10.1.2.2 !N  *

理由は転送エントリーに出ます。VPNラベルは分かっているのに、トランスポートラベルが得られず転送先がdropになっています。

STEP 1 PE1 show cef vrf CUST-A 192.168.2.0/24 detail（末尾）
RP/0/RP0/CPU0:PE1#show cef vrf CUST-A 192.168.2.0/24 detail
Sun Sep 27 21:57:58.538 UTC
192.168.2.0/24, version 7, internal 0x5000001 0x30 (ptr 0x885192c0) [1], 0x0 (0x0), 0x208 (0x899cb518)
 Updated Sep 27 21:41:43.111
 Prefix Len 24, traffic index 0, precedence n/a, priority 3
  gateway array (0x8938ba58) reference count 1, flags 0x203a, source rib (7), 0 backups
                [1 type 1 flags 0xc0441 (0x89a044b8) ext 0x0 (0x0)]
  LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
  gateway array update type-time 3 Sep 27 21:57:51.444
 LDI Update time Sep 27 21:52:21.357
   via 7.7.7.7/32, 0 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0x885295e0 0x0]
    recursion-via-/32
    next hop VRF - 'default', table - 0xe0000000
    unresolved
     labels imposed {24011}

    Load distribution: 0 (refcount 1)

    Hash  OK  Interface                 Address
    0     Y   recursive                 drop

一方、同じ状態でも素のIPは通ります。PE1からPE2のLoopback0へのpingは全部成功し、1ホップ目にラベルが付いていません。PE1はラベル無しで送り出し、P1はIP経路を持つので転送できます。IP転送に落ちられるかどうかが、VPNと素のIPの分かれ目です。

STEP 1 PE1 ping / traceroute（7.7.7.7 宛）
RP/0/RP0/CPU0:PE1#ping 7.7.7.7 source 2.2.2.2 count 50 timeout 1
Sun Sep 27 21:55:50.945 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 7.7.7.7 timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 10/12/47 ms
RP/0/RP0/CPU0:PE1#traceroute 7.7.7.7 source 2.2.2.2 timeout 1 probe 2 maxttl 6
Sun Sep 27 21:55:52.371 UTC

Type escape sequence to abort.
Tracing the route to 7.7.7.7

 1  10.2.3.3 7 msec  5 msec
 2  10.3.5.5 [MPLS: Label 24008 Exp 0] 11 msec  11 msec
 3  10.5.7.7 13 msec  *

最大コストで広告させる

PE1とP1のOSPFに、そのインタフェースへmpls ldp syncを入れます。

STEP 2 PE1にcommitした設定
RP/0/RP0/CPU0:PE1#show configuration commit changes last 1
Sun Sep 27 22:02:02.263 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router ospf 1
 area 0
  interface GigabitEthernet0/0/0/1
   mpls ldp sync
  !
 !
!
end

同期の状態はインタフェースごとに表示され、満たしていない条件まで書かれます。No hello adjacencyは、fully operationalの条件1が満たされていないという意味です。ACLを当てていないGi0/0/0/2はReadyで、同じ出力の中で対照になっています。

STEP 2 PE1 show mpls ldp igp sync
RP/0/RP0/CPU0:PE1#show mpls ldp igp sync
Sun Sep 27 22:05:52.251 UTC

GigabitEthernet0/0/0/1:
  VRF: 'default' (0x60000000)
  Sync delay: Disabled
  Sync status: Not ready (No hello adjacency)

GigabitEthernet0/0/0/2:
  VRF: 'default' (0x60000000)
  Sync delay: Disabled
  Sync status: Ready
    Peers:
      4.4.4.4:0

広告されている値はRouter-LSAに出ます。P1（3.3.3.3）へのリンクだけが65535です。

STEP 2 PE1 show ospf database router self-originate（抜粋）
RP/0/RP0/CPU0:PE1#show ospf database router self-originate
Sun Sep 27 22:05:47.791 UTC


            OSPF Router with ID (2.2.2.2) (Process ID 1)

		Router Link States (Area 0)

  LS age: 226
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000005
  Checksum: 0xe3cd
  Length: 84
   Number of Links: 5

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 2.2.2.2
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 3.3.3.3
     (Link Data) Router Interface address: 10.2.3.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 65535

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.2.3.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 4.4.4.4
     (Link Data) Router Interface address: 10.2.4.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 100

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.2.4.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 100

トラフィックはコスト100のリンクへ移り、2段ラベルを保ったまま迂回します。P2（10.2.4.4）へ出て、クロスリンクでP1（10.3.4.3）へ戻り、元の経路に合流しています。

STEP 2 CE1 traceroute
RP/0/RP0/CPU0:CE1#traceroute 192.168.2.1 source 192.168.1.1 timeout 1 probe 2 maxttl 8
Sun Sep 27 22:04:49.702 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.4.4 [MPLS: Labels 24009/24011 Exp 0] 22 msec  21 msec
 3  10.3.4.3 [MPLS: Labels 24009/24011 Exp 0] 21 msec  23 msec
 4  10.3.5.5 [MPLS: Labels 24008/24011 Exp 0] 22 msec  19 msec
 5  10.5.7.7 [MPLS: Label 24011 Exp 0] 20 msec  19 msec
 6  10.7.8.8 19 msec  *

Sync delay: Disabledは、同期の3つ目の条件（すべてのラベルバインディングの交換）が推定でしかないことに対応します。RFC 5443の2節は「現時点ではこの条件をルータが確かめられないので、推定が必要になる」「実装としては設定可能なhold-downタイマーを使う方法が簡単だ」と述べています。確かめられるようにする仕組みがRFC 5919のEnd-of-LIB（ラベル広告の完了を通知する）で、これが実装されればタイマーは不要になります。

このラボのXRdはEnd-of-LIBを広告していません。LDPの能力の一覧に出てこないので、推定に頼る側の動作になります。

STEP 0 PE1 show mpls ldp capabilities
RP/0/RP0/CPU0:PE1#show mpls ldp capabilities
Sun Sep 27 21:47:53.665 UTC
  Type     Description                                Owner
  ------   ----------------------------------------   ------------
  0x50b    Typed Wildcard FEC                         LDP
  0x3eff   Cisco IOS-XR                               LDP
  0x508    MP: Point-to-Multipoint (P2MP)             mLDP
  0x509    MP: Multipoint-to-Multipoint (MP2MP)       mLDP
  0x50c    MP: Multi-Topology (MT)                    mLDP
  0x703    P2MP PW                                    L2VPN-AToM

STEP 3でACLを外すと同期が完了します。traceに宣言の瞬間が残り、コストは1に戻ります。

STEP 3 PE1 show mpls ldp trace igp-sync（末尾）
RP/0/RP0/CPU0:PE1#show mpls ldp trace igp-sync
Sun Sep 27 22:14:09.547 UTC
5 wrapping entries (1027456 possible, 3200 allocated, 826 filtered, 831 total)
Sep 27 21:40:38.884 mpls/ldp/isyn 0/RP0/CPU0 t4113  [ISYNC]:2158: Intf GigabitEthernet0/0/0/1 (ifh 0x18): Nbr 3.3.3.3:0 came up, sync_achieved up
Sep 27 21:40:43.190 mpls/ldp/isyn 0/RP0/CPU0 t4113  [ISYNC]:2158: Intf GigabitEthernet0/0/0/2 (ifh 0x20): Nbr 4.4.4.4:0 came up, sync_achieved up
Sep 27 21:52:20.343 mpls/ldp/isyn 0/RP0/CPU0 t4113  [ISYNC]:1472: Intf GigabitEthernet0/0/0/1 (ifh 0x18): Adj 10.2.3.3 is being deleted, sync achieved 0
Sep 27 21:52:20.343 mpls/ldp/isyn 0/RP0/CPU0 t4113  [ISYNC]:1476: Adj 10.2.3.3 being deleted belongs to adj_grp 3.3.3.3, has adj_flags 0xb4
Sep 27 22:10:09.824 mpls/ldp/isyn 0/RP0/CPU0 t4113  [ISYNC]:2158: Intf GigabitEthernet0/0/0/1 (ifh 0x18): Nbr 3.3.3.3:0 came up, sync_achieved up
STEP 3 PE1 show ospf database router self-originate（抜粋）
RP/0/RP0/CPU0:PE1#show ospf database router self-originate
Sun Sep 27 22:13:44.803 UTC


            OSPF Router with ID (2.2.2.2) (Process ID 1)

		Router Link States (Area 0)

  LS age: 215
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000006
  Checksum: 0xffaf
  Length: 84
   Number of Links: 5

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 2.2.2.2
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 3.3.3.3
     (Link Data) Router Interface address: 10.2.3.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.2.3.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 4.4.4.4
     (Link Data) Router Interface address: 10.2.4.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 100

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.2.4.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 100

リンクの復旧では同期の有無で差が出ない

PE1 - P1を両端でshutdownし、40秒後に戻す操作を、同期なし（STEP 9）と同期あり（STEP 10）で行いました。どちらもロスは1発で、差がありません。

理由はsyslogの時刻に出ています。LDPのほうがOSPFより先に上がっています。

STEP 9 PE1 show logging（復旧の2行）
RP/0/RP0/CPU0:Sep 27 19:14:28.310 UTC: mpls_ldp[1178]: %ROUTING-LDP-5-NBR_CHANGE : VRF 'default' (0x60000000), Neighbor 3.3.3.3:0 is UP (IPv4 connection)
RP/0/RP0/CPU0:Sep 27 19:14:30.424 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 3.3.3.3 on GigabitEthernet0/0/0/1 in area 0 from LOADING to FULL, Loading Done, vrf default vrfid 0x60000000

IGPが選び直した時点ですでにラベルが使えており、同期が抑えるべき瞬間がありません。IOS XRの既定ではLDPのセッションがTCPで即座に張られ、OSPFはHello 10秒を待ってExStart / Exchange / Loadingを経るためです。

同期は「復旧を速くする機能」ではなく「LDPが使えないリンクをIGPに選ばせない保険」です。出番があるのは、設定漏れ・フィルタ・認証の不一致でLDPが上がらない場合（STEP 1 → 2がそれです）や、経路数が多く対向が遅いなどでLDPの収束がIGPより遅れる場合です。

セッション保護：リンクが無くなってもセッションを残す

session protectionを入れると（STEP 11）、同じ操作でLDPセッションが一度も落ちません。NBR_CHANGEが1件も出ず、ラベルバインディングも保持されたままです。

show mpls ldp discoveryにその理由が並んでいます。リンクのhello adjacencyとは別にTargeted Hellosの項目があり、hold timeも15秒ではなく90秒です。

STEP 11 PE1 show mpls ldp discovery
RP/0/RP0/CPU0:PE1#show mpls ldp discovery
Sun Sep 27 19:37:43.015 UTC

Local LDP Identifier: 2.2.2.2:0
Discovery Sources:
  Interfaces:
    GigabitEthernet0/0/0/1 : xmit/recv
      VRF: 'default' (0x60000000)
      LDP Id: 3.3.3.3:0, Transport address: 3.3.3.3
          Hold time: 15 sec (local:15 sec, peer:15 sec)
          Established: Sep 27 19:33:39.109 (00:04:03 ago)

    GigabitEthernet0/0/0/2 : xmit/recv
      VRF: 'default' (0x60000000)
      LDP Id: 4.4.4.4:0, Transport address: 4.4.4.4
          Hold time: 15 sec (local:15 sec, peer:15 sec)
          Established: Sep 27 19:07:06.757 (00:30:36 ago)

  Targeted Hellos:
    2.2.2.2 -> 3.3.3.3 (active), xmit/recv
      LDP Id: 3.3.3.3:0
          Hold time: 90 sec (local:90 sec, peer:90 sec)
          Established: Sep 27 19:32:25.537 (00:05:17 ago)

    2.2.2.2 -> 4.4.4.4 (active), xmit
          Established: N/A

どこを通ったかはキャプチャーに出ます。断の区間だけ、迂回路（PE1 - P2）にユニキャストのHelloが流れました。宛先は相手のLoopback0（3.3.3.3）です。

STEP 11 No.204 targeted hello（PE1 → P1、迂回路を通る）tshark -V 抜粋
Internet Protocol Version 4, Src: 2.2.2.2, Dst: 3.3.3.3
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT)
        1100 00.. = Differentiated Services Codepoint: Class Selector 6 (48)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 70
    Identification: 0xb900 (47360)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 255
    Protocol: UDP (17)
    Header Checksum: 0xf7dc [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 2.2.2.2
    Destination Address: 3.3.3.3
    [Stream index: 5]
User Datagram Protocol, Src Port: 646, Dst Port: 646
    Source Port: 646
    Destination Port: 646
    Length: 50
    Checksum: 0x5cc5 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 3]
    [Stream Packet Number: 2]
    [Timestamps]
        [Time since first frame: 253.577000 milliseconds]
        [Time since previous frame: 253.577000 milliseconds]
    UDP payload (42 bytes)
Label Distribution Protocol
    Version: 1
    PDU Length: 38
    LSR ID: 2.2.2.2
    Label Space ID: 0
    Hello Message
        0... .... = U bit: Unknown bit not set
        Message Type: Hello Message (0x100)
        Message Length: 28
        Message ID: 0x00000000
        Common Hello Parameters
            00.. .... = TLV Unknown bits: Known TLV, do not Forward (0x0)
            TLV Type: Common Hello Parameters (0x400)
            TLV Length: 4
            Hold Time: 90
            1... .... .... .... = Targeted Hello: Targeted Hello
            .1.. .... .... .... = Hello Requested: Source requests periodic hellos
上のtshark出力のパケット（No.204 targeted hello）のpcapをダウンロード

Hello Requestedビットが、RFC 5036の2.4.2節が定める非対称なやりとり（送り始めた側が定期的な送り返しを要求する）にあたります。

保護が変えるのはセッションとラベルを失うかどうかで、断の長さは変わりません（ロスは1発のまま）。この構成ではリンクが落ちた時点で迂回路へ移るため、切り替えのコストは条件によらず同じです。ラベルが残っていれば、再確立とラベルの再交換をやり直さずに済みます。

hold-downタイマー：同期を宣言するまで待たせる

IOS XRではmpls ldp配下のigp sync delay on-session-up <秒>で、セッションが上がってから同期を宣言するまでの待ち時間を設定できます。STEP 12では30秒にし、保護を外した状態（セッションが落ちる状態）でリンク断を起こしました。

復旧の直後にPE1を覗くと、同期がDeferredで待っている間、Router-LSAはP1へのリンクを65535で広告したままです。

STEP 12 復旧直後のPE1（+5秒と+15秒）
Sun Sep 27 19:43:16.685 UTC
RP/0/RP0/CPU0:PE1#show clock

Sun Sep 27 19:43:16.963 UTC
19:43:17.006 UTC Sun Sep 27 2026
RP/0/RP0/CPU0:PE1#show mpls ldp igp sync

Sun Sep 27 19:43:17.081 UTC

GigabitEthernet0/0/0/1:
  VRF: 'default' (0x60000000)
  Sync delay: 30 sec
  Sync status: Deferred   (20 sec remaining)

GigabitEthernet0/0/0/2:
  VRF: 'default' (0x60000000)
  Sync delay: 30 sec
  Sync status: Ready
    Peers:
      4.4.4.4:0


RP/0/RP0/CPU0:PE1#show ospf database router self-originate

Sun Sep 27 19:43:17.202 UTC


            OSPF Router with ID (2.2.2.2) (Process ID 1)

		Router Link States (Area 0)

  LS age: 8
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000010
  Checksum: 0xcdd8
  Length: 84
   Number of Links: 5

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 2.2.2.2
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 3.3.3.3
     (Link Data) Router Interface address: 10.2.3.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 65535

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.2.3.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 4.4.4.4
     (Link Data) Router Interface address: 10.2.4.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 100

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.2.4.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 100


RP/0/RP0/CPU0:PE1#show route 7.7.7.7/32

Sun Sep 27 19:43:18.000 UTC

Routing entry for 7.7.7.7/32
  Known via "ospf 1", distance 110, metric 104, type intra area
  Installed Sep 27 19:42:07.212 for 00:01:10
  Routing Descriptor Blocks
    10.2.4.4, from 7.7.7.7, via GigabitEthernet0/0/0/2
      Route metric is 104
  No advertising protos.

15秒後のスナップショットではReadyに戻り、コストも1に戻っています。RFC 5443が「推定」と呼んだ部分を、実装がタイマーで埋めている様子がそのまま見えます。

4条件の比較

STEP同期保護遅延断をまたぐ pingLDPセッション迂回路の targeted hello
9なしなしなし599/600（ロス 1 発）断0
10ありなしなし599/600（ロス 1 発）断0
11ありありなし599/600（ロス 1 発）継続6
12ありなしあり599/600（ロス 1 発）断0
同期が効いたのはSTEP 1 → 2だけで、0%から100%へ変わりました。リンク断の復旧（STEP 9〜12）では、同期・保護・遅延のどれを入れてもロスは1発のままです。変わるのはセッションとラベルを失うかどうか（保護）と、同期を宣言するまでの待ち時間（遅延）です。
CE1 → CE2（STEP 0、収束後の50発）
RP/0/RP0/CPU0:CE1#ping 192.168.2.1 source 192.168.1.1 count 50 timeout 1
Sun Sep 27 21:46:49.592 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 = 16/22/81 ms

検証Configおよびshow結果

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

ファイル内容
..._clear.txtそのSTEPの最初にクリアしたカウンタ
..._ping.txt収束後のping（50発）とtraceroute。顧客間はCEから、コアはLo0間
..._flap.txt設定変更をまたいで流したping（600発 × 100ms）。リンク断のSTEPのみ、CE1から
..._show.txtshow version / show route / OSPF一式 / LDP一式（igp sync / discovery / neighbor / bindings / capabilities）/ MPLS転送 / VPNとBGP
..._log.txtそのSTEPの範囲だけに絞ったshow logging
..._run.txtそのSTEP時点のshow running-config（＝そのSTEPの検証Config）
..._trace.txtコア6台のみ。show mpls ldp trace igp-sync / peer / bindingとshow mpls lsd trace
..._commit.cfgそのSTEPでcommitされた設定。リンク断のSTEPは落としたとき（pe1 / p1）と戻したとき（pe1r / p1r）に分けてあります
..._during.txtリンク断のSTEPのみ。復旧直後（+5秒 / +15秒）のPE1の同期状態とRouter-LSA

STEP 0：初期状態

ルータshow出力ping断の測定clearsyslogrunning-configtrace投入した設定復旧直後
CE1showping—clearlogrun———
PE1showping—clearlogruntrace——
P1showping—clearlogruntrace——
P2showping—clearlogruntrace——
P3showping—clearlogruntrace——
P4showping—clearlogruntrace——
PE2showping—clearlogruntrace——
CE2showping—clearlogrun———

STEP 1：PE1 - P1の両端にACL（UDP 646をdeny）

ルータshow出力ping断の測定clearsyslogrunning-configtrace投入した設定復旧直後
CE1showping—clearlogrun———
PE1showping—clearlogruntracepe1—
P1showping—clearlogruntracep1—
P2showping—clearlogruntrace——
P3showping—clearlogruntrace——
P4showping—clearlogruntrace——
PE2showping—clearlogruntrace——
CE2showping—clearlogrun———

STEP 2：両端にmpls ldp sync

ルータshow出力ping断の測定clearsyslogrunning-configtrace投入した設定復旧直後
CE1showping—clearlogrun———
PE1showping—clearlogruntracepe1—
P1showping—clearlogruntracep1—
P2showping—clearlogruntrace——
P3showping—clearlogruntrace——
P4showping—clearlogruntrace——
PE2showping—clearlogruntrace——
CE2showping—clearlogrun———

STEP 3：ACLを外す

ルータshow出力ping断の測定clearsyslogrunning-configtrace投入した設定復旧直後
CE1showping—clearlogrun———
PE1showping—clearlogruntracepe1—
P1showping—clearlogruntracep1—
P2showping—clearlogruntrace——
P3showping—clearlogruntrace——
P4showping—clearlogruntrace——
PE2showping—clearlogruntrace——
CE2showping—clearlogrun———

STEP 4：同期を外してリンク断→復旧

ルータshow出力ping断の測定clearsyslogrunning-configtrace投入した設定復旧直後
CE1showpingoutageclearlogrun———
PE1showping—clearlogruntracepe1 pe1rduring
P1showping—clearlogruntracep1 p1r—
P2showping—clearlogruntrace——
P3showping—clearlogruntrace——
P4showping—clearlogruntrace——
PE2showping—clearlogruntrace——
CE2showping—clearlogrun———

STEP 5：同期ありで同じ操作

ルータshow出力ping断の測定clearsyslogrunning-configtrace投入した設定復旧直後
CE1showpingoutageclearlogrun———
PE1showping—clearlogruntracepe1 pe1rduring
P1showping—clearlogruntracep1 p1r—
P2showping—clearlogruntrace——
P3showping—clearlogruntrace——
P4showping—clearlogruntrace——
PE2showping—clearlogruntrace——
CE2showping—clearlogrun———

STEP 6：session protectionを足して同じ操作

ルータshow出力ping断の測定clearsyslogrunning-configtrace投入した設定復旧直後
CE1showpingoutageclearlogrun———
PE1showping—clearlogruntracepe1 pe1rduring
P1showping—clearlogruntracep1 p1r—
P2showping—clearlogruntrace——
P3showping—clearlogruntrace——
P4showping—clearlogruntrace——
PE2showping—clearlogruntrace——
CE2showping—clearlogrun———

STEP 7：hold-downタイマーを入れて同じ操作

ルータshow出力ping断の測定clearsyslogrunning-configtrace投入した設定復旧直後
CE1showpingoutageclearlogrun———
PE1showping—clearlogruntracepe1 pe1rduring
P1showping—clearlogruntracep1 p1r—
P2showping—clearlogruntrace——
P3showping—clearlogruntrace——
P4showping—clearlogruntrace——
PE2showping—clearlogruntrace——
CE2showping—clearlogrun———

STEP 8：保護・遅延・同期をすべて削除

ルータshow出力ping断の測定clearsyslogrunning-configtrace投入した設定復旧直後
CE1showping—clearlogrun———
PE1showping—clearlogruntracepe1—
P1showping—clearlogruntracep1—
P2showping—clearlogruntrace——
P3showping—clearlogruntrace——
P4showping—clearlogruntrace——
PE2showping—clearlogruntrace——
CE2showping—clearlogrun———

STEP 9：同期なし・保護なしでリンク断→復旧

ルータshow出力ping断の測定clearsyslogrunning-configtrace投入した設定復旧直後
CE1showpingoutageclearlogrun———
PE1showping—clearlogruntracepe1 pe1rduring
P1showping—clearlogruntracep1 p1r—
P2showping—clearlogruntrace——
P3showping—clearlogruntrace——
P4showping—clearlogruntrace——
PE2showping—clearlogruntrace——
CE2showping—clearlogrun———

STEP 10：同期あり・保護なしで同じ操作

ルータshow出力ping断の測定clearsyslogrunning-configtrace投入した設定復旧直後
CE1showpingoutageclearlogrun———
PE1showping—clearlogruntracepe1 pe1rduring
P1showping—clearlogruntracep1 p1r—
P2showping—clearlogruntrace——
P3showping—clearlogruntrace——
P4showping—clearlogruntrace——
PE2showping—clearlogruntrace——
CE2showping—clearlogrun———

STEP 11：同期あり・保護ありで同じ操作

ルータshow出力ping断の測定clearsyslogrunning-configtrace投入した設定復旧直後
CE1showpingoutageclearlogrun———
PE1showping—clearlogruntracepe1 pe1rduring
P1showping—clearlogruntracep1 p1r—
P2showping—clearlogruntrace——
P3showping—clearlogruntrace——
P4showping—clearlogruntrace——
PE2showping—clearlogruntrace——
CE2showping—clearlogrun———

STEP 12：同期あり・保護なし・遅延ありで同じ操作

ルータshow出力ping断の測定clearsyslogrunning-configtrace投入した設定復旧直後
CE1showpingoutageclearlogrun———
PE1showping—clearlogruntracepe1 pe1rduring
P1showping—clearlogruntracep1 p1r—
P2showping—clearlogruntrace——
P3showping—clearlogruntrace——
P4showping—clearlogruntrace——
PE2showping—clearlogruntrace——
CE2showping—clearlogrun———

STEP 13：同期・遅延を削除（最終状態）

ルータshow出力ping断の測定clearsyslogrunning-configtrace投入した設定復旧直後
CE1showping—clearlogrun———
PE1showping—clearlogruntracepe1—
P1showping—clearlogruntracep1—
P2showping—clearlogruntrace——
P3showping—clearlogruntrace——
P4showping—clearlogruntrace——
PE2showping—clearlogruntrace——
CE2showping—clearlogrun———

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

STEPCE1 - PE1間PE1 - P1間PE1 - P2間（迂回路）
0pcappcappcap
1pcappcappcap
2pcappcappcap
3pcappcappcap
4pcappcappcap
5pcappcappcap
6pcappcappcap
7pcappcappcap
8pcappcappcap
9pcappcappcap
10pcappcappcap
11pcappcappcap
12pcappcappcap
13pcappcappcap

参考

RFCタイトル概要
RFC 5443LDP IGP SynchronizationLDPがfully operationalになるまでIGPが最大コストで広告する仕組み。fully operationalの定義と最大コストの値（2節）、適用条件とブロードキャストリンクでの扱い（3節）。
RFC 5036LDP SpecificationBasic Discovery（2.4.1節）とExtended Discovery（2.4.2節）。targeted helloの非対称なやり取りを定義。

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

関連記事