現行 vSRX アーキテクチャーへのレガシー構成のマイグレーション
レガシー・アーキテクチャーから最新アーキテクチャーへの IBM Cloud® Juniper vSRX 構成のマイグレーションには、注意深い検討が必要です。
通常、 vSRX 18.4 デプロイメントでは、 vSRX 18.4 1G SR-IOV オファリングを含む現行のアーキテクチャーが使用されます。 古い vSRX 18.4 1G Standard オファリングは Linux ブリッジングに基づいており、Ubuntu ホスト、KVM ハイパーバイザー、および vSRX 構成において、異なるネットワーク構成を持ちます。 構成の変更は自動化プロセスによって処理されるので、ホストと KVM の設定には特別なマイグレーション・ステップは不要です。 ただし、レガシー・アーキテクチャーの vSRX 構成を現行の vSRX 構成にインポートする場合は、構成の一部のリファクタリングが必要となる可能性があります。
1G vSRX スタンドアロン構成のマイグレーション
スタンドアロン 18.4 1G Public + Private Linux Bridge (レガシー・アーキテクチャー) インスタンスの vSRX 構成設定をスタンドアロン 18.4 1G Public + Private SR-IOV (現行アーキテクチャー) インスタンスに変換する必要が生じる可能性があるステップがいくつかあります。
SR-IOV ベースの現行アーキテクチャーのデフォルト構成の例については、 ここ を参照してください。
以下は、Linux Bridge (レガシー・アーキテクチャー) のデフォルト構成のサンプルです。 この例は、複数の異なるデータ・センター・ポッドにプロビジョンされた vSRX インスタンスを示しています。 結果として、トランジット VLAN (native-vlan-id
) は異なります。
## Last commit: 2020-04-16 22:48:33 UTC by root
version 18.4R1-S1.3;
system {
login {
class security {
permissions [ security-control view-configuration ];
}
user admin {
uid 2000;
class super-user;
authentication {
encrypted-password "$6$vKPIcB3I$XlDRg3Oto9tLa7zRPkalSfonrKUEJI7U16XX2lrke3k2sPaV.CY0CJhSBIPx5aXhqo7h1GWPhhMbv0Ce1WANO."; ## SECRET-DATA
}
}
}
root-authentication {
encrypted-password "$6$cbXBMc8b$jHd6LtR4OjXvjmgubQXAlofNonk6lLbNPs35beda7ffEV4XKEUQiEf1XUA3mMvJv2V1YET3kiWBogqz8h2zB7."; ## SECRET-DATA
}
services {
ssh {
root-login allow;
}
netconf {
ssh {
port 830;
}
}
web-management {
http {
interface fxp0.0;
}
https {
port 8443;
system-generated-certificate;
interface [ fxp0.0 ge-0/0/0.0 ge-0/0/1.0 ];
}
session {
session-limit 100;
}
}
}
host-name asloma-e2e-tc15-18-1g-1270-sa-vsrx-vSRX;
name-server {
10.0.80.11;
10.0.80.12;
}
syslog {
user * {
any emergency;
}
file messages {
any any;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
}
ntp {
server 10.0.77.54;
}
}
security {
log {
mode stream;
report;
}
address-book {
global {
address SL8 10.1.192.0/20;
address SL9 10.1.160.0/20;
address SL4 10.2.128.0/20;
address SL5 10.1.176.0/20;
address SL6 10.1.64.0/19;
address SL7 10.1.96.0/19;
address SL1 10.0.64.0/19;
address SL2 10.1.128.0/19;
address SL3 10.0.86.0/24;
address SL20 10.3.80.0/20;
address SL18 10.2.176.0/20;
address SL19 10.3.64.0/20;
address SL16 10.2.144.0/20;
address SL17 10.2.48.0/20;
address SL14 10.1.208.0/20;
address SL15 10.2.80.0/20;
address SL12 10.2.112.0/20;
address SL13 10.2.160.0/20;
address SL10 10.2.32.0/20;
address SL11 10.2.64.0/20;
address SL_PRIV_MGMT 10.129.33.87/32;
address SL_PUB_MGMT 161.202.136.77/32;
address-set SERVICE {
address SL8;
address SL9;
address SL4;
address SL5;
address SL6;
address SL7;
address SL1;
address SL2;
address SL3;
address SL20;
address SL18;
address SL19;
address SL16;
address SL17;
address SL14;
address SL15;
address SL12;
address SL13;
address SL10;
address SL11;
}
}
}
screen {
ids-option untrust-screen {
icmp {
ping-death;
}
ip {
source-route-option;
tear-drop;
}
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
queue-size 2000; ## Warning: 'queue-size' is deprecated
timeout 20;
}
land;
}
}
}
policies {
from-zone SL-PRIVATE to-zone SL-PRIVATE {
policy Allow_Management {
match {
source-address any;
destination-address [ SL_PRIV_MGMT SERVICE ];
application any;
}
then {
permit;
}
}
}
from-zone SL-PUBLIC to-zone SL-PUBLIC {
policy Allow_Management {
match {
source-address any;
destination-address SL_PUB_MGMT;
application [ junos-ssh junos-https junos-http junos-icmp-ping ];
}
then {
permit;
}
}
}
}
zones {
security-zone SL-PRIVATE {
interfaces {
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
all;
}
}
}
}
}
security-zone SL-PUBLIC {
interfaces {
ge-0/0/1.0 {
host-inbound-traffic {
system-services {
all;
}
}
}
}
}
}
}
interfaces {
ge-0/0/0 {
description PRIVATE_VLANs;
flexible-vlan-tagging;
native-vlan-id 1214;
unit 0 {
vlan-id 1214;
family inet {
address 10.129.33.87/26;
}
}
}
ge-0/0/1 {
description PUBLIC_VLAN;
flexible-vlan-tagging;
native-vlan-id 764;
unit 0 {
vlan-id 764;
family inet {
address 161.202.136.77/29;
}
family inet6 {
address 2401:c900:1001:0210:0000:0000:0000:000a/64;
}
}
}
fxp0 {
unit 0;
}
lo0 {
unit 0 {
family inet {
filter {
input PROTECT-IN;
}
address 127.0.0.1/32;
}
}
}
}
firewall {
filter PROTECT-IN {
term PING {
from {
destination-address {
161.202.136.77/32;
10.129.33.87/32;
}
protocol icmp;
}
then accept;
}
term SSH {
from {
destination-address {
161.202.136.77/32;
10.129.33.87/32;
}
protocol tcp;
destination-port ssh;
}
then accept;
}
term WEB {
from {
destination-address {
161.202.136.77/32;
10.129.33.87/32;
}
protocol tcp;
port 8443;
}
then accept;
}
term DNS {
from {
protocol udp;
source-port 53;
}
then accept;
}
}
}
routing-options {
static {
route 166.9.0.0/16 next-hop 10.129.33.65;
route 0.0.0.0/0 next-hop 161.202.136.73;
route 161.26.0.0/16 next-hop 10.129.33.65;
route 10.0.0.0/8 next-hop 10.129.33.65;
}
}
interface セクションの変換
この 1G Public + Private スタンドアロンの例では、現在のアーキテクチャーによって集約されたインターフェース ae0
および ae1
が追加されます。 これらのインターフェースを、レガシー・アーキテクチャーで ge-0/0/0 (private / ae0)
および ge-0/0/1 (public / ae1)
として定義されているものにマップします。
また、新しいアーキテクチャーでは、 vSRX インターフェース内の冗長性をサポートするために ge-0/0/2
および ge-0/0/3
が追加されています。 古いアーキテクチャーでは、冗長性はホスト (ハイパーバイザー) 結合インターフェース (bond0 private / bond1 public
) に存在していました。 現行のアーキテクチャーでは、 ge
インターフェースに直接マップされる
SR-IOV VF が冗長性のために使用されます。
vSRX 構成に関するこれらの違いは、vSRX スタンドアロン・インターフェース (最新アーキテクチャー) と vSRX スタンドアロン・インターフェース (レガシー・アーキテクチャー) で比較できます。
以前 ge-0/0/0
に構成されていたプライベート VLAN は、ae0
を経由してルーティングする必要があります。 さらに、以前 ge-0/0/1
に構成されていたパブリック VLAN は、ae1
を経由してルーティングする必要があります。
zones セクションの変換
以前 ge-0/0/0
と ge-0/0/1
を参照していたデフォルトのセキュリティー・ゾーンは、今後は ae0.0 (SL-PRIVATE)
インターフェースと ae1.0 (SL-PUBLIC)
インターフェースを使用する必要があります。 同じ変更が、以前 ge-0/0/0
と ge-0/0/1
を参照していたゾーンにも当てはまります。
その他の変更
最新アーキテクチャーで、集約デバイス構成に以下を追加する必要があります。
set chassis aggregated-devices ethernet device-count 10
JWEB 構成には、以下の集約インターフェースも含まれます。
set system services web-management https interface ae0.0
set system services web-management https interface ae1.0
1G vSRX 高可用性構成のマイグレーション
高可用性構成の場合、レガシー・アーキテクチャーから最新アーキテクチャーに構成をインポートする際の vSRX の主な変更は、インターフェース・マッピングの小変更です。
最新アーキテクチャーの 1G SR-IOV HA 構成では、冗長性のために、ホスト (ハイパーバイザー) の bond インターフェースを使用する代わりに、vSRX インターフェースが追加されています。 これは、ホストが vSRX インターフェースに直接マップできる SR-IOV VF を使用するようになったためです。 レガシー・アーキテクチャーからエクスポートされた構成は、現行アーキテクチャーにインポートされる場合、これを考慮する必要があります。
1G HA の現行アーキテクチャーの vSRX 構成については、 ここ を参照してください。 1G HA のレガシー・アーキテクチャーの vSRX 構成については、 ここ を参照してください。
追加の ge-0/*
インターフェースおよび ge-7/*
インターフェースが追加され、既存の reth
インターフェースに関連付けられました。これらのインターフェースは、レガシー・アーキテクチャーと現行アーキテクチャーの両方に存在していました。 これらにより、vSRX 構成内の冗長性が可能になっています。 fab
インターフェースにも冗長性が構成されています。