跳到主要内容

4. 通过 BGP 分发 VPN 路由

4. 通过 BGP 分发 VPN 路由 (VPN Route Distribution via BGP)​

PE routers 使用 BGP 相互分发 VPN routes (更准确地说, 促使 VPN routes 相互分发).

我们允许每个 VPN 拥有自己的 address space, 这意味着某个给定 address 在不同 VPN 中可以表示不同 systems. 如果到同一 IP address prefix 的两条 routes 实际上是到不同 systems 的 routes, 则必须确保 BGP 不把它们视为可比较的 routes. 否则, BGP 可能只选择安装其中一条, 使另一个 system 不可达. 此外, 我们必须确保使用 POLICY 来决定哪些 packets 走哪些 routes; 在 BGP 安装了若干这样的 routes 的情况下, 任何特定 VRF 中只能出现其中一条.

我们通过使用一个新的 address family 来满足这些目标, 如下所述.

4.1. VPN-IPv4 地址族 (VPN-IPv4 Address Family)​

BGP Multiprotocol Extensions [BGP-MP] 允许 BGP 携带来自多个 "address families" 的 routes. 我们引入 "VPN-IPv4 address family" 的概念. VPN-IPv4 address 是一个 12-byte 数量, 以 8-byte Route Distinguisher (RD) 开始, 以 4-byte IPv4 address 结束. 如果多个 VPNs 使用同一个 IPv4 address prefix, PEs 会将它们转换为唯一的 VPN-IPv4 address prefixes. 这确保了如果同一个 address 在多个不同 VPNs 中使用, BGP 可以为该 address 携带若干完全不同的 routes, 每个 VPN 一条.

由于 VPN-IPv4 addresses 和 IPv4 addresses 属于不同 address families, BGP 从不把它们视为可比较的 addresses.

RD 只是一个数字, 不包含任何内在信息; 它不标识 route 的来源, 也不标识该 route 要被分发到的 VPNs 集合. RD 的目的只是允许为一个公共 IPv4 address prefix 创建不同 routes. route 应重新分发到哪里由其他手段决定 (见 Section 4.3).

RD 还可用于为完全相同的 system 创建多条不同 routes. 我们已经讨论过一种情形, 即到某个特定 server 的 route 对 intranet traffic 和 extranet traffic 应该不同. 这可以通过创建两条具有相同 IPv4 部分但 RD 不同的 VPN-IPv4 routes 来实现. 这允许 BGP 安装到同一 system 的多条不同 routes, 并允许使用 policy (见 Section 4.3.5) 来决定哪些 packets 使用哪条 route.

RDs 被结构化, 使得每个 Service Provider 都能管理自己的 "numbering space" (即可以自行分配 RDs), 而不会与任何其他 Service Provider 所做的 RD 分配冲突. RD 由三个 fields 组成: 2-byte type field, administrator field, 以及 assigned number field. type field 的值决定另外两个 fields 的长度, 以及 administrator field 的语义. administrator field 标识一个 assigned number authority, assigned number field 包含由该已标识 authority 为某个特定目的分配的数字. 例如, 一个 RD 的 administrator field 可以包含 Autonomous System number (ASN), 其 (4-byte) number field 包含由该 ASN 所属 SP 分配的数字 (该 ASN 由适当 authority 分配给该 SP).

RDs 采用这种结构是为了确保提供 VPN backbone service 的 SP 在需要时总能创建唯一的 RD. 不过, 该结构对 BGP 没有意义; 当 BGP 比较两个这样的 address prefixes 时, 它完全忽略该结构.

PE 需要配置为使通向某个特定 CE 的 routes 与某个特定 RD 关联. 配置可以使所有通向同一 CE 的 routes 都与同一个 RD 关联, 也可以使不同 routes 与不同 RDs 关联, 即使它们通向同一 CE.

4.2. 路由区分符 (Route Distinguisher) 的编码 (Encoding of Route Distinguishers)​

如前所述, VPN-IPv4 address 由 8-byte Route Distinguisher 后跟 4-byte IPv4 address 组成. RDs 编码如下:

  • Type Field: 2 bytes
  • Value Field: 6 bytes

Value field 的解释取决于 type field 的值. 目前, type field 定义了三个值: 0, 1 和 2.

  • Type 0: Value field 由两个 subfields 组成:

    • Administrator subfield: 2 bytes
    • Assigned Number subfield: 4 bytes

    Administrator subfield 必须包含 Autonomous System number. 如果该 ASN 来自 public ASN space, 它必须已由适当 authority 分配 (强烈不建议使用 private ASN space 中的 ASN values). Assigned Number subfield 包含来自某个 numbering space 的数字, 该 numbering space 由已被适当 authority 分配该 ASN 的企业管理.

  • Type 1: Value field 由两个 subfields 组成:

    • Administrator subfield: 4 bytes
    • Assigned Number subfield: 2 bytes

    Administrator subfield 必须包含一个 IP address. 如果该 IP address 来自 public IP address space, 它必须已由适当 authority 分配 (强烈不建议使用 private IP address space 中的 addresses). Assigned Number subfield 包含来自某个 numbering space 的数字, 该 numbering space 由已被分配该 IP address 的企业管理.

  • Type 2: Value field 由两个 subfields 组成:

    • Administrator subfield: 4 bytes
    • Assigned Number subfield: 2 bytes

    Administrator subfield 必须包含一个 4-byte Autonomous System number [BGP-AS4]. 如果该 ASN 来自 public ASN space, 它必须已由适当 authority 分配 (强烈不建议使用 private ASN space 中的 ASN values). Assigned Number subfield 包含来自某个 numbering space 的数字, 该 numbering space 由已被适当 authority 分配该 ASN 的企业管理.

4.3. 控制路由分发 (Controlling Route Distribution)​

本节讨论如何控制 VPN-IPv4 routes 的分发.

如果 PE router 连接到某个特定 VPN (通过连接到该 VPN 中的某个特定 CE), 它会从所连接的 CE router 学到该 VPN 的一些 IP routes. 通过某个特定 attachment circuit 从 CE routing peer 学到的 routes 可以安装到与该 attachment circuit 关联的 VRF 中. 以这种方式安装哪些 routes, 由 PE 从 CE 学习 routes 的方式决定. 特别是, 当 PE 和 CE 是 routing protocol peers 时, 这由 routing protocol 的 decision process 决定; Section 7 会讨论这一点.

然后这些 routes 被转换为 VPN-IP4 routes, 并 "exported" 到 BGP. 如果到某个特定 VPN-IP4 address prefix 有多条 routes, BGP 使用 BGP decision process 选择 "best" 的一条. 然后 BGP 将该 route 分发给需要知道它的其他 PEs 集合. 在这些其他 PEs 上, BGP 会再次为某个特定 VPN-IP4 address prefix 选择最佳 route. 随后, 所选 VPN-IP4 routes 被转换回 IP routes, 并 "imported" 到一个或多个 VRFs 中. 它们是否实际安装到 VRFs 中, 取决于 PE 与那些关联到相关 VRF 的 CEs 之间所用 routing method 的 decision process. 最后, 安装在 VRF 中的任何 route 都可以分发给关联的 CE routers.

4.3.1. 路由目标属性 (Route Target Attribute)​

每个 VRF 都与一个或多个 Route Target (RT) attributes 关联.

当 PE router 创建 VPN-IPv4 route (来自 PE 从 CE 学到的一条 IPv4 route) 时, 它会与一个或多个 Route Target attributes 关联. 这些 attributes 作为 route 的 attributes 在 BGP 中携带.

任何与 Route Target T 关联的 route 都必须分发给每台拥有与 Route Target T 关联的 VRF 的 PE router. 当 PE router 接收到这样的 route 时, 它有资格被安装到该 PE 中那些与 Route Target T 关联的 VRFs 中. (它是否实际被安装, 取决于 BGP decision process 的结果, 以及运行在 PE/CE interface 上的 IGP (即 intra-domain routing protocol) 的 decision process 结果.)

Route Target attribute 可以被理解为标识一组 sites. (不过, 更精确地说, 应将其理解为标识一组 VRFs.) 将某个特定 Route Target attribute 与 route 关联, 允许该 route 被放入那些用于路由从对应 sites 接收的 traffic 的 VRFs.

PE router 附加到从 site S 接收的 route 上的一组 Route Targets 可称为 "Export Targets". PE router 用来判断从另一个 PE router 接收的 route 是否可放入与 site S 关联的 VRF 的一组 Route Targets 可称为 "Import Targets". 这两个集合是不同的, 且不必相同. 注意, 只有当某个 Route Target 既是 route 的 Route Targets 之一, 又是 VRF 的 Import Targets 之一时, 特定 VPN-IPv4 route 才有资格安装到特定 VRF 中.

Route Target attribute 执行的功能类似于 BGP Communities attribute. 然而, 后者的格式不适合当前目的, 因为它只允许 2-byte numbering space. 希望以类似我们为 RDs 描述的方式 (见 Section 4.2) 结构化格式, 使 type field 定义 administrator field 的长度, attribute 的其余部分则是来自指定 administrator 的 numbering space 的数字. 这可以使用 BGP Extended Communities 来完成. 本文讨论的 Route Targets 编码为 BGP Extended Community Route Targets [BGP-EXTCOMM]. 它们的结构与 RDs 类似.

当 BGP speaker 已收到多条到同一 VPN- IPv4 prefix 的 routes 时, 使用 BGP 的 route preference 规则选择由 BGP 安装哪条 VPN-IPv4 route.

注意, 一条 route 只能有一个 RD, 但可以有多个 Route Targets. 在 BGP 中, 与多条 routes 相比, 单条 route 携带多个 attributes 可改善可扩展性. 可以通过创建更多 routes (即使用更多 RDs) 来消除 Route Target attribute, 但其扩展特性会较差.

PE 如何决定把哪些 Route Target attributes 与给定 route 关联? 有许多不同可能方式. PE 可以被配置为将所有通向指定 site 的 routes 与指定 Route Target 关联. 或者, PE 可以被配置为将通向指定 site 的某些 routes 与一个 Route Target 关联, 将其他 routes 与另一个 Route Target 关联.

如果 PE 和 CE 本身是 BGP 对等体 (见 Section 7), 则 SP 可以允许客户在一定限制内指定其路由应如何分发. SP 和客户需要预先约定允许附加到客户 VPN 路由上的 RT 集合. 然后 CE 可以把这些 RT 中的一个或多个附加到其分发给 PE 的每条 IP 路由上. 这使客户能够在约定限制内实时指定自己的路由分发策略. 如果允许 CE 将 RT 附加到其路由上, PE 必须过滤掉包含客户不允许使用的 RT 的所有路由. 如果不允许 CE 将 RT 附加到其路由上, 但 CE 仍这样做, PE 必须在将客户的路由转换为 VPN-IPv4 路由之前移除该 RT.

4.3.2. PE 之间通过 BGP 分发路由 (Route Distribution Among PEs by BGP)​

如果某个 VPN 的两个 sites 连接到位于同一 Autonomous System 中的 PEs, 这些 PEs 可以通过它们之间的 IBGP connection 相互分发 VPN-IPv4 routes. ("IBGP" 一词指当同一 Autonomous System 中两个 BGP speakers 之间存在 BGP connection 时所使用的一组 protocols 和 procedures. 这不同于 "EBGP", 后者是在不同 Autonomous Systems 中两个 BGP speakers 之间使用的一组 procedures.) 或者, 每个 PE 都可以有一条到 route reflector [BGP-RR] 的 IBGP connection.

当 PE router 通过 BGP 分发 VPN-IPv4 route 时, 它使用自己的 address 作为 "BGP next hop". 该 address 被编码为 RD 为 0 的 VPN-IPv4 address. ([BGP-MP] 要求 next hop address 与 Network Layer Reachability Information (NLRI) 位于同一 address family.) 它还分配并分发一个 MPLS label. (本质上, PE routers 分发的不是 VPN-IPv4 routes, 而是 Labeled VPN-IPv4 routes. 参见 [MPLS-BGP].) 当 PE 处理一个栈顶带有该 label 的 received packet 时, PE 会弹出 stack, 并适当地处理该 packet.

PE 可以分发 VRF 中出现的确切 routes 集合, 也可以执行 summarization 并分发这些 routes 的 aggregates, 或者两者兼而有之.

假设某 PE 已为 route R 分配 label L, 并已通过 BGP 分发该 label mapping. 如果 R 是 VRF 中一组 routes 的 aggregate, PE 将知道来自 backbone 且携带此 label 到达的 packets 必须在某个 VRF 中查找其 destination addresses. 当 PE 在其 Label Information Base 中查找该 label 时, 它会知道必须使用哪个 VRF. 另一方面, 如果 R 不是 aggregate, 则 PE 查找该 label 时会知道 egress attachment circuit, 以及 packet 的 encapsulation header. 在这种情况下, 不会在 VRF 中执行查找.

我们预期最常见的情形是 route 不是 aggregate. 不过, 如果 VRF 包含大量 host routes (例如 dial-in 情形), 或者 VRF 有关联的 Local Area Network (LAN) interface (LAN 上每个 system 都有不同的 outgoing layer 2 header, 但不会为每个这样的 system 分发一条 route), aggregate 情形会非常有用.

每条 route 是否具有不同 label 是实现问题. 可以使用多种可能算法来决定两条 routes 是否被分配相同 label:

  • 可以选择为整个 VRF 使用单个 label, 使该 VRF 中所有 routes 共享一个 label. 然后, 当 egress PE 接收到携带该 label 的 packet 时, 它必须在该 VRF (packet 的 "egress VRF") 中查找 packet 的 IP destination address, 以确定 packet 的 egress attachment circuit 和对应的数据链路封装.

  • 可以选择为每个 attachment circuit 使用单个 label, 使具有相同 "outgoing attachment circuit" 的所有 routes 共享一个 label. 这使得可以避免在 egress VRF 中查找, 但可能仍需执行某种查找以确定数据链路封装, 例如 Address Resolution Protocol (ARP) lookup.

  • 可以选择为每条 route 使用不同 label. 这样, 如果某条 route 可能通过多个 attachment circuits 到达, PE/CE routing 可以将某条 route 的 preferred path 从一个 attachment circuit 切换到另一个, 而无需为该 route 分发新的 label.

也可能存在其他算法. 算法的选择完全由 egress PE 自行决定, 对其他部分透明.

以这种方式使用 BGP-distributed MPLS labels 时, 我们预设一个携带此类 label 的 MPLS packet 可以从安装相应 BGP-distributed route 的 router tunneling 到该 route 的 BGP next hop router. 这要求这两台 routers 之间存在 label switched path, 或者它们之间可以使用某种其他 tunneling technology (例如 [MPLS-in-IP-GRE]).

该隧道可以沿 "best effort" 路由, 也可以沿流量工程路由. 在给定一对路由器之间, 可以有一个这样的隧道, 也可以有多个, 可能具有不同的 Quality of Service (QoS) 特性. 对 VPN 架构而言, 重要的只是存在某个这样的隧道. 为了确保使用 MPLS label switched paths 作为隧道技术实现该 VPN 架构的系统之间可互操作, 所有此类系统必须支持 Label Distribution Protocol (LDP) [MPLS-LDP]. 特别是, 在既不是 Label Controlled ATM (LC-ATM) [MPLS-ATM] 也不是 Label Controlled Frame Relay (LC-FR) [MPLS-FR] 的接口上必须支持 Downstream Unsolicited mode, 并且在 LC-ATM 接口和 LC-FR 接口上必须支持 Downstream on Demand mode.

如果 tunnel 沿 best-effort route, 则 PE 通过在 default forwarding table 中查找远端 endpoint 的 IP address 来找到通往该 endpoint 的 route.

PE router, UNLESS 它是 route reflector (见 Section 4.3.3) 或 inter-provider VPN 的 Autonomous System Border Router (ASBR) (见 Section 10), 不应安装 VPN-IPv4 route, 除非它至少有一个 VRF 的 Import Target 与该 route 的某个 Route Target attribute 相同. 应使用 inbound filtering 使这类 routes 被丢弃. 如果后来向该 PE 的某个 VRF 添加新的 Import Target (一次 "VPN Join" 操作), 则它必须获取此前可能已丢弃的 routes. 这可以使用 [BGP-RFSH] 中描述的 refresh mechanism 完成. [BGP-ORF] 的 outbound route filtering mechanism 也可用于让过滤更动态.

类似地, 如果某个特定 Import Target 不再存在于 PE 的任何 VRFs 中 (作为一次或多次 "VPN Prune" 操作的结果), PE 可以丢弃所有因此不再把 PE 的任何 VRF Import Targets 作为其 Route Target attributes 之一的 routes.

一台未连接任何 VPN 且不是 Route Reflector 的 router (即 P router) 根本不会安装任何 VPN-IPv4 routes.

注意, 只要使用 [BGP-RFSH] 的 refresh mechanism, VPN Join 和 Prune 操作就是非中断的, 不需要关闭任何 BGP connections.

由于这些分发规则, 从不会有某台 PE 需要维护所有 VPNs 的全部 routes; 这是一个重要的可扩展性考虑.

4.3.3. 使用路由反射器 (Route Reflectors) (Use of Route Reflectors)​

与其在 PEs 之间建立完整 IBGP mesh, 使用 BGP Route Reflectors [BGP-RR] 来提升可扩展性更有利. 所有通常用于通过 route reflectors 提升可扩展性的技术 (例如 route reflector hierarchies) 都可使用.

Route reflectors 是唯一需要拥有其未直接连接的 VPNs 的 routing information 的 systems. 不过, 并不需要任何一个 route reflector 知道 backbone 支持的所有 VPNs 的全部 VPN-IPv4 routes.

下面概述两种不同方式, 用于在一组 route reflectors 之间划分 VPN-IPv4 routes 集合.

  1. 每个 route reflector 预配置一份 Route Targets 列表. 为了冗余, 可以有多个 route reflectors 预配置相同列表. route reflector 使用预配置的 Route Targets 列表来构造其 inbound route filtering. route reflector 可以使用 [BGP-ORF] 的技术, 在其每个 peers (无论该 peer 是另一个 route reflector 还是 PE) 上安装一组 Outbound Route Filters (ORFs), 其中包含其预配置 Route Targets 列表. 注意, route reflectors 应接受来自其他 route reflectors 的 ORFs, 这意味着 route reflectors 应向其他 route reflectors 通告 ORF capability.

    service provider 可以修改 route reflector 上预配置的 Route Targets 列表. 这样做时, route reflector 会修改它在所有 IBGP peers 上安装的 ORFs. 为了降低 route reflectors 上配置变更的频率, 每个 route reflector 可以预配置一块 Route Targets. 这样, 当新的 VPN 需要新的 Route Target 时, 已经有一个或多个 route reflectors (预)配置了该 Route Target.

    除非给定 PE 是所有 route reflectors 的 client, 否则当向该 PE 添加新的 VPN ("VPN Join") 时, 它需要成为维护该 VPN routes 的 route reflector(s) 的 client. 同样, 从该 PE 删除现有 VPN ("VPN Prune") 可能导致该 PE 不再需要成为某些 route reflector(s) 的 client. 在任一种情况下, Join 或 Prune 操作都是非中断的 (只要使用 [BGP-RFSH]), 并且绝不要求先关闭 BGP connection 再立即重新建立.

    (所谓 "adding a new VPN to a PE", 实际上是指向其某个 VRF 添加新的 import Route Target, 或添加一个具有任何该 PE 其他 VRFs 都不具备的 import Route Target 的新 VRF.)

  2. 另一种方法是让每个 PE 成为某个 route reflectors 子集的 client. route reflector 不预配置 Route Targets 列表, 也不对从其 clients (PEs) 接收的 routes 执行 inbound route filtering; 相反, 它接受从所有 clients (PEs) 接收的所有 routes. route reflector 跟踪其收到的所有 routes 所携带的 Route Targets 集合. 当 route reflector 从其 client 接收到携带某个不在此集合中的 Route Target 的 route 时, 该 Route Target 会立即被加入集合. 另一方面, 当 route reflector 不再有任何携带集合中某个特定 Route Target 的 routes 时, route reflector 应延迟 (数小时) 从集合中删除该 Route Target.

    route reflector 使用此集合来形成应用于从其他 route reflectors 接收的 routes 的 inbound route filters. route reflector 也可以使用 ORFs 在其他 route reflectors 上安装适当的 outbound route filtering. 与第一种方法一样, route reflector 应接受来自其他 route reflectors 的 ORFs. 为此, route reflector 向其他 route reflectors 通告 ORF capability.

    当 route reflector 改变该集合时, 它应立即改变其 inbound route filtering. 此外, 如果 route reflector 使用 ORFs, 则 ORFs 也必须立即改变以反映集合中的变化. 如果 route reflector 不使用 ORFs, 且有新的 Route Target 被加入集合, route reflector 在改变其 inbound route filtering 后, 必须向其他 route reflectors 发出 BGP Refresh.

    上述 "数小时" 的延迟允许 route reflector 即使在失去最后一个对此类 routes 感兴趣的 client 后, 仍保留具有给定 RT 的 routes. 如果 clients 的 "disappearance" 只是临时的, 这可避免重新获取所有此类 routes.

    使用该过程时, VPN Join 和 Prune 操作同样是非中断的.

    注意, 如果某些 client PE 的 VRF 具有一个不是其 export Route Targets 之一的 import Route Target, 该技术将无法正常工作.

在这些过程中, 连接到某个特定 VPN 的 PE router 会 "auto-discovers" 连接到同一 VPN 的其他 PEs. 当添加新的 PE router, 或现有 PE router 连接到新的 VPN 时, 不需要重新配置其他 PE routers.

正如不存在某一台 PE router 需要知道 backbone 上支持的所有 VPN-IPv4 routes 一样, 这些分发规则确保不存在某一台 Route Reflector (RR) 需要知道 backbone 上支持的所有 VPN-IPv4 routes. 因此, backbone 上可支持的此类 routes 总数不受任何单个设备容量约束, 因而几乎可以无限增长.

4.3.4. BGP 如何携带 VPN-IPv4 NLRI (How VPN-IPv4 NLRI Is Carried in BGP)​

BGP Multiprotocol Extensions [BGP-MP] 用于编码 NLRI. 如果 Address Family Identifier (AFI) field 被设置为 1, 且 Subsequent Address Family Identifier (SAFI) field 被设置为 128, 则 NLRI 是 MPLS-labeled VPN-IPv4 address. 使用 AFI 1 是因为与 NLRI 关联的 network layer protocol 仍然是 IP. 注意, 该 VPN architecture 不要求具备分发 unlabeled VPN-IPv4 addresses 的能力.

为了让两个 BGP speakers 交换 labeled VPN-IPv4 NLRI, 它们必须使用 BGP Capabilities Advertisement 来确保双方都能够正确处理此类 NLRI. 这按 [BGP-MP] 中的规定完成, 即使用 capability code 1 (multiprotocol BGP), AFI 为 1, SAFI 为 128.

labeled VPN-IPv4 NLRI 本身按 [MPLS-BGP] 中的规定编码, 其中 prefix 由 8-byte RD 后跟 IPv4 prefix 组成.

4.3.5. 使用路由目标 (Route Targets) 构建 VPN (Building VPNs Using Route Targets)​

通过正确设置 Import Targets 和 Export Targets, 可以构造不同类型的 VPNs.

假设希望创建一个 fully meshed closed user group, 即一组 sites, 其中每个 site 都可以直接向其他 site 发送 traffic, 但不能向其他 sites 发送 traffic 或从其他 sites 接收 traffic. 则每个 site 都与一个 VRF 关联, 选择单个 Route Target attribute, 将该 Route Target 分配给每个 VRF, 同时作为 Import Target 和 Export Target, 并且不把该 Route Target 作为 Import Target 或 Export Target 分配给任何其他 VRFs.

或者, 假设出于某种原因希望创建一种 "hub and spoke" 类型的 VPN. 可以通过使用两个 Route Target values 来做到这一点, 一个表示 "Hub", 一个表示 "Spoke". 在连接到 hub sites 的 VRFs 上, "Hub" 是 Export Target, "Spoke" 是 Import Target. 在连接到 spoke site 的 VRFs 上, "Hub" 是 Import Target, "Spoke" 是 Export Target.

因此, 控制各种 sites 集合之间 routing information 分发的方法非常灵活, 这反过来为构建 VPNs 提供了很大的灵活性.

4.3.6. 单个 PE 中 VRF 之间的路由分发 (Route Distribution Among VRFs in a Single PE)​

即使两个 VRFs 位于同一 PE 中, 也可以将 routes 从一个 VRF 分发到另一个 VRF, 尽管在这种情况下不能说该 route 是由 BGP 分发的. 不过, 在单个 PE 内决定是否将某条特定 route 从一个 VRF 分发到另一个 VRF, 与 VRFs 位于不同 PEs 上时所做的决定相同. 也就是说, 它取决于分配给该 route 的 Route Target attribute (如果该 route 由 BGP 分发, 则会分配该 attribute), 以及第二个 VRF 的 import target.

最后于 更新