Migrazione delle configurazioni legacy all'architettura vSRX corrente
La migrazione delle configurazioni IBM Cloud® Juniper vSRX dall'architettura legacy a quella corrente richiede un'attenta considerazione.
Di solito, le distribuzioni di vSRX 18.4 utilizzano l'architettura corrente, incluso vSRX 18.4 1G SR - IOV. La precedente offerta standard vSRX 18.4 1G si basa sul bridging Linux e ha diverse configurazioni di rete sull'host Ubuntu, l'hypervisor KVM e nella configurazione vSRX. Le impostazioni host e KVM non richiedono alcuna procedura di migrazione speciale, in quanto il processo di automazione gestisce le modifiche di configurazione. Tuttavia, se vuoi importare la configurazione vSRX dall'architettura legacy nella configurazione vSRX corrente, probabilmente devi eseguire il refactoring di parte della configurazione.
Migrazione di configurazioni autonome 1G vSRX
Ci sono alcuni passi di cui hai potenzialmente bisogno per convertire le impostazioni di configurazione vSRX su un'istanza Standalone 18.4 1G Pubblico + privato Linux Bridge (architettura legacy) in un'istanza Standalone 18.4 1G Pubblico + privato SR - IOV (architettura corrente).
Puoi trovare una configurazione predefinita di esempio per l'architettura corrente basata su SR - IOV qui.
Di seguito viene riportata una configurazione predefinita di esempio per il bridge Linux (architettura legacy). L'esempio mostra le istanze vSRX di cui è stato eseguito il provisioning in diversi pod Datacenter. Di conseguenza, le VLAN di transito
(native-vlan-id) sono diverse.
## 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;
}
}
Conversione della sezione di interfaccia
In questo esempio autonomo 1G Public + Private, l'architettura corrente aggiunge le interfacce aggregate ae0 e ae1. Associare queste interfacce a ciò che l'architettura legacy definisce come ge-0/0/0 (private / ae0) e ge-0/0/1 (public / ae1). Inoltre, la nuova architettura aggiunge ge-0/0/2 e ge-0/0/3 per supportare la ridondanza all'interno delle interfacce vSRX. Nella vecchia architettura, la ridondanza esisteva
sulle interfacce di collegamento host (Hypervisor) (bond0 private / bond1 public). Nell'architettura corrente, i VF SR - IOV associati direttamente alle interfacce ge vengono utilizzati per la ridondanza.
Puoi confrontare queste differenze di configurazione vSRX in vSRX Interfaccia autonoma(architettura corrente) e vSRX Interfaccia autonoma(architettura legacy).
Qualsiasi VLAN privato precedentemente configurato per ge-0/0/0 deve essere instradato tramite ae0. Inoltre, qualsiasi VLAN pubblica che hai precedentemente configurato per ge-0/0/1 deve essere instradato
tramite ae1.
Conversione della sezione zone
Eventuali zone di sicurezza predefinite che precedentemente hanno fatto riferimento a ge-0/0/0 e ge-0/0/1 dovrebbero ora utilizzare le interfacce ae0.0 (SL-PRIVATE) e ae1.0 (SL-PUBLIC). Le
stesse modifiche si applicano anche a eventuali zone che precedentemente hanno fatto riferimento a ge-0/0/0 e ge-0/0/1.
Altre modifiche
La configurazione del dispositivo aggregato richiede la seguente aggiunta nell'architettura corrente:
set chassis aggregated-devices ethernet device-count 10
La configurazione JWEB include anche le interfacce aggregate:
set system services web-management https interface ae0.0
set system services web-management https interface ae1.0
Migrazione delle configurazioni di 1G vSRX High Availability
Per le configurazioni ad alta disponibilità, le modifiche principali di vSRX quando si importano le configurazioni dall'architettura legacy all'architettura corrente sono piccole modifiche alle associazioni dell'interfaccia.
La configurazione della HA SR - IOV 1G per l'architettura corrente aggiunge ulteriori interfacce vSRX per la ridondanza, invece di utilizzare le interfacce di collegamento host (hypervisor). Ciò è possibile poiché l'host ora utilizza VF SR - IOV che possono essere associate direttamente alle interfacce vSRX. Le configurazioni che sono state esportate dall'architettura legacy devono tenere conto di questo se vengono importati nell'architettura corrente.
La configurazione vSRX per l'architettura corrente per 1G HA può essere trovata qui. Mentre la configurazione vSRX per l'architettura legacy per 1G HA può essere trovata qui.
Le interfacce aggiuntive ge-0/* e ge-7/* sono state aggiunte e associate con le interfacce reth esistenti, presenti sia nell'architettura legacy che in quella corrente. Questi consentono la ridondanza all'interno
della configurazione vSRX. La ridondanza è configurata anche per le interfacce fab.