适用于商业边缘的第 3 层 VPN 上的内联静态 NAT
关于此示例
此示例说明了服务提供商如何通过服务提供商核心到云服务，使用来自客户 LAN 的内联 NAT，让不同网络上的企业员工访问云服务。该示例包含以下内容：
三个客户边缘 （CE） 路由器，用于发起从客户 LAN 到云服务的流量。
三个提供商边缘 （PE） 路由器。
可能属于企业或服务提供商的云服务。
技术概述
图 2 概述了此示例中使用的技术。
路由概述
核心是使用 MPLS 核心：
RSVP 作为设置端到端路径的信令协议。
PE 路由器之间的标签交换路径 （LSP） 隧道。
EBGP 用于将路由从客户边缘路由器和云服务分发到 PE 路由器。
多协议 BGP （MP–BGP），用于在 PE 路由器之间交换路由信息。
OSPF 在核心中提供可访问性信息，以允许 BGP 解析其下一跃点。
第 3 层 VPN
第 3 层 VPN 是一组共享公共路由信息的站点，其连接由策略控制。第 3 层 VPN 允许服务提供商使用其 IP 核心为其客户提供 VPN 服务。
此示例中的第 3 层 VPN 类型称为 BGP/MPLS VPN，因为 BGP 在提供商的核心中分配 VPN 路由信息，而 MPLS 则通过核心将 VPN 流量转发到 VPN 站点。
在此示例中，有四个站点连接到第 3 层 VPN：三个客户站点和一个云服务站点。第 3 层 VPN 采用中心辐射型配置。路由器 PE1 和 PE2 是分支，它们连接到客户网络。PE3 是枢纽，它连接到云服务。
内联 NAT
在 MX 系列设备中，您可以在 MPC 线卡上使用内联 NAT。您不需要专用的服务接口，如 MS-MPC。内联 NAT 应用于转发平面，类似于在 Junos OS 中处理防火墙和监管器的方式。 内联 NAT 在基于 FPC 和 PIC 的服务内联 （si） 接口上运行。
由于数据包不需要发送到服务卡进行处理，因此 MX 系列路由器可以实现线速、低延迟的 NAT 转换。虽然内联 NAT 服务提供比使用服务卡更好的性能，但它们的功能更基本;内联 NAT 仅支持静态 NAT。
有两种类型的内联 NAT：
接口样式 — 一种基于接口的方法，到达接口的数据包通过服务集发送。您可以使用接口样式的 NAT 将 NAT 应用于接口上的所有流量。
下一跃点样式 — 一种基于路由的方法，通常用于路由实例转发来自特定网络或发往特定目标的数据包。路由实例将客户流量移动到服务接口，在该接口中，NAT 将应用于与路由匹配的流量。
此示例中使用了这两种方法。
要求
此示例使用以下硬件和软件组件：
带有模块化端口集中器 （MPC） 的 MX 系列路由器
Junos OS 17.1R1 或更高版本
配置核心
核心概述
核心配置由物理接口和环路接口以及路由协议组成。路由协议设计包括：
RSVP 是在 PE1 和 PE3 之间以及 PE2 和 PE3 之间建立端到端路径的信令协议。
MPLS LSP 在 PE1 和 PE3 之间以及 PE2 和 PE3 之间提供隧道。
OSPF 在核心中提供可访问性信息，以允许 BGP 解析其下一跃点。
MP-BGP 允许 PE 路由器交换有关在 VPN 中发起和终止的路由的信息，从而支持第 3 层 VPN。
核心传输信令设计注意事项
PE 设备在它们之间使用 LSP，通过 MPLS 核心发送客户流量。在此设计中，我们考虑了设置端到端 LSP 路径的两种最常见的信令类型：LDP 和 RSVP。我们使用 RSVP 作为设置端到端路径的信令协议。
在此示例中，MP-BGP 在提供商的核心之间分配 VPN 路由信息，MPLS 跨核心将 VPN 流量转发到远程 VPN 站点。
内部网关协议 （IGP） 设计注意事项
IGP 在自治系统 （AS） 内交换路由信息。我们使用 OSPF 作为核心网络的 IGP。之所以选择 OSPF，是因为它易于配置，不需要大量规划，具有灵活的汇总和过滤功能，并且可以扩展到大型网络。
配置 PE1
配置 PE2
配置 PE3
验证您的配置
提交，然后验证核心配置。以下示例显示了 PE3 的输出。
在 PE 路由器上配置第 3 层 VPN
第 3 层 VPN 概述
我们使用第 3 层 VPN 通过核心分离和路由来自每个客户 LAN 和云服务的流量。VPN 中有四个站点，即三个客户 LAN 和云服务。
为了区分 PE 路由器上客户 LAN 和云服务的路由，我们使用虚拟路由和转发 （VRF） 路由实例。VRF 路由实例具有一个或多个路由表、一个转发表、使用转发表的接口以及控制转发表内容的策略和路由协议。VRF 表中填充了从客户边缘站点和云服务接收的路由，以及从 VPN 中的其他 PE 路由器接收的路由。由于每个站点都有自己的路由实例，因此每个站点都有单独的表、规则和策略。
此示例使用中心辐射型 VPN 配置。路由器 PE1 和 PE2 是分支，它们代表客户网络。PE3 是枢纽，它代表云服务。策略将流量标记为中心或分支，标记用于将流量定向到正确的 VRF 路由实例。
的第 3 层 VPN
配置 PE1
配置 PE2
配置 PE3
验证您的配置
若要验证配置，请提交配置，然后执行以下操作：
配置从客户边缘路由器和云服务到 PE 路由器的连接
- 客户边缘路由器和云服务到 PE 路由器的连接概述
- 配置 CE1 和 PE1 之间的连接
- 配置 CE2 和 PE1 之间的连接
- 配置 CE3 和 PE2 之间的连接
- 验证来自客户边缘路由器和云服务的连接
客户边缘路由器和云服务到 PE 路由器的连接概述
我们将 EBGP 用于客户边缘路由器与 PE1 和 PE2 之间以及云服务与 PE3 之间的路由。客户边缘路由器使用与客户 LAN 地址匹配的路由策略。将此策略作为导出策略应用于 EBGP 对等方，这会导致 EBGP 将这些地址发送到 PE 路由器。云服务路由器上的相同配置会导致其路由发送到 PE3。
的连接
配置 CE1 和 PE1 之间的连接
在此示例中，我们使用路由器上的环路接口来表示客户 LAN。这就是环路接口使用客户 LAN 的 IP 地址的原因。
配置 CE1
配置 PE1
routing-instances {
Cust-A-VRF {
protocols {
bgp {
group to-Cust-A {
type external;
peer-as 65101;
neighbor 10.0.1.2; ## CE1 interface address
}
}
}
}
}
配置 CE2 和 PE1 之间的连接
在此示例中，我们使用路由器上的环路接口来表示客户 LAN。这就是环路接口使用客户 LAN 的 IP 地址的原因。
配置 CE2
配置 PE1
routing-instances {
Cust-B-VRF {
protocols {
bgp {
group to-Cust-B {
type external;
peer-as 65102
neighbor 10.0.1.4; ## CE2 interface address
}
}
}
}
}
配置 CE3 和 PE2 之间的连接
在此示例中，我们使用路由器上的环路接口来表示客户 LAN。这就是环路接口使用客户 LAN 的 IP 地址的原因。
配置 CE3
配置 PE2
routing-instances {
Cust-C {
protocols {
bgp {
group to-Cust-C {
type external;
peer-as 65103
neighbor 10.0.50.2; ## CE3 interface address
}
}
}
}
}
验证来自客户边缘路由器和云服务的连接
配置内联 NAT
- 内联 NAT 设计注意事项
- 在 PE1 上配置下一跃点样式内联源 NAT
- 允许来自云服务的返回流量到达客户 LAN
- 验证下一跃点样式内联 NAT
- 在 PE2 上配置接口样式内联 NAT
- 验证接口样式内联 NAT
内联 NAT 设计注意事项
内联 NAT 在具有 MPC 线卡的 MX 系列路由器上提供无状态地址转换。使用内联服务的好处是您不需要专用服务卡，并且对转发容量或延迟几乎没有影响。虽然内联服务通常比使用服务卡提供更好的性能，但它们的功能往往更基本。例如，内联 NAT 仅支持静态 NAT。
在此内联 NAT 示例中，我们使用源静态 NAT。
内联 NAT 的类型
有两种类型的内联 NAT：
接口样式 — 一种基于接口的方法，到达接口的数据包通过服务集发送。使用接口样式 NAT 将 NAT 应用于遍历接口的所有流量。
接口样式 NAT 比下一跃点样式 NAT 更易于配置。
下一跃点样式 — 一种基于路由的方法，通常用于路由实例通过内联服务转发来自特定网络或发往特定目标的数据包。
此示例说明如何使用这两种内联 NAT 方法，如下所示：
PE1 将基于下一跃点的内联 NAT 用于从客户 A 和客户 B 网络到云服务的流量。
PE 2 对从客户 C 网络到云服务的流量使用基于接口的内联 NAT。
在 PE1 上配置下一跃点样式内联源 NAT
本节介绍如何使用具有下一跃点样式服务集的 si- 接口来配置基于路由的内联 NAT。
在此示例中，客户 A LAN 和客户 B LAN 具有重叠的子网。PE1 路由器根据流量到达的 si- 接口来区分流量。
本节使用以下配置项：
内联服务接口 — 驻留在 MPC 的数据包转发引擎上的虚拟接口。要访问服务，流量流入和流出 si-（内联服务）接口。
服务集 — 定义执行的服务，并确定哪个内联接口将流量馈入和送出服务集。本节实现下一跃点样式的服务集，该服务集使用基于路由的方法，其中静态路由用于通过内联服务转发发往特定目标的数据包。
NAT 规则 — 使用 if-then 结构（如防火墙过滤器）定义匹配条件，然后将地址转换应用于匹配流量。
NAT 池 — NAT 规则用于转换的用户定义的一组 IP 地址。
虚拟路由器 （VR） 路由实例 — 包括一个默认静态路由，用于将客户流量发送到应用 NAT 的 si- 接口。
防火墙过滤器 — 将来自客户 A 和客户 B 的入站流量重定向到相应的 VR 路由实例。
VRF 路由实例 — 外部 si 接口将添加到客户 A 和客户 B 的 VRF 路由实例中，以便 NAT 转换的出站流量可以在其通过 VPN 的预期路径上继续。
图 7 显示了来自客户 A LAN 并流向云服务的内联 NAT 流量通过 PE1 的流量。
要在 PE1 上配置下一跃点样式内联 NAT，请执行以下操作：
允许来自云服务的返回流量到达客户 LAN
当来自云服务的返回流量通过服务接口时，将删除 NAT 寻址，并将流量发送到 VR 路由实例。但是，VR 路由实例中没有到客户 LAN 的路由，因此我们需要添加它们。为此，我们将使用 RIB 组将路由从 VRF 路由实例共享到 VR 路由实例。
例如，对于到客户 A LAN 的流量，我们会将路由从 Cust-A-VRF.inet.0 路由表共享到 Cust-A-VR.inet.0 路由表中。 图 8 显示了从云服务流向客户 A LAN 的内联 NAT 流量通过 PE1 的流量。
的下一跳样式内联 NAT 流量的流量
在 PE1 上设置路由共享之前，Cust-A-VR.inet.0 路由表中只有一个默认静态路由：
host@PE1> show route table Cust-A-VR.inet.0
Cust-A-VR.inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 02:10:53
> via si-0/0/0.1
要将来自 Cust-A-VRF.inet.0 路由表的路由与 Cust-A-VR.inet.0 路由表共享：
设置路由共享后，CUST-A-VR.inet.0 路由表中已添加直接接口路由和到客户 A LAN 的 BGP 路由：
host@PE1> show route table Cust-A-VR.inet.0
Cust-A-VR.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 02:26:20
> via si-0/0/0.1
10.0.1.0/24 *[Direct/0] 00:00:50
> via xe-0/0/0.0
10.250.100.101/32 *[BGP/170] 00:00:50, localpref 100
AS path: 65101 I, validation-state: unverified
> to 10.0.1.2 via xe-0/0/0.0
返回流量现在可以到达客户 LAN。
验证下一跃点样式内联 NAT
在 PE2 上配置接口样式内联 NAT
对于来自客户 C 的流量，我们使用接口样式的内联 NAT。本节介绍如何配置基于接口的内联 NAT，该 NAT 使用的配置比下一跃点样式 NAT 更简单。
本节使用以下配置项：
内联服务接口 — 驻留在 MPC 的数据包转发引擎上的虚拟接口。要访问服务，流量流入和流出 si-（内联服务）接口。
服务集 — 定义所执行的服务，并确定哪些内联接口将流量送入和送出服务集。本节实现接口样式的服务集，其中到达接口的数据包通过内联服务接口发送。
NAT 规则 — 使用 if-then 结构（类似于防火墙过滤器）定义匹配条件，然后将地址转换应用于匹配流量。
NAT 池 — NAT 规则用于转换的用户定义的一组 IP 地址。
VRF 路由实例 — si- 接口将添加到客户 C 的 VRF 路由实例中。
图 10 显示了从客户 C LAN 发送到云服务的流量在 PE2 上的流量。
图 11 显示了 PE2 上从云服务到客户 C LAN 的流量。
要在 PE2 上配置接口样式内联 NAT，请执行以下操作：
完成此配置后，来自客户 C 的流量进入 PE2 的接口，通过服务接口重定向到用于 NAT 转换的服务集。然后，流量将返回到 VRF 路由实例，并可以像往常一样通过 VPN 发送。
验证接口样式内联 NAT
完整的路由器配置
此部分包含每个路由器的完整配置。
PE1 配置
## Configuring the Core
interfaces {
xe-0/0/2 {
description "Outside to PE3";
unit 0 {
family inet {
address 172.16.1.1/24;
}
family mpls; ## allows interface to support MPLS protocol traffic
}
}
lo0 {
unit 0 {
family inet {
address 10.250.1.1/32;
}
}
}
}
protocols {
rsvp {
interface xe-0/0/2.0;
}
mpls {
no-cspf;
label-switched-path PE1toPE3 {
to 10.250.1.3; ## PE3 loopback address
}
interface xe-0/0/2.0; ## core-facing interface
}
bgp {
group IBGP {
type internal;
local-address 10.250.1.1;
neighbor 10.250.1.3; ## PE3 loopback address
}
}
ospf {
area 0.0.0.0 {
interface xe-0/0/2.0; ## core-facing interface
interface lo0.0;
}
}
}
routing-options {
autonomous-system 65000;
}
policy-options {
policy-statement LB { ## load balancing policy
then {
load-balance per-packet; ## actually applied per flow
}
}
routing-options {
forwarding-table { ## adds the LB policy to the forwarding table
export LB;
}
## Configuring the Layer 3 VPN
interfaces {
xe-0/0/0 {
description "Inside to CE1_Cust-A";
unit 0 {
family inet {
address 10.0.1.1/24;
}
}
}
xe-0/0/1 {
description "Inside to CE1_Cust-B";
unit 0 {
family inet {
address 10.0.1.2/24;
}
}
}
}
policy-options {
policy-statement CustA-to-CloudSvcs {
term 1 {
from protocol static;
then {
community add SpokeA; ## Add SpokeA tag when BGP exports route
accept;
}
}
term 2 {
then reject;
}
}
policy-statement CustB-to-CloudSvcs {
term 1 {
from protocol static;
then {
community add SpokeB; ## Add SpokeB tag when BGP exports route
accept;
}
}
term 2 {
then reject;
}
}
policy-statement from-CloudSvcs { ## add routes received with Hub tag to routing table
term 1 {
from community Hub;
then accept;
}
term 2 {
then reject;
}
}
routing-instances {
Cust-A-VRF {
instance-type vrf;
interface xe-0/0/0.0;
route-distinguisher 10.250.1.1:1;
vrf-import from-CloudSvcs;
vrf-export CustA-to-CloudSvcs;
vrf-table-label;
}
Cust-B-VRF {
instance-type vrf;
interface xe-0/0/1.0;
route-distinguisher 10.250.1.1:2;
vrf-import from-CloudSvcs;
vrf-export CustB-to-CloudSvcs;
vrf-table-label;
}
}
protocols {
bgp {
group IBGP {
family inet-vpn { ## enables MP-BGP to carry IPv4 Layer 3 VPN NLRI
unicast;
}
}
}
## Configuring the Connection to CE1
interfaces {
xe-0/0/1 {
description Cust-B_to_PE1;
unit 0 {
family inet {
address 10.0.1.4/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.250.100.102/32;
}
}
}
}
## Configuring the Connection to CE2
routing-instances {
Cust-B-VRF {
protocols {
bgp {
group to-Cust-B {
type external;
peer-as 65102
neighbor 10.0.1.4; ## CE2 interface address
}
}
}
}
}
## Configuring Next-hop Style Inline NAT
chassis {
fpc 0 {
pic 0 {
inline-services {
bandwidth 1g;
}
}
}
}
interfaces {
si-0/0/0 {
unit 1 { ## Customer A traffic
family inet; ## causes NAT to be applied to IPv4 traffic
service-domain inside; ## traffic from customer A LAN to core
}
unit 2 { ## Customer A traffic
family inet;
service-domain outside; ## customer A traffic from core to customer LAN
}
unit 3 { ## Customer B traffic
family inet;
service-domain inside; ## traffic from customer B LAN to core
}
unit 4 { ## Customer B traffic
family inet;
service-domain outside; ## customer B traffic from core to customer LAN
}
services {
nat {
pool A { ## applied to customer A traffic
address 192.0.2.0/24;
}
pool B { ## applied to customer B traffic
address 198.51.100.0/24;
}
services {
nat {
rule SRC-NAT-A { ## applied to traffic from customer A
match-direction input; ## direction from which traffic is received
term r1 {
from {
source-address {
10.250.100.0/24; ## from customer A
}
}
then {
translated {
source-pool A;
translation-type {
basic-nat44; ## type of one-to-one static NAT
}
}
}
}
}
rule SRC-NAT-B { ## applied to traffic from customer B
match-direction input;
term r1 {
from {
source-address {
10.250.100.0/24; ## from customer B
}
}
then {
translated {
source-pool B;
translation-type {
basic-nat44; ## type of one-to-one static NAT
}
}
}
}
}
services {
service-set NH-STYLE-SS-NAT_A { ## applied to Customer A traffic
nat-rules SRC-NAT-A;
next-hop-service {
inside-service-interface si-0/0/0.1;
outside-service-interface si-0/0/0.2;
}
}
service-set NH-STYLE-SS-NAT_B { ## applied to Customer B traffic
nat-rules SRC-NAT-B;
next-hop-service {
inside-service-interface si-0/0/0.3;
outside-service-interface si-0/0/0.4;
}
}
routing-instances {
Cust-A-VR {
instance-type virtual-router;
interface si-0/0/0.1; ## Cust A inside service interface
routing-options {
static {
route 0.0.0.0/0 next-hop si-0/0/0.1; ## incoming Cust A traffic to si
}
}
}
Cust-B-VR {
instance-type virtual-router;
interface si-0/0/0.3; ## Cust B inside service interface
routing-options {
static {
route 0.0.0.0/0 next-hop si-0/0/0.3; ## incoming Cust B traffic to si
}
}
}
}
firewall {
filter CustA-to-NAT-VR {
term 1 {
from {
source-address { ## traffic from Customer A network
10.250.100.0/24;
}
}
then {
routing-instance Cust-A-VR; ## sends matching traffic to this RI
}
}
term 2 {
then accept;
}
}
filter CustB-to-NAT-VR {
term 1 {
from {
source-address { ## traffic from Customer B network
10.250.100.0/24;
}
}
then {
routing-instance Cust-B-VR; ## sends matching traffic to this RI
}
}
term 2 {
then accept;
}
interfaces {
xe-0/0/0 { ## to Customer A
unit 0 {
family inet {
filter {
input CustA-to-NAT-VR;
}
}
}
}
routing-instances {
Cust-A-VRF {
interface si-0/0/0.2;
}
Cust-B-VRF {
interface si-0/0/0.4;
}
}
## Allow return traffic from Cloud Services
policy-options {
policy-statement leak-to-Cust-A-VR { ## share matching route with Cust-A-VR
term 1 {
from {
route-filter 10.250.100.0/24 orlonger; ## match routes to Cust LAN
}
then accept;
}
term 2 {
from protocol direct; ## match interface routes
then accept;
}
term 3 {
then reject;
}
}
policy-statement leak-to-Cust-B-VR { ## share matching route with Cust-B-VR
term 1 {
from {
route-filter 10.250.100.0/24 orlonger; ## match routes to Cust LAN
}
then accept;
}
term 2 {
from protocol direct; ## match interface routes
then accept;
}
term 3 {
then reject;
}
}
routing-options {
rib-groups {
Cust-A_leak-VRF-to-VR { ## share routes from A-VRF to A-VR
import-rib [ Cust-A-VRF.inet.0 Cust-A-VR.inet.0 ];
import-policy leak-to-Cust-A-VR;
}
Cust-B_leak-VRF-to-VR { ## share routes from B-VRF to B-VR
import-rib [ Cust-B-VRF.inet.0 Cust-B-VR.inet.0 ];
import-policy leak-to-Cust-B-VR;
}
routing-instances {
Cust-A-VRF {
routing-options {
interface-routes { ## sharing interface routes with A-VR
rib-group inet Cust-A_leak-VRF-to-VR;
}
}
protocols {
bgp {
group to-Cust-A {
family inet {
unicast { ## sharing Cust-A network with A-VR
rib-group Cust-A_leak-VRF-to-VR;
}
}
}
}
}
PE2 配置
## Configuring the Corre
interfaces {
xe-0/0/0 {
description "Outside to PE3";
unit 0 {
family inet {
address 172.17.1.1/24;
}
family mpls; ## allows interface to support MPLS protocol traffic
}
}
lo0 {
unit 0 {
family inet {
address 10.250.1.2/32;
}
}
}
}
protocols {
rsvp {
interface xe-0/0/0.0;
}
mpls {
no-cspf;
label-switched-path PE2toPE3 {
to 10.250.1.3; ## PE3 loopback address
}
interface xe-0/0/0.0 ## core-facing interface
}
bgp {
group IBGP {
type internal;
local-address 10.250.1.2; ## local loopback address
family inet {
unicast;
}
neighbor 10.250.1.3; ## lo0 address of PE3
}
}
ospf {
area 0.0.0.0 {
interface xe-0/0/0.0;
interface lo0.0;
}
}
}
routing-options {
autonomous-system 65000;
}
policy-options {
policy-statement LB { ## load balancing policy
then {
load-balance per-packet; ## actually applied per flow
}
}
routing-options {
forwarding-table { ## adds the LB policy to the forwarding table
export LB;
}
policy-options {
policy-statement CustA-to-CloudSvcs {
term 1 {
from protocol static;
then {
community add SpokeA; ## Add SpokeA tag when BGP exports route
accept;
}
}
term 2 {
then reject;
}
}
policy-statement CustB-to-CloudSvcs {
term 1 {
from protocol static;
then {
community add SpokeB; ## Add SpokeB tag when BGP exports route
accept;
}
}
term 2 {
then reject;
}
}
policy-statement from-CloudSvcs { ## add routes received with Hub tag to routing table
term 1 {
from community Hub;
then accept;
}
term 2 {
then reject;
}
}
routing-instances {
Cust-A-VRF {
instance-type vrf;
interface xe-0/0/0.0;
route-distinguisher 10.250.1.1:1;
vrf-import from-CloudSvcs;
vrf-export CustA-to-CloudSvcs;
vrf-table-label;
}
Cust-B-VRF {
instance-type vrf;
interface xe-0/0/1.0;
route-distinguisher 10.250.1.1:2;
vrf-import from-CloudSvcs;
vrf-export CustB-to-CloudSvcs;
vrf-table-label;
}
}
protocols {
bgp {
group IBGP {
family inet-vpn { ## enables MP-BGP to carry IPv4 Layer 3 VPN NLRI
unicast;
}
}
}
## Configuring the Layer 3 VPN
interfaces {
xe-0/0/3 {
description "Inside to CE1_Cust-C";
unit 0 {
family inet {
address 10.0.50.1/24;
}
}
}
}
policy-options {
policy-statement CustC-to-CloudSvcs { ## Add SpokeC tag when BGP exports route
term 1 {
from protocol static;
then {
community add SpokeC;
accept;
}
}
term 2 {
then reject;
}
}
policy-statement from-CloudSvcs { ## add routes received with Hub tag to routing table
term 1 {
from community Hub;
then accept;
}
term 2 {
then reject;
}
}
routing-instances {
Cust-C {
instance-type vrf;
interface xe-0/0/3.0;
route-distinguisher 10.250.1.2:3;
vrf-import from-CloudSvcs;
vrf-export CustC-to-CloudSvcs;
vrf-table-label;
}
}
protocols {
bgp {
group IBGP {
family inet-vpn { ## enables MP-BGP to carry IPv4 Layer 3 VPN NLRI
unicast
}
}
}
## Configuring the Connection to CE3
routing-instances {
Cust-C {
protocols {
bgp {
group to-Cust-C {
type external;
peer-as 65103
neighbor 10.0.50.2; ## CE3 interface address
}
}
}
}
}
## Configuring Interface-Style Inline NAT
chassis {
fpc 0 {
pic 0 {
inline-services {
bandwidth 1g;
}
}
}
}
interfaces {
si-0/0/0 {
unit 0 {
family inet; ## protocol family that will need NAT services
}
}
}
services {
nat {
pool C {
address 203.0.113.0/24;
}
}
}
services {
nat {
rule SRC-NAT-C { ## applied to traffic from Customer C
match-direction input; ## direction from which traffic is received
term r1 {
from {
source-address {
10.250.100.0/24; ## customer C
}
}
then {
translated {
source-pool C;
translation-type {
basic-nat44; ## type of one-to-one static NAT
}
}
}
}
}
}
services {
service-set INT-STYLE-SS-NAT_C {
nat-rules SRC-NAT-C;
interface-service { ## defines that this is an interface-style service set
service-interface si-0/0/0.0;
}
}
interfaces {
xe-0/0/3{
unit 0 {
family inet {
service {
input {
service-set INT-STYLE-SS-NAT_C;
}
output {
service-set INT-STYLE-SS-NAT_C;
}
}
}
}
}
}
routing-instances {
Cust-C {
interface si-0/0/0.0;
}
}
PE3 配置
## Configuring the Core
interfaces {
xe-0/0/0 {
description "to PE1";
unit 0 {
family inet {
address 172.16.1.2/24;
}
family mpls; ## allows interface to support MPLS protocol traffic
}
}
xe-0/0/1 {
description "to PE2";
unit 0 {
family inet {
address 172.17.1.2/24;
}
family mpls; ## allows interface to support MPLS protocol traffic
}
}
lo0 {
unit 0 {
family inet {
address 10.250.1.3/32;
}
}
}
}
protocols {
rsvp {
interface xe-0/0/0.0;
interface xe-0/0/1.0;
}
mpls {
no-cspf;
label-switched-path PE3toPE1 {
to 10.250.1.1; ## PE1 loopback address
}
label-switched-path PE3toPE2 {
to 10.250.1.2; ## PE2 loopback address
}
interface xe-0/0/0.0; ## core-facing interface
interface xe-0/0/1.0; ## core-facing interface
}
bgp {
group IBGP {
type internal;
local-address 10.250.1.3; ## local loopback address
family inet {
unicast;
}
neighbor 10.250.1.1; ## lo0 address of spoke router PE1
neighbor 10.250.1.2; ## lo0 address of spoke router PE2
}
}
ospf {
area 0.0.0.0 {
interface xe-0/0/0.0;
interface xe-0/0/1.0;
interface lo0.0;
}
}
}
routing-options {
autonomous-system 65000;
}
policy-options {
policy-statement LB { ## load balancing policy
then {
load-balance per-packet; ## actually applied per session
}
}
routing-options {
forwarding-table { ## adds the LB policy to the forwarding table
export LB;
}
## Configuring the Layer 3 VPN
interfaces {
xe-0/0/2 {
description "PE3 to CloudSvcs";
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
}
policy-options {
policy-statement from-Cust { ## add routes with hub tag to routing table
term 1 {
from community [ SpokeA SpokeB SpokeC ];
then accept;
}
}
policy-statement to-Cust { ## add hub tag when BGP exports route
term 1 {
from protocol bgp;
then {
community add Hub;
accept;
}
}
}
routing-instances {
CloudSvcs {
instance-type vrf;
interface xe-0/0/2.0;
route-distinguisher 10.250.1.3:100; ## PE3
vrf-import from-Cust;
vrf-export to-Cust;
}
}
protocols {
bgp {
group IBGP {
family inet-vpn { ## enables MP-BGP to carry IPv4 Layer 3 VPN NLRI
unicast
}
}
}
CE1 配置
interfaces {
xe-0/0/0 {
description Cust-A_to_PE1;
unit 0 {
family inet {
address 10.0.1.2/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.250.100.101/32;
}
}
}
}
policy-options {
policy-statement CustA-to-PE1 {
term 1 {
from {
route-filter 10.250.100.101/32 exact;
}
then accept;
}
term 2 {
then reject;
}
}
}
protocols {
bgp {
group to-PE1 {
type external;
export CustA-to-PE1; ## BGP advertises routes to the L3VPN
peer-as 65000;
neighbor 10.0.1.1; ## PE1 interface address
}
}
}
routing-options {
autonomous-system 65101;
}
CE2 配置
interfaces {
xe-0/0/1 {
description Cust-B_to_PE1;
unit 0 {
family inet {
address 10.0.1.4/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.250.100.102/32;
}
}
}
}
policy-options {
policy-statement CustB-to-PE1 {
term 1 {
from {
route-filter 10.250.100.102/32 exact;
}
then accept;
}
term 2 {
then reject;
}
}
}
protocols {
bgp {
group to-PE1 {
type external;
export CustB-to-PE1;
peer-as 65000;
neighbor 10.0.1.2; ## PE1 interface address
}
}
}
routing-options {
autonomous-system 65102;
}
CE3 配置
interfaces {
xe-0/0/2 {
description Cust-C_to_PE2;
unit 0 {
family inet {
address 10.0.50.2/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.250.100.103/32;
}
}
}
}
policy-options {
policy-statement CustC-to-PE2 {
term 1 {
from {
route-filter 10.250.100.103/32 exact;
}
then accept;
}
term 2 {
then reject;
}
}
}
protocols {
bgp {
group to-PE2 {
type external;
export CustC-to-PE2;
peer-as 65000;
neighbor 10.0.50.1; ## PE2 interface address
}
}
}
routing-options {
autonomous-system 65103;
}