SDN開発エンジニアを目指した活動ブログ

〜SDNなオープンソース製品を実際に使って試してみる〜

vSRXを活用した、JUNOSのお勉強まとめ【mpBGP / MPLS-VPN編】

今回も、引き続き、JUNOSのお勉強メモです。
ttsubo.hatenablog.com

◼︎ 前回の記事での技術課題

エンド端末間での疎通確認において、エンド端末"pc1"から、エンド端末"pc2"側"10.0.0.1"に対して、pingをうってみたところ、
pingは成功した。この時、pc2側でパケットキャプチャを行ったところ、ICMP Echo Request / Replyが観測されなかった。
「誰がICMP Echo Replyを送信したのだろうか?」というものでした。

まず、こちらのトポロジ構成をご覧ください。
BGP運用経験の豊富な方は、すでに発生事象の原因にお気づきだと思います。

                     [ AS: 65000 ]                                       [ AS: 65000 ]

                       10.0.0.1                   10.0.0.2                  10.0.0.3
                      +---------+                +--------+                +---------+                                   
                      |         |                |        |                |         |
                      | vSRX-1  |                | vSRX-2 |                | vSRX-3  |
+-----+ 172.16.0.0/30 | +-----+ | 192.168.0.0/30 |        | 192.168.1.0/30 | +-----+ | 172.16.1.0/30 +-----+ 10.0.0.1/24
| pc1 +-----------------+ GRT +----------------+ |        | +----------------+ GRT +-----------------+ pc2 | 10.0.1.1/24
+-----+ .1         .2 | +-----+ | .1          .2 |        | .1          .2 | +-----+ | .1        .2  +-----+ 10.0.2.1/24
                      |         |                |        |                |         |
                      +---------+                +--------+                +---------+

      :               :         :                :        :                :         :               :
      : < --------- > :         : < ---------- > :        : < ---------- > :         : < --------- > :
           static               :    LDP(ospf)                 LDP(ospf)   :               static
                                :                                          :
                                :                                          :
                                : < ------------------------------------ > :
                                                    iBGP

vSRX-1側での追跡調査
まず、vSRX-1で保持しているルーティング情報を確認してみましょう。

root@vSRX-1> show route table inet.0    

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.0/24        *[BGP/170] 03:08:48, localpref 100, from 10.0.0.3
                      AS path: I, validation-state: unverified
                    > to 192.168.0.2 via ge-0/0/1.0, Push 299792
10.0.0.1/32        *[Direct/0] 07:51:02
                    > via lo0.0
10.0.0.2/32        *[OSPF/10] 04:12:50, metric 1
                    > to 192.168.0.2 via ge-0/0/1.0
10.0.0.3/32        *[OSPF/10] 04:12:50, metric 2
                    > to 192.168.0.2 via ge-0/0/1.0
10.0.1.0/24        *[BGP/170] 03:08:48, localpref 100, from 10.0.0.3
                      AS path: I, validation-state: unverified
                    > to 192.168.0.2 via ge-0/0/1.0, Push 299792
10.0.2.0/24        *[BGP/170] 03:08:48, localpref 100, from 10.0.0.3
                      AS path: I, validation-state: unverified
                    > to 192.168.0.2 via ge-0/0/1.0, Push 299792
172.16.0.0/30      *[Direct/0] 06:30:00
                    > via ge-0/0/0.0
172.16.0.2/32      *[Local/0] 06:30:00
                      Local via ge-0/0/0.0
172.16.1.0/30      *[BGP/170] 03:25:48, localpref 100, from 10.0.0.3
                      AS path: I, validation-state: unverified
                    > to 192.168.0.2 via ge-0/0/1.0, Push 299792
192.168.0.0/30     *[Direct/0] 06:32:29
                    > via ge-0/0/1.0
192.168.0.1/32     *[Local/0] 06:32:29
                      Local via ge-0/0/1.0
192.168.1.0/30     *[OSPF/10] 04:12:50, metric 2
                    > to 192.168.0.2 via ge-0/0/1.0
224.0.0.5/32       *[OSPF/10] 04:13:05, metric 1
                      MultiRecv

はい、お察しの通りでしたね。
vSRXでのルーティング情報は、グローバルルーティングテーブル(GRT)で全て保持することになります。
このGRTでは、OSPF, BGPなどのルーティングプロトコルで学習したルーティング情報に加えて、スタティック経路や、ダイレクト接続された経路も保持することになります。
そして、vSRX-1では、pc1から10.0.0.1”宛のIPパケットを受信した際には、このGRTをルックアップして、次の転送先が決定されますが、この場合だと、ループバックインタフェースが選定されます。
最終的に、vSRX-1のルップバックインタフェースが、ICMP Echo Replyを送信することになります。
これが、前回記事での技術課題の発生原因です。

課題解決を目指して ... mpBGP/ MPLS-VPM化
そもそも、エンド端末を使う人の立場から述べると、
「エンド端末"pc1", "pc2"間で通信できればよくて、vSRX側で構成されるバックボーンネットワークと通信したいわけではない。」
と主張されるのでしょう。

この技術課題を解決する手段として、mpBGP / MPLS-VPN適用が有望だと思います。
そこで、今回のJUNOSのお勉強の素材として、mpBGP / MPLS-VPN対応に着手してみます。

◼︎ vSRXトポロジ構成

前回と同様のトポロジ構成になっています。このトポロジ構成の特徴は、mpBGP / MPLS-VPN対応です。
従って、GRT / VRFの関係がわかりやすいよう記載しました。

                     [ AS: 65000 ]                                       [ AS: 65000 ]

                       10.0.0.1                   10.0.0.2                  10.0.0.3
                      +---------+                +--------+                +---------+                                   
                      |         |                |        |                |         |                      
                      | vSRX-1  |                | vSRX-2 |                | vSRX-3  |
                      | +-----+ | 192.168.0.0/30 |        | 192.168.1.0/30 | +-----+ |
                      | | GRT +----------------+ |        | +----------------+ GRT | | 
                      | +--+--+ | .1          .2 |        | .1          .2 | +--+--+ |
                      |    |    |                |        |                |    |    |
+-----+ 172.16.0.0/30 | +--+--+ |                |        |                | +--+--+ | 172.16.1.0/30 +-----+ 10.0.0.1/24
| pc1 +-----------------+ VRF | |                |        |                | | VRF +-----------------+ pc2 | 10.0.1.1/24
+-----+ .1         .2 | +-----+ |                |        |                | +-----+ | .1        .2  +-----+ 10.0.2.1/24
                      +---------+                +--------+                +---------+

      :               :         :                :        :                :         :               :
      : < --------- > :         : < ---------- > :        : < ---------- > :         : < --------- > :
           static               :    LDP(ospf)                 LDP(ospf)   :               static
                                :                                          :
                                :                                          :
                                : < ------------------------------------ > :
                                                   mp-iBGP

ここでのポイントは、エンド端末を収容するvSRXルータは、ProviderEdge(PE)ルータの役割を担うということです。
なお、PEルータでは、GRT, VRFテーブルをおのおの保持しており、エンド端末との間で共有すべきルーティング情報は、VRFテーブルで保持することになります。
PEルータ間でのエンド端末に関わるBGP経路情報を共有する際には、GRTテーブルを介してmp-BGP UPDATEメッセージでやりとりが行われます。そして、最終的にVRFテーブルに保持されます。

◼︎ JUNOSルーティング設定

mpBGP / MPLS-VPNに関わる各種ルーティング設定を行います。

(0) 事前準備

前回の記事で設定したBGP関連のコンフィグ設定を、全て削除しておきます。
ただし、OSPF, LDPのコンフィグ設定は、前回のまま活用することとします。

root@vSRX-1# delete protocols bgp     
root@vSRX-1# delete policy-options 

[edit]
root@vSRX-1# show | compare 
[edit protocols]
-   bgp {
-       group INTERNAL {
-           type internal;
-           local-address 10.0.0.1;
-           export export-bgp;
-           neighbor 10.0.0.3;
-       }
-   }
[edit]
-  policy-options {
-      policy-statement export-bgp {
-          term 1 {
-              from {
-                  route-filter 172.16.0.0/30 exact;
-              }
-              then accept;
-          }
-      }
-  }

root@vSRX-1# commit 

vSRX-3では、スタティック経路の設定も削除しておきます。

root@vSRX-3# delete routing-options static

(1) mpBGP / MPLS-VPN基本設定

1. routing-instancesを設定する

root@vSRX-1# set routing-instances VPN-A instance-type vrf  
root@vSRX-1# set routing-instances VPN-A interface ge-0/0/0.0 
root@vSRX-1# set routing-instances VPN-A route-distinguisher 65000:101 
root@vSRX-1# set routing-instances VPN-A vrf-target target:65000:101
root@vSRX-1# show | compare                                            
[edit]
+  routing-instances {
+      VPN-A {
+          instance-type vrf;
+          interface ge-0/0/0.0;
+          route-distinguisher 65000:101;
+          vrf-target target:65000:101;
+      }
+  }

root@vSRX-1# commit

2. protocolsを設定する

root@vSRX-1# set protocols bgp group L3VPN type internal
root@vSRX-1# set protocols bgp group L3VPN local-address 10.0.0.1
root@vSRX-1# set protocols bgp group L3VPN neighbor 10.0.0.3
root@vSRX-1# set protocols bgp group L3VPN family inet-vpn unicast
root@vSRX-1# show | compare 
[edit protocols]
+   bgp {
+       group L3VPN {
+           type internal;
+           local-address 10.0.0.1;
+           family inet-vpn {
+               unicast;
+           }
+           neighbor 10.0.0.3;
+       }
+   }

root@vSRX-1# commit 

3. static routeを設定する
vSRX-3側では、pc2配下のスタティック経路をエントリしておく必要があります。

set routing-instances VPN-A routing-options static route 10.0.0.0/24 next-hop 172.16.1.2
set routing-instances VPN-A routing-options static route 10.0.1.0/24 next-hop 172.16.1.2
set routing-instances VPN-A routing-options static route 10.0.2.0/24 next-hop 172.16.1.2
root@vSRX-3# show | compare                                                                              
[edit routing-instances VPN-A routing-options static]
+      route 10.0.0.0/24 next-hop 172.16.1.2;
+      route 10.0.1.0/24 next-hop 172.16.1.2;
+      route 10.0.2.0/24 next-hop 172.16.1.2;

root@vSRX-3# commit

4. BGP Peerの状態を確認しておく

root@vSRX-1> show bgp neighbor 
Peer: 10.0.0.3+50824 AS 65000  Local: 10.0.0.1+179 AS 65000
  Type: Internal    State: Established    Flags: <Sync>
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  Last Error: None
  Options: <Preference LocalAddress AddressFamily Rib-group Refresh>
  Address families configured: inet-vpn-unicast
  Local Address: 10.0.0.1 Holdtime: 90 Preference: 170
  Number of flaps: 0
  Peer ID: 10.0.0.3        Local ID: 10.0.0.1          Active Holdtime: 90
  Keepalive Interval: 30         Group index: 0    Peer index: 0   
  BFD: disabled, down
  NLRI for restart configured on peer: inet-vpn-unicast
  NLRI advertised by peer: inet-vpn-unicast
  NLRI for this session: inet-vpn-unicast
  Peer supports Refresh capability (2)
  Stale routes from peer are kept for: 300
  Peer does not support Restarter functionality
  NLRI that restart is negotiated for: inet-vpn-unicast
  NLRI of received end-of-rib markers: inet-vpn-unicast
  NLRI of all end-of-rib markers sent: inet-vpn-unicast
  Peer supports 4 byte AS extension (peer-as 65000)
  Peer does not support Addpath
  Table bgp.l3vpn.0
    RIB State: BGP restart is complete
    RIB State: VPN restart is complete
    Send state: not advertising
    Active prefixes:              4
    Received prefixes:            4
    Accepted prefixes:            4
    Suppressed due to damping:    0
  Table VPN-A.inet.0 Bit: 20000
    RIB State: BGP restart is complete
    RIB State: VPN restart is complete
    Send state: in sync
    Active prefixes:              4
    Received prefixes:            4
    Accepted prefixes:            4
    Suppressed due to damping:    0
    Advertised prefixes:          1
  Last traffic (seconds): Received 16   Sent 22   Checked 32  
  Input messages:  Total 137    Updates 8       Refreshes 0     Octets 2973
  Output messages: Total 136    Updates 7       Refreshes 0     Octets 2913
  Output Queue[1]: 0            (VPN-A.inet.0, inet-vpn-unicast)

5. VPN-Aのアドバタイズ経路を確認しておく
通常のBGP設定と異なり、mpBGP/MPLS-VPN設定の場合は、vSRX-3ルータ側でExport policy適用せずとも、アドバタイズされるようです。
対向側(vSRX-3ルータ)からアドバタイズされた経路を受信できるようになりました。

root@vSRX-1> show route receive-protocol bgp 10.0.0.3 table bgp.l3vpn.0    

bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  65000:101:10.0.0.0/24                    
*                         10.0.0.3                     100        I
  65000:101:10.0.1.0/24                    
*                         10.0.0.3                     100        I
  65000:101:10.0.2.0/24                    
*                         10.0.0.3                     100        I
  65000:101:172.16.1.0/30                    
*                         10.0.0.3                     100        I

つづいて、対向側(vSRX-3ルータ)へのアドバイズを確認してみました。
しかしながら、"172.16.0.0/30"は、アドバタイズされていないようです。

root@vSRX-1> show route advertising-protocol bgp 10.0.0.3                  

VPN-A.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.0.0/30           Not advertised               100        I

ここでのトラブル解析として、各々のvSRXルータでのVRFテーブルの保持状態を確認してみます。
まずは、vSRX-1側から確認します。

root@vSRX-1> show route table VPN-A.inet.0                                 

VPN-A.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.0/24        *[BGP/170] 00:43:58, localpref 100, from 10.0.0.3
                      AS path: I, validation-state: unverified
                    > to 192.168.0.2 via ge-0/0/1.0, Push 299808, Push 299792(top)
10.0.1.0/24        *[BGP/170] 00:17:30, localpref 100, from 10.0.0.3
                      AS path: I, validation-state: unverified
                    > to 192.168.0.2 via ge-0/0/1.0, Push 299808, Push 299792(top)
10.0.2.0/24        *[BGP/170] 00:17:30, localpref 100, from 10.0.0.3
                      AS path: I, validation-state: unverified
                    > to 192.168.0.2 via ge-0/0/1.0, Push 299808, Push 299792(top)
172.16.0.0/30      *[Direct/0] 01:21:51
                    > via ge-0/0/0.0
172.16.0.2/32      *[Local/0] 01:21:51
                      Local via ge-0/0/0.0
172.16.1.0/30      *[BGP/170] 00:43:58, localpref 100, from 10.0.0.3
                      AS path: I, validation-state: unverified
                    > to 192.168.0.2 via ge-0/0/1.0, Push 299808, Push 299792(top)

問題なく、VRFテーブルは構築できているようです。

つづいて、vSRX-3側でも確認してみます。

root@vSRX-3> show route table VPN-A.inet.0    

VPN-A.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.0/24        *[Static/5] 00:46:45
                    > to 172.16.1.2 via ge-0/0/1.0
10.0.1.0/24        *[Static/5] 00:20:17
                    > to 172.16.1.2 via ge-0/0/1.0
10.0.2.0/24        *[Static/5] 00:20:17
                    > to 172.16.1.2 via ge-0/0/1.0
172.16.1.0/30      *[Direct/0] 01:12:49
                    > via ge-0/0/1.0
172.16.1.1/32      *[Local/0] 01:12:49
                      Local via ge-0/0/1.0

やはり、vSRX-1側でのダイレクト接続経路"172.16.0.0/30"が、VRFテーブルに保持されておりませんね。
どうやら、pc1側では、スタティック経路が存在しないので、next-hopに該当するダイレクト接続経路"172.16.0.0/30"を、敢えて、BGP経路としてアドバタイズしていないようです。

6. ダイレクト接続経路"172.16.0.0/30"を再配布するには、
CiscoIOSの"redistribute connected"コマンドのように、BGP経路に再配布する方法をいろいろ試行錯誤してみましたが、うまく行きません。そこで、不本意ながら、default-routeを再配布する方法で、問題回避を試みました。

root@vSRX-1# set routing-instances VPN-A routing-options static route 0.0.0.0/0 next-hop 172.16.0.1    

[edit]
root@vSRX-1# show | compare 
[edit routing-instances VPN-A]
+    routing-options {
+        static {
+            route 0.0.0.0/0 next-hop 172.16.0.1;
+        }
+    }

root@vSRX-1# commit 

とりあえず、vSRX-1側で、ダイレクト接続経路"172.16.0.0/30"をアドバタイズするようになりました。

root@vSRX-1> show route advertising-protocol bgp 10.0.0.3                  

VPN-A.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 0.0.0.0/0               Self                         100        I
* 172.16.0.0/30           Self                         100        I

改めて、vSRX-3側でのVRFテーブルの保持状態を確認してみます。

root@vSRX-3> show route table VPN-A.inet.0    

VPN-A.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[BGP/170] 00:03:03, localpref 100, from 10.0.0.1
                      AS path: I, validation-state: unverified
                    > to 192.168.1.1 via ge-0/0/0.0, Push 299824, Push 299776(top)
10.0.0.0/24        *[Static/5] 00:57:51
                    > to 172.16.1.2 via ge-0/0/1.0
10.0.1.0/24        *[Static/5] 00:31:23
                    > to 172.16.1.2 via ge-0/0/1.0
10.0.2.0/24        *[Static/5] 00:31:23
                    > to 172.16.1.2 via ge-0/0/1.0
172.16.0.0/30      *[BGP/170] 00:03:03, localpref 100, from 10.0.0.1
                      AS path: I, validation-state: unverified
                    > to 192.168.1.1 via ge-0/0/0.0, Push 299824, Push 299776(top)
172.16.1.0/30      *[Direct/0] 01:23:55
                    > via ge-0/0/1.0
172.16.1.1/32      *[Local/0] 01:23:55
                      Local via ge-0/0/1.0

今回は、問題なく、VRFテーブルは構築できているようです。

(2) エンド端末間での疎通確認

エンドエンド端末間でpingをうってみましょう。

1. "172.16.1.2"宛にpingをうってみる

tsubo@pc1:~$ ping 172.16.1.2
PING 172.16.1.2 (172.16.1.2) 56(84) bytes of data.
64 bytes from 172.16.1.2: icmp_seq=1 ttl=61 time=0.849 ms
64 bytes from 172.16.1.2: icmp_seq=2 ttl=61 time=0.905 ms
64 bytes from 172.16.1.2: icmp_seq=3 ttl=61 time=0.829 ms
64 bytes from 172.16.1.2: icmp_seq=4 ttl=61 time=0.759 ms
64 bytes from 172.16.1.2: icmp_seq=5 ttl=61 time=0.960 ms
^C
--- 172.16.1.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 0.759/0.860/0.960/0.073 ms

pingが成功しました!

この時、pc2側でtcpdumpを動作させて、パケットモニタリングしておきます。

root@pc2:~# tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
23:04:48.390124 IP 172.16.0.1 > 172.16.1.2: ICMP echo request, id 2594, seq 1, length 64
23:04:48.390160 IP 172.16.1.2 > 172.16.0.1: ICMP echo reply, id 2594, seq 1, length 64
23:04:49.390956 IP 172.16.0.1 > 172.16.1.2: ICMP echo request, id 2594, seq 2, length 64
23:04:49.390985 IP 172.16.1.2 > 172.16.0.1: ICMP echo reply, id 2594, seq 2, length 64
23:04:50.390871 IP 172.16.0.1 > 172.16.1.2: ICMP echo request, id 2594, seq 3, length 64
23:04:50.390901 IP 172.16.1.2 > 172.16.0.1: ICMP echo reply, id 2594, seq 3, length 64
23:04:51.390847 IP 172.16.0.1 > 172.16.1.2: ICMP echo request, id 2594, seq 4, length 64
23:04:51.390876 IP 172.16.1.2 > 172.16.0.1: ICMP echo reply, id 2594, seq 4, length 64
23:04:52.391451 IP 172.16.0.1 > 172.16.1.2: ICMP echo request, id 2594, seq 5, length 64
23:04:52.391480 IP 172.16.1.2 > 172.16.0.1: ICMP echo reply, id 2594, seq 5, length 64
23:04:53.393256 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28
23:04:53.394175 ARP, Reply 172.16.1.1 is-at 00:0c:29:70:81:a6 (oui Unknown), length 46
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

期待通り、ICMP Echo Request / Replyが観測できました。

2. "10.0.0.1"宛にpingをうってみる

tsubo@pc1:~$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=61 time=1.68 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=61 time=1.10 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=61 time=0.794 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=61 time=0.975 ms
64 bytes from 10.0.0.1: icmp_seq=5 ttl=61 time=0.763 ms
^C
--- 10.0.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 0.763/1.064/1.685/0.334 ms

こちらも、pingが成功しましたね!

この時、pc2側でtcpdumpを動作させて、パケットモニタリングしておきます。

root@pc2:~# tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
23:07:52.149141 IP 172.16.0.1 > 10.0.0.1: ICMP echo request, id 2595, seq 1, length 64
23:07:52.149182 IP 10.0.0.1 > 172.16.0.1: ICMP echo reply, id 2595, seq 1, length 64
23:07:53.150952 IP 172.16.0.1 > 10.0.0.1: ICMP echo request, id 2595, seq 2, length 64
23:07:53.150983 IP 10.0.0.1 > 172.16.0.1: ICMP echo reply, id 2595, seq 2, length 64
23:07:54.152578 IP 172.16.0.1 > 10.0.0.1: ICMP echo request, id 2595, seq 3, length 64
23:07:54.152607 IP 10.0.0.1 > 172.16.0.1: ICMP echo reply, id 2595, seq 3, length 64
23:07:55.151633 IP 172.16.0.1 > 10.0.0.1: ICMP echo request, id 2595, seq 4, length 64
23:07:55.151664 IP 10.0.0.1 > 172.16.0.1: ICMP echo reply, id 2595, seq 4, length 64
23:07:56.153395 IP 172.16.0.1 > 10.0.0.1: ICMP echo request, id 2595, seq 5, length 64
23:07:56.153424 IP 10.0.0.1 > 172.16.0.1: ICMP echo reply, id 2595, seq 5, length 64
23:07:57.152492 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28
23:07:57.153588 ARP, Reply 172.16.1.1 is-at 00:0c:29:70:81:a6 (oui Unknown), length 46
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

こちらも、期待通り、ICMP Echo Request / Replyが観測できましたね!
ただし、pc1拠点相当を、さらに追加する場合には、default-routeを再配布する方法は採用できません。
CiscoIOSの"redistribute connected"コマンド相当をサルベージする必要があるのかもしれません。

◼︎ 3/27追記「@kazubuさんから、回避策を教えてもらいました」

こちらが、Direct経路がBGPアドバタイズ経路に乗らない件の回避策になります。

Juniper Networks - BGP not advertising the directly connected network to the remote PE router in L3VPN - Knowledge Base

では、早速、試してみましょう。
1. 暫定的に設定しておいたdefault-routeの再配布の設定を削除する

root@vSRX-1# delete routing-instances VPN-A routing-options static
root@vSRX-1# commit

2. routing-instanceにvrf-table-labelを設定する

root@vSRX-1# set routing-instances VPN-A vrf-table-label    
root@vSRX-1# show | compare 
[edit routing-instances VPN-A]
+    vrf-table-label;

root@vSRX-1# commit

vSRX-1側で、ダイレクト接続経路"172.16.0.0/30"をアドバタイズされるようになりました。

root@vSRX-1> show route advertising-protocol bgp 10.0.0.3             

VPN-A.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 172.16.0.0/30           Self                         100        I

対向側(vSRX-3)でも、ダイレクト接続経路"172.16.0.0/30"が、受信できたことも確認できました。

root@vSRX-3> show route receive-protocol bgp 10.0.0.1 table bgp.l3vpn.0    

bgp.l3vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  65000:101:172.16.0.0/30                    
*                         10.0.0.1                     100        I

以下、個人的な所感です。
今まで、「VRFにて保持されるルーティング情報は、一律、BGP Peerにアドバタイズされる。」と理解しておりました。
ところが、通常のMPLSルータでは、「VRFにて保持されるルーティング情報は、next-hopが検出されるタイミングでVPNラベルが付与されるので、BGP Peerへのアドバタイズも可能になる」という仕様なんですね。
ダイレクト接続経路の場合だと、このままでは、next-hopが検出されないので、BGP Peerへのアドバタイズは行われない。
そこで、ダイレクト接続経路に対して、明示的にVPNラベルを付与する必要がある。
その方法は、JUNOSの場合だと、"vhf-table-label"を設定し、CiscoIOSの場合だと、"redistribute connected"を設定する。

ちょっとだけ、賢くなりました。これにて、一件落着という感じです。

◼︎ 最終的なコンフィグ内容の確認

1. vSRX-1側コンフィグ内容

root@vSRX-1> show configuration
... (snip)
routing-options {
    router-id 10.0.0.1;
    autonomous-system 65000;
}
protocols {
    mpls {
        interface ge-0/0/1.0;
    }
    bgp {
        group L3VPN {
            type internal;
            local-address 10.0.0.1;
            family inet-vpn {
                unicast;
            }
            neighbor 10.0.0.3;
        }
    }
    ospf {
        area 0.0.0.0 {
            interface ge-0/0/1.0;
            interface lo0.0 {
                passive;
            }
        }
    }
    ldp {
        interface ge-0/0/1.0;
    }
}
routing-instances {
    VPN-A {
        instance-type vrf;              
        interface ge-0/0/0.0;
        route-distinguisher 65000:101;
        vrf-target target:65000:101;
        vrf-table-label;
    }
}

2. vSRX-3側コンフィグ内容

root@vSRX-3> show configuration 
... (snip)
routing-options {
    router-id 10.0.0.3;
    autonomous-system 65000;
}
protocols {
    mpls {
        interface ge-0/0/0.0;
    }
    bgp {
        group L3VPN {
            type internal;
            local-address 10.0.0.3;
            family inet-vpn {
                unicast;
            }
            neighbor 10.0.0.1;
        }
    }
    ospf {
        area 0.0.0.0 {
            interface ge-0/0/0.0;
            interface lo0.0 {
                passive;
            }
        }
    }
    ldp {
        interface ge-0/0/0.0;
    }
}
routing-instances {
    VPN-A {
        instance-type vrf;              
        interface ge-0/0/1.0;
        route-distinguisher 65000:101;
        vrf-target target:65000:101;
        routing-options {
            static {
                route 10.0.0.0/24 next-hop 172.16.1.2;
                route 10.0.1.0/24 next-hop 172.16.1.2;
                route 10.0.2.0/24 next-hop 172.16.1.2;
            }
        }
    }
}

◼︎ 最後に

今回は、JUNOSによる、mpBGP / MPLS-VPNの基本動作を確認しました。
基本的なJUNOSコマンド操作感は、とてもわかりやすいと感じました。
以上です。