Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuration requise pour le pare-feu virtuel vSRX sur KVM

Cette section présente un aperçu des exigences relatives au déploiement d’une instance de pare-feu virtuel vSRX sur KVM.

Spécifications logicielles

Le tableau ci-dessous répertorie les spécifications logicielles requises pour le déploiement du pare-feu virtuel vSRX dans un environnement KVM. Le tableau décrit la version de Junos OS dans laquelle une spécification logicielle particulière pour le déploiement du pare-feu virtuel vSRX sur KVM a été introduite. Vous devrez télécharger une version spécifique de Junos OS pour profiter de certaines fonctionnalités.

PRUDENCE:

Un problème de journalisation des modifications de page (PML) lié au noyau hôte KVM peut empêcher le pare-feu virtuel vSRX de démarrer correctement. Si vous rencontrez ce problème avec le pare-feu virtuel vSRX, nous vous recommandons de désactiver la PML au niveau du noyau hôte. Reportez-vous à la section Préparer votre serveur pour l’installation de vSRX pour plus d’informations sur la désactivation du PML dans le cadre de l’activation de la virtualisation imbriquée.

Tableau 1 : Fonctionnalités prises en charge sur le pare-feu virtuel vSRX
Spécification des fonctionnalités Lancement de la version de Junos OS
vCPU/Mémoire

2 vCPU / 4 Go de RAM

Junos OS version 15.1X49-D15 et Junos OS version 17.3R1 (pare-feu virtuel vSRX)

5 vCPU / 8 Go de RAM

Junos OS version 15.1X49-D70 et Junos OS version 17.3R1 (pare-feu virtuel vSRX)

9 vCPU / 16 Go de RAM

Junos OS version 18.4R1 (pare-feu virtuel vSRX)

Junos OS version 19.1R1 (pare-feu virtuel vSRX 3.0)

17 vCPU / 32 Go de RAM

Junos OS version 18.4R1 (pare-feu virtuel vSRX)

Junos OS version 19.1R1 (pare-feu virtuel vSRX 3.0)

Mise à l’échelle flexible de la capacité des sessions de flux grâce à une vRAM supplémentaire

NA

Junos OS version 19.1R1 (pare-feu virtuel vSRX)

Junos OS version 19.2R1 (pare-feu virtuel vSRX 3.0)

Prise en charge de la mise à l’échelle multicœur (RSS logiciel)

NA Junos OS version 19.3R1 (pare-feu virtuel vSRX 3.0 uniquement)

Réserver des cœurs de vCPU supplémentaires pour le moteur de routage (Pare-feu virtuel vSRX et Pare-feu virtuel vSRX 3.0)

NA  

Virtio (virtio-net, vhost-net) (pare-feu virtuel vSRX et pare-feu virtuel vSRX 3.0)

NA  
Hyperviseurs pris en charge

Prise en charge de l’hyperviseur KVM Linux

Note:

À partir des versions de Junos OS mentionnées ici, toutes les versions ultérieures de Junos OS prennent également en charge ces versions RHEL et ultérieures.

Ubuntu 14.04.5, 16.04 et 16.10

Junos OS version 18.4R1
Ubuntu 18.04 et 20.04 Junos OS version 20.4R1
Red Hat Enterprise Linux (RHEL) 7.3, 7.6 et 7.7 Junos OS version 18.4R1
Red Hat Enterprise Linux (RHEL) 8.2 Junos OS version 19.2R1
Red Hat Enterprise Linux (RHEL) 9 Junos OS version 23.4R1
CentOS 7.1, 7.2, 7.6 et 7.7 Junos OS version 20.4R1
Autres caractéristiques

Cloud-init

NA  

Mode d’alimentation IPSec (PMI)

NA  

Cluster de châssis

NA  

Distribution de sessions basée sur GTP TEID à l’aide du RSS logiciel

NA Oui (à partir de Junos OS version 19.3R1)

Moteur d’analyse antivirus sur l’appareil (Avira)

NA Oui (à partir de Junos OS version 19.4R1)

LLDP (en anglais seulement)

NA Oui (à partir de Junos OS version 21.1R1)

Interface de télémétrie Junos

NA Oui (à partir de Junos OS version 20.3R1)
Configuration requise

Accélération matérielle/indicateur de CPU VMX activé dans l’hyperviseur

NA  

Espace disque

16 Go (disques IDE ou SCSI) (pare-feu virtuel vSRX)

Junos OS version 15.1X49-D15 et Junos OS version 17.3R1

18 Go (pare-feu virtuel vSRX 3.0)

 
Tableau 2 : prise en charge de vNIC sur le pare-feu virtuel vSRX
Lancement de la version vNIC
Virtio SA et HA  
SR-IOV SA et HA sur Intel séries 82599/X520 Junos OS version 15.1X49-D90 et Junos OS version 17.3R1
SR-IOV SA et HA sur les séries Intel X710/XL710/XXV710 Junos OS version 15.1X49-D90
SR-IOV SA et HA sur Intel série E810 Junos OS version 21.2R1
Note:

À partir de Junos OS version 23.2R2, seul le pilote ICE 1.12.7 est compatible avec E810 avec vSRX 3.0. La version antérieure à la version 1.12.7 pose un problème de compatibilité et n’affichera pas le FPC en ligne.

SR-IOV SA et HA sur Mellanox ConnectX-3 Non pris en charge
SR-IOV SA et HA sur Mellanox ConnectX-4/5/6 (pilote MLX5 uniquement)

Junos OS version 18.1R1 (pare-feu virtuel vSRX)

Junos OS version 21.2R1 et ultérieure sur pare-feu virtuel vSRX 3.0

Relais PCI sur les séries Intel 82599/X520 Non pris en charge
Relais PCI sur les séries Intel X710/XL710 Non pris en charge

Kit de développement de plan de données (DPDK) version 17.05

Junos OS version 18.2R1

Kit de développement de plan de données (DPDK) version 18.11

À partir de Junos OS version 19.4R1, DPDK version 18.11 est pris en charge sur le pare-feu virtuel vSRX. Grâce à cette fonctionnalité, la carte d’interface réseau (NIC) Mellanox Connect sur le pare-feu virtuel vSRX prend désormais en charge OSPF, Multicast et VLAN.

Junos OS version 19.4R1

Kit de développement de plan de données (DPDK) version 20.11

À partir de la version 21.2R1 de Junos OS, nous avons mis à niveau le kit de développement de plan de données (DPDK) de la version 18.11 à la version 20.11. La nouvelle version prend en charge le pilote ICE Poll Mode Driver (PMD), qui active la prise en charge de la carte réseau physique Intel E810 série 100G sur le pare-feu virtuel vSRX 3.0.
Junos OS version 21.2R1
Note:

Un déploiement de pare-feu virtuel vSRX sur KVM nécessite que vous activiez la virtualisation matérielle sur un système d’exploitation hôte contenant un processeur compatible Intel Virtualization Technology (VT). Vous pouvez vérifier la compatibilité du processeur ici : http://www.linux-kvm.org/page/Processor_support

Le tableau ci-dessous répertorie les spécifications de la machine virtuelle de pare-feu virtuel vSRX.

À partir de Junos OS version 19.1R1, l’instance de pare-feu virtuel vSRX prend en charge le système d’exploitation invité utilisant 9 ou 17 vCPU avec une virtualisation d’E/S à racine unique sur Intel X710/XL710 sur l’hyperviseur KVM Linux pour une évolutivité et des performances améliorées.

Recommandations du noyau KVM pour le pare-feu virtuel vSRX

Le Tableau 3 répertorie la version du noyau Linux recommandée pour votre système d’exploitation hôte Linux lors du déploiement du pare-feu virtuel vSRX sur KVM. Le tableau décrit la version de Junos OS dans laquelle la prise en charge d’une version particulière du noyau Linux a été introduite.

Tableau 3 : Recommandations du noyau pour KVM

Linux Distribution

Version du noyau Linux

Version de Junos OS prise en charge

Centos

3.10.0.229

Mettez à niveau le noyau Linux pour capturer la version recommandée.

Junos OS version 15.1X49-D15 et Junos OS version 17.3R1 ou ultérieure

Ubuntu

3.16

Junos OS version 15.1X49-D15 et Junos OS version 17.3R1 ou ultérieure

4.4

Junos OS version 15.1X49-D15 et Junos OS version 17.3R1 ou ultérieure

18.04

Junos OS version 20.4R1 ou ultérieure

20.04

Junos OS version 20.4R1 ou ultérieure

RHEL

3.10

Junos OS version 15.1X49-D15 et Junos OS version 17.3R1 ou ultérieure

Packages Linux supplémentaires pour le pare-feu virtuel vSRX sur KVM

Le Tableau 4 répertorie les packages supplémentaires dont vous avez besoin sur votre système d’exploitation hôte Linux pour exécuter le pare-feu virtuel vSRX sur KVM. Consultez la documentation de votre système d’exploitation hôte pour savoir comment installer ces packages s’ils ne sont pas présents sur votre serveur.

Tableau 4 : packages Linux supplémentaires pour KVM

Colis

Version

Lien de téléchargement

libvirt

0.10.0

libvirt télécharger

virt-manager (Recommandé)

0.10.0

Virt-Manager Télécharger

Spécifications matérielles

Le Tableau 5 répertorie les spécifications matérielles de la machine hôte qui exécute la machine virtuelle de pare-feu virtuel vSRX.

Tableau 5 : Spécifications matérielles de la machine hôte

Composant

Spécification

Type de processeur hôte

Processeur Intel x86_64 multicœur

Note:

DPDK nécessite la prise en charge de la virtualisation Intel VT-x/VT-d dans le processeur. Reportez-vous à la section À propos de la technologie de virtualisation Intel.

Prise en charge de la carte réseau physique pour le pare-feu virtuel vSRX et le pare-feu virtuel vSRX 3.0

  • Virtio

  • SR-IOV (Intel X710/XL710, X520/540, 82599)

  • SR-IOV (Mellanox ConnectX-3/ConnectX-3 Pro et Mellanox ConnectX-4 EN/ConnectX-4 Lx EN)

Note:

Si vous utilisez SR-IOV avec les adaptateurs de la famille Mellanox ConnectX-3 ou ConnectX-4, installez si nécessaire le dernier pilote MLNX_OFED Linux sur l’hôte Linux. Voir Mellanox OpenFabrics Enterprise Distribution pour Linux (MLNX_OFED).

Note:

Vous devez activer les extensions Intel VT-d pour fournir une prise en charge matérielle de l’affectation directe de périphériques physiques par invité. Reportez-vous à la section Configurer SR-IOV et PCI sur KVM.

Prise en charge de la carte réseau physique pour pare-feu virtuel vSRX 3.0

Prend en charge SR-IOV sur Intel X710/XL710/XXV710 et Intel E810.

Meilleures pratiques pour améliorer les performances du pare-feu virtuel vSRX

Passez en revue les pratiques suivantes pour améliorer les performances du pare-feu virtuel vSRX.

Noeuds NUMA

L’architecture de serveur x86 se compose de plusieurs sockets et de plusieurs cœurs au sein d’un socket. Chaque socket dispose d’une mémoire qui est utilisée pour stocker les paquets lors des transferts d’E/S de la carte réseau vers l’hôte. Pour lire efficacement les paquets de la mémoire, les applications invitées et les périphériques associés (tels que la carte réseau) doivent résider dans un socket unique. Une pénalité est associée au fait de s’étendre sur les sockets du processeur pour les accès à la mémoire, ce qui peut entraîner des performances non déterministes. Pour le pare-feu virtuel vSRX, nous recommandons que tous les vCPU de la machine virtuelle pare-feu virtuel vSRX se trouvent sur le même nœud physique non uniforme d’accès à la mémoire (NUMA) pour des performances optimales.

PRUDENCE:

Le moteur de transfert de paquets (PFE) du pare-feu virtuel vSRX ne répond plus si la topologie des nœuds NUMA est configurée dans l’hyperviseur pour répartir les vCPU de l’instance sur plusieurs nuds NUMA hôtes. Le pare-feu virtuel vSRX exige que vous vous assuriez que tous les vCPU résident sur le même nœud NUMA.

Nous vous recommandons de lier l’instance du pare-feu virtuel vSRX à un nœud NUMA spécifique en définissant l’affinité du nœud NUMA. L’affinité de nœud NUMA limite la planification des ressources de VM du pare-feu virtuel vSRX au nud NUMA spécifié uniquement.

Mappage d’interfaces virtuelles à une machine virtuelle de pare-feu virtuel vSRX

Pour déterminer quelles interfaces virtuelles de votre système d’exploitation hôte Linux sont mappées à une machine virtuelle de pare-feu virtuel vSRX :

  1. Utilisez la virsh list commande sur votre système d’exploitation hôte Linux pour répertorier les machines virtuelles en cours d’exécution.

  2. Utilisez la virsh domiflist vsrx-name commande pour répertorier les interfaces virtuelles sur cette machine virtuelle de pare-feu virtuel vSRX.

    Note:

    La première interface virtuelle correspond à l’interface fxp0 dans Junos OS.

Mappage d’interface pour le pare-feu virtuel vSRX sur KVM

Chaque carte réseau définie pour un pare-feu virtuel vSRX est mappée à une interface spécifique, selon que l’instance du pare-feu virtuel vSRX est une machine virtuelle autonome ou une paire de clusters pour une haute disponibilité. Les noms d’interface et les mappages dans le pare-feu virtuel vSRX sont indiqués dans les Tableaux 6 et 7.

Notez les points suivants :

  • En mode autonome :

    • FXP0 est l’interface de gestion hors bande.

    • GE-0/0/0 est la première interface de trafic (revenus).

  • En mode cluster :

    • FXP0 est l’interface de gestion hors bande.

    • em0 est le lien de contrôle du cluster pour les deux nœuds.

    • N’importe laquelle des interfaces de trafic peut être spécifiée en tant que liens de structure, par exemple ge-0/0/0 pour fab0 sur le nœud 0 et ge-7/0/0 pour fab1 sur le nœud 1.

Le Tableau 6 présente les noms d’interface et les mappages d’une machine virtuelle de pare-feu virtuel vSRX autonome.

Tableau 6 : noms d’interface d’une machine virtuelle de pare-feu virtuel vSRX autonome

Carte réseau

Nom d’interface dans Junos OS pour pare-feu virtuel vSRX

1

fxp0

2

GE-0/0/0

3

GE-0/0/1

4

GE-0/0/2

5

GE-0/0/3

6

GE-0/0/4

7

GE-0/0/5

8

GE-0/0/6

Le Tableau 7 présente les noms d’interface et les mappages pour une paire de machines virtuelles de pare-feu virtuel vSRX dans un cluster (nœud 0 et nœud 1).

Tableau 7 : noms d’interface pour une paire de clusters de pare-feu virtuel vSRX vSRX

Carte réseau

Nom d’interface dans Junos OS pour pare-feu virtuel vSRX

1

fxp0 (noeuds 0 et 1)

2

em0 (nœud 0 et 1)

3

GE-0/0/0 (nœud 0)GE-7/0/0 (nœud 1)

4

GE-0/0/1 (noeud 0)GE-7/0/1 (noeud 1)

5

GE-0/0/2 (noeud 0)GE-7/0/2 (noeud 1)

6

GE-0/0/3 (noeud 0)GE-7/0/3 (noeud 1)

7

GE-0/0/4 (nœud 0)GE-7/0/4 (nœud 1)

8

GE-0/0/5 (nœud 0)GE-7/0/5 (nœud 1)

Paramètres par défaut du pare-feu virtuel vSRX sur KVM

Le pare-feu virtuel vSRX requiert les paramètres de configuration de base suivants :

  • Des adresses IP doivent être attribuées aux interfaces.

  • Les interfaces doivent être liées à des zones.

  • Les stratégies doivent être configurées entre les zones pour autoriser ou refuser le trafic.

Le Tableau 8 répertorie les paramètres d’usine par défaut des stratégies de sécurité sur le pare-feu virtuel vSRX.

Tableau 8 : paramètres d’usine par défaut pour les stratégies de sécurité

Source Zone

Destination Zone

Mesures politiques

confiance

défiance

permettre

confiance

confiance

permettre

défiance

confiance

nier