SR-IOV et PCI
Cette section comprend les rubriques suivantes sur SR-IOV pour une instance de pare-feu virtuel vSRX déployée sur KVM :
Présentation du SR-IOV
Le pare-feu virtuel vSRX sur KVM prend en charge les types d’interfaces de virtualisation d’E/S à racine unique (SR-IOV). La SR-IOV est une norme qui permet à une seule carte réseau physique de se présenter sous la forme de plusieurs vNIC (fonctions virtuelles) auxquelles une machine virtuelle (VM) peut se connecter. SR-IOV se combine avec d’autres technologies de virtualisation, telles qu’Intel VT-d, pour améliorer les performances d’E/S de la machine virtuelle. SR-IOV permet à chaque machine virtuelle d’avoir un accès direct aux paquets mis en file d’attente pour les VF attachés à la machine virtuelle. Vous pouvez utiliser le SR-IOV lorsque vous avez besoin de performances d’E/S proches de celles des interfaces physiques bare metal.
Dans les déploiements utilisant des interfaces SR-IOV, les paquets sont abandonnés lorsqu’un adresse MAC est affecté à une interface Pare-feu virtuel vSRX Junos OS. Ce problème se produit parce que SR-IOV n’autorise pas les changements d’adresse MAC dans le PF ou le VF.
Le SR-IOV dans KVM ne remappe pas les numéros d’interface. La séquence d’interface dans le fichier XML de VM pare-feu virtuel vSRX correspond à la séquence d’interface affichée dans l’interface de ligne de commande Junos OS sur l’instance de pare-feu virtuel vSRX.
Le SR-IOV utilise deux fonctions PCI :
Physical Functions (PFs) : périphériques PCIe complets incluant des capacités SR-IOV. Les fonctions physiques sont détectées, gérées et configurées comme des périphériques PCI normaux. Les fonctions physiques configurent et gèrent la fonctionnalité SR-IOV en attribuant des fonctions virtuelles. Lorsque SR-IOV est désactivé, l’hôte crée un seul PF sur une carte réseau physique.
Fonctions virtuelles (VF) : fonctions PCIe simples qui ne traitent que les E/S. Chaque fonction virtuelle est dérivée d’une fonction physique. Le nombre de fonctions virtuelles qu’un périphérique peut avoir est limité par le matériel de l’appareil. Un seul port Ethernet, le périphérique physique, peut être mappé à de nombreuses fonctions virtuelles qui peuvent être partagées avec les invités. Lorsque SR-IOV est activé, l’hôte crée un seul PF et plusieurs VF sur une carte réseau physique. Le nombre de VF dépend de la configuration et de la prise en charge des pilotes.
Prise en charge de SR-IOV HA avec le mode Trust désactivé (KVM uniquement)
- Comprendre la prise en charge de SR-IOV HA lorsque le mode de confiance est désactivé (KVM uniquement)
- Configurer la prise en charge de SR-IOV avec le mode Trust désactivé (KVM uniquement)
- Limitations
Comprendre la prise en charge de SR-IOV HA lorsque le mode de confiance est désactivé (KVM uniquement)
Une interface RETH (Redundant Ethernet Interface) est une interface virtuelle composée d’un nombre égal d’interfaces membres de chaque nud participant d’un cluster SRX. Toutes les configurations logiques telles que l’adresse IP, la QoS, les zones et les VPN sont liées à cette interface. Les propriétés physiques sont appliquées aux interfaces membre ou enfant. Une interface RETH possède une adresse MAC virtuelle calculée à l’aide de l’ID de cluster. RETH a été implémenté en tant qu’interface/LAG agrégée dans Junos OS. Pour un LAG, l’adresse MAC de l’IFD parent (logique) est copiée sur chacune des interfaces enfants. Lorsque vous configurez l’interface enfant sous l’interface RETH, l’adresse MAC virtuelle de l’interface RETH est écrasée dans le current MAC address champ de l’interface physique enfant. Cela nécessite également que l’adresse MAC virtuelle soit programmée sur la carte réseau correspondante.
Junos OS s’exécute en tant que machine virtuelle sur le pare-feu virtuel vSRX. Junos OS n’a pas d’accès direct à la carte réseau et dispose uniquement d’un accès à la carte réseau virtuelle fourni par l’hyperviseur qui peut être partagé avec d’autres machines virtuelles exécutées sur la même machine hôte. Cet accès virtuel s’accompagne de certaines restrictions telles qu’un mode spécial appelé mode de confiance, qui est nécessaire pour programmer une adresse MAC virtuelle sur la carte réseau. Pendant les déploiements, il peut être impossible de fournir l’accès en mode d’approbation en raison de problèmes de sécurité possibles. Pour permettre au modèle RETH de fonctionner dans de tels environnements, le comportement de réécriture MAC est modifié. Au lieu de copier l’adresse MAC virtuelle parent aux enfants, nous conservons l’adresse MAC physique des enfants intacte et copions l’adresse MAC physique de l’enfant appartenant au nœud actif du cluster vers l’adresse MAC actuelle de l’interface reth. De cette façon, l’accès à la réécriture MAC n’est pas nécessaire lorsque le mode de confiance est désactivé.
Dans le cas du pare-feu virtuel vSRX, le DPDK lit l’adresse MAC physique fournie par l’hyperviseur et la partage avec le plan de contrôle Junos OS. En mode autonome, cette adresse MAC physique est programmée sur les IFD physiques. Cependant, sa prise en charge n’est pas disponible en mode cluster, l’adresse MAC de l’interface physique provient du pool MAC réservé Juniper. Dans un environnement où le mode de confiance n’est pas possible, l’hyperviseur n’est pas en mesure de fournir l’adresse MAC physique.
Pour surmonter ce problème, nous avons ajouté la prise en charge de l’utilisation de l’adresse MAC physique fournie par l’hyperviseur au lieu de l’allouer à partir du pool MAC réservé. Reportez-vous à la section Configurer la prise en charge de SR-IOV avec le mode de confiance désactivé (KVM uniquement).
Configurer la prise en charge de SR-IOV avec le mode Trust désactivé (KVM uniquement)
parent
À partir de Junos OS version 19.4R1, SR-IOV HA est pris en charge lorsque le mode confiance est désactivé. Vous pouvez activer ce mode en configurant les use-active-child-mac-on-reth instructions de configuration et use-actual-mac-on-physical-interfaces au niveau de la [edit chassis cluster] hiérarchie. Si vous configurez des commandes dans un cluster, l’hyperviseur attribue l’adresse MAC de l’interface physique enfant et l’adresse MAC de l’interface RETH parent est remplacée par l’adresse MAC de l’interface physique enfant active
Vous pouvez configurer SR-IOV avec le mode de confiance désactivé, uniquement si les interfaces de revenus sont SR-IOV. Les interfaces ou liaisons de structure ne peuvent pas utiliser SR-IOV lorsque le mode d’approbation est désactivé lorsque les interfaces physiques MAC réelles sont configurées.
L’utilisation de SRIOV avec le mode de confiance désactivé est prise en charge si seules les interfaces de revenus sont SR-IOV.
Vous devez redémarrer l’instance de pare-feu virtuel vSRX pour activer ce mode. Les deux nœuds du cluster doivent être redémarrés pour que les commandes soient prises en compte.
Vous devez configurer les commandes use-active-child-mac-on-reth et use-actual-mac-on-physical-interfaces ensemble pour activer cette fonctionnalité.
Voir aussi
Limitations
La prise en charge de SR-IOV HA lorsque le mode de confiance est désactivé sur KVM présente les limitations suivantes :
La prise en charge de SR-IOV HA lorsque le mode de confiance est désactivé n’est prise en charge que sur les systèmes basés sur KVM.
Une interface reth peut avoir au maximum un port en tant que membre sur chaque nud de cluster de pare-feu virtuel vSRX.
Vous ne pouvez pas utiliser
security nat proxy-arpla fonctionnalité pour les pools NAT, car aucun G-ARP n’est envoyé lors du basculement pour les adresses IP des pools NAT. Au lieu de cela, on peut définir les routes vers la plage de pool NAT dans le routeur en amont pour qu’elles pointent vers l’adresse IP de l’interface reth du pare-feu virtuel vSRX en tant que prochain saut. Ou, si des hôtes directement connectés ont besoin d’accéder aux adresses de pool NAT, ces adresses de pool NAT peuvent être configurées pour le proxy ARP sous l’interface reth.Si l’interface reth est configurée avec de nombreux VLAN, l’envoi de tous les G-ARP lors d’un basculement peut prendre un certain temps. Cela peut entraîner une interruption notable du trafic.
Un basculement du plan de données entraînera une modification de l’adresse MAC de l’interface reth. Par conséquent, le basculement n’est pas transparent pour les appareils de couche 3 voisins directement connectés (routeurs ou serveurs). L’adresse IP de reth du pare-feu virtuel vSRX doit être mappée à une nouvelle adresse MAC dans la table ARP des périphériques voisins. Le pare-feu virtuel vSRX enverra un G-ARP qui aidera ces appareils. Si ces périphériques voisins n’agissent pas sur le G-ARP reçu du pare-feu virtuel vSRX ou affichent une réponse lente, le trafic peut être interrompu jusqu’à ce que cet équipement mette correctement à jour sa table ARP.
-
Les fonctionnalités de pare-feu virtuel vSRX suivantes ne sont pas prises en charge dans les déploiements qui utilisent des interfaces SR-IOV :
Ces limitations s’appliquent dans les déploiements où les pilotes PF ne peuvent pas être mis à jour ou contrôlés. Ces limitations ne s’appliquent pas lorsque le pare-feu virtuel vSRX est déployé sur les équipements Juniper Networks pris en charge.
-
Haute disponibilité (HA)
-
Interfaces IRB
-
Adressage IPv6
-
Trames Jumbo
-
Prise en charge de la couche 2
-
Multicast avec d’autres fonctionnalités telles qu’OSPF et IPv6
-
Mode paquet
-
Configurer une interface SR-IOV sur KVM
Si vous disposez d’une carte réseau physique prenant en charge SR-IOV, vous pouvez attacher des vNIC compatibles SR-IOV ou des fonctions virtuelles (VF) à l’instance du pare-feu virtuel vSRX pour améliorer les performances. Si vous utilisez SR-IOV, nous vous recommandons de configurer tous les ports payants en tant que SR-IOV.
Notez ce qui suit à propos de la prise en charge de SR-IOV pour le pare-feu virtuel vSRX sur KVM :
À partir de Junos OS version 15.1X49-D90 et Junos OS version 17.3R1, une instance de pare-feu virtuel vSRX déployée sur KVM prend en charge SR-IOV sur une carte réseau Intel X710/XL710 en plus d’Intel 82599 ou X520/540.
À partir de Junos OS version 18.1R1, une instance de pare-feu virtuel vSRX déployée sur KVM prend en charge SR-IOV sur les cartes de la famille Mellanox ConnectX-3 et ConnectX-4.
Reportez-vous à la discussion sur la montée en charge des performances du pare-feu virtuel vSRX dans Comprendre vSRX avec KVM pour le pare-feu virtuel vSRX Augmenter les performances lorsqu’il est déployé sur KVM, en fonction de la carte réseau virtuelle vNIC et du nombre de vCPU et de vRAM appliqués à une machine virtuelle pare-feu virtuel vSRX.
Avant de pouvoir attacher un VF compatible SR-IOV à l’instance de pare-feu virtuel vSRX, vous devez effectuer les tâches suivantes :
Insérez une carte réseau physique compatible SR-IOV dans le serveur hôte.
Activez les extensions de virtualisation de processeur Intel VT-d dans le BIOS de votre serveur hôte. Les extensions Intel VT-d fournissent une prise en charge matérielle pour l’affectation directe d’un périphérique physique à l’invité. Vérifiez le processus auprès du fournisseur, car les différents systèmes ont des méthodes différentes pour activer VT-d.
Assurez-vous que SR-IOV est activé au niveau du BIOS système/serveur en accédant aux paramètres du BIOS pendant la séquence de démarrage du serveur hôte pour confirmer le paramètre SR-IOV. Différents fabricants de serveurs ont des conventions de nommage différentes pour le paramètre BIOS utilisé pour activer SR-IOV au niveau du BIOS. Par exemple, pour un serveur Dell, assurez-vous que l’option d’activation globale SR-IOV est définie sur Activé.
Nous vous recommandons d’utiliser virt-manager pour configurer les interfaces SR-IOV. Consultez la documentation des virsh attach-device commandes si vous souhaitez savoir comment ajouter un périphérique hôte PCI à une machine virtuelle à l’aide des virsh commandes CLI.
En outre, vous devez configurer les interfaces dans l’ordre de 1G, 10G, 40G et 100G. Si cet ordre n’est pas respecté, vous devez réinitialiser les cartes réseau.
Pour ajouter un VF SR-IOV à une machine virtuelle pare-feu virtuel vSRX à l’aide de l’interface virt-manager graphique :
Pour ajouter un VF SR-IOV à une machine virtuelle de pare-feu virtuel vSRX vSRX à l’aide virsh de commandes CLI :
Définissez quatre fonctions virtuelles pour l’interface eno2, mettez à jour le fichier sriov_numvfs avec le numéro 4.
root@LabHost:~# echo 4 > /sys/class/net/eno2/device/sriov_numvfs root@LabHost:~# more /sys/class/net/eno2/device/sriov_numvfs
Identifiez l’appareil.
Identifiez le périphérique PCI désigné pour l’attribution du périphérique à la machine virtuelle. Utilisez la
lspcicommande pour répertorier les périphériques PCI disponibles. Vous pouvez affiner la sortie delspciavecgrep.Utilisez la commande
lspcipour vérifier le numéro VF en fonction de l’ID VF.root@ kvmsrv:~# lspci | grep Ether
…… 83:00.0 Ethernet controller: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (rev 02) - Physical Function 83:00.1 Ethernet controller: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (rev 02) - Physical Function 83:02.0 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02) 83:02.1 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02) 83:02.2 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02) 83:02.3 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02) 83:02.4 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02) 83:02.5 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02) 83:02.6 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02) 83:02.7 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02) 83:0a.0 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02) 83:0a.1 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02) 83:0a.2 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02) 83:0a.3 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02) 83:0a.4 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02) 83:0a.5 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02) 83:0a.6 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02) 83:0a.7 Ethernet controller: Intel Corporation Ethernet Virtual Function 700 Series (rev 02) ………
Ajoutez l’affectation de périphérique SR-IOV à partir d’un profil XML de pare-feu virtuel vSRX sur KVM et consultez les informations sur le périphérique.
Le pilote peut utiliser vfio ou kvm, dépend de la version du système d’exploitation/noyau du serveur KVM et des pilotes pour la prise en charge de la virtualisation. Le type d’adresse fait référence au numéro de slot PCI unique pour chaque fonction virtuelle VF SR-IOV.
Des informations sur le domaine, le bus et la fonction sont disponibles à partir de la sortie de la
virsh nodedev-dumpxmlcommande.<interface type="hostdev" managed="yes"> <driver name="vfio"/> <source> <address type="pci" domain="0x0000" bus="0x83" slot="0x02" function="0x3"/> </source> <address type="pci" domain="0x0000" bus="0x00" slot="0x05" function="0x0"/> </interface>
Ajoutez un périphérique PCI dans les paramètres d’édition et sélectionnez VF en fonction du numéro VF.
Note:Cette opération doit être effectuée lorsque la machine virtuelle est mise hors tension. De plus, ne clonez pas de machines virtuelles avec des périphériques PCI, ce qui pourrait entraîner un conflit VF ou MAC.
Démarrez la machine virtuelle à l’aide de la
# virsh start name of virtual machinecommande.
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plate-forme et la version que vous utilisez. Utilisez l’Explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.