Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

SR-IOV y PCI

En esta sección se incluyen los siguientes temas sobre SR-IOV para una instancia de firewall virtual vSRX implementada en KVM:

Descripción general de SR-IOV

El firewall virtual vSRX en KVM admite tipos de interfaz de virtualización de E/S de raíz única (SR-IOV). SR-IOV es un estándar que permite que una sola NIC física se presente como varias vNIC o funciones virtuales (VF) a las que se puede conectar una máquina virtual (VM). SR-IOV se combina con otras tecnologías de virtualización, como Intel VT-d, para mejorar el rendimiento de E/S de la máquina virtual. SR-IOV permite que cada máquina virtual tenga acceso directo a los paquetes en cola para las VF conectadas a la máquina virtual. Puede utilizar SR-IOV cuando necesita un rendimiento de E/S similar al de las interfaces físicas sin sistema operativo.

En las implementaciones que utilizan interfaces SR-IOV, los paquetes se descartan cuando se asigna una dirección MAC a una interfaz de Junos OS de vSRX Virtual Firewall. Este problema se produce porque SR-IOV no permite cambios de dirección MAC en PF o VF.

Nota:

SR-IOV en KVM no reasigna los números de interfaz. La secuencia de interfaz en el archivo XML de máquina virtual de vSRX Virtual Firewall coincide con la secuencia de interfaz que se muestra en la CLI de Junos OS en la instancia de vSRX Virtual Firewall.

SR-IOV utiliza dos funciones PCI:

  • Funciones físicas (PF): dispositivos PCIe completos que incluyen capacidades de SR-IOV. Las funciones físicas se descubren, administran y configuran como dispositivos PCI normales. Las funciones físicas configuran y administran la funcionalidad de SR-IOV mediante la asignación de funciones virtuales. Cuando SR-IOV está deshabilitado, el host crea un único PF en una NIC física.

  • Funciones virtuales (VF): funciones PCIe simples que solo procesan E/S. Cada función virtual se deriva de una función física. El número de funciones virtuales que puede tener un dispositivo está limitado por el hardware del dispositivo. Un solo puerto Ethernet, el dispositivo físico, puede asignarse a muchas funciones virtuales que se pueden compartir con los invitados. Cuando SR-IOV está habilitado, el host crea un único PF y varias VF en una NIC física. El número de VF depende de la configuración y de la compatibilidad con el controlador.

Compatibilidad con SR-IOV HA con el modo de confianza desactivado (solo KVM)

Comprender la compatibilidad con SR-IOV HA con el modo de confianza deshabilitado (solo KVM)

Una interfaz Ethernet redundante (RETH) es una interfaz virtual que consta de igual número de interfaces miembro de cada nodo participante de un clúster SRX. Todas las configuraciones lógicas, como la dirección IP, la QoS, las zonas y las VPN, están enlazadas a esta interfaz. Las propiedades físicas se aplican a las interfaces miembro o secundaria. Una interfaz RETH tiene una dirección MAC virtual que se calcula utilizando el ID de clúster. RETH se implementó como una interfaz agregada/LAG en Junos OS. Para un LAG, la dirección MAC de los IFD primarios (lógicos) se copia en cada una de las interfaces secundarias. Cuando configura la interfaz secundaria en la interfaz RETH, el MAC virtual de la interfaz RETH se sobrescribe en el current MAC address campo de la interfaz física secundaria. Esto también requiere que la dirección MAC virtual se programe en la NIC correspondiente.

Junos OS se ejecuta como una máquina virtual en el firewall virtual vSRX. Junos OS no tiene acceso directo a la NIC y solo tiene un acceso NIC virtual proporcionado por el hipervisor que podría compartirse con otras máquinas virtuales que se ejecuten en el mismo equipo host. Este acceso virtual viene con ciertas restricciones, como un modo especial llamado modo de confianza, que se requiere para programar una dirección MAC virtual en la NIC. Durante las implementaciones, es posible que no sea factible proporcionar acceso al modo de confianza debido a posibles problemas de seguridad. Para permitir que el modelo RETH funcione en dichos entornos, se modifica el comportamiento de reescritura de MAC. En lugar de copiar la dirección MAC virtual principal a los hijos, mantenemos intacta la dirección MAC física de los hijos y copiamos la dirección MAC física del hijo que pertenece al nodo activo del clúster a la MAC actual de la interfaz reth. De esta manera, el acceso de reescritura de MAC no es necesario cuando el modo de confianza está deshabilitado.

En el caso del firewall virtual vSRX, el DPDK lee la dirección MAC física proporcionada por el hipervisor y la comparte con el plano de control de Junos OS. En el modo independiente, esta dirección MAC física se programa en los IFD físicos. Pero la compatibilidad con la misma no está disponible en el modo de clúster, por lo que la dirección MAC de la interfaz física se toma del grupo MAC reservado de Juniper. En un entorno donde el modo de confianza no es factible, el hipervisor no puede proporcionar la dirección MAC física.

Para superar este problema, hemos agregado soporte para usar la dirección MAC física proporcionada por el hipervisor en lugar de asignarla desde el grupo MAC reservado. Consulte Configurar la compatibilidad con SR-IOV con el modo de confianza deshabilitado (solo KVM).

Configurar la compatibilidad con SR-IOV con el modo de confianza deshabilitado (solo KVM)

Figura 1: Copia de la dirección MAC de la interfaz secundaria activa a la RETH Copying MAC address from active child interface to parent RETH principal

A partir de Junos OS versión 19.4R1, se admite SR-IOV HA con el modo de confianza deshabilitado. Puede habilitar este modo configurando las use-active-child-mac-on-reth instrucciones de configuración y use-actual-mac-on-physical-interfaces en el nivel de [edit chassis cluster] jerarquía. Si configura comandos en un clúster, el hipervisor asigna la dirección MAC de la interfaz física secundaria y la dirección MAC de la interfaz RETH principal se sobrescribe con la dirección MAC de la interfaz física secundaria activa

Nota:

Puede configurar SR-IOV con el modo de confianza deshabilitado, solo si las interfaces de ingresos son SR-IOV. Las interfaces o vínculos de estructura no pueden usar SR-IOV con el modo de confianza deshabilitado cuando se configuran las interfaces físicas MAC reales.

Se admite el uso de SRIOV con el modo de confianza deshabilitado si solo las interfaces de ingresos son SR-IOV.

Debe reiniciar la instancia de vSRX Virtual Firewall para habilitar este modo. Ambos nodos del clúster deben reiniciarse para que los comandos surtan efecto.

Debe configurar los comandos use-active-child-mac-on-reth y use-actual-mac-on-physical-interfaces juntos para habilitar esta característica.

Limitaciones

La compatibilidad con HA SR-IOV con el modo de confianza deshabilitado en KVM tiene las siguientes limitaciones:

  • La compatibilidad con SR-IOV HA con el modo de confianza desactivado solo se admite en sistemas basados en KVM.

  • Una interfaz reth puede tener un máximo de un puerto como miembro en cada nodo de clúster de vSRX Virtual Firewall.

  • No puede usar security nat proxy-arp la función para grupos NAT porque no se envía ningún G-ARP por conmutación por error para las direcciones IP en los grupos NAT. En su lugar, se pueden establecer las rutas al rango del grupo NAT en el enrutador ascendente para que apunten a la dirección IP de la interfaz de firewall virtual vSRX como el próximo salto. O, si los hosts conectados directamente necesitan acceder a las direcciones del grupo NAT, estas direcciones del grupo NAT se pueden configurar para ARP de proxy en la interfaz reth.

  • Si la interfaz reth está configurada con muchas VLAN, es posible que tarde algún tiempo en enviar todos los G-ARP a una conmutación por error. Esto podría conducir a una interrupción notable en el tráfico.

  • Una conmutación por error del plano de datos provocará un cambio de la dirección MAC de la interfaz reth. Por lo tanto, la conmutación por error no es transparente para los dispositivos de capa 3 vecinos conectados directamente (enrutadores o servidores). La dirección IP reth del firewall virtual vSRX debe asignarse a una nueva dirección MAC en la tabla ARP de los dispositivos vecinos. El firewall virtual vSRX enviará un G-ARP que ayudará a estos dispositivos. En caso de que estos dispositivos vecinos no actúen sobre el G-ARP recibido del firewall virtual vSRX o muestren una respuesta lenta, es posible que el tráfico se interrumpa hasta que ese dispositivo actualice correctamente su tabla ARP.

  • Las siguientes funciones de firewall virtual vSRX no se admiten en implementaciones que utilizan interfaces SR-IOV:

    Estas limitaciones se aplican en implementaciones en las que los controladores PF no se pueden actualizar ni controlar. Las limitaciones no se aplican cuando el firewall virtual vSRX se implementa en dispositivos compatibles de Juniper Networks.

    • Alta disponibilidad (HA)

    • Interfaces IRB

    • Direccionamiento IPv6

    • Marcos Jumbo

    • Soporte de capa 2

    • Multidifusión con otras características como OSPF e IPv6

    • Modo de paquete

Configurar una interfaz SR-IOV en KVM

Si tiene una NIC física que admite SR-IOV, puede asociar vNIC habilitadas para SR-IOV o funciones virtuales (VF) a la instancia del firewall virtual vSRX para mejorar el rendimiento. Recomendamos que si usa SR-IOV, todos los puertos de ingresos se configuren como SR-IOV.

Tenga en cuenta lo siguiente acerca de la compatibilidad de SR-IOV con el firewall virtual vSRX en KVM:

  • A partir de Junos OS versión 15.1X49-D90 y Junos OS versión 17.3R1, una instancia de firewall virtual vSRX desplegada en KVM admite SR-IOV en una NIC Intel X710/XL710 además de Intel 82599 o X520/540.

  • A partir de Junos OS versión 18.1R1, una instancia de firewall virtual vSRX desplegada en KVM admite SR-IOV en los adaptadores de las familias Mellanox ConnectX-3 y ConnectX-4.

Nota:

Consulte la discusión sobre la ampliación del rendimiento del firewall virtual vSRX en Descripción de vSRX con KVM para conocer el rendimiento de escalabilidad vertical del firewall virtual vSRX cuando se implementa en KVM, según vNIC y la cantidad de vCPU y vRAM aplicadas a una máquina virtual vSRX Virtual Firewall.

Antes de poder asociar una VF habilitada para SR-IOV a la instancia de firewall virtual vSRX, debe completar las siguientes tareas:

  • Inserte un adaptador de red físico compatible con SR-IOV en el servidor host.

  • Habilite las extensiones de virtualización de CPU Intel VT-d en el BIOS del servidor host. Las extensiones Intel VT-d proporcionan soporte de hardware para asignar directamente un dispositivo físico al invitado. Verifique el proceso con el proveedor, ya que los diferentes sistemas tienen diferentes métodos para habilitar VT-d.

  • Asegúrese de que SR-IOV esté habilitado en el nivel del BIOS del sistema/servidor yendo a la configuración del BIOS durante la secuencia de arranque del servidor host para confirmar la configuración de SR-IOV. Los distintos fabricantes de servidores tienen diferentes convenciones de nomenclatura para el parámetro del BIOS utilizado para habilitar SR-IOV en el nivel del BIOS. Por ejemplo, para un servidor Dell, asegúrese de que la opción Habilitar global de SR-IOV esté establecida en Habilitado.

Nota:

Se recomienda usar virt-manager para configurar interfaces SR-IOV. Consulte la documentación de comandos virsh attach-device si desea obtener información sobre cómo agregar un dispositivo host PCI a una máquina virtual con los comandos de CLI virsh .

Además, debe configurar las interfaces del orden de 1G, 10G, 40G y 100G. Si no se sigue este orden, debe restablecer los adaptadores de red.

Para agregar una VF SR-IOV a una máquina virtual vSRX Virtual Firewall mediante la virt-manager interfaz gráfica:

  1. En la CLI de Junos OS, apague la máquina virtual del firewall virtual vSRX si se está ejecutando.

  2. En virt-manager, haga doble clic en la máquina virtual vSRX Virtual Firewall y seleccione Ver>Detalles. Aparecerá el cuadro de diálogo Detalles de la máquina virtual del firewall virtual vSRX.
  3. Seleccione la pestaña Hardware y, a continuación, haga clic en Agregar hardware. Aparecerá el cuadro de diálogo Agregar hardware.
  4. Seleccione PCI Host Device (Dispositivo host PCI) en la lista Hardware de la izquierda.
  5. Seleccione el SR-IOV VF para esta nueva interfaz virtual en la lista de dispositivos host.
  6. Haga clic en Finalizar para agregar el nuevo dispositivo. La configuración se completó y la máquina virtual del firewall virtual vSRX ahora tiene acceso directo al dispositivo.
  7. Desde la barra de iconos virt-manager en la parte superior izquierda de la ventana, haga clic en la flecha Encender. Se inicia la máquina virtual del firewall virtual vSRX. Una vez que el firewall virtual vSRX esté encendido, aparecerá el estado En ejecución en la ventana.

    Puede conectarse a la consola de administración para ver la secuencia de arranque.

    Nota:

    Una vez iniciado el arranque, debe seleccionar View>Text Consoles>Serial 1 in virt-manager para conectarse a la consola del firewall virtual vSRX.

Para agregar una VF SR-IOV a una máquina virtual virsh vSRX Virtual Firewall mediante comandos de CLI:

  1. Defina cuatro funciones virtuales para la interfaz eno2, actualice el archivo sriov_numvfs con el número 4.

  2. Identifique el dispositivo.

    Identifique el dispositivo PCI designado para la asignación de dispositivos a la máquina virtual. Utilice el lspci comando para enumerar los dispositivos PCI disponibles. Puede refinar el resultado de lspci con grep.

    Use el comando lspci para verificar el número de VF de acuerdo con el ID de VF.

  3. Agregue la asignación de dispositivos SR-IOV desde un perfil XML de firewall virtual vSRX en KVM y revise la información del dispositivo.

    El controlador puede usar vfio o kvm, depende de la versión del kernel/sistema operativo del servidor KVM y de los controladores para la compatibilidad con la virtualización. El tipo de dirección hace referencia al número de ranura PCI único para cada SR-IOV VF (Virtual Function).

    La información sobre el dominio, el bus y la función está disponible en la salida del virsh nodedev-dumpxml comando.

  4. Agregue el dispositivo PCI en la configuración de edición y seleccione VF de acuerdo con el número VF.

    Nota:

    Esta operación debe realizarse cuando la máquina virtual está apagada. Además, no clone máquinas virtuales con dispositivos PCI que puedan provocar conflictos de VF o MAC.

  5. Inicie la máquina virtual con el # virsh start name of virtual machine comando.

Tabla de historial de cambios

La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.

Lanzamiento
Descripción
18.1R1
A partir de Junos OS versión 18.1R1, una instancia de firewall virtual vSRX desplegada en KVM admite SR-IOV en los adaptadores de las familias Mellanox ConnectX-3 y ConnectX-4.
15,1 X 49-D90
A partir de Junos OS versión 15.1X49-D90 y Junos OS versión 17.3R1, una instancia de firewall virtual vSRX desplegada en KVM admite SR-IOV en una NIC Intel X710/XL710 además de Intel 82599 o X520/540.