Traditionelle Konfigurationen auf die aktuelle vSRX-Architektur migrieren
Die Migration von IBM Cloud® Juniper vSRX-Konfigurationen von der traditionellen auf die aktuelle Architektur erfordert ein sorgfältiges Vorgehen.
Gewöhnlich verwenden vSRX 18.4-Implementierungen die aktuelle Architektur, einschließlich des Angebots vSRX 18.4 1G SR-IOV. Das ältere 1G-Standardangebot von vSRX Version 18.4 basiert auf der Linux-Überbrückung und weist für den Ubuntu-Host, den KVM-Hypervisor sowie die vSRX-Konfiguration abweichende Netzkonfigurationen auf. Für die Host-und KVM-Einstellungen sind keine speziellen Migrationsschritte erforderlich, da der Automatisierungsprozess die Konfigurationsänderungen durchführt. Falls Sie jedoch die vSRX-Konfiguration aus der traditionellen Architektur in die aktuelle vSRX-Konfiguration importieren wollen, müssen Sie wahrscheinlich einen Teil der Konfiguration einem Refactoring unterziehen.
1G vSRX-Standalone-Konfigurationen migrieren
Es gibt einige Schritte, die möglicherweise erforderlich sind, um vSRX-Konfigurationseinstellungen in einer eigenständigen Instanz von 18.4 1G Public + Private Linux Bridge (traditionelle Architektur) in eine eigenständige Instanz von 18.4 1G Public + Private SR-IOV (aktuelle Architektur) zu konvertieren.
Eine Beispielstandardkonfiguration für die auf SR-IOV basierende aktuelle Architektur finden Sie hier.
Das folgende Beispiel zeigt eine Standardkonfiguration für die Linux-Brücke (traditionelle Architektur) Die vSRX-Instanzen im Beispiel wurden in unterschiedlichen Rechenzentrum-Pods bereitgestellt. Daher unterscheiden sich die Transit-VLANs
(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;
}
}
Abschnitt für Schnittstellen konvertieren
In diesem eigenständigen Beispiel 1G Public + Private fügt die aktuelle Architektur aggregierte Schnittstellen ae0 und ae1 hinzu. Ordnen Sie diese Schnittstellen der Definition der traditionellen Architektur als ge-0/0/0 (private / ae0) und ge-0/0/1 (public / ae1) zu. Außerdem fügt die neue Architektur ge-0/0/2 und ge-0/0/3 hinzu, um Redundanz innerhalb der vSRX-Schnittstellen zu unterstützen. In der alten Architektur bestand Redundanz
an den Bondschnittstellen des Hosts (Hypervisor) (bond0 private / bond1 public). In der aktuellen Architektur werden SR-IOV-VFs, die direkt den ge-Schnittstellen zugeordnet werden, für Redundanz verwendet.
Diese Unterschiede bei der vSRX-Konfiguration können Sie mithilfe der Abschnitte Schnittstelle für eigenständige vSRX-Instanz (aktuelle Architektur) und Schnittstelle für eigenständige vSRX-Instanz (traditionelle Architektur) vergleichen.
Alle privaten VLANs, die zuvor für ge-0/0/0 konfiguriert wurden, müssen über ae0 weitergeleitet werden. Außerdem müssen alle öffentlichen VLANs, die zuvor für ge-0/0/1 konfiguriert wurden, über ae1 weitergeleitet werden.
Abschnitt für Zonen konvertieren
Alle Standardsicherheitszonen, die zuvor ge-0/0/0 und ge-0/0/1 referenziert haben, sollten jetzt die Schnittstellen ae0.0 (SL-PRIVATE) und ae1.0 (SL-PUBLIC) verwenden. Dieselben Änderungen
gelten auch für alle Zonen, die zuvor ge-0/0/0 und ge-0/0/1 referenziert haben.
Sonstige Änderungen
Für die aggregierte Einheitenkonfiguration muss in der aktuellen Architektur Folgendes hinzugefügt werden:
set chassis aggregated-devices ethernet device-count 10
Die JWEB-Konfiguration enthält auch die zusammengefassten Schnittstellen:
set system services web-management https interface ae0.0
set system services web-management https interface ae1.0
vSRX-1G-Konfigurationen mit Hochverfügbarkeit migrieren
Für Hochverfügbarkeitskonfigurationen bestehen die vSRX-Änderungen beim Importieren von Konfigurationen aus der traditionellen Architektur in die neue Architektur hauptsächlich aus geringfügigen Änderungen an den Schnittstellenzuordnungen.
Die 1G-Konfiguration mit SR-IOV und Hochverfügbarkeit (1G SR-IOV HA) für die aktuelle Architektur fügt zur Redundanz weitere vSRX-Schnittstellen hinzu, statt die bond-Schnittstellen des Hosts (Hypervisors) zu nutzen. Dies ist möglich, da der Host jetzt SR-IOV-VFs verwendet, die direkt den vSRX-Schnittstellen zugeordnet werden können. Konfigurationen, die aus der traditionellen Architektur exportiert wurden, müssen dies berücksichtigen, wenn sie in die aktuelle Architektur importiert werden.
Die vSRX-Konfiguration für die aktuelle Architektur für 1G HA finden Sie hier. Die vSRX-Konfiguration für die traditionelle Architektur für 1G HA finden Sie hier.
Die zusätzlichen Schnittstellen ge-0/* und ge-7/* wurden hinzugefügt und den vorhandenen reth-Schnittstellen zugeordnet, die sowohl in der traditionellen als auch in der aktuellen Architektur vorhanden
waren. Sie ermöglichen Redundanz innerhalb der vSRX-Konfiguration. Redundanz wird auch für die fab-Schnittstellen konfiguriert.