Migration des configurations existantes à l'architecture actuelle du vSRX
La migration des configurations du IBM Cloud® Juniper vSRX de l'ancienne architecture à l'architecture actuelle requiert une attention particulière.
Généralement, les déploiements vSRX 18.4 utilisent l'architecture actuelle, y compris l'offre vSRX 18.4 1G SR-IOV. L'ancienne offre vSRX 18.4 1G standard est basée sur Linux Bridge et possède des configurations réseau différentes sur l'hôte Ubuntu, l'hyperviseur KVM et dans la configuration de vSRX. Les paramètres de l'hôte et du KVM ne nécessitent aucune étape de migration particulière, car le processus d'automatisation gère les changements de configuration. Toutefois, si vous souhaitez importer la configuration vSRX de l'ancienne architecture dans la configuration vSRX actuelle, vous devrez éventuellement modifier une partie de la configuration.
Migration des configurations autonomes 1G vSRX
Il est possible que vous deviez convertir des paramètres de configuration vSRX sur une instance 18.4 1G publique + privée Linux Bridge (architecture existante) en instance 18.4 1G publique + privée SR-IOV (architecture en cours) autonome.
Vous trouverez un exemple de configuration par défaut pour l'architecture actuelle basée sur SR-IOV ici.
Voici un exemple de configuration par défaut de Linux Bridge (ancienne architecture). L'exemple montre des instances vSRX qui ont été mises à disposition dans différents pods du centre de données. Par conséquent, les réseaux locaux virtuels
de transit (native-vlan-id) sont différents.
## 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;
}
}
Conversion de la section de l'interface
Dans cet exemple 1G Public + Private autonome, l'architecture actuelle ajoute des interfaces agrégées ae0 et ae1. Mappez ces interfaces à ce que l'architecture existante définit comme ge-0/0/0 (private / ae0) et ge-0/0/1 (public / ae1). De plus, la nouvelle architecture ajoute ge-0/0/2 et ge-0/0/3 pour prendre en charge la redondance dans les interfaces vSRX. Dans l'ancienne architecture, la redondance existait
au niveau des interfaces de liaison de l'hôte (hyperviseur) (bond0 private / bond1 public). Dans l'architecture actuelle, les VFs SR-IOV qui mappent directement aux interfaces ge sont utilisées pour la redondance.
Vous pouvez comparer ces différences de configuration vSRX dans les rubriques Interface vSRX autonome (architecture actuelle) et Interface vSRX autonome (ancienne architecture).
Tout VLAN privé qui était précédemment configuré pour ge-0/0/0 doit être acheminé par ae0. En outre, tout VLAN public que vous avez configuré précédemment pour ge-0/0/1 doit être acheminé par ae1.
Conversion de la section des zones
Toutes les zones de sécurité par défaut qui faisaient auparavant référence à ge-0/0/0 et ge-0/0/1 doivent maintenant utiliser les interfaces ae0.0 (SL-PRIVATE) et ae1.0 (SL-PUBLIC). Les mêmes
modifications s'appliquent également à toutes les zones qui faisaient auparavant référence à ge-0/0/0 et ge-0/0/1.
Autres changements
La configuration des dispositifs agrégés nécessite l'ajout suivant dans l'architecture actuelle :
set chassis aggregated-devices ethernet device-count 10
La configuration JWEB inclut également les interfaces agrégées:
set system services web-management https interface ae0.0
set system services web-management https interface ae1.0
Migration des configurations vSRX 1G haute disponibilité
Pour les configurations à haute disponibilité, les principales modifications apportées au vSRX lors de l'importation de configurations de l'ancienne architecture vers l'architecture actuelle sont de petites modifications des mappages d'interface.
La configuration SR-IOV 1G haute disponibilité de l'architecture actuelle ajoute des interfaces vSRX supplémentaires pour la redondance, au lieu d'utiliser les interfaces de liaison avec l'hôte (hyperviseur). Cela est possible car l'hôte utilise désormais des VFs SR-IOV qui peuvent être mappées directement aux interfaces vSRX. Les configurations exportées à partir de l'architecture existante doivent en tenir compte si elles sont importées dans l'architecture en cours.
La configuration vSRX de l'architecture en cours pour la haute disponibilité 1G est disponible ici. Alors que la configuration vSRX de l'architecture existante pour la haute disponibilité 1G est disponible ici.
Les interfaces ge-0/* et ge-7/* supplémentaires ont été ajoutées et associées aux interfaces reth existantes, qui étaient présentes à la fois dans l'architecture existante et dans l'architecture en cours.
Celles-ci permettent une redondance au sein de la configuration vSRX. La redondance est également configurée pour les interfaces fab.