[ Juniper ] inet.3 路由表到底是做什么的？

这篇文章我们来简单的聊一下 Juniper 路由器的 inet.3 路由表的作用，以及实际生产环境对 inet.3 路由表的操作与处理。

快速开始：Juniper 常用的路由表有哪些？

首先我们来看一下 Juniper 官方对于 JunOS 的路由表的解释，这里摘取部分有关的条目来翻译：

inet.0—“普通” IPv4 路由表所使用。这个路由表用于存储 IPv4 本地/直连/静态/动态路由。
inet.3—用于基于 IPv4 的 MPLS. 该表存储 MPLS 标签转换路径（LSP）的出口地址、LSP名称和出接口名称。这张表的条目由 RSVP / LDP 等信令控制协议产生。
inet6.0—“普通” IPv6 路由表所使用。这个路由表用于存储 IPv6 本地/直连/静态/动态路由。
mpls.0—用于 MPLS 转发。当本机为中转路由器（P 路由器），则使用该表进行转发。

今天我们来简要讲述下 inet.0 与 inet.3 的关系。

如上所述，你已经知道 inet.0 与 inet.3 是存储什么表用的了。inet.0 这张路由表有点像 Cisco 或者 Huawei 的路由表，它是用于存储“普通”路由所使用的。不管是手工写的静态路由，还是从 OSPF / IS-IS 这种 IGP 路由协议，学习到的路由 IPv4 路由均存储在 inet.0 路由表内。

对于 BGP 协议来说，它所学习到的路由也进入 inet.0, 但是对于下一跳的处理有些略微不同。让我们来使用拓扑图来讲一下这个知识点吧！

这张拓扑中，vMX-1 与 vMX-2 使用 lo0.0 作为更新源建立了 IPv4 Unicast 邻居，且两台 vMX 路由器均宣告了自己客户的 IP 段。我们都知道 BGP 传递给邻居的路由条目里，下一跳是自己的更新源，所以发给邻居的路由下一跳为自己的 lo0.0 接口的 IP 地址。由于下一跳是对方路由器的 lo0.0 接口地址，所以对于 vMX-1 路由器来说，这就需要进行二次查找（迭代路由查询），来查询真正的下一跳。

让我们来看一下 vMX-1 收到的 BGP 路由：

root@vMX-1> show route table inet.0 192.0.1.0/24 extensive

inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
192.0.1.0/24 (1 entry, 1 announced)
TSI:
KRT in-kernel 192.0.1.0/24 -> {indirect(1048574)}
        *BGP    Preference: 170/-101
                Next hop type: Indirect
                Address: 0x940f9d0
                Next-hop reference count: 3
                Source: 10.0.0.3
                Next hop type: Router, Next hop index: 569
                Next hop: 172.16.0.2 via ge-0/0/0.0, selected
                Session Id: 0x1
                Protocol next hop: 10.0.0.3
             ...

root@vMX-1> show route table inet.0 192.0.1.0/24

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

192.0.1.0/24       *[BGP/170] 02:20:53, localpref 100, from 10.0.0.3
                      AS path: I, validation-state: unverified
                    > to 172.16.0.2 via ge-0/0/0.0

非常好，BGP 已经成功收到了路由。根据输出所示，BGP 收到路由后，Protocol next-hop 显示了是对方的更新源，但由于该下一跳是非直连，所以 BGP 需要继续在路由表中做迭代查询。经过查询后成功解析 10.0.0.3 的真正下一跳为 172.16.0.2，出接口为 ge-0/0/0.0，所以在路由表中显示的下一跳为 172.16.0.2 这个地址，并将数据包发送给下一跳。

哦，但是请等等——我们只在 vMX-1 和 vMX-3 之间建立了 iBGP 连接，vMX-2 并没有任何路由，因为 vMX-2 没有和任何设备建立 BGP 邻居！想一想，在这种情况下会发生什么？数据包会怎么转发？让我们来梳理下整个流程：

1. BGP 收到该目的地址路由，发现协议中下一跳为 10.0.0.3
2. 由于 10.0.0.3 是非直连路由，所以会去查询 10.0.0.3 的真正下一跳
3. 得知 10.0.0.3 下一跳为 ge-0/0/0.0 出接口，下一跳地址为 172.16.0.2，BGP 解析实际下一跳为这个地址
4. 路由器将数据包发给 172.16.0.2，数据包到达 vMX-2
5. vMX-2 查询路由表，发现路由表里面是没有 vMX-3 的客户网段路由的。由于没有路由，数据包也就没了

我们可以发现，由于 vMX-2 没有路由所以导致数据包被丢弃。这就是典型的“路由黑洞问题”，中间骨干网路由器没有客户的地址所以导致通信中断。像这种问题，我们一般有以下几个方案：

iBGP full mesh
MPLS
GRE
VxLAN, etc…

其中因为 MPLS 部署简便，功能多而受到很多运营商青睐。所以，我们接下来要为所有路由器的骨干网侧开启 MPLS 协议。但在做这件事之前，我们需要先了解下 Juniper 设备的 inet.3 路由表。

新的挑战：inet.3 路由表是什么？

在配置 MPLS + LDP 协议之前，我们需要先了解一下 inet.3 路由表。

在 MPLS 网络内，如果一台路由器是一个 LSP 的入口（你可以把 LSP 理解成一个 Tunnel），那么你可以在 JunOS 的 inet.3 路由表里面找到对方出口的路由。请注意，上面我曾说过，inet.3 路由表是由 LDP/RSVP 等信令控制协议产生的，所以条目内的协议必定为 LDP/RSVP 等信令控制协议，而不是 OSPF/ISIS 等传统 IGP 协议。

说了那么多，我们来看一下 inet.3 路由表的条目。在 LDP 的基础之上我还创建了 RSVP 为基础的 MPLS-TE 隧道。配置 RSVP 隧道邻居也很简单，就以下几句话：

root@vMX-1# show protocols rsvp
interface ge-0/0/0.0; // 内网互联接口

[edit]
root@vMX-1# show protocols mpls
label-switched-path to-r3 { // 手工定义的 MPLS PATH
    to 10.0.0.3;
    ldp-tunneling;
}
interface ge-0/0/0.0;

root@vMX-1> show configuration protocols ospf
traffic-engineering;
area 0.0.0.0 {
    interface ge-0/0/0.0;
    interface lo0.0;
}

inet.3 路由表：

root@vMX-1> show route table inet.3

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

10.0.0.2/32        *[LDP/9] 14:15:00, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0
10.0.0.3/32        *[RSVP/7/1] 14:13:50, metric 2
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3
                    [LDP/9] 14:13:49, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3

我们发现到一个很有意思的事情：JunOS 只将它们的 loopback 接口通告了出来。事实上这就是 JunOS 的特性，LDP 协议在默认情况下只会通告 loopback LSP，而物理接口是不会去通告的。在这一点上，Huawei 设备与 Juniper 相同。但 Cisco 会通告物理接口和 lo 接口的 LSP，这是相对前两家设备所不同的点。

图中我还手动创建了一条 RSVP LSP，你可以发现它的优先级是比 LDP 要高的，所以下一跳去往 10.0.0.3 的流量会优先去寻找 TE LSP 进行转发。

其中，经过仔细的观察，10.0.0.2 这条条目并没有和 10.0.0.3 一样显示有 push label 或者 label-switched-path 等字样，是由于 10.0.0.2 这台路由器（vMX-2）是与 vMX-1 直连的，MPLS 有个特性为 PHP (Penultimate-Hop-Popping，倒数第二跳弹出标签) ，所以在这条路由上只看到了下一跳和出接口。但是如果你需要做 MPLS QoS 等业务，则 PHP 特性会导致标签被提前丢弃。针对这个问题，可以开启显式空标签来防止 QoS 失败，我们以后的文章会详细解释这个问题。

了解特性：inet.3 路由表的具体作用

JunOS 中，inet.3 路由表承担了一个很重要的作用：解析 BGP 下一跳。

在 JunOS 中，BGP 总是会优先去查询 inet.3 路由表，这和别的协议是不太一样的，别的协议默认情况下会去查询 inet.0 路由表，而 BGP 会优先查询 inet.3 路由表，若 inet.3 路由表没有所对应的路由，则会 fallback 到 inet.0 做查询。由于在核心网中，我们一般是用 lo 接口来作为 BGP 更新源，所以默认情况下，JunOS LDP 信令公告 lo 接口 IP 地址的 LSP，大多数情况下是够用了的。当然，这个默认行为也可以使用策略来进行更改。

而其他路由协议则有些不同——比如说 OSPF 协议，它并不需要 inet.3 的 LSP，因为它是通过直连获取路由的，并不需要去查询 inet.3 路由表，inet.0 已经可以满足其工作需要了。所以在默认情况下，只有 BGP 会去解析 inet.3 路由表，匹配到该表里面的条目后，压入标签，进行转发（解析 inet.3 的路由才会压入标签）。

接着上面的实验，当我们开启 MPLS + LDP 后，我们再来看一下 vMX-1 的路由表：

root@vMX-1> show route table inet.0 192.0.1.0/24

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

192.0.1.0/24       *[BGP/170] 18:31:51, localpref 100, from 10.0.0.3
                      AS path: I, validation-state: unverified
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3

可见路由表里面多出了一条 label-switched-path to-r3 ，这是我们写的一条 MPLS-TE 表项。我们再来梳理一下转发流程：

1. BGP 收到该目的地址路由，发现协议中下一跳为 10.0.0.3
2. 由于 10.0.0.3 是非直连路由，所以会去查询 10.0.0.3 的真正下一跳
3. 从 inet.3 路由表内得知 10.0.0.3 下一跳为 ge-0/0/0.0 出接口，下一跳地址为 172.16.0.2，BGP 解析实际下一跳为这个地址，并得到具体的压入标签信息（LSP path）后压入具体标签
4. 路由器将数据包发给 172.16.0.2，数据包到达 vMX-2
5. vMX-2 接收到该数据包，由于该数据包含有 MPLS header，则使用 mpls.0 表进行查询，查询对应的表项后，发现附带 Pop label 信息，执行 pop 动作后，发送给 vMX-3 （期间无需查询路由表）
6. vMX-3 收到 raw packet，查询路由表，发现是客户的路由且是直连接口，查询 ARP Table，发送给客户

回程数据包反之亦然。

由于使用了 LSP 进行了转发活动，所以 vMX-2 只需要查询 mpls.0 路由表即可完成转发，无需查询路由表，也就解决了路由黑洞的问题。事实上，很多运营商核心网内有很多的路由器是没有运行 BGP 协议的，它们只运行了 OSPF 或者 IS-IS 这类的 IGP 协议并开启了 MPLS 转发，这种情况很常见。如果是企业流量比较大，核心之间互联大带宽的话，其实可以用线速交换机来进行转发。因为交换机实际无需承载那么多的 Prefix，只需要参与计算 LSP 储存并转发即可，节省硬件的采购成本。

开始实验：联动 inet.3 与 inet.0

为了研究这个问题，我们来升级一下拓扑：

现在 vMX-3 连接了一台 External 路由器，该路由器宣告了其 lo0.0 接口地址，vMX-3 将其收到的条目宣告到了内网内。我们先在 vMX-1 上看一下该路由：

root@vMX-1> show route 192.168.192.168

root@vMX-1> show route 192.168.192.168 hidden extensive

inet.0: 13 destinations, 13 routes (12 active, 0 holddown, 1 hidden)
192.168.192.168/32 (1 entry, 0 announced)
         BGP    Preference: 170/-101
                Next hop type: Unusable
                Address: 0x9293e84
                Next-hop reference count: 3
                State: <Hidden Int Ext>
                Peer AS: 65000
                Age: 17:18:17
                Validation State: unverified
                Task: BGP_65000_65000.10.0.0.3+59929
                AS path: 65001 I
                Accepted
                Localpref: 100
                Router ID: 10.0.0.3
                Indirect next hops: 1
                        Protocol next hop: 100.64.1.2
                        Indirect next hop: 0x0 - INH Session ID: 0x0

结果发现 inet.0 路由表是没有该路由的，为什么？因为下一跳不可达，eBGP 传给 iBGP 路由，默认下一跳不改变。由于 BGP 没有在 inet.3 表内查到对应的 LSP，且在 inet.0 中查表未查询到对应的下一跳，所以导致路由不可用（unusable）。具体的查询过程如下：

1. vMX-1 查询下一跳，为 100.64.1.2
2. 在 inet.3 路由表中查询该下一跳，发现没有匹配的条目
3. 在 inet.0 路由表中查询该下一跳，也没有发现匹配的条目
4. 路由被隐藏

正所以下一跳不可用，所以有了大名鼎鼎的 “next-hop-self” 命令，但是我们假定 vMX-3 与 External 的互联链路，内网已经通过 OSPF / ISIS 协议学习到了（无论是 passive network 或者是 redistribute ），但是在 vMX-2 上依旧是没有路由的，所以我们需要流量使用 MPLS 的方式转发流量。

解决方案：在 inet.3 路由表中手动安装该下一跳，和 RSVP-LSP 安装在一起

root@vMX-1> show configuration protocols mpls
label-switched-path to-r3 {
    to 10.0.0.3;
    ldp-tunneling;
    install 100.64.1.2/32;
}
interface ge-0/0/0.0;

语法很简单，将该下一跳与 RSVP-LSP 绑定在一起，使用install 命令安装该 LSP. 然后我们来检查下路由表：

root@vMX-1> show route table inet.3

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

10.0.0.2/32        *[LDP/9] 20:10:48, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0
10.0.0.3/32        *[RSVP/7/1] 00:00:20, metric 2
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3
                    [LDP/9] 20:10:33, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3
100.64.1.2/32      *[RSVP/7/1] 00:00:20, metric 2
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3

root@vMX-1> show route table inet.0 192.168.192.168

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

192.168.192.168/32 *[BGP/170] 17:33:08, localpref 100, from 10.0.0.3
                      AS path: 65001 I, validation-state: unverified
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3

再检查连通性：

root@Normal-IP-Forwarding-Client-A:~# ping 192.168.192.168
PING 192.168.192.168 (192.168.192.168) 56(84) bytes of data.
64 bytes from 192.168.192.168: icmp_seq=1 ttl=61 time=10.4 ms
64 bytes from 192.168.192.168: icmp_seq=2 ttl=61 time=8.77 ms
--- 192.168.192.168 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 8.773/9.585/10.397/0.812 ms

优点：你可以通过静态 LSP 精确控制路由方向

缺点：它是静态写入的，扩展性较差，条目多后手工管理会很麻烦

如果你愿意的话，还可以把 OSPF LSA 和 LSP 捆绑在一起：

root@vMX-1# show protocols ospf | display set | grep label
set protocols ospf area 0.0.0.0 label-switched-path to-r3 metric 1

root@vMX-1# run show route table inet.0 protocol ospf

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

10.0.0.2/32        *[OSPF/10] 00:13:38, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0
10.0.0.3/32        *[OSPF/10] 00:13:38, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3
100.64.1.0/24      *[OSPF/10] 00:04:51, metric 2
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3
172.16.1.0/24      *[OSPF/10] 00:04:51, metric 2
                    > to 172.16.0.2 via ge-0/0/0.0
                      to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3
224.0.0.5/32       *[OSPF/10] 23:09:00, metric 1
                      MultiRecv

root@vMX-1# run show ospf neighbor
Address          Interface              State     ID               Pri  Dead
172.16.0.2       ge-0/0/0.0             Full      10.0.0.2         128    37
10.0.0.3         to-r3                  Full      10.0.0.3           0     0

OSPF 会将该链路是 vMX-1 和 vMX-3 的直连链路。如果你从双方向配置了 RSVP-LSP，则 OSPF 会使用该 LSP 建立邻居（本质上还是 Tunnel ）

研究：如何将所有经过vMX-3 的流量 ( 10.0.0.3 ) 都经过 LSP 转发？

现在 vMX-1 inet.3 有一条去往 10.0.0.3 的 LSP，意味着去往 BGP 收到的目的地址路由会经由 LSP 转发。如果需要将所有经过 10.0.0.3 的流量都走 LSP，则需要对 MPLS 设置一些参数。

在讲述这些方案前，我们需要先完成拓扑剩余的部分，将 VRF RED 连接起来。

root@vMX-1> show route table red.inet.0

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

192.1.0.0/24       *[Direct/0] 00:05:46
                    > via ge-0/0/5.0
192.1.0.1/32       *[Local/0] 00:05:46
                      Local via ge-0/0/5.0
192.1.1.0/24       *[BGP/170] 00:04:59, localpref 100, from 10.0.0.3
                      AS path: I, validation-state: unverified
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3

root@Client-L3VPN-RED-1:~# ping 192.1.1.2
PING 192.1.1.2 (192.1.1.2) 56(84) bytes of data.
64 bytes from 192.1.1.2: icmp_seq=1 ttl=61 time=7.02 ms
64 bytes from 192.1.1.2: icmp_seq=2 ttl=61 time=6.32 ms
--- 192.1.1.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 3ms
rtt min/avg/max/mdev = 6.324/6.673/7.022/0.349 ms

L3VPN 建立完成后，VRF RED 内的两台机器可以互通了。请注意——我们接下来使用的方法会影响到该业务。让我们继续往下看。

方案1：将 inet.3 路由表所有条目都移动到 inet.0

root@vMX-1# set protocols mpls traffic-engineering bgp-igp

root@vMX-1# run show route table inet.0

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

10.0.0.1/32        *[Direct/0] 1d 00:32:24
                    > via lo0.0
10.0.0.2/32        *[LDP/9] 00:02:03, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0
                    [OSPF/10] 01:37:06, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0
10.0.0.3/32        *[RSVP/7/1] 00:02:03, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3 (!!!caution!!!)
                    [LDP/9] 00:02:03, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3
                    [OSPF/10] 01:37:06, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3

root@vMX-1# run show route table inet.3

[edit]

可以看到 inet.3 路由已经被*移动*到 inet.0 了。但是请注意，表间移动的行为导致 inet.3 不再有 LSP （现在都跑去 inet.0 了），这会导致一个问题：所有的基于 MP-BGP + MPLS 的业务都会中断。我们现在来测试下 MPLS-VPN 客户的连通性：

root@localhost:~# ping 192.1.1.2
PING 192.1.1.2 (192.1.1.2) 56(84) bytes of data.
From 192.1.0.1 icmp_seq=1 Destination Net Unreachable
From 192.1.0.1 icmp_seq=2 Destination Net Unreachable
--- 192.1.1.2 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 2ms

由于 MP-BGP 业务都是查询 inet.3 表的（不查 inet.0 ），所以导致无法解析下一跳，进而引起业务中断。

优点：一句话即可让所有不在 VRF 里面的条目都会走 LSP 转发

缺点：这样做会破坏 MPLS-VPN 业务

方案2：将 inet.3 路由表所有条目都复制到 inet.0

root@vMX-1# set protocols mpls traffic-engineering bgp-igp-both-ribs

[edit]

root@vMX-1# run show route table inet.0

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

10.0.0.1/32        *[Direct/0] 1d 00:41:02
                    > via lo0.0
10.0.0.2/32        *[LDP/9] 00:00:15, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0
                    [OSPF/10] 01:45:44, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0
10.0.0.3/32        *[RSVP/7/1] 00:00:15, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3
                    [LDP/9] 00:00:15, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3
                    [OSPF/10] 01:45:44, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3

root@vMX-1# run show route table inet.3

inet.3: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
  {snip..}

OK，现在已经看到 inet.3 路由表恢复了，而且 MPLS-VPN 客户业务正常。但是这个办法并不是最好的，因为 inet.0 里面最优的表项是 RSVP / LDP，而不是 IGP 协议，这会严重影响路由分发，且会导致路由策略被破坏。

优点：可以保证实现非 VRF 路由使用 LSP 进行转发的同时，保证 MPLS-VPN 业务不会中断

缺点：会破坏路由策略，影响 IGP 路由分发

方案3：使用 IGP 来进行路由通告，但使用 LSP 进行转发

root@vMX-1# set protocols mpls traffic-engineering mpls-forwarding

root@vMX-1# run show route table inet.3 10.0.0.3

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

10.0.0.3/32        *[RSVP/7/1] 00:24:25, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3
                    [LDP/9] 00:01:37, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3

[edit]
root@vMX-1# run show route table inet.0 10.0.0.3

inet.0: 13 destinations, 16 routes (13 active, 1 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both

10.0.0.3/32        @[OSPF/10] 02:09:58, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3
                   #[RSVP/7/1] 00:24:29, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3
                    [LDP/9] 00:01:41, metric 1
                    > to 172.16.0.2 via ge-0/0/0.0, label-switched-path to-r3

看起来很不错，既不影响 IGP 选路，也不会影响 MP-BGP 的业务。但是你要知道这个依旧是不完美的，你只能决定是全复制或者不复制。在大的 ISP 骨干网里面你肯定不会想去这么做，因为你无法去精细的控制使用 LSP 进行转发的路由条目。

优点：在保证基于 MP-BGP 业务正常运行与 IGP 路由选路正常的同时，实现非 VRF 路由条目使用 LSP 进行转发

缺点：你无法精细控制想要用 LSP 转发的流量

总而言之，没有任何方案是完美的，你需要根据你实际环境来进行方案的选择。

总结：

inet.3 默认情况下只有 BGP 会用且优先使用，如果开启了MPLS，默认情况下在 inet.3 里面查询到的下一跳会被压上最优标签。
在 inet.3 查不到的路由，会 fallback 到 inet.0 进行查询，如果有默认路由或者详细路由，数据包出去就不会被 push label
如果你在一台 LER 上写下一跳为对方 lo0.0 的静态路由，由于静态路由默认不查 inet.3 表且默认不做迭代解析，所以它无法装入 inet.0 ，需要加上 resolve 参数，让它查 inet.3 表并压入 label 后发出去
set protocols mpls traffic-engineering bgp-igp ——能让你 inet.0 路由走 LSP 但由于搬空了 inet.3 导致 MPLS-VPN 出问题
set protocols mpls traffic-engineering bgp-igp-both-ribs ——由于 LDP 取代了 IGP 的路由，会影响你的 IGP 选路决策甚至路由传递
set protocols mpls traffic-engineering mpls-forwarding ——还行但也有缺点，虽然不会影响 IGP 决策，但是会影响对流量转发的控制精度，在大型 ISP 网络里面影响尤其大

参考资料：

JUNOS ROUTERS: WHAT DOES THE INET.3 ROUTING TABLE ACTUALLY DO?

JunOS: MPLS Traffic Engineering Configuration

JunOS: traffic-engineering (Protocols MPLS)

JunOS: Configuring Junos OS Routing Tables

J unOS: LSP Routes