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

LDPのラベル広告制御（フィルタリング）

目次

LDPのラベル広告制御（フィルタリング）

LDPは既定で、IGPが知っているプレフィックスすべてにラベルを割り当てて配ります。しかし実際に必要なのは、BGPのネクストホップになるLoopbackの/32だけです。配るラベルを絞る3つの制御点と、絞り込みを緩めたときにどちらのルータが動いて取り戻すのかを解説し、IOS XR（XRd）のラボで確かめます。LDPの基本はLDPとはで解説しています。

何を絞るのか

MPLSでパケットを運ぶとき、入口のPEが積むトランスポートラベルはBGPのネクストホップ（相手PEのLoopback）へ向かうLSPのラベルです。コアのリンクのサブネットは、そこを通過はしますがネクストホップにはならないので、ラベルを持つ必要がありません。

それでもLDPが全部に配ってしまうのは、規格が「何を配るか」を決めていないからです。RFC 5036の2.6.3節が定めるのはDownstream Unsolicited / Downstream on Demandという「いつ配るか」だけで、フィルタの仕組みはプロトコルに存在しません。何を配るかは実装ごとのローカルな方針です。

絞る理由は3つあります。ラベルテーブルが小さくなること、LDPが交換するメッセージが減ること、そして意図しないLSPを作らせないことです。

3つの制御点

ラベルは「自分のLIBに作る → 相手へ配る → 相手が受け取る」という順に流れます。IOS XRはこの3か所それぞれで止められます。

制御点止まる場所効果
label allocate作る前ローカルラベルを作らない。LIBそのものが小さくなる
label advertise配るとき作るが相手に配らない。ピアごとに変えられる
label remote accept受け取るとき受け取った分を捨てる。受ける側だけで決められる

自分の装置のラベルテーブルを小さくしたいならlabel allocate、相手に見せたくないだけならlabel advertise、相手の設定に期待できないならlabel remote accept、という使い分けになります。

3つともmpls ldpのaddress-family ipv4配下のlabelにあり、local（自分が作る・配る）とremote（相手から受け取る）に分かれます。絞り込みの対象はルートポリシーではなくIPアクセスリストで、ピアの指定はLDP識別子（3.3.3.3:0のようにラベルスペース番号まで含む形）です。

IOS XRの構文（XRd 26.1.1）
mpls ldp
 address-family ipv4
  label
   local
    allocate for <アクセスリスト>      ← 作る前に止める
    advertise
     to <LDP識別子> for <アクセスリスト>   ← ピアごとに配る中身を決める
   remote
    accept
     from <LDP識別子> for <アクセスリスト>  ← 受け取る側で捨てる

allocate forにはhost-routesというキーワードもあり、アクセスリストを書かずに「/32だけ」を指定できます。

フィルタを緩めたときに動くのは、絞った側ではない

絞り込みをきつくする変更は、どの制御点でも即座に効きます。送信側で絞ればLabel Withdrawalが飛び、受信側で絞れば自分が持っている分をその場で捨てます。

緩める変更も反映されますが、動くルータが違います。LDPはDownstream Unsolicitedで、変化があったときに1回配るだけで、定期的な再送をしません。したがって待っていても戻ってきません。

緩めた制御点誰が動くか流れるメッセージ
label advertise（送信側）送信側が自分の広告内容を見直すLabel Mapping
label remote accept（受信側）受信側が相手に送り直すよう頼むLabel Request → Label Mapping

受信側は、いったん捨てたバインディングを自分では復元できません。そこでLabel Requestメッセージ（RFC 5036の3.5.8節）を使い、FECにTyped Wildcard FEC要素（RFC 5918の3節）を入れて「このFEC型のバインディングを全部もう一度送ってほしい」と要求します。RFC 5918の4節は、これを受けた側がその型の全FECについてLabel Mappingを送る要求として解釈すると定めています。

この要求が使えるかどうかはセッション確立時に決まります。InitializationメッセージでTyped Wildcard FEC Capability（0x050B、RFC 5918の5節）を交換していなければ要求できないため、相手が対応していない装置では、緩めた分を戻すのにclear mpls ldp neighborでセッションを張り直す必要があります。

検証構成

冗長性のない直列構成です。コア（PE1 - P1 - P2 - PE2）でOSPFとLDPを動かし、CE1とCE2はVRF CUST-AでPEに接続してVPNv4で疎通させます。

MPLS-FILTERラボ
  CE1 ------ PE1 ------ P1 ------ P2 ------ PE2 ------ CE2
(AS 65101)    |                              |   (AS 65102)
           vrf CUST-A                  vrf CUST-A
              +------ iBGP vpnv4 (Lo0) ------+
ルータLo0役割リンクサブネット
CE11.1.1.1AS 65101、192.168.1.0/24CE1 - PE110.1.2.0/24（VRF）
PE12.2.2.2入口/出口LSR、vrf CUST-APE1 - P110.2.3.0/24
P13.3.3.3中継LSRP1 - P210.3.4.0/24
P24.4.4.4中継LSRP2 - PE210.4.5.0/24
PE25.5.5.5入口/出口LSR、vrf CUST-APE2 - CE210.5.6.0/24（VRF）
CE26.6.6.6AS 65102、192.168.2.0/24

グローバルのOSPFが知るのは7プレフィックスです。Lo0の/32が4本と、コアのリンクの/24が3本。PE - CEのリンクはVRFにあるためグローバルのOSPFに入らず、はじめからラベルが付きません。

検証の全体像

STEP操作確かめること
0初期状態7本すべてにラベルが付いていること。疎通とラベルスタック
1label allocateで/32だけに絞る（コア4台）LIBが7→4に縮むこと。疎通が変わらないこと
2label advertiseでP1がPE1へ配る中身を絞るPE1は1本、絞っていないP2は4本のままであること
3送信側のフィルタを外す（clearしない）P1が自分で再広告して4本に戻ること
4clear mpls ldp neighborでセッションを張り直すすでに戻っていて、変化が無いこと
5label remote acceptでPE1の受け取りを絞るPE1は1本。線路には4本流れていること
6すべて撤去7本に戻ること
7label allocateを入れ直す（コア4台）LIBを4に戻すこと
8label remote acceptを入れ直す（PE1）PE1が1本になること
9受信側のフィルタを外す（clearしない）PE1がLabel Requestを送って4本に戻ること
10clear mpls ldp neighborでセッションを張り直すすでに戻っていて、変化が無いこと
11すべて撤去（最終状態）STEP 0と一致すること

各STEPはカウンタをクリアしてからCE1でping 192.168.2.1 source 192.168.1.1 count 50 timeout 1とtracerouteを流し、そのあとにshow一式を取っています。

STEP 0：既定では全プレフィックスにラベルが付く

P1のローカルバインディングです。Lo0の/32が4本とリンクの/24が3本、合わせて7本すべてにラベルが割り当たっています。

STEP 0 P1 show mpls ldp bindings local
RP/0/RP0/CPU0:P1#show mpls ldp bindings local
Sun Oct 11 15:59:38.563 UTC

2.2.2.2/32, rev 11
	Local binding: label: 24000
3.3.3.3/32, rev 7
	Local binding: label: ImpNull
4.4.4.4/32, rev 12
	Local binding: label: 24001
5.5.5.5/32, rev 14
	Local binding: label: 24003
10.2.3.0/24, rev 8
	Local binding: label: ImpNull
10.3.4.0/24, rev 9
	Local binding: label: ImpNull
10.4.5.0/24, rev 13
	Local binding: label: 24002

転送テーブルを見ると、その/24のラベルが使われていないことが数字で分かります。クリアしてからpingを流したあとの値なので、このSTEPの転送量そのものです。10.4.5.0/24のラベルはBytes Switchedが0のままです。

STEP 0 P1 show mpls forwarding
RP/0/RP0/CPU0:P1#show mpls forwarding
Sun Oct 11 15:59:39.027 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
24000  Pop         2.2.2.2/32         Gi0/0/0/0    10.2.3.2        29883
24001  Pop         4.4.4.4/32         Gi0/0/0/1    10.3.4.4        5750
24002  Pop         10.4.5.0/24        Gi0/0/0/1    10.3.4.4        0
24003  24003       5.5.5.5/32         Gi0/0/0/1    10.3.4.4        29817

STEP 1：作る前に止める（label allocate）

コア4台に、Lo0の/32だけを許可するアクセスリストとallocate forを入れます。

STEP 1 P1にcommitした設定
ipv4 access-list LDP-LOOPBACKS
 10 permit ipv4 host 2.2.2.2 any
 20 permit ipv4 host 3.3.3.3 any
 30 permit ipv4 host 4.4.4.4 any
 40 permit ipv4 host 5.5.5.5 any
!
mpls ldp
 address-family ipv4
  label
   local
    allocate for LDP-LOOPBACKS
   !
  !
 !
!

LIBのプレフィックス数が7から4に減ります。ラベルを作らなくなるだけで、経路を失うわけではありません。

STEP 1 P1 show mpls ldp bindings summary
RP/0/RP0/CPU0:P1#show mpls ldp bindings summary
Sun Oct 11 16:06:11.105 UTC

LIB Summary:
  Total Prefix   : 4
  Revision No    : Current:17, Advertised:17
  Local Bindings : 4
      NULL    : 1 (implicit:1, explicit:0)
      Non-NULL: 3 (lowest:24000, highest:24003)
  Remote Bindings: 8

OSPFの経路表には10.4.5.0/24がそのまま残っています。ラベルが無いプレフィックス宛のパケットは、ラベルを積まない素のIPとして転送されます。

STEP 1 P1 show route ospf
RP/0/RP0/CPU0:P1#show route ospf
Sun Oct 11 16:05:56.993 UTC

O    2.2.2.2/32 [110/2] via 10.2.3.2, 00:17:45, GigabitEthernet0/0/0/0
O    4.4.4.4/32 [110/2] via 10.3.4.4, 00:17:42, GigabitEthernet0/0/0/1
O    5.5.5.5/32 [110/3] via 10.3.4.4, 00:17:31, GigabitEthernet0/0/0/1
O    10.4.5.0/24 [110/2] via 10.3.4.4, 00:17:42, GigabitEthernet0/0/0/1

絞っても通信は変わらない

この記事の核心です。CE1からCE2へのtracerouteは、STEP 0とまったく同じラベルスタックを通ります。

STEP 0 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 6
Sun Oct 11 15:57:23.406 UTC

Type escape sequence to abort.
Tracing the route to 192.168.2.1

 1  10.1.2.2 9 msec  5 msec
 2  10.2.3.3 [MPLS: Labels 24003/24005 Exp 0] 23 msec  46 msec
 3  10.3.4.4 [MPLS: Labels 24003/24005 Exp 0] 21 msec  17 msec
 4  10.4.5.5 [MPLS: Label 24005 Exp 0] 20 msec  38 msec
 5  10.5.6.6 25 msec  *
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 6
Sun Oct 11 16:03:53.034 UTC

Type escape sequence to abort.
Tracing the route to 192.168.2.1

 1  10.1.2.2 8 msec  6 msec
 2  10.2.3.3 [MPLS: Labels 24003/24005 Exp 0] 20 msec  16 msec
 3  10.3.4.4 [MPLS: Labels 24003/24005 Exp 0] 16 msec  16 msec
 4  10.4.5.5 [MPLS: Label 24005 Exp 0] 15 msec  27 msec
 5  10.5.6.6 19 msec  *

トランスポートラベル24003（5.5.5.5/32行き）とVPNラベル24005の2段スタックで、P2でPHPによりトランスポートラベルが外れる、という動きが保たれています。

STEPLIBのプレフィックス数（P1）PE1がP1から受け取ったラベル数CE1 → CE2のping
077100%（50/50）
144100%（50/50）
241100%（50/50）
344100%（50/50）
444100%（50/50）
541100%（50/50）
677100%（50/50）
744100%（50/50）
841100%（50/50）
944100%（50/50）
1044100%（50/50）
1177100%（50/50）

ラベルを4割減らしても、転送は1パケットも落ちません。

STEP 2：配るときに止める（label advertise）

P1がPE1にだけ配る中身を5.5.5.5/32に絞ります。P2向けは触りません。

STEP 2 P1にcommitした設定
ipv4 access-list LDP-PE2-ONLY
 10 permit ipv4 host 5.5.5.5 any
!
mpls ldp
 address-family ipv4
  label
   local
    advertise
     to 2.2.2.2:0 for LDP-PE2-ONLY
    !
   !
  !
 !
!

同じP1を相手にしていても、PE1が受け取るラベルは1本、P2は4本のままです。Labelsの列にそれが出ます。

STEP 2 PE1 show mpls ldp neighbor brief
RP/0/RP0/CPU0:PE1#show mpls ldp neighbor brief
Sun Oct 11 16:10:54.641 UTC

Peer               GR  NSR  Up Time     Discovery   Addresses     Labels
                                        ipv4  ipv6  ipv4  ipv6  ipv4   ipv6
-----------------  --  ---  ----------  ----------  ----------  ------------
3.3.3.3:0          N   N    00:22:36    1     0     3     0     1      0
STEP 2 P2 show mpls ldp neighbor brief
RP/0/RP0/CPU0:P2#show mpls ldp neighbor brief
Sun Oct 11 16:12:56.915 UTC

Peer               GR  NSR  Up Time     Discovery   Addresses     Labels
                                        ipv4  ipv6  ipv4  ipv6  ipv4   ipv6
-----------------  --  ---  ----------  ----------  ----------  ------------
3.3.3.3:0          N   N    00:24:40    1     0     3     0     4      0
5.5.5.5:0          N   N    00:24:28    1     0     2     0     4      0

設定を入れた瞬間、P1はPE1へLabel Withdrawalを3つ送っています。このSTEPのキャプチャーでP1が送ったラベルのメッセージは、この1パケットだけです。

STEP 2 No.8 Label Withdrawal ×3（P1 → PE1）
$ tshark -r - -Y 'frame.number==8' -T fields -E header=y \
    -e ip.src -e ldp.msg.type -e ldp.msg.tlv.fec.pfval -e ldp.msg.tlv.generic.label \
    < mpls-ldp-filtering-step2-pe1p1.pcap
ip.src	ldp.msg.type	ldp.msg.tlv.fec.pfval	ldp.msg.tlv.generic.label
3.3.3.3	0x0402,0x0402,0x0402	3.3.3.3,2.2.2.2,4.4.4.4	3,24000,24001
上のtshark出力のパケット（No.8 Label Withdrawal）のpcapをダウンロード

PE1が持たなくなったのは、P1が送るのをやめたからです。

STEP 5：受け取るときに止める（label remote accept）

今度はPE1側で、受け取るラベルを絞ります。P1に広告のフィルタはありません（STEP 3で外したままです）。

STEP 5 PE1にcommitした設定
ipv4 access-list LDP-PE2-ONLY
 10 permit ipv4 host 5.5.5.5 any
!
mpls ldp
 address-family ipv4
  label
   remote
    accept
     from 3.3.3.3:0 for LDP-PE2-ONLY
    !
   !
  !
 !
!

PE1から見た結果は、STEP 2と区別が付きません。許可していない3本はNo remote bindingsで、リモートバインディングとして残っていません。

STEP 5 PE1 show mpls ldp bindings
RP/0/RP0/CPU0:PE1#show mpls ldp bindings
Sun Oct 11 16:30:12.897 UTC

2.2.2.2/32, rev 2
	Local binding: label: ImpNull
	No remote bindings
3.3.3.3/32, rev 7
	Local binding: label: 24000
	No remote bindings
4.4.4.4/32, rev 11
	Local binding: label: 24002
	No remote bindings
5.5.5.5/32, rev 14
	Local binding: label: 24004
	Remote bindings: (1 peers)
	    Peer                Label
	    -----------------   ---------
	    3.3.3.3:0           24003

違いが出るのは線路の上です。PE1はフィルタを入れた直後に、持っていた分を捨てたうえで「もう一度全部送ってほしい」と要求し（この要求の中身は後の節で見ます）、P1はそれに応えて4本すべてのLabel Mappingを送ります。PE1はそれを受け取ってから、許可していない3本を捨てています。

STEP 5 No.50 Label Mapping ×4（P1 → PE1）
$ tshark -r - -Y 'frame.number==50' -T fields -E header=y \
    -e ip.src -e ldp.msg.type -e ldp.msg.tlv.fec.pfval -e ldp.msg.tlv.generic.label \
    < mpls-ldp-filtering-step5-pe1p1.pcap
ip.src	ldp.msg.type	ldp.msg.tlv.fec.pfval	ldp.msg.tlv.generic.label
3.3.3.3	0x0400,0x0400,0x0400,0x0400	3.3.3.3,2.2.2.2,4.4.4.4,5.5.5.5	3,24000,24001,24003
上のtshark出力のパケット（No.50 Label Mapping）のpcapをダウンロード

showの数字は同じでも、帯域とメッセージ処理は節約できていません。 相手の設定を変えられる立場ならadvertise側で止めるほうが有利です。

どちらで止めるかLDPメッセージ使いどころ
advertise（送信側）流れない自分が広告する側を管理できるとき
remote accept（受信側）流れる（捨てるだけ）相手の設定に期待できないとき、受ける側だけで決めたいとき

フィルタを緩めたときに動くのはどちらか

前半で述べたとおり、緩めたときに動くルータは制御点によって違います。どちらの場合も、その前提としてセッション確立時にTyped Wildcard FEC Capabilityを交換しています。Initializationメッセージに0x050BのTLVが入っており、同じメッセージで広告の方式がDownstream Unsolicitedであることも決まっています。

STEP 10 No.26 Initialization（PE1 → P1、tshark -V 抜粋）
        Common Session Parameters
            00.. .... = TLV Unknown bits: Known TLV, do not Forward (0x0)
            TLV Type: Common Session Parameters (0x500)
            TLV Length: 14
            Parameters
                Session Protocol Version: 1
                Session KeepAlive Time: 180
                0... .... = Session Label Advertisement Discipline: Downstream Unsolicited proposed
                .0.. .... = Session Loop Detection: Loop Detection Disabled
                Session Path Vector Limit: 0
                Session Max PDU Length: 0
                Session Receiver LSR Identifier: 3.3.3.3
                Session Receiver Label Space Identifier: 0
        P2MP Capability Parameter
            10.. .... = TLV Unknown bits: Unknown TLV, do not Forward (0x2)
            TLV Type: P2MP Capability Parameter (0x508)
            TLV Length: 1
            TLV Value: 80
        MP2MP Capability Parameter
            10.. .... = TLV Unknown bits: Unknown TLV, do not Forward (0x2)
            TLV Type: MP2MP Capability Parameter (0x509)
            TLV Length: 1
            TLV Value: 80
        Typed Wildcard FEC Capability
            10.. .... = TLV Unknown bits: Unknown TLV, do not Forward (0x2)
            TLV Type: Typed Wildcard FEC Capability (0x50B)
上のtshark出力のパケット（No.26 Initialization）のpcapをダウンロード

送信側を緩めると、送信側が自分で配り直す

STEP 2で入れたadvertiseのフィルタを外します。セッションは張り直しません。

STEP 3 P1にcommitした設定
mpls ldp
 address-family ipv4
  label
   local
    advertise
     no to 2.2.2.2:0 for LDP-PE2-ONLY
    !
   !
  !
 !
!

P1はこの直後に、取り下げた3本のLabel Mappingを自分から送り直しています。PE1は何も要求していません。

STEP 3 No.8 Label Mapping ×3（P1 → PE1）
$ tshark -r - -Y 'frame.number==8' -T fields -E header=y \
    -e ip.src -e ldp.msg.type -e ldp.msg.tlv.fec.pfval -e ldp.msg.tlv.generic.label \
    < mpls-ldp-filtering-step3-pe1p1.pcap
ip.src	ldp.msg.type	ldp.msg.tlv.fec.pfval	ldp.msg.tlv.generic.label
3.3.3.3	0x0400,0x0400,0x0400	3.3.3.3,2.2.2.2,4.4.4.4	3,24000,24001
上のtshark出力のパケット（No.8 Label Mapping）のpcapをダウンロード

受信側を緩めると、受信側が相手に要求する

STEP 8で入れ直したremote acceptのフィルタを外します。こちらもセッションは張り直しません。

STEP 9 PE1にcommitした設定
mpls ldp
 address-family ipv4
  label
   remote
    accept
     no from 3.3.3.3:0 for LDP-PE2-ONLY
    !
   !
  !
 !
!

PE1はLabel Requestを送ります。tsharkはこのFEC要素を解析できずError in FEC Element 1と表示しますが、メッセージ種別はLabel Request Message（0x401）です。

STEP 9 No.47 Label Request（PE1 → P1、tshark -V 抜粋）
    Label Request Message
        0... .... = U bit: Unknown bit not set
        Message Type: Label Request Message (0x401)
        Message Length: 13
        Message ID: 0x00000075
        FEC
            00.. .... = TLV Unknown bits: Known TLV, do not Forward (0x0)
            TLV Type: FEC (0x100)
            TLV Length: 5
            FEC Elements
                Error in FEC Element 1
                    [Expert Info (Error/Protocol): Error in FEC Element 1]
                        [Error in FEC Element 1]
                        [Severity level: Error]
                        [Group: Protocol]

FEC TLVの中身をバイト列で見ると、RFC 5918の3節・6節の形に一致します。05がTyped Wildcard、02がPrefix FEC、02が続く情報の長さ（ここまで各1バイト）、00 01がアドレスファミリのIPv4です。

STEP 9 No.47 のバイト列（tshark -x）
0000  52 54 00 23 17 21 52 54 00 94 4c 69 08 00 45 c0   RT.#.!RT..Li..E.
0010  00 4b bd 7e 00 00 ff 06 f3 64 02 02 02 02 03 03   .K.~.....d......
0020  03 03 02 86 f0 b1 66 ac 48 84 a5 de 10 2b 50 18   ......f.H....+P.
0030  3e ae 81 cf 00 00 00 01 00 1f 02 02 02 02 00 00   >...............
0040  04 01 00 0d 00 00 00 75 01 00 00 05 05 02 02 00   .......u........
0050  01 02 01 00 04 00 00 00 76                        ........v
上のtshark出力のパケット（No.47 Label Request）のpcapをダウンロード

P1はこれに応えて、4本すべてのLabel Mappingを送り直しました。

STEP 9 No.49 Label Mapping ×4（P1 → PE1）
$ tshark -r - -Y 'frame.number==49' -T fields -E header=y \
    -e ip.src -e ldp.msg.type -e ldp.msg.tlv.fec.pfval -e ldp.msg.tlv.generic.label \
    < mpls-ldp-filtering-step9-pe1p1.pcap
ip.src	ldp.msg.type	ldp.msg.tlv.fec.pfval	ldp.msg.tlv.generic.label
3.3.3.3	0x0400,0x0400,0x0400,0x0400	3.3.3.3,2.2.2.2,4.4.4.4,5.5.5.5	3,24000,24001,24003
上のtshark出力のパケット（No.49 Label Mapping）のpcapをダウンロード

clearは要らなかった

STEP 4とSTEP 10ではclear mpls ldp neighborを打っていますが、どちらも打つ前からラベルは戻っていました。STEP 10の記録では、clearの直前のLabels ipv4が4で、Up Timeも41分を超えています（セッションは一度も切れていません）。

STEP 10 PE1 clear mpls ldp neighbor 3.3.3.3 の記録
RP/0/RP0/CPU0:PE1#show clock

Sun Oct 11 17:01:38.670 UTC
17:01:38.713 UTC Sun Oct 11 2026
RP/0/RP0/CPU0:PE1#show mpls ldp neighbor brief

Sun Oct 11 17:01:38.811 UTC

Peer               GR  NSR  Up Time     Discovery   Addresses     Labels
                                        ipv4  ipv6  ipv4  ipv6  ipv4   ipv6
-----------------  --  ---  ----------  ----------  ----------  ------------
3.3.3.3:0          N   N    00:41:22    1     0     3     0     4      0

RP/0/RP0/CPU0:PE1#clear mpls ldp neighbor 3.3.3.3

Sun Oct 11 17:01:38.950 UTC
RP/0/RP0/CPU0:PE1#show clock

Sun Oct 11 17:01:39.064 UTC
17:01:39.162 UTC Sun Oct 11 2026

STEP 11：撤去して元に戻る

すべてのアクセスリストとフィルタを外すと、LIBは7本に戻ります。

STEP 11 P1 show mpls ldp bindings summary
RP/0/RP0/CPU0:P1#show mpls ldp bindings summary
Sun Oct 11 17:14:00.432 UTC

LIB Summary:
  Total Prefix   : 7
  Revision No    : Current:32, Advertised:32
  Local Bindings : 7
      NULL    : 3 (implicit:3, explicit:0)
      Non-NULL: 4 (lowest:24000, highest:24003)
  Remote Bindings: 14

最終STEPのrunning-configは、STEP 0と一致します（6台とも差分なし。採取データを行の個数まで突き合わせて確認しています）。

設計上の注意

  • 絞る基準はBGPのネクストホップです。PEのLoopbackに加えて、RRやインターAS向けに他のPEから参照されるアドレスがあれば、それもアクセスリストに含めます。漏らすとそのPE宛のLSPだけが張れず、VPNが片方向で落ちます
  • allocateで絞ると、LIBそのものが小さくなります。 show mpls ldp bindings summaryのTotal Prefixも減ります。ラベルを作らなくなるだけで、経路は失いません。 絞ったプレフィックス宛のパケットは、ラベルを積まない素のIPとして転送されます
  • 受信側で絞ると、LDPのメッセージは流れたままです。 帯域とメッセージ処理を節約したいなら、送信側のadvertiseで止めます
  • 緩めるときに相手の実装を確認します。 Typed Wildcard FEC（RFC 5918）に対応していない装置が相手だと、受信側で緩めた分は要求できません。その場合はclear mpls ldp neighborでセッションを張り直します

検証Configおよびshow結果

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

ファイル内容
..._clear.txtそのSTEPでクリアしたカウンタの記録（clear counters interface / clear mpls forwarding counters）
..._ping.txtそのSTEPのping（50発、timeout 1秒）とtraceroute
..._show.txtshow version / show interface description / OSPF・LDP・MPLS転送の一式 / show running-config mpls ldpなど
..._log.txtそのSTEPの範囲だけに絞ったshow logging。各STEPの開始時にlogmsgでマーカーを入れ、その時刻をshow logging startに指定して取得したもの
..._run.txtそのSTEP時点のshow running-config（＝そのSTEPの検証Config）
..._trace.txtshow mpls ldp trace binding / peer / show mpls lsd trace（コア4台のみ）
..._commit.cfgそのSTEPで実際にcommitした設定だけ。 設定を変えたルータの分のみ
..._reset.txtclear mpls ldp neighborの記録（STEP 4と10のみ）

STEP 0：初期状態

ルータクリアpingshow出力syslogrunning-configtrace
CE1clearpingshowlogrun—
PE1clearpingshowlogruntrace
P1clearpingshowlogruntrace
P2clearpingshowlogruntrace
PE2clearpingshowlogruntrace
CE2clearpingshowlogrun—

STEP 1：label allocateで/32だけに絞る（コア4台）

ルータクリアpingshow出力syslogrunning-configtrace投入した設定
CE1clearpingshowlogrun——
PE1clearpingshowlogruntracecommit
P1clearpingshowlogruntracecommit
P2clearpingshowlogruntracecommit
PE2clearpingshowlogruntracecommit
CE2clearpingshowlogrun——

STEP 2：label advertiseでP1がPE1へ配る中身を絞る

ルータクリアpingshow出力syslogrunning-configtrace投入した設定
CE1clearpingshowlogrun——
PE1clearpingshowlogruntrace—
P1clearpingshowlogruntracecommit
P2clearpingshowlogruntrace—
PE2clearpingshowlogruntrace—
CE2clearpingshowlogrun——

STEP 3：送信側のフィルタを外す（clearしない）

ルータクリアpingshow出力syslogrunning-configtrace投入した設定
CE1clearpingshowlogrun——
PE1clearpingshowlogruntrace—
P1clearpingshowlogruntracecommit
P2clearpingshowlogruntrace—
PE2clearpingshowlogruntrace—
CE2clearpingshowlogrun——

STEP 4：clear mpls ldp neighborでセッションを張り直す

ルータクリアpingshow出力syslogrunning-configtraceclearの記録
CE1clearpingshowlogrun——
PE1clearpingshowlogruntrace—
P1clearpingshowlogruntracereset
P2clearpingshowlogruntrace—
PE2clearpingshowlogruntrace—
CE2clearpingshowlogrun——

STEP 5：label remote acceptでPE1の受け取りを絞る

ルータクリアpingshow出力syslogrunning-configtrace投入した設定
CE1clearpingshowlogrun——
PE1clearpingshowlogruntracecommit
P1clearpingshowlogruntrace—
P2clearpingshowlogruntrace—
PE2clearpingshowlogruntrace—
CE2clearpingshowlogrun——

STEP 6：すべて撤去

ルータクリアpingshow出力syslogrunning-configtrace投入した設定
CE1clearpingshowlogrun——
PE1clearpingshowlogruntracecommit
P1clearpingshowlogruntracecommit
P2clearpingshowlogruntracecommit
PE2clearpingshowlogruntracecommit
CE2clearpingshowlogrun——

STEP 7：label allocateを入れ直す（コア4台）

ルータクリアpingshow出力syslogrunning-configtrace投入した設定
CE1clearpingshowlogrun——
PE1clearpingshowlogruntracecommit
P1clearpingshowlogruntracecommit
P2clearpingshowlogruntracecommit
PE2clearpingshowlogruntracecommit
CE2clearpingshowlogrun——

STEP 8：label remote acceptを入れ直す（PE1）

ルータクリアpingshow出力syslogrunning-configtrace投入した設定
CE1clearpingshowlogrun——
PE1clearpingshowlogruntracecommit
P1clearpingshowlogruntrace—
P2clearpingshowlogruntrace—
PE2clearpingshowlogruntrace—
CE2clearpingshowlogrun——

STEP 9：受信側のフィルタを外す（clearしない）

ルータクリアpingshow出力syslogrunning-configtrace投入した設定
CE1clearpingshowlogrun——
PE1clearpingshowlogruntracecommit
P1clearpingshowlogruntrace—
P2clearpingshowlogruntrace—
PE2clearpingshowlogruntrace—
CE2clearpingshowlogrun——

STEP 10：clear mpls ldp neighborでセッションを張り直す

ルータクリアpingshow出力syslogrunning-configtraceclearの記録
CE1clearpingshowlogrun——
PE1clearpingshowlogruntracereset
P1clearpingshowlogruntrace—
P2clearpingshowlogruntrace—
PE2clearpingshowlogruntrace—
CE2clearpingshowlogrun——

STEP 11：すべて撤去（最終状態）

ルータクリアpingshow出力syslogrunning-configtrace投入した設定
CE1clearpingshowlogrun——
PE1clearpingshowlogruntracecommit
P1clearpingshowlogruntracecommit
P2clearpingshowlogruntracecommit
PE2clearpingshowlogruntracecommit
CE2clearpingshowlogrun——

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

STEPPE1 - P1間P1 - P2間
0pcappcap
1pcappcap
2pcappcap
3pcappcap
4pcappcap
5pcappcap
6pcappcap
7pcappcap
8pcappcap
9pcappcap
10pcappcap
11pcappcap

参考

出典参照した箇所
RFC 5036 LDP Specification2.6.3節（Downstream Unsolicited / on Demand）、3.5.8節（Label Request Message）。ラベル広告のフィルタはRFCに規定が無いことの確認
RFC 5918 LDP ‘Typed Wildcard’ FEC3節（Typed Wildcard FEC要素の形式）、4節（Label Requestで受けたときの解釈）、5節（Capability TLV 0x050B）、6節（Prefix FEC用の形式）
IOS XR MPLS Configuration Guidelabel allocate / label advertise / label remote acceptの構文

検証はXRd 26.1.1（Cisco Modeling Labs）で実施しました。