ビジネス エッジ向けのレイヤー 3 VPN 経由のインライン静的 NAT
この例について
この例では、サービスプロバイダーのMPLSコアを経由してクラウドサービスに至る顧客のLANからインラインNATを使用して、サービスプロバイダーがさまざまなネットワーク上の企業の従業員にクラウドサービスへのアクセスを提供する方法を示します。この例は、次のもので構成されています。
顧客LANからクラウドサービスへのトラフィック発信を行う3台のカスタマーエッジ(CE)ルーター。
3 台の PE(プロバイダ エッジ)ルーター。
企業またはサービス プロバイダーに属するクラウド サービス。
技術概要
図 2 に、この例で使用されているテクノロジの概要を示します。
ルーティングの概要
コアは、以下を使用する MPLS コアです。
エンドツーエンドのパスを設定するシグナリングプロトコルとしてのRSVP。
PE ルーター間の LSP(ラベルスイッチ パス)トンネル。
CEルーターとクラウドサービスからPEルーターにルートを分配するEBGP。
PEルーター間でルーティング情報を交換するためのマルチプロトコルBGP(MP–BGP)。
OSPF はコア内の到達可能性情報を提供し、BGP がネクストホップを解決できるようにします。
レイヤー 3 VPN
レイヤー3 VPNは、共通のルーティング情報を共有し、その接続がポリシーによって制御されるサイトのセットです。レイヤー3 VPNにより、サービスプロバイダはIPコアを使用して、顧客にVPNサービスを提供することができます。
この例のレイヤー3 VPNのタイプは、BGP/MPLS VPNと呼ばれます。これは、BGPがVPNルーティング情報をプロバイダのコア全体に分配し、MPLSがコア全体のVPNトラフィックをVPNサイトに転送するためです。
この例では、レイヤー3 VPNに接続されている4つのサイト(3つの顧客サイトと1つのクラウドサービスサイト)があります。レイヤー 3 VPN にはハブアンドスポーク構成があります。ルーターPE1とPE2はスポークであり、お客様のネットワークに接続します。PE3はハブであり、クラウドサービスに接続します。
インライン NAT
MX シリーズ デバイスでは、MPC ライン カードでインライン NAT を使用できます。MS-MPCのような専用のサービスインターフェイスは必要ありません。インラインNATは、Junos OSでファイアウォールやポリサーが処理される方法と同様に、転送プレーンで適用されます。 インラインNATは、FPCおよびPICベースのサービスインライン(si)インターフェイスで実行されます。
パケットを処理するためにサービスカードに送信する必要がないため、MXシリーズルーターはラインレートと低レイテンシのNAT変換を実現できます。インラインNATサービスは、サービスカードを使用するよりも優れたパフォーマンスを提供しますが、その機能はより基本的です。インライン NAT はスタティック NAT のみをサポートします。
インラインNATには2種類あります。
インターフェイススタイル:インターフェイスに到着するパケットがサービスセットを介して送信されるインターフェイスベースの方法。インターフェイス上のすべてのトラフィックにNATを適用するには、インターフェイススタイルのNATを使用します。
Next-hop-style:ルーティングインスタンスが特定のネットワークからパケットを転送する場合、または特定の宛先に宛てたパケットを転送する場合に通常使用されるルートベースの方式。ルーティングインスタンスは、顧客のトラフィックをサービスインターフェイスに移動し、そこでルートに一致するトラフィックにNATが適用されます。
この例では、両方の方法を使用します。
要件
この例では、以下のハードウェアとソフトウェアのコンポーネントを使用しています。
MPC(Modular Port Concentrators)搭載の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 パスを設定するための最も一般的な 2 つのシグナリング タイプ(LDP と RSVP)を検討しました。エンドツーエンドのパスを設定するシグナリングプロトコルとしてRSVPを使用しています。
この例では、MP-BGP が VPN ルーティング情報をプロバイダのコアに配信し、MPLS がコア全体の VPN トラフィックをリモート VPN サイトに転送します。
内部ゲートウェイプロトコル(IGP)の設計上の考慮事項
IGPは、自律システム(AS)内でルーティング情報を交換します。コアネットワークのIGPとしてOSPFを使用しています。OSPFを選択した理由は、設定が容易で、大量の計画を必要とせず、柔軟な要約とフィルタリングが可能で、大規模ネットワークに拡張できるからです。
PE1の設定
PE2の設定
PE3の設定
設定の確認
コア コンフィギュレーションをコミットしてから検証します。次の例は、PE3 からの出力を示しています。
PE ルーターでのレイヤー 3 VPN の設定
レイヤー 3 VPN の概要
レイヤー3 VPNを使用して、コア上の各顧客LANとクラウドサービスからのトラフィックを分離してルーティングしています。VPNには、3つの顧客LANとクラウドサービスの4つのサイトがあります。
PEルーター上の顧客LANとクラウドサービスのルートを区別するために、仮想ルーティングおよび転送(VRF)ルーティングインスタンスを使用しています。VRF ルーティング インスタンスには、1 つ以上のルーティング テーブル、転送テーブル、転送テーブルを使用するインターフェイス、および転送テーブルに入る内容を制御するポリシーとルーティング プロトコルがあります。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に到達できるようにする
- ネクストホップスタイルのインラインNATの検証
- PE2でのインターフェイススタイルインラインNATの設定
- インターフェイススタイルのインライン NAT の検証
インライン NAT の設計に関する考慮事項
インラインNATは、MPCラインカードを持つMXシリーズルーター上でステートレスアドレス変換を提供します。インライン サービスを使用するメリットは、専用のサービス カードが不要で、転送容量や遅延にほとんど影響しないことです。インライン サービスは通常、サービス カードを使用するよりも優れたパフォーマンスを提供しますが、その機能はより基本的なものになる傾向があります。たとえば、インライン NAT はスタティック NAT のみをサポートします。
このインラインNATの例では、ソース静的NATを使用しています。
インラインNATのタイプ
インラインNATには2種類あります。
インターフェイススタイル:インターフェイスに到着するパケットがサービスセットを介して送信されるインターフェイスベースの方法。インターフェイスを通過するすべてのトラフィックにNATを適用するには、インターフェイススタイルNATを使用します。
インターフェイススタイルのNATは、ネクストホップスタイルのNATよりも設定が簡単です。
Next-hop-style:ルーティングインスタンスが、特定のネットワークから発信されたパケットまたはインラインサービスを通じて特定の宛先宛てのパケットを転送する場合に通常使用されるルートベースの方式。
この例では、インライン 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ルーティングテーブルと共有するには、以下を行います。
ルート共有を設定した後、顧客への直接インターフェイスルートとBGPルートLANが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 に到達できるようになります。
ネクストホップスタイルのインラインNATの検証
PE2でのインターフェイススタイルインラインNATの設定
カスタマーCからのトラフィックには、インターフェイススタイルのインラインNATを使用しています。このセクションでは、ネクストホップスタイルのNATよりもシンプルな設定を使用するインターフェイスベースのインラインNATを設定する方法を示します。
このセクションでは、次の構成項目を使用します。
インラインサービスインターフェイス—MPCのパケット転送エンジンに存在する仮想インターフェイス。サービスにアクセスするために、トラフィックはsi-(サービスインライン)インターフェイスに出入りします。
サービスセット:実行されるサービスを定義し、どのインラインインターフェイスがサービスセットに出入りするトラフィックを特定するかを識別します。このセクションでは、インターフェイスに到着するパケットがインライン サービス インターフェイスを介して送信されるインターフェイス スタイルのサービス セットを実装します。
NATルール:if-then構造(ファイアウォールフィルターに類似)を使用して一致条件を定義し、一致するトラフィックにアドレス変換を適用します。
NAT プール:NAT ルールが変換に使用するユーザー定義の IP アドレスのセット。
VRFルーティングインスタンス—si-インターフェイスが顧客CのVRFルーティングインスタンスに追加されます。
図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;
}