将旧配置迁移到当前 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 (旧体系结构) 的样本缺省配置。 此示例显示在不同 Datacenter pod 中供应的 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;
}
}
转换接口部分
在此 1G Public + Private 独立示例中，当前体系结构添加了聚集接口 ae0 和 ae1。 将这些接口映射到旧体系结构定义为 ge-0/0/0 (private / ae0) 和 ge-0/0/1 (public / ae1) 的接口。 此外，新体系结构还添加了 ge-0/0/2 和 ge-0/0/3，以支持
vSRX 接口中的冗余。 在旧体系结构中，在主机 (Hypervisor) 绑定接口 (bond0 private / bond1 public) 上存在冗余。在当前体系结构中，直接映射到 ge 接口的 SR-IOV VF 用于冗余。
您可以在 vSRX 独立接口(当前体系结构) 和 vSRX 独立接口(旧体系结构) 中比较这些 vSRX 配置差异。
先前为 ge-0/0/0 配置的任何专用 VLAN 都需要通过 ae0 进行路由。 此外，您先前为 ge-0/0/1 配置的任何公用 VLAN 都需要通过 ae1 进行路由。
转换“区域”部分
先前引用了 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 配置添加了其他 vSRX 接口以实现冗余，而不是使用主机 (管理程序) 结合接口。 这是可能的，因为主机现在使用可直接映射到 vSRX 接口的 SR-IOV VF。 如果将从旧体系结构导出的配置导入到当前体系结构中，那么必须将这些配置考虑在内。
此处 可以找到 1G HA 的当前体系结构的 vSRX 配置。 在 此处 可以找到 1G HA 的旧体系结构的 vSRX 配置。
额外的 ge-0/* 和 ge-7/* 接口已添加并与现有 reth 接口相关联，这些接口同时存在于旧体系结构和当前体系结构中。 这些允许在 vSRX 配置中实现冗余。 还为 fab 接口配置了冗余。