비즈니스 에지용 레이어 3 VPN을 통한 인라인 정적 NAT
이 예에 대한 정보
이 예에서는 서비스 프로바이더가 고객 LAN에서 인라인 NAT를 사용하여 서비스 프로바이더 MPLS 코어에서 클라우드 서비스까지 인라인 NAT를 사용하여 서로 다른 네트워크에 있는 엔터프라이즈 직원에게 클라우드 서비스에 대한 액세스 권한을 부여하는 방법을 보여줍니다. 이 예제는 다음과 같이 구성됩니다.
고객 LAN에서 클라우드 서비스로 트래픽을 생성하는 고객 에지(CE) 라우터 3개.
PE(Provider Edge) 라우터 3개.
기업 또는 서비스 공급자에 속할 수 있는 클라우드 서비스.
기술 개요
그림 2는 이 예에서 사용된 기술에 대한 개요를 보여줍니다.
라우팅 개요
코어는 다음을 사용하는 MPLS 코어입니다.
엔드 투 엔드 경로를 설정하는 신호 프로토콜로서의 RSVP.
PE 라우터 간의 LSP(Label-switched path) 터널.
EBGP를 사용하여 CE 라우터 및 클라우드 서비스에서 PE 라우터로 경로를 배포합니다.
PE 라우터 간에 라우팅 정보를 교환하기 위한 멀티프로토콜 BGP(MP–BGP).
OSPF는 BGP가 다음 홉을 확인할 수 있도록 코어에 도달 가능성 정보를 제공합니다.
레이어 3 VPN
레이어 3 VPN은 공통 라우팅 정보를 공유하고 정책에 의해 연결이 제어되는 사이트 집합입니다. 레이어 3 VPN을 사용하면 서비스 프로바이더가 IP 코어를 사용하여 고객에게 VPN 서비스를 제공할 수 있습니다.
BGP는 프로바이더의 코어에 VPN 라우팅 정보를 배포하고 MPLS는 코어를 통해 VPN 사이트로 VPN 트래픽을 전달하기 때문에 이 예에서 계층 3 VPN 유형을 BGP/MPLS VPN이라고 합니다.
이 예에서 레이어 3 VPN에는 고객 사이트 3개와 클라우드 서비스 사이트 1개, 총 4개의 사이트가 연결되어 있습니다. 레이어 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(Modular Port Concentrator)가 탑재된 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(Interior Gateway Protocol) 설계 고려 사항
IGP는 AS(Autonomous System) 내에서 라우팅 정보를 교환합니다. OSPF를 코어 네트워크의 IGP로 사용하고 있습니다. OSPF를 선택한 이유는 구성이 쉽고, 많은 계획이 필요하지 않고, 요약 및 필터링이 유연하고, 대규모 네트워크로 확장할 수 있기 때문입니다.
PE1 구성
PE2 구성
PE3 구성
구성 확인
코어 구성을 커밋한 후 확인합니다. 아래 예제에서는 PE3의 출력을 보여 줍니다.
PE 라우터에서 레이어 3 VPN 구성
레이어 3 VPN 개요
주니퍼는 레이어 3 VPN을 사용하여 코어를 통해 각 고객 LAN 및 클라우드 서비스의 트래픽을 분리하고 라우팅합니다. VPN에는 4개의 사이트, 즉 3개의 고객 LAN 및 클라우드 서비스가 있습니다.
PE 라우터에서 고객 LAN과 클라우드 서비스에 대한 경로를 구분하기 위해 가상 라우팅 및 포워딩(VRF) 라우팅 인스턴스를 사용하고 있습니다. VRF 라우팅 인스턴스에는 하나 이상의 라우팅 테이블, 포워딩 테이블, 포워딩 테이블을 사용하는 인터페이스, 포워딩 테이블로 들어가는 항목을 제어하는 정책 및 라우팅 프로토콜이 있습니다. VRF 테이블은 CE 사이트 및 클라우드 서비스에서 수신한 경로와 VPN의 다른 PE 라우터에서 수신한 경로로 채워집니다. 각 사이트에는 자체 라우팅 인스턴스가 있으므로 각 사이트에는 별도의 테이블, 규칙 및 정책이 있습니다.
이 예에서는 허브 및 스포크 VPN 구성을 사용합니다. 라우터 PE1 및 PE2는 스포크이며 고객 네트워크를 나타냅니다. PE3는 허브이며 클라우드 서비스를 나타냅니다. 정책은 트래픽을 허브 또는 스포크로 표시하며, 표시는 트래픽을 올바른 VRF 라우팅 인스턴스로 전달하는 데 사용됩니다.
가 있는 레이어 3 VPN
PE1 구성
PE2 구성
PE3 구성
구성 확인
구성을 확인하려면 구성을 커밋한 후 다음을 수행합니다.
CE 라우터 및 클라우드 서비스에서 PE 라우터로의 연결 구성
- CE 라우터 및 클라우드 서비스에서 PE 라우터로의 연결 개요
- CE1과 PE1 간의 연결 구성
- CE2와 PE1 간의 연결 구성
- CE3와 PE2 간의 연결 구성
- CE 라우터 및 클라우드 서비스에서 연결 확인
CE 라우터 및 클라우드 서비스에서 PE 라우터로의 연결 개요
CE 라우터와 PE1 및 PE2 간, 클라우드 서비스와 PE3 간 라우팅에 EBGP를 사용하고 있습니다. CE 라우터는 고객 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
}
}
}
}
}
CE 라우터 및 클라우드 서비스에서 연결 확인
인라인 네트워크 주소 변환(NAT) 구성
- 인라인 네트워크 주소 변환(NAT) 설계 고려 사항
- PE1에서 다음 홉 스타일 인라인 소스 네트워크 주소 변환(NAT) 구성
- 클라우드 서비스의 반환 트래픽이 고객 LAN에 도달하도록 허용
- Next-Hop 스타일 인라인 NAT 확인
- PE2에서 인터페이스 스타일 인라인 네트워크 주소 변환(NAT) 구성
- 인터페이스 스타일 인라인 NAT 확인
인라인 네트워크 주소 변환(NAT) 설계 고려 사항
인라인 NAT는 MPC 라인 카드가 있는 MX 시리즈 라우터에서 스테이트리스 주소 변환을 제공합니다. 인라인 서비스를 사용하면 전용 서비스 카드가 필요 없고 포워딩 용량이나 지연 시간에 거의 영향을 주지 않는다는 이점이 있습니다. 인라인 서비스는 일반적으로 서비스 카드를 사용하는 것보다 더 나은 성능을 제공하지만 그 기능은 더 기본적인 경향이 있습니다. 예를 들어 인라인 NAT는 정적 NAT만 지원합니다.
이 인라인 NAT 예제에서는 소스 정적 NAT를 사용하고 있습니다.
인라인 NAT의 유형
인라인 네트워크 주소 변환(NAT)에는 두 가지 유형이 있습니다.
인터페이스 스타일—인터페이스에 도착하는 패킷이 서비스 세트를 통해 전송되는 인터페이스 기반 방법입니다. 인터페이스 스타일 NAT를 사용하여 인터페이스를 통과하는 모든 트래픽에 NAT를 적용합니다.
인터페이스 스타일 NAT는 다음 홉 스타일의 NAT보다 구성이 간단합니다.
다음 홉 스타일—라우팅 인스턴스가 인라인 서비스를 통해 특정 네트워크에서 소싱되거나 특정 대상으로 향하는 패킷을 전달할 때 일반적으로 사용되는 경로 기반 방법입니다.
이 예에서는 다음과 같이 인라인 NAT의 두 가지 방법을 모두 사용하는 방법을 보여줍니다.
PE1은 고객 A 및 고객 B 네트워크에서 클라우드 서비스로의 트래픽에 대해 다음 홉 기반 인라인 NAT를 사용합니다.
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을 통과하는 트래픽 흐름을 보여줍니다.
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 라우팅 테이블과 공유하려면 다음을 수행합니다.
경로 공유를 설정한 후 고객 A LAN에 대한 직접 인터페이스 경로와 BGP 경로가 Cust-A-VR.inet.0 라우팅 테이블에 추가되었습니다.
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에 도달할 수 있습니다.
Next-Hop 스타일 인라인 NAT 확인
PE2에서 인터페이스 스타일 인라인 네트워크 주소 변환(NAT) 구성
고객 C의 트래픽에는 인터페이스 스타일의 인라인 NAT가 사용됩니다. 이 섹션에서는 다음 홉 스타일 네트워크 주소 변환(NAT)보다 간단한 구성을 사용하는 인터페이스 기반 인라인 네트워크 주소 변환(NAT)을 구성하는 방법을 보여줍니다.
이 섹션에서 사용되는 구성 항목은 다음과 같습니다.
인라인 서비스 인터페이스 - MPC의 패킷 전달 엔진에 상주하는 가상 인터페이스. 서비스에 액세스하기 위해 트래픽은 si-(service-inline) 인터페이스 안팎으로 흐릅니다.
Service set(서비스 세트) - 수행된 서비스를 정의하고 서비스 세트로 들어오고 나가는 트래픽을 공급할 인라인 인터페이스를 식별합니다. 이 섹션에서는 인터페이스에 도착하는 패킷이 인라인 서비스 인터페이스를 통해 전송되는 인터페이스 스타일의 서비스 세트를 구현합니다.
NAT 규칙 - 방화벽 필터와 유사한 if-then 구조를 사용하여 일치 조건을 정의한 다음 일치하는 트래픽에 주소 변환을 적용합니다.
NAT 풀 - NAT 규칙이 변환에 사용하는 사용자 정의 IP 주소 집합입니다.
VRF 라우팅 인스턴스 - 고객 C의 VRF 라우팅 인스턴스에 si- 인터페이스가 추가됩니다.
그림 10 은 고객 C LAN에서 클라우드 서비스로 전송된 트래픽에 대한 PE2의 트래픽 플로우를 보여줍니다.
그림 11 은 클라우드 서비스에서 고객 C LAN으로의 트래픽에 대한 PE2의 트래픽 플로우를 보여줍니다.
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;
}