Migración de configuraciones antiguas a la arquitectura actual de vSRX
La migración de configuraciones de IBM Cloud® Juniper vSRX de la arquitectura antigua a la arquitectura actual debe considerarse detenidamente.
Normalmente, los despliegues de vSRX 18.4 utilizan la arquitectura actual, incluida la oferta vSRX 18.4 1G SR-IOV. La oferta estándar anterior vSRX 18.4 1 G se basa en puentes Linux y tiene diferentes configuraciones de red en el host de Ubuntu, el hipervisor de KVM y la configuración de vSRX. Los valores de host y KVM no requieren ningún paso de migración especial, ya que el proceso de automatización gestiona los cambios de configuración. Sin embargo, si desea importar la configuración de vSRX de la arquitectura antigua a la configuración de vSRX actual, es probable que tenga que refactorizar parte de la configuración.
Migración de configuraciones autónomas de 1G vSRX
Existen algunos pasos que potencialmente necesita para convertir los valores de configuración de vSRX en una instancia autónoma 18.4 1G Pública + Privada Linux Bridge (arquitectura heredada) a una instancia autónoma 18.4 1G Pública + Privada SR-IOV (arquitectura actual).
Puede encontrar una configuración predeterminada de ejemplo para la arquitectura actual basada en SR-IOV aquí.
A continuación se muestra una configuración predeterminada de ejemplo para Linux Bridge (arquitectura antigua). El ejemplo muestra las instancias de vSRX que se han suministrado en diferentes pods de centro de datos. Como resultado, las VLAN
de tránsito (native-vlan-id) son diferentes.
## 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;
}
}
Sección de conversión de la interfaz
En este ejemplo 1G Público + Privado autónomo, la arquitectura actual añade interfaces agregadas ae0 y ae1. Correlacione estas interfaces con lo que la arquitectura heredada define como ge-0/0/0 (private / ae0) y ge-0/0/1 (public / ae1). Además, la nueva arquitectura añade ge-0/0/2 y ge-0/0/3 para dar soporte a la redundancia en las interfaces vSRX. En la arquitectura antigua, existía redundancia en las interfaces
de enlace de host (hipervisor) (bond0 private / bond1 public). En la arquitectura actual, los VF SR-IOV que se correlacionan directamente con las interfaces ge se utilizan para la redundancia.
Puede comparar las diferencias de estas configuraciones de vSRX en Interfaz autónoma de vSRX (arquitectura actual) e Interfaz autónoma de vSRX (arquitectura antigua).
Cualquier VLAN privada que se haya configurado previamente para ge-0/0/0 debe direccionarse a través de ae0. Además, cualquier VLAN pública que haya configurado previamente para ge-0/0/1 se debe direccionar
a través de ae1.
Sección de conversión de las zonas
Las zonas de seguridad predeterminadas que anteriormente hacían referencia a ge-0/0/0 y ge-0/0/1, ahora deben utilizar las interfaces ae0.0 (SL-PRIVATE) y ae1.0 (SL-PUBLIC). Se aplican los
mismos cambios a las zonas que anteriormente hacían referencia a ge-0/0/0 y ge-0/0/1.
Otros cambios
La configuración de dispositivo agregada requiere añadir lo siguiente en la arquitectura actual:
set chassis aggregated-devices ethernet device-count 10
La configuración JWEB también incluye las interfaces agregadas:
set system services web-management https interface ae0.0
set system services web-management https interface ae1.0
Migración de configuraciones de alta disponibilidad de vSRX de 1 G
Para las configuraciones de alta disponibilidad, los cambios de vSRX principales al importar configuraciones de la arquitectura antigua a la arquitectura actual son pequeños cambios en las correlaciones de interfaz.
La configuración de alta disponibilidad de SR-IOV de 1 G para la arquitectura actual añade interfaces de vSRX adicionales por redundancia, en lugar de utilizar interfaces de enlace del host (hipervisor). Esto es posible porque el host ahora utiliza VF SR-IOV que se pueden correlacionar directamente con las interfaces vSRX. Las configuraciones que se exportaron desde la arquitectura heredada deben tener esto en cuenta si se importan en la arquitectura actual.
La configuración de vSRX para la arquitectura actual para 1G HA se puede encontrar aquí. Mientras que la configuración de vSRX para la arquitectura heredada para 1G HA se puede encontrar aquí.
Las interfaces ge-0/* y ge-7/* adicionales se han añadido y asociado con las interfaces reth existentes, que estaban presentes tanto en la arquitectura existente como en la actual. Permiten la redundancia
dentro de la configuración de vSRX. La redundancia también se configura para las interfaces de fab.