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節）。

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

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

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セッションが成立しません。

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 192.168.2.1 source 192.168.1.1 count 20 interval 100を流し、tracerouteで経路とラベルスタックを見ます。各STEPで8台すべてのping / tracerouteを記録しています。途切れた時間はCE1 - PE1のキャプチャーで、echo replyの間隔から測りました。

IOS XRのpingはintervalが効きますが、応答が無いとtimeout（既定2秒）を待ってから次を送ります。ロス数は比較できますが、ロス数に間隔を掛けても途切れた時間にはなりません。

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

検証のSTEP

以降の節はSTEP順ではなく、2つの仕組みごとにまとめています。

LDPが上がらないリンクは選ばれ続ける（STEP 1）

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

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

ACLを当ててからセッションが落ちるまでhold timeの15秒かかります。 P1とのセッションだけが消え、P2とのセッションは残ります。

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

顧客のトラフィックは全部落ちました。tracerouteはPE1から先へ1ホップも進みません。

Success rate is 0 percent (0/20)
 1  10.1.2.2 !N  *  !N 

!Nはnetwork unreachableで、PE1自身が返しています。理由は転送エントリーに出ます。

   via 7.7.7.7/32, 0 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0x88521758 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           

VPNラベル（24011）は分かっているのに、トランスポートラベルが得られず、転送先が「drop」になっています。

一方、同じ状態でも素のIPは通ります。PE1からPE2のLo0へのpingは全部成功しました。

Success rate is 100 percent (20/20), round-trip min/avg/max = 8/14/60 ms
 1  10.2.3.3 5 msec  5 msec  5 msec 
 2  10.3.5.5 [MPLS: Label 24009 Exp 0] 11 msec  10 msec  9 msec 
 3  10.5.7.7 10 msec  *  13 msec 

1ホップ目の10.2.3.3（P1）にラベルが付いていません。PE1はラベル無しで送り出し、P1はIP経路を持つので転送でき、2ホップ目からはP1が付けたラベルが乗ります。IP転送に落ちられるかどうかが、VPNと素のIPの分かれ目です。

最大コストで広告させる（STEP 2・3）

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

router ospf 1
 area 0
  interface GigabitEthernet0/0/0/1
   mpls ldp sync

同期の状態はインタフェースごとに表示され、満たしていない条件まで書かれます。

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

No hello adjacencyは、fully operationalの条件1が満たされていないという意味です。ACLを当てていないGi0/0/0/2はReadyで、同じ出力の中で対照になっています。インタフェースのコスト設定は1のままです。

GigabitEthernet0/0/0/1 is up, line protocol is up 
  Internet Address 10.2.3.2/24, Area 0, SID 0, Strict-SPF SID 0
  Label stack Primary label 1 Backup label 3 SRTE label 10
  auto path capability supported
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 1

広告されている値はRouter-LSAに出ます。

    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

トラフィックはコスト100のリンクへ移り、2段ラベルを保ったまま迂回します。

Success rate is 100 percent (20/20), round-trip min/avg/max = 17/18/24 ms
 1  10.1.2.2 7 msec  16 msec  5 msec 
 2  10.2.4.4 [MPLS: Labels 24009/24011 Exp 0] 20 msec  17 msec  17 msec 
 3  10.3.4.3 [MPLS: Labels 24009/24011 Exp 0] 19 msec  21 msec  20 msec 
 4  10.3.5.5 [MPLS: Labels 24009/24011 Exp 0] 18 msec  16 msec  17 msec 
 5  10.5.7.7 [MPLS: Label 24011 Exp 0] 18 msec  20 msec  18 msec 
 6  10.7.8.8 20 msec  *  20 msec 

P2（10.2.4.4）へ出て、クロスリンクでP1（10.3.4.3）へ戻り、元の経路に合流しています。STEP 0の5ホップに対して6ホップです。

STEP 3でACLを外すと同期が完了し、コストが1に戻ります。LDPが同期を宣言してからOSPFが最大コストを下ろすまでの順序が時刻に残ります。

Sep 11 14:14:12.047 mpls/ldp/isyn 0/RP0/CPU0 t4071  [ISYNC]:2158: Intf GigabitEthernet0/0/0/1 (ifh 0x10): Nbr 3.3.3.3:0 came up, sync_achieved up

このあと経路がInstalled Sep 11 14:14:12.183で戻っており、同期の宣言から0.136秒後でした。

リンクの復旧ではブラックホールにならなかった（STEP 4・5）

PE1 - P1を両端でshutdownし、40秒後に戻す操作を、同期なし（STEP 4）と同期あり（STEP 5）で行います。

どちらもロスは1発、途切れは約2.1秒で、差がありませんでした。しかもその2.1秒はshutdownした瞬間のもので、復旧時には途切れていません。

理由はsyslogの時刻に出ています。

Sep 11 14:22:29.026 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 3.3.3.3 on GigabitEthernet0/0/0/1 in area 0 from FULL to DOWN, Neighbor Down: interface down or detached, vrf default vrfid 0x60000000 
Sep 11 14:22:29.086 UTC: mpls_ldp[1178]: %ROUTING-LDP-5-NBR_CHANGE : VRF 'default' (0x60000000), Neighbor 3.3.3.3:0 is DOWN (Interface state down) 
Sep 11 14:23:23.596 UTC: mpls_ldp[1178]: %ROUTING-LDP-5-NBR_CHANGE : VRF 'default' (0x60000000), Neighbor 3.3.3.3:0 is UP (IPv4 connection) 
Sep 11 14:23:28.016 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 

LDPが14:23:23.596、OSPFが14:23:28.016で、LDPのほうが4.4秒早く上がっています。 STEP 5でも同じ順序でした（LDPが3.5秒早い）。IGPが選び直した時点ですでにラベルが使えており、同期が抑えるべき瞬間がありません。

セッション保護（STEP 6）

mpls ldp配下にsession protectionを入れ、STEP 4・5と同じ手順を踏みます。ロスは1発、途切れは2.11秒で数値は変わりません。変わったのはセッションの側です。

Sep 11 14:37:22.782 UTC: ospf[1035]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 3.3.3.3 on GigabitEthernet0/0/0/1 in area 0 from FULL to DOWN, Neighbor Down: interface down or detached, vrf default vrfid 0x60000000 
Sep 11 14:38:25.254 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 

OSPFの隣接は落ちて戻っているのに、NBR_CHANGEが1件もありません。LDPセッションは一度も落ちていないということです。STEP 4では同じ操作でInterface state downが記録されていました。

show mpls ldp discoveryにその理由が並んでいます。

  Interfaces:
    GigabitEthernet0/0/0/1 : xmit/recv
          Hold time: 15 sec (local:15 sec, peer:15 sec)
          Established: Sep 11 14:38:21.013 (00:03:02 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 11 14:36:32.378 (00:04:51 ago)

リンク断は14:37:18から14:38:21でした。リンクのhello adjacencyは断のあとに作り直されている（14:38:21）のに対し、targeted helloのadjacencyは断の前（14:36:32）から一度も切れていません。 hold timeもリンクが15秒、targetedが90秒と違います。

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

リンク断の区間とぴったり一致します。逆方向（P1 → PE1）も同じ区間に出ていました。

    Source Address: 2.2.2.2
    Destination Address: 3.3.3.3
    Source Port: 646
    Destination Port: 646
Label Distribution Protocol
    LSR ID: 2.2.2.2
    Label Space ID: 0
    Hello Message
        Message Type: Hello Message (0x100)
        Common Hello Parameters
            TLV Type: Common Hello Parameters (0x400)
            Hold Time: 90
            1... .... .... .... = Targeted Hello: Targeted Hello
            .1.. .... .... .... = Hello Requested: Source requests periodic hellos

宛先が相手のLo0（3.3.3.3）へのユニキャストです。Hello Requestedビットが、2.4.2節の非対称なやり取り（送り始めた側が定期的な送り返しを要求する）にあたります。

比較結果

読み取れることは3つです。

同期が効いたのはSTEP 1 → 2だけで、0%から100%へ変わりました。LDPが上がらないリンクをIGPに選ばせないという、この仕組みそのものの効果です。

リンクの復旧では同期の有無で差が出ませんでした（STEP 4と5）。既定タイマーではLDPのほうが先に上がるためで、2回とも同じ順序でした。同期は「復旧を速くする機能」ではなく「LDPが使えないリンクをIGPに選ばせない保険」です。 出番があるのは、設定漏れ・フィルタ・認証の不一致でLDPが上がらない場合や、経路数が多く対向が遅いなどでLDPの収束がIGPより遅れる場合です。

セッション保護もロス数と途切れ時間は変えませんでした（STEP 4・5と6）。この構成ではリンクが落ちた時点でP2経由へ迂回し、戻すときも同じ経路をたどるため、切り替えのコストは条件によらず約2.1秒です。保護が変えたのはセッションとラベルを失うかどうかで、ラベルが残っていれば再確立と再交換をやり直さずに済みます。

キャプチャー

3本のリンクをフィルターなしで全STEPにわたり採取しています。

CE1 - PE1（ロスの測定点）

PE1 - P1（ACLを当てたリンク）

PE1 - P2（迂回路、targeted helloが通る）

検証Configおよびshow結果

各STEPで8台すべてから、次の種類をルータごとに分けて取得しています。検証Configはこの..._run.txtです（最終状態は最後のSTEPのもの）。

STEP 0：初期状態

STEP 1：PE1 - P1 に ACL を当てて LDP の Discovery を落とす

STEP 2：OSPF に mpls ldp sync を入れる

STEP 3：ACL を外す

STEP 4：同期なしで PE1 - P1 を落として戻す

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

STEP 6：session protection を入れて同じ操作

STEP 7：設定を削除（最終状態）

参考

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

関連記事

• MPLSとは
• MPLSラベルとラベルスタック
• MPLSのラベル操作（push / swap / pop）とPHP
• MPLSのTTL処理とMTU
• LDPとは
• LDPのラベル配布モードとラベルスペース
• LDP-IGPシンクロナイゼーションとLDPセッション保護