Inline Static NAT over Layer 3 VPNs for Business Edge
About This Example
This example shows how a service provider can give enterprise employees on different networks access to cloud services by using inline NAT from their customers’ LANs through the service provider MPLS core to cloud services. The example consists of the following:
Three Customer Edge (CE) routers that originate traffic from the customer LANs to cloud services.
Three Provider Edge (PE) routers.
Cloud Services that could belong to the enterprise or to the service provider.
Technology Overview
Figure 2 gives an overview of the technology used in this example.
Routing Overview
The core is an MPLS core that uses:
RSVP as the signaling protocol that sets up end-to-end paths.
Label-switched path (LSP) tunnels between the PE routers.
EBGP to distribute routes from the CE routers and cloud services to PE routers.
Multiprotocol BGP (MP–BGP) to exchange routing information among the PE routers.
OSPF to provide reachability information in the core to allow BGP to resolve its next-hops.
Layer 3 VPN
A Layer 3 VPN is a set of sites that share common routing information and whose connectivity is controlled by policies. Layer 3 VPNs allow service providers to use their IP core to provide VPN services to their customers.
The type of Layer 3 VPN in this example is called BGP/MPLS VPN because BGP distributes VPN routing information across the provider’s core, and MPLS forwards VPN traffic across the core to the VPN sites.
There are four sites attached to the Layer 3 VPN in this example—three customer sites and one cloud services site. The Layer 3 VPN has a hub-and-spoke configuration. Routers PE1 and PE2 are the spokes, and they connect to the customer networks. PE3 is the hub, and it connects to cloud services.
Inline NAT
In an MX Series device, you can use inline NAT on MPC line cards. You do not need a dedicated services interface, such as an MS-MPC. Inline NAT is applied in the forwarding plane, similar to the way firewalls and policers are handled in the Junos OS. Inline NAT runs on services inline (si) interfaces that are based on the FPC and PIC.
Because packets do not need to be sent to a services card for processing, the MX Series router can achieve line rate, low latency NAT translations. While Inline NAT services provide better performance than using a services card, their functionality is more basic; inline NAT supports only static NAT.
There are two types of inline NAT:
Interface-style—an interface-based method, where packets arriving at an interface are sent through a service set. You use interface-style NAT to apply NAT to all traffic on an interface.
Next-hop-style—a route-based method that is typically used when routing instances forward packets from a specific network or destined for a specific destination. Routing instances move customer traffic to a service interface where NAT is applied to traffic that matches the route.
Both methods are used in this example.
Requirements
This example uses the following hardware and software components:
MX Series routers with Modular Port Concentrators (MPCs)
Junos OS Release 17.1R1 or higher
Configuring the Core
Core Overview
The core configuration consists of the physical and loopback interfaces and routing protocols. The routing protocol design includes:
RSVP is the signaling protocol that sets up end-to-end paths between PE1 and PE3 and between PE2 and PE3.
MPLS LSPs provide tunnels between PE1 and PE3 and between PE2 and PE3.
OSPF provides reachability information in the core to allow BGP to resolve its next-hops.
MP-BGP supports Layer 3 VPNs by allowing the PE routers to exchange information about routes originating and terminating in the VPNs.
- Core Transport Signaling Design Considerations
- Interior Gateway Protocol (IGP) Design Considerations
Core Transport Signaling Design Considerations
The PE devices use LSPs between them to send customer traffic over the MPLS core. In this design, we considered the two most common signaling types to set up the end-to-end LSP paths—LDP and RSVP. We are using RSVP as the signaling protocol that sets up end-to-end paths.
In this example, MP-BGP distributes VPN routing information across the provider’s core, and MPLS forwards VPN traffic across the core to remote VPN sites.
Interior Gateway Protocol (IGP) Design Considerations
An IGP exchanges routing information within an autonomous system (AS). We are using OSPF as the IGP for the core network. We chose OSPF because it is easy to configure, does not require a large amount of planning, has flexible summarization and filtering, and can scale to large networks.
Configuring PE1
Configuring PE2
Configuring PE3
Verifying Your Configuration
Commit and then verify the core configuration. The examples below show output from PE3.
Configuring the Layer 3 VPN on PE Routers
Layer 3 VPN Overview
We are using a Layer 3 VPN to separate and route traffic from each of the customer LANs and cloud services over the core. There are four sites in the VPN—the three customer LANs and cloud services.
To distinguish routes for the customer LANs and cloud services on the PE routers, we are using virtual routing and forwarding (VRF) routing instance . A VRF routing instance has one or more routing tables, a forwarding table, the interfaces that use the forwarding table, and the policies and routing protocols that control what goes into the forwarding table. The VRF tables are populated with routes received from the CE sites and cloud services, and with routes received from other PE routers in the VPN. Because each site has its own routing instance, each site has separate tables, rules, and policies.
This example uses a hub-and-spoke VPN configuration. Routers PE1 and PE2 are the spokes, and they represent the customer networks. PE3 is the hub, and it represents the cloud services. Policies mark traffic as either a hub or spoke, and the marking is used to direct traffic to the correct VRF routing instance.
Configuring PE1
Configuring PE2
Configuring PE3
Verifying Your Configuration
To verify your configuration, commit the configuration, and then do the following:
Configuring Connections from CE Routers and Cloud Services to PE Routers
- Connections from CE Routers and Cloud Services to PE Routers Overview
- Configuring the Connection Between CE1 and PE1
- Configuring the Connection Between CE2 and PE1
- Configuring the Connection Between CE3 and PE2
- Verifying Connections from CE Routers and Cloud Services
Connections from CE Routers and Cloud Services to PE Routers Overview
We are using EBGP for routing between the CE routers and PE1 and PE2 and between cloud services and PE3. The CE routers use a routing policy that matches the address of the customer LAN. You apply this policy as an export policy in the EBGP peer, which causes EBGP to send these addresses to PE routers. The same configuration on the cloud services router causes its routes to be sent to PE3.
Configuring the Connection Between CE1 and PE1
In this example we are using the loopback interfaces on the router to represent the customer LANs. That is why the loopback interfaces use the IP addresses of the customer LAN.
Configuring CE1
Configuring 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
}
}
}
}
}
Configuring the Connection Between CE2 and PE1
In this example we are using the loopback interfaces on the router to represent the customer LANs. That is why the loopback interfaces use the IP addresses of the customer LAN.
Configuring CE2
Configuring 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
}
}
}
}
}
Configuring the Connection Between CE3 and PE2
In this example we are using the loopback interfaces on the router to represent the customer LANs. That is why the loopback interfaces use the IP addresses of the customer LAN.
Configuring CE3
Configuring PE2
routing-instances {
Cust-C {
protocols {
bgp {
group to-Cust-C {
type external;
peer-as 65103
neighbor 10.0.50.2; ## CE3 interface address
}
}
}
}
}
Verifying Connections from CE Routers and Cloud Services
Configuring Inline NAT
- Inline NAT Design Considerations
- Configuring Next-Hop Style Inline Source NAT on PE1
- Allowing Return Traffic from Cloud Services to Reach Customer LANs
- Verifying Next-Hop Style Inline NAT
- Configuring Interface-Style Inline NAT on PE2
- Verifying Interface Style Inline NAT
Inline NAT Design Considerations
Inline NAT provides stateless address translation on MX Series routers that have MPC line cards. The benefit of using an inline service is that you do not need a dedicated services card and there is almost no impact to forwarding capacity or latency. While inline services generally provide better performance than using a services card, their functionality tends to be more basic. For example, inline NAT supports only static NAT.
We are using source static NAT in this inline NAT example.
Types of Inline NAT
There are two types of inline NAT:
Interface-style—an interface-based method, where packets arriving at an interface are sent through a service set. Use interface-style NAT to apply NAT to all traffic that traverses an interface.
Interface-style NAT is simpler to configure than next-hop style NAT.
Next-hop-style—a route-based method that is typically used when routing instances forward packets sourced from a specific network or destined to a specific destination through the inline service.
This example shows how to use both methods of inline NAT as follows:
PE1 uses next-hop based inline NAT for traffic from the Customer A and Customer B networks to cloud services.
PE 2 uses interface-based inline NAT for traffic from the Customer C network to cloud services.
Configuring Next-Hop Style Inline Source NAT on PE1
This section shows how to configure route-based inline NAT using si- interfaces with next-hop style service-sets.
In this example, the Customer A LAN and Customer B LAN have overlapping subnets. The PE1 router differentiates the traffic according to which si- interface the traffic arrives on.
The following configuration items are used in this section:
Inline service interface—a virtual interface that resides on the Packet Forwarding Engine of the MPC. To access services, traffic flows in and out of the si- (service-inline) interfaces.
Service set—defines the service(s) performed, and identifies which inline interface will feed traffic into and out of the service set. This section implements next-hop style service sets, which uses a route-based method, where static routes are used to forward packets destined for a specific destination through the inline service.
NAT rule—uses an if-then structure (like firewall filters) to define match conditions and then apply address translation to the matching traffic.
NAT pool—a user-defined set of IP addresses that the NAT rule uses for translation.
Virtual router (VR) routing instance—includes a default static route that sends customer traffic to the si- interface where NAT is applied.
Firewall filters— redirects inbound traffic from Customer A and Customer B to the appropriate VR routing instances.
VRF routing instance—the outside si- interfaces are added to the VRF routing instances for Customer A and Customer B so NAT-translated outbound traffic can continue on its intended path across the VPN.
Figure 7 shows the traffic flow through PE1 for inline NAT traffic coming from the Customer A LAN and going to cloud services.
To configure next-hop style inline NAT on PE1:
Allowing Return Traffic from Cloud Services to Reach Customer LANs
When return traffic from Cloud Services goes through the services interfaces, NAT addressing is removed, and traffic is sent to the VR routing instances. However, there is no route to the customer LANs in the VR routing instances, so we need to add them. To do this, we will share routes from the VRF routing instances into the VR routing instances using RIB groups.
For example, for traffic to the Customer A LAN, we will share routes from the Cust-A-VRF.inet.0 routing table into the Cust-A-VR.inet.0 routing table. Figure 8 shows the traffic flow through PE1 for inline NAT traffic coming from cloud services going to the Customer A LAN.
Before we set up route sharing on PE1, there is only a default static route in the Cust-A-VR.inet.0 routing table:
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
To share routes from the Cust-A-VRF.inet.0 routing table with the Cust-A-VR.inet.0 routing table:
After we set up route sharing, a direct interface route and a BGP route to the customer A LAN have been added to the Cust-A-VR.inet.0 routing table:
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
Return traffic can now reach the Customer LANs.
Verifying Next-Hop Style Inline NAT
Configuring Interface-Style Inline NAT on PE2
For traffic from Customer C, we are using interface-style inline NAT. This section shows how to configure interface-based inline NAT, which uses a simpler configuration than next-hop style NAT.
The following configuration items are used in this section:
Inline service interface—a virtual interface that resides on the Packet Forwarding Engine of the MPC. To access services, traffic flows in and out of the si- (service-inline) interface.
Service set—defines the service(s) performed, and identifies which inline interface(s) will feed traffic into and out of the service set. This section implements interface-style service sets, where packets arriving at an interface are sent through the inline service interface.
NAT rule—uses an if-then structure (similar to firewall filters) to define match conditions and then apply address translation to the matching traffic.
NAT pool—a user-defined set of IP addresses that the NAT rule uses for translation.
VRF routing instance—the si- interface is added to the VRF routing instance for Customer C.
Figure 10 shows the traffic flow on PE2 for traffic sent from the Customer C LAN to cloud services.
Figure 11 shows the traffic flow on PE2 for traffic from cloud services to the Customer C LAN.
To configure interface style inline NAT on PE2:
With this configuration in place, traffic from Customer C enters the interface at PE2, is redirected through the service interface to the service set for NAT translation. The traffic is then returned to the VRF routing instance and can be sent across the VPN as usual.
Verifying Interface Style Inline NAT
Complete Router Configurations
This section has the complete configuration of each router.
- PE1 Configuration
- PE2 Configuration
- PE3 Configuration
- CE1 Configuration
- CE2 Configuration
- CE3 Configuration
PE1 Configuration
## 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 Configuration
## 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 Configuration
## 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 Configuration
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 Configuration
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 Configuration
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;
}