Administrar redes

Los procedimientos de configuración de red de esta sección varían en función de si está configurando un servidor independiente o un servidor que forma parte de un grupo de recursos.

Redes privadas entre servidores

Las versiones anteriores de Citrix Hypervisor permiten crear redes privadas de un solo servidor que permiten que las máquinas virtuales que se ejecutan en el mismo host se comuniquen entre sí. La característica de red privada entre servidores , que amplía el concepto de red privada de un solo servidor para permitir que las máquinas virtuales de diferentes hosts se comuniquen entre sí. Las redes privadas entre servidores combinan las mismas propiedades de aislamiento de una red privada de un solo servidor pero con la capacidad adicional de abarcar hosts a través de un grupo de recursos. Esta combinación permite el uso de funciones de agilidad de VM, como la migración en vivo para máquinas virtuales con conexiones a redes privadas entre servidores.

Las redes privadas entre servidores están aisladas. Las máquinas virtuales que no están conectadas a la red privada no pueden detectar ni inyectar tráfico en la red. Esto sucede incluso cuando están en el mismo host físico con VIFs conectados a una red en el mismo dispositivo de red física subyacente (PIF). Las VLAN proporcionan una funcionalidad similar. Sin embargo, a diferencia de las VLAN, las redes privadas entre servidores proporcionan aislamiento sin requerir la configuración de una estructura de switch física, mediante el uso del protocolo de tunelización IP de Encapsulación de enrutamiento genérico (GRE).

Las redes privadas ofrecen los siguientes beneficios sin necesidad de un conmutador físico:

  • Las propiedades de aislamiento de redes privadas de un solo servidor

  • La capacidad de abarcar un fondo de recursos, lo que permite que las máquinas virtuales conectadas a una red privada vivan en varios hosts dentro del mismo grupo

  • Compatibilidad con funciones como la migración en vivo

Cree redes privadas entre servidores en una interfaz de administración o una interfaz secundaria, ya que requieren una NIC direccionable IP. Puede utilizar cualquier NIC habilitada para IP como transporte de red subyacente. Si selecciona colocar tráfico de red privada entre servidores en una interfaz secundaria, esta interfaz secundaria debe estar en una subred independiente.

Si hay alguna interfaz secundaria o de administración en la misma subred, el tráfico se enruta incorrectamente.

Notas:

Para crear una red privada entre servidores, se deben cumplir las siguientes condiciones:

  • Todos los hosts del grupo deben utilizar Citrix Hypervisor 6.0 o superior.

  • Todos los hosts del grupo deben utilizar el conmutador virtual para la pila de redes.

  • El vSwitch Controller debe estar en ejecución y debe haber agregado el grupo a él. (El grupo debe tener configurado un vSwitch Controller que controle las tareas de inicialización y configuración necesarias para la conexión vSwitch.)

  • Debe crear la red privada entre servidores en una NIC configurada como interfaz de administración. Puede ser la interfaz de administración o una interfaz secundaria (PIF habilitado para IP) que configure específicamente para este propósito, siempre que esté en una subred separada.

Para obtener más información sobre la configuración de vSwitch, consulteConmutador virtual y Controller. Para obtener información sobre los procedimientos basados en la interfaz de usuario para configurar redes privadas, consulte la Ayuda de XenCenter.

Crear redes en un servidor independiente

Dado que las redes externas se crean para cada PIF durante la instalación del host, normalmente solo se requiere crear redes adicionales para:

  • Utilizar una red privada

  • Admite operaciones avanzadas como VLAN o enlace NIC

Para obtener información sobre cómo agregar o eliminar redes mediante XenCenter, consulte la Ayuda de XenCenter.

Abra la consola de texto del servidor Citrix Hypervisor.

Cree la red mediante el comando network-create, que devuelve el UUID de la red recién creada:

xe network-create name-label=mynetwork

En este punto, la red no está conectada a un PIF y, por lo tanto, es interna.

Crear redes en grupos de recursos

Todos los servidores Citrix Hypervisor de un grupo de recursos deben tener el mismo número de NIC físicas (NIC). Este requisito no se aplica estrictamente cuando un host se une a un grupo.

Como todos los hosts de un grupo comparten un conjunto común de red. Es importante tener la misma configuración de red física para los servidores Citrix Hypervisor en un grupo. Los PIF de los hosts individuales están conectados a redes de toda la agrupación en función del nombre del dispositivo. Por ejemplo, todos los servidores Citrix Hypervisor de un grupo con una NIC eth0 tienen un PIF correspondiente conectado a laNetwork 0 red de toda la agrupación. Lo mismo ocurre con los hosts con NIC eth1 y otras NIC presentes al menos en un servidor Citrix Hypervisor del grupo.Network 1``

Si un servidor Citrix Hypervisor tiene un número diferente de NIC que otros hosts en el grupo, pueden surgir complicaciones. Las complicaciones pueden surgir porque no todas las redes de grupo son válidas para todos los hosts de grupo. Por ejemplo, si los hosts host1 y host2 están en el mismo grupo y host1 tiene cuatro NIC y host2 sólo tiene dos, sólo las redes conectadas a PIF correspondientes a eth0 y eth1 son válidas en host2 . Las máquinas virtuales del host1 con VIF conectadas a redes correspondientes a eth2 y eth3 no pueden migrar al host2 del host2 .

Crear VLAN

Para los servidores de un grupo de recursos, puede utilizar elpool-vlan-create comando. Este comando crea la VLAN y crea y conecta automáticamente los PIF necesarios en los hosts del grupo. Para obtener más información, consulte pool-vlan-create.

Abra la consola del servidor Citrix Hypervisor.

Cree una red para utilizarla con la VLAN. Se devuelve el UUID de la nueva red:

xe network-create name-label=network5

Utilice elpif-list comando para buscar el UUID del PIF correspondiente a la NIC física que soporta la etiqueta VLAN deseada. Se devuelven los UUID y los nombres de dispositivos de todos los PIF, incluidas las VLAN existentes:

xe pif-list

Cree un objeto VLAN que especifique la PIF física y la etiqueta VLAN deseada en todas las máquinas virtuales que se conecten a la nueva VLAN. Se crea un nuevo PIF y se conecta a la red especificada. Se devuelve el UUID del nuevo objeto PIF.

xe vlan-create network-uuid=network_uuid pif-uuid=pif_uuid vlan=5

Adjunte VIFs de VM a la nueva red. Consulte Creación de redes en un servidor independiente para obtener más detalles.

Crear bonos NIC en un host independiente

Se recomienda utilizar XenCenter para crear enlaces NIC. Para obtener instrucciones, consulte la Ayuda de XenCenter.

En esta sección se describe cómo utilizar la CLI xe para vincular interfaces NIC en servidores Citrix Hypervisor que no están en un grupo. Para obtener información sobre el uso de la CLI xe para crear bonos NIC en servidores Citrix Hypervisor que comprenden un fondo de recursos, consulte Creación de bonos NIC en pools de recursos.

Crear un bono NIC

Cuando vinculo una NIC, el bono absorbe el PIF/NIC en uso como interfaz de administración. A partir de Citrix Hypervisor 6.0, la interfaz de administración se mueve automáticamente al enlace PIF.

  1. Utilice elnetwork-create comando para crear una red para utilizarla con la NIC enlazada. Se devuelve el UUID de la nueva red:

    xe network-create name-label=bond0
    
  2. Utilice elpif-list comando para determinar los UUID de los PIF que se utilizarán en el enlace:

    xe pif-list
    
  3. Lleve a cabo una de las siguientes acciones:

    • Para configurar el vínculo en modo activo-activo (predeterminado), utilice el comando bond-create para crear el vínculo. Usando comas para separar los parámetros, especifique el UUID de red recién creado y los UUID de los PIF que se van a unir:

       xe bond-create network-uuid=network_uuid /
            pif-uuids=pif_uuid_1,pif_uuid_2,pif_uuid_3,pif_uuid_4
      

      Escriba dos UUID cuando vinculo dos NIC y cuatro UUID cuando vinculo cuatro NIC. El UUID para el enlace se devuelve después de ejecutar el comando.

    • Para configurar el enlace en modo de enlace activo-pasivo o LACP, utilice la misma sintaxis, agregue el parámetro modeopcional y especifique lacp o active-backup :

       xe bond-create network-uuid=network_uuid pif-uuids=pif_uuid_1, /
            pif_uuid_2,pif_uuid_3,pif_uuid_4 /
            mode=balance-slb | active-backup | lacp
      

Controlar la dirección MAC del bono

Cuando vinculo la interfaz de administración, se subsuma la PIF/NIC en uso como interfaz de administración. Si el host utiliza DHCP, la dirección MAC del enlace es la misma que la PIF/NIC en uso. La dirección IP de la interfaz de administración puede permanecer sin cambios.

Puede cambiar la dirección MAC del bono para que sea diferente de la dirección MAC de la NIC de interfaz de administración (actual). Sin embargo, a medida que el enlace está habilitado y cambia la dirección MAC/IP en uso, se eliminan las sesiones de red existentes en el host.

Puede controlar la dirección MAC de un enlace de dos maneras:

  • Se puede especificar unmac parámetro opcional en elbond-create comando. Puede utilizar este parámetro para establecer la dirección MAC de enlace a cualquier dirección arbitraria.

  • Si no se especifica elmac parámetro, Citrix Hypervisor utiliza la dirección MAC de la interfaz de administración si es una de las interfaces del enlace. Si la interfaz de gestión no forma parte del bono, pero otra interfaz de gestión lo es, el bono utiliza la dirección MAC (y también la dirección IP) de esa interfaz de gestión. Si ninguna de las NIC del bono es una interfaz de administración, el bono utiliza el MAC de la primera NIC denominada.

Revertir bonos NIC

Al revertir el servidor Citrix Hypervisor a una configuración no vinculada, elbond-destroy comando configura automáticamente el primario-esclavo como interfaz para la interfaz de administración. Por lo tanto, todos los VIF se mueven a la interfaz de administración. Si la interfaz de administración de un host está en la interfaz vinculada VLAN etiquetada, al realizarbond-destroy, la VLAN de administración se mueve a esclavo primario.

El término primary-slave se refiere al PIF del que se copió la configuración MAC e IP al crear el vínculo. Al vincular dos NIC, el esclavo principal es:

  1. NIC de la interfaz de administración (si la interfaz de administración es una de las NIC enlazadas).

  2. Cualquier otra NIC con una dirección IP (si la interfaz de administración no formaba parte del bono).

  3. El primer NIC llamado. Puede averiguar cuál es ejecutando lo siguiente:

    xe bond-list params=all
    

Crear bonos NIC en pools de recursos

Siempre que sea posible, cree bonos NIC como parte de la creación inicial del fondo de recursos, antes de unir más hosts al grupo o crear máquinas virtuales. Al hacerlo, la configuración de bonos se replica automáticamente en los hosts a medida que se unen al grupo y reduce el número de pasos necesarios.

La adición de un enlace NIC a un grupo existente requiere una de las siguientes opciones:

  • Uso de la CLI para configurar los enlaces en el maestro y, a continuación, en cada miembro del grupo.

  • Usar la CLI para configurar enlaces en el maestro y, a continuación, reiniciar cada miembro del grupo para que herede su configuración del maestro.

  • Uso de XenCenter para configurar los enlaces en el maestro. XenCenter sincroniza automáticamente la configuración de red de los servidores miembros con el maestro, por lo que no es necesario reiniciar los servidores miembros.

Para simplificar y evitar errores de configuración, se recomienda utilizar XenCenter para crear enlaces NIC. Para obtener más información, consulte la Ayuda de XenCenter.

En esta sección se describe el uso de la CLI xe para crear interfaces NIC enlazadas en servidores Citrix Hypervisor que comprenden un fondo de recursos. Para obtener información sobre el uso de la CLI xe para crear bonos NIC en un host independiente, consulte Creación de bonos NIC en un host independiente.

Advertencia:

No intente crear enlaces de red cuando esté habilitada la alta disponibilidad. El proceso de creación de bonos perturba el latido de alta disponibilidad en curso y hace que los anfitriones se autovalen (se cierren ellos mismos). Los hosts pueden no reiniciarse correctamente y pueden necesitar elhost-emergency-ha-disable comando para recuperarse.

Select el host en el que desea que sea el maestro. El host principal pertenece a un grupo sin nombre de forma predeterminada. Para crear un fondo de recursos con la CLI, cambie el nombre del grupo sin nombre existente:

xe pool-param-set name-label="New Pool" uuid=pool_uuid

Cree el enlace NIC como se describe enCrear un bono NIC.

Abra una consola en un host al que desee unir al grupo y ejecute el comando:

xe pool-join master-address=host1 master-username=root master-password=password

La información de red y enlace se replica automáticamente en el nuevo host. La interfaz de administración se mueve automáticamente desde la NIC host donde se configuró originalmente al PIF enlazado. Es decir, la interfaz de gestión se absorbe ahora en el bono, de modo que todo el bono funciona como interfaz de gestión.

Utilice elhost-list comando para buscar el UUID del host que se está configurando:

xe host-list

Advertencia:

No intente crear enlaces de red mientras esté activada la alta disponibilidad. El proceso de creación de bonos perturba el latido de alta disponibilidad en curso y hace que los anfitriones se autovalen (se cierren ellos mismos). Los hosts pueden no reiniciarse correctamente y es posible que deba ejecutar elhost-emergency-ha-disable comando para recuperarse.

Configurar una NIC de almacenamiento dedicado

Puede usar XenCenter o la CLI xe para asignar a una NIC una dirección IP y dedicarla a una función específica, como el tráfico de almacenamiento. Cuando configura una NIC con una dirección IP, lo hace creando una interfaz secundaria. (El Citrix Hypervisor NIC habilitado para IP utilizado para la administración se conoce como interfaz de administración).

Cuando desee dedicar una interfaz secundaria para un propósito específico, asegúrese de que la configuración de red adecuada esté en su lugar. Esto es para garantizar que la NIC se utiliza sólo para el tráfico deseado. Para dedicar una NIC al tráfico de almacenamiento, configure la NIC, el destino de almacenamiento, el switch y la VLAN de manera que el destino sólo sea accesible a través de la NIC asignada. Si la configuración física e IP no limita el tráfico enviado a través de la NIC de almacenamiento, puede enviar tráfico, como el tráfico de administración a través de la interfaz secundaria.

Cuando crea una nueva interfaz secundaria para el tráfico de almacenamiento, debe asignarle una dirección IP que sea:

  • En la misma subred que la controladora de almacenamiento, si procede, y

  • No en la misma subred que cualquier otra interfaz secundaria o la interfaz de administración.

Al configurar interfaces secundarias, cada interfaz secundaria debe estar en una subred independiente. Por ejemplo, si desea configurar dos interfaces secundarias más para el almacenamiento, necesita direcciones IP en tres subredes diferentes: una subred para la interfaz de administración, una subred para la Interfaz Secundaria 1 y una subred para la Interfaz Secundaria 2.

Si está utilizando la vinculación para la resiliencia del tráfico de almacenamiento, es posible que desee considerar el uso de LACP en lugar de la vinculación del puente Linux. Para utilizar la vinculación LACP, debe configurar el vSwitch como su pila de red. Para obtener más información, consulte Redes de conmutadores virtuales.

Nota:

Al seleccionar una NIC para configurarla como interfaz secundaria para utilizarla con SRs iSCSI o NFS, asegúrese de que la NIC dedicada utilice una subred IP independiente que no se pueda enrutar desde la interfaz de administración. Si esto no se aplica, el tráfico de almacenamiento de información se puede dirigir a través de la interfaz de administración principal después de reiniciar el host, debido al orden en que se inicializan las interfaces de red.

Asegúrese de que el PIF está en una subred independiente o de que el enrutamiento esté configurado para adaptarse a la topología de red para forzar el tráfico deseado sobre el PIF seleccionado.

Configure una configuración IP para el PIF, agregando los valores apropiados para el parámetro mode. Si utiliza direcciones IP estáticas, agregue los parámetros IP, máscara de red, puerta de enlace y DNS:

xe pif-reconfigure-ip mode=DHCP | Static uuid=pif-uuid

Establezca el parámetro disallow-unplug de PIF en true:

xe pif-param-set disallow-unplug=true uuid=pif-uuid
xe pif-param-set other-config:management_purpose="Storage" uuid=pif-uuid

Si desea utilizar una interfaz secundaria para el almacenamiento que también se puede enrutar desde la interfaz de administración (teniendo en cuenta que esta configuración no es la mejor práctica), tiene dos opciones:

  • Después de reiniciar el host, asegúrese de que la interfaz secundaria esté configurada correctamente. Utilice losxe pbd-unplug comandosxe pbd-plug y para reinicializar las conexiones de almacenamiento en el host. Este comando reinicia la conexión de almacenamiento y la enruta a través de la interfaz correcta.

  • También puede utilizarxe pif-forget para eliminar la interfaz de la base de datos de Citrix Hypervisor y configurarla manualmente en el dominio de control. xe pif-forget es una opción avanzada y requiere que esté familiarizado con cómo configurar las redes Linux manualmente.

Usar NIC habilitadas para SR-IOV

La virtualización de E/S de raíz única (SR-IOV) es una tecnología de virtualización que permite que un solo dispositivo PCI aparezca como varios dispositivos PCI en el sistema físico. El dispositivo físico real se conoce como una función física (PF), mientras que los demás se conocen como funciones virtuales (VF). El hipervisor puede asignar uno o más VF a una máquina virtual (VM): el invitado puede utilizar el dispositivo como si estuviera asignado directamente.

La asignación de una o más VF NIC a una VM permite que el tráfico de red omita el switch virtual. Cuando se configura, cada VM se comporta como si estuviera utilizando la NIC directamente, lo que reduce la sobrecarga de procesamiento y mejora el performance.

Beneficios de SR-IOV

Una VF SR-IOV tiene un mejor rendimiento que VIF. Puede garantizar la segregación basada en hardware entre el tráfico de diferentes máquinas virtuales a través de la misma NIC (evitando la pila de red de Citrix Hypervisor).

Con esta función, puede:

  • Habilite SR-IOV en NIC que admitan SR-IOV.

  • Deshabilite SR-IOV en NIC que admitan SR-IOV.

  • Administre las VF de SR-IOV como un fondo de recursos de VF.

  • Asigne VFs SR-IOV a una VM.

  • Configure las VF SR-IOV (por ejemplo, dirección MAC, VLAN, velocidad).

  • Ejecute pruebas para confirmar si SR-IOV es compatible como parte del kit de certificación automatizada.

Configuración del sistema

Configure la plataforma de hardware correctamente para admitir SR-IOV. Se requieren las siguientes tecnologías:

  • Virtualización de MMU de E/S (AMD-VI e Intel VT-d)

  • Interpretación alternativa de Id. de enrutamiento (ARI)

  • Servicios de traducción de direcciones (ATS)

  • Servicios de control de acceso (ACS)

Consulte la documentación que viene con su sistema para obtener información sobre cómo configurar el BIOS para habilitar las tecnologías mencionadas.

Habilitar una red SR-IOV en una NIC

En XenCenter, utilice el Asistente para nueva red de la ficha Redes para crear y habilitar una red SR-IOV en una NIC.

Asignar una red SR-IOV a la interfaz virtual (nivel de VM)

En XenCenter, a nivel de VM, utilice el Asistente para agregar interfaz virtual de la ficha Redes para agregar una red habilitada para SR-IOV como interfaz virtual para esa máquina virtual. Consulte la Ayuda de XenCenter para obtener más información.

NIC e invitados admitidos

Para obtener una lista de las plataformas de hardware y NIC compatibles, consulteLista de compatibilidad de hardware. Consulte la documentación proporcionada por el proveedor para un invitado concreto para determinar si es compatible con SR-IOV.

Limitaciones

  • Para ciertas NIC que utilizan controladores heredados (por ejemplo, la familia Intel I350), el host debe reiniciarse para habilitar o deshabilitar SR-IOV en estos dispositivos.

  • SR-IOV admite sólo los huéspedes HVM.

  • No se admite una red SR-IOV de nivel de grupo que tenga diferentes tipos de NIC.

  • Es posible que una VF SR-IOV y un VIF normal de la misma NIC no puedan comunicarse entre sí debido a las limitaciones de hardware de la NIC. Para permitir que estos hosts se comuniquen, asegúrese de que la comunicación utiliza el patrón VF a VF o VIF a VIF, y no VF a VIF.

  • La configuración de calidad de servicio para algunas VF SR-IOV no tiene efecto porque no admiten la limitación de velocidad de red.

  • No se admite la migración en vivo, la suspensión y el punto de comprobación en las máquinas virtuales que utilizan una VF SR-IOV.

  • Las VF SR-IOV no admiten la conexión en marcha.

  • Para algunas NIC con controladores NIC heredados, es posible que sea necesario reiniciar incluso después del reinicio del host, lo que indica que la NIC no puede habilitar SR-IOV.

  • Las máquinas virtuales creadas en versiones anteriores no pueden utilizar esta función desde XenCenter.

  • Si su máquina virtual tiene una VF SR-IOV, las funciones que requieren migración en vivo no son posibles. Esto se debe a que la máquina virtual está directamente vinculada a la VF NIC habilitada para SR-IOV física. Cualquier tráfico de red de VM enviado a través de un VF SR-IOV omite el vSwitch. Por lo tanto, no es posible crear ACL ni ver Calidad de servicio (QoS).

  • Restricción de hardware: La función SR-IOV se basa en el Controller para restablecer las funciones del dispositivo a un estado impecable dentro de 100 ms, cuando el hipervisor lo solicite mediante el restablecimiento de nivel de función (FLR).

  • SR-IOV se puede utilizar en un entorno que hace uso de alta disponibilidad. Sin embargo, el SR-IOV no se tiene en cuenta en la planificación de la capacidad. Las máquinas virtuales que tienen asignadas VFS SR-IOV se reinician según el máximo esfuerzo cuando hay un host en el grupo que tiene los recursos adecuados. Estos recursos incluyen SR-IOV habilitado en la red correcta y una VF gratuita.

Configurar las VF SR-IOV para controladores heredados

Por lo general, el número máximo de VF que una NIC puede admitir puede determinarse automáticamente. Para las NIC que utilizan controladores heredados (por ejemplo, la familia Intel I350), el límite se define en el archivo de configuración del módulo de controlador. Es posible que el límite deba ajustarse manualmente. Para establecerlo al máximo, abra el archivo con un editor y cambie la línea de inicio:

## VFs-maxvfs-by-user:

Por ejemplo, para establecer el máximo de VF en 4 para que la edición/etc/modprobe.d/igb.conf del controlador igb lea:

## VFs-param: max_vfs
## VFs-maxvfs-by-default: 7
## VFs-maxvfs-by-user: 4
options igb max_vfs=0

Notas:

  • El valor debe ser menor o igual que el valor de la líneaVFs-maxvfs-by-default.

  • No cambie ninguna otra línea en estos archivos.

  • Realice los cambios antes de habilitar SR-IOV.

CLI

ConsulteComandos SR-IOVpara obtener instrucciones de CLI sobre la creación, eliminación, visualización de redes SR-IOV y asignación de un VF SR-IOV a una VM.

Controlar la velocidad de datos salientes (QoS)

Para limitar la cantidad de datos salientes que una máquina virtual puede enviar por segundo, establezca un valor opcional de calidad de servicio (QoS) en las interfaces virtuales (VIF) de VM. La configuración le permite especificar una velocidad máxima de transmisión para los paquetes salientes en kilobytes por segundo.

El valor de Calidad de servicio limita la velocidad de transmisión desde la máquina virtual. La configuración de Calidad de servicio no limita la cantidad de datos que puede recibir la máquina virtual. Si se desea tal límite, se recomienda limitar la velocidad de los paquetes entrantes más arriba en la red (por ejemplo, en el nivel del switch).

Dependiendo de la pila de red configurada en el grupo, puede establecer el valor Calidad de servicio en las interfaces virtuales (VIF) de VM en uno de los dos lugares. Ya sea en vSwitch Controller o en Citrix Hypervisor (mediante la CLI o XenCenter).

Conmutador virtual

Métodos de configuración:

  • vSwitch Controller Este es el método preferido para establecer la velocidad máxima de transmisión en un VIF cuando el vSwitch es la pila de red. Cuando se utiliza la pila vSwitch, la opción Calidad de servicio de XenCenter no está disponible.
  • comandos xe Es posible establecer la velocidad de transmisión de Calidad de Servicio mediante los comandos del ejemplo siguiente. Sin embargo, el método preferido es a través de la interfaz de usuario del vSwitch Controller, que proporciona un control más fino.

Puente Linux

Métodos de configuración disponibles:

  • XenCenter Puede establecer el valor límite de velocidad de transmisión de Calidad de servicio en el cuadro de diálogo de propiedades de la interfaz virtual.
  • comandos xe Puede establecer la velocidad de transmisión de Calidad de Servicio mediante la CLI mediante los comandos de la sección siguiente.

Importante:

Cuando vSwitch está configurado como la pila de red, es posible configurar un valor QoS inadvertidamente en vSwitch Controller y dentro del servidor Citrix Hypervisor. En este caso, Citrix Hypervisor limita el tráfico saliente utilizando la velocidad más baja que haya establecido.

Ejemplo de comando CLI para QoS:

Para limitar un VIF a una velocidad de transmisión máxima de 100 kilobytes por segundo mediante la CLI, utilice elvif-param-set comando:

xe vif-param-set uuid=vif_uuid qos_algorithm_type=ratelimit
xe vif-param-set uuid=vif_uuid qos_algorithm_params:kbps=100

Nota:

Si utiliza vSwitch Controller, se recomienda establecer el límite de velocidad de transmisión en vSwitch Controller en lugar de este comando CLI. Para obtener instrucciones sobre cómo configurar el límite de velocidad de QoS en el vSwitch Controller, consulteConmutador virtual y Controller.

Cambiar las opciones de configuración de red

En esta sección se explica cómo cambiar la configuración de red del servidor Citrix Hypervisor. Incluye:

  • Cambiar el nombre de host (es decir, el nombre del sistema de nombres de dominio (DNS))

  • Agregar o eliminar servidores DNS

  • Cambio de direcciones IP

  • Cambio de la NIC que se utiliza como interfaz de administración

  • Agregar una nueva NIC física al servidor

  • Agregar un propósito a una red

  • Activación del filtrado ARP (bloqueo de puertos de conmutación)

Nombre de host

El nombre de host del sistema, también conocido como nombre de dominio o DNS, se define en la base de datos de toda la agrupación y se cambia mediante el comandoxe host-set-hostname-live CLI de la siguiente manera:

xe host-set-hostname-live host-uuid=host_uuid host-name=host-name

El nombre de host del dominio de control subyacente cambia dinámicamente para reflejar el nuevo nombre de host.

Servidores DNS

Para agregar o eliminar servidores DNS en la configuración de direcciones IP del servidor Citrix Hypervisor, utilice elpif-reconfigure-ip comando. Por ejemplo, para un PIF con una IP estática:

pif-reconfigure-ip uuid=pif_uuid mode=static DNS=new_dns_ip

Cambiar la configuración de la dirección IP para un host independiente

Puede usar la CLI xe para cambiar la configuración de la interfaz de red. No cambie directamente los scripts de configuración de red subyacentes.

Para cambiar la configuración de la dirección IP de un PIF, utilice el comandopif-reconfigure-ip CLI. Consultepif-reconfigure-ippara obtener más información sobre los parámetros delpif-reconfigure-ipcomando. Consulte la siguiente sección para obtener información sobre cómo cambiar las direcciones IP de host en los grupos de recursos.

Cambiar la configuración de la dirección IP en los grupos de recursos

Los servidores Citrix Hypervisor de los grupos de recursos tienen una única dirección IP de administración utilizada para la administración y la comunicación con y desde otros hosts del grupo. Los pasos necesarios para cambiar la dirección IP de la interfaz de administración de un host son diferentes para los hosts maestro y otros.

Nota:

Debe tener cuidado al cambiar la dirección IP de un servidor y otros parámetros de red. Dependiendo de la topología de red y del cambio que se realice, las conexiones al almacenamiento de red se pueden perder. Cuando esto sucede, el almacenamiento debe volver a conectarse mediante la función Reparar almacenamiento de XenCenter o mediante el comandopbd-plug CLI. Por este motivo, se recomienda migrar las máquinas virtuales fuera del servidor antes de cambiar su configuración IP.

Utilice el comandopif-reconfigure-ip CLI para establecer la dirección IP como desee. Consultepif-reconfigure-ippara obtener más información sobre los parámetros delpif-reconfigure-ipcomando. :

xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP

Utilice el comandohost-list CLI para confirmar que el host miembro se ha vuelto a conectar correctamente al host maestro comprobando que todos los demás servidores Citrix Hypervisor del grupo están visibles:

xe host-list

Cambiar la dirección IP del servidor Citrix Hypervisor maestro requiere pasos adicionales. Esto se debe a que cada miembro del grupo utiliza la dirección IP anunciada del maestro de grupo para la comunicación. Los miembros del grupo no saben cómo ponerse en contacto con el maestro cuando cambia su dirección IP.

Siempre que sea posible, utilice una dirección IP dedicada que no sea probable que cambie durante la vida útil del grupo para los maestros del grupo.

Utilice el comandopif-reconfigure-ip CLI para establecer la dirección IP como desee:

xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP

Cuando cambia la dirección IP del maestro de grupo, todos los hosts miembros entran en modo de emergencia cuando no se ponen en contacto con el host maestro.

En el maestro de grupo, utilice elpool-recover-slaves comando para forzar al maestro a ponerse en contacto con cada miembro del grupo e informarles de la nueva dirección IP maestra:

xe pool-recover-slaves

Interfaz de administración

Cuando Citrix Hypervisor está instalado en un host con varias NIC, se selecciona una NIC para utilizarla como interfaz de administración. La interfaz de administración se utiliza para las conexiones de XenCenter al host y para la comunicación de host a host.

Utilice elpif-list comando para determinar qué PIF corresponde a la NIC que se utilizará como interfaz de administración. Se devuelve el UUID de cada PIF.

xe pif-list

Utilice elpif-param-list comando para verificar la configuración de direcciones IP para el PIF utilizado para la interfaz de administración. Si es necesario, utilice el comando pif-reconfigure-ip para configurar el direccionamiento IP para el PIF que se va a utilizar.

xe pif-param-list uuid=pif_uuid

Utilice el comandohost-management-reconfigure CLI para cambiar el PIF utilizado para la interfaz de administración. Si este host forma parte de un fondo de recursos, este comando debe emitirse en la consola del host miembro:

xe host-management-reconfigure pif-uuid=pif_uuid

Utilice elnetwork-list comando para determinar qué PIF corresponde a la NIC que se utilizará como interfaz de administración para todos los hosts del grupo. Se devuelve el UUID de la red de toda la agrupación.

xe network-list

Utilice elnetwork-param-list comando para obtener los UUID PIF de todos los hosts del grupo. Utilice elpif-param-list comando para verificar la configuración de direcciones IP para el PIF para la interfaz de administración. Si es necesario, utilice el comando pif-reconfigure-ip para configurar el direccionamiento IP para el PIF que se va a utilizar.

xe pif-param-list uuid=pif_uuid

Utilice el comandopool-management-reconfigure CLI para cambiar el PIF utilizado para la interfaz de administración que aparece en la lista Redes.

xe pool-management-reconfigure network-uuid=network_uuid

Deshabilitar el acceso de administración

Para deshabilitar completamente el acceso remoto a la consola de administración, utilice el comandohost-management-disable CLI.

Advertencia:

Cuando la interfaz de administración está deshabilitada, debe iniciar sesión en la consola del host físico para realizar tareas de administración. Las interfaces externas como XenCenter no funcionan cuando la interfaz de administración está deshabilitada.

Agregar una NIC física nueva

Instale una nueva NIC física en el servidor Citrix Hypervisor de la manera habitual. A continuación, después de reiniciar el servidor, ejecute el comandopif-scan xe CLI para crear un nuevo objeto PIF para la nueva NIC.

Agregar un propósito a una red

El propósito de la red se puede utilizar para agregar funcionalidades adicionales a una red. Por ejemplo, la capacidad de usar la red para realizar conexiones NBD.

Para agregar un propósito de red, utilice elxe network-param-add comando:

xe network-param-add param-name=purpose param-key=purpose uuid=network-uuid

Para eliminar un propósito de red, utilice elxe network-param-remove comando:

xe network-param-remove param-name=purpose param-key=purpose uuid=network-uuid

Actualmente, los valores disponibles para el propósito de red sonnbd yinsecure_nbd . Para obtener más información, consulte la Guía de seguimiento de bloques modificados de Citrix Hypervisor.

Usar bloqueo del puerto del conmutador

La función de bloqueo del puerto del conmutador de Citrix Hypervisor le permite controlar el tráfico enviado desde máquinas virtuales desconocidas, no confiables o potencialmente hostiles, limitando su capacidad de pretender que tienen una dirección MAC o IP que no se les asignó. Puede utilizar los comandos de bloqueo de puertos para bloquear todo el tráfico de una red de forma predeterminada o definir direcciones IP específicas desde las que una máquina virtual individual puede enviar tráfico.

El bloqueo de puertos de conmutación es una característica diseñada para proveedores de servicios de nube pública en entornos preocupados por amenazas internas. Esta funcionalidad ayuda a los proveedores de servicios de nube pública que tienen una arquitectura de red en la que cada máquina virtual tiene una dirección IP pública conectada a Internet. Dado que los inquilinos de la nube no son de confianza, puede utilizar medidas de seguridad como la protección de suplantación de identidad para asegurarse de que los inquilinos no puedan atacar a otras máquinas virtuales en la nube.

El uso del bloqueo de puertos de conmutación le permite simplificar la configuración de red al permitir que todos sus inquilinos o invitados utilicen la misma red de capa 2.

Una de las funciones más importantes de los comandos de bloqueo de puertos es que pueden restringir el tráfico que envía un invitado que no es de confianza. Esto restringe la capacidad del huésped para fingir que tiene una dirección MAC o IP que realmente no posee. Específicamente, puede utilizar estos comandos para evitar que un invitado:

  • Reclamar una dirección IP o MAC distinta de las que el administrador de Citrix Hypervisor ha especificado que puede utilizar

  • Interceptar, suplantar o interrumpir el tráfico de otras máquinas virtuales

Requisitos

  • La función de bloqueo de puertos de conmutación de Citrix Hypervisor se admite en las pilas de redes de puente de Linux y vSwitch.

  • Cuando habilita Control de acceso basado en roles (RBAC) en su entorno, el usuario que configura el bloqueo de puerto conmutador debe iniciar sesión con una cuenta que tenga al menos una función de operador de grupo o administrador de grupo. Cuando RBAC no está habilitado en su entorno, el usuario debe iniciar sesión con la cuenta raíz del maestro de grupo.

  • Cuando ejecuta los comandos switch-port locking, las redes pueden estar en línea o sin conexión.

  • En los invitados de Windows, el icono Red desconectada sólo aparece cuando Citrix VM Tools está instalado en el invitado.

Notas

Sin configuraciones de bloqueo de puertos de conmutación, los VIF se establecen en «network_default» y las redes se establecen en «unlocked. «

No se admite la configuración del bloqueo del puerto del conmutador cuando el controlador vSwitch y otros controladores de terceros están en uso en el entorno.

El bloqueo del puerto del conmutador no impide que los inquilinos de la nube:

  • Realizar un ataque a nivel de IP en otro inquilino/usuario. Sin embargo, el bloqueo del puerto conmutador les impide realizar el ataque a nivel de IP si intentan utilizar los siguientes medios para hacerlo y el bloqueo del puerto conmutador está configurado: a) hacerse pasar por otro inquilino en la nube o usuario o b) iniciar una interceptación del tráfico destinado a otro usuario.

  • Agotar recursos de red.

  • Recibir cierto tráfico destinado a otras máquinas virtuales a través de comportamientos normales de inundación de conmutadores (para direcciones MAC de difusión o direcciones MAC de destino desconocido).

Del mismo modo, el bloqueo del puerto de conmutación no restringe dónde una máquina virtual puede enviar tráfico.

Notas de aplicación

Puede implementar la funcionalidad de bloqueo del puerto de conmutación mediante la línea de comandos o la API de Citrix Hypervisor. Sin embargo, en entornos grandes, donde la automatización es una preocupación principal, el método de implementación más típico podría ser mediante el uso de la API.

Ejemplos

Esta sección proporciona ejemplos de cómo el bloqueo de puertos conmutadores puede prevenir ciertos tipos de ataques. En estos ejemplos, VM-c es una máquina virtual que un inquilino hostil (inquilino C) está arrendando y utilizando para ataques. VM a y VM b son máquinas virtuales arrendadas por inquilinos que no atacan.

Ejemplo 1: Cómo el bloqueo del puerto del conmutador puede impedir la prevención de suplantación de ARP:

La suplantación de ARP se utiliza para indicar los intentos de un atacante de asociar su dirección MAC con la dirección IP de otro nodo. La suplantación de ARP puede provocar que el tráfico del nodo se envíe al atacante en su lugar. Para lograr este objetivo, el atacante envía mensajes ARP falsos (falsificados) a una LAN Ethernet.

Escenario:

La máquina virtual A (VM-a) desea enviar tráfico IP desde VM-A a Virtual Machine B (VM-b) dirigiéndolo a la dirección IP de VM-B. El propietario de Virtual Machine C quiere usar ARP spoofing para pretender que su VM, VM-c, es realmente VM-b.

  1. VM-c envía una secuencia especulativa de respuestas ARP a VM-a. Las respuestas de ARP afirman que la dirección MAC de la respuesta (C_MAC) está asociada a la dirección IP, b_IP

    Resultado: Debido a que el administrador habilitó el bloqueo del puerto del conmutador, todos estos paquetes se descartan porque habilitar el bloqueo del puerto del conmutador impide la suplantación.

  2. vm-b envía una respuesta ARP a vm-a, afirmando que la dirección MAC de la respuesta (b_mac) está asociada a la dirección IP b_IP.

    Resultado: vm-a recibe la respuesta ARP de vm-b.

Ejemplo 2: Prevención de suplantación de identidad de IP:

La suplantación de direcciones IP es un proceso que oculta la identidad de los paquetes mediante la creación de paquetes de Protocolo de Internet (IP) con una dirección IP de origen falsificada.

Escenario:

El inquilino C está intentando realizar un ataque de denegación de servicio utilizando su host, Host-C, en un sistema remoto para ocultar su identidad.

Intento 1:

El inquilino C establece la dirección IP y la dirección MAC del host en las direcciones IP y MAC de VM-A (A_IP y A_MAC). El inquilino C indica al Host-C que envíe tráfico IP a un sistema remoto.

Resultado: Los paquetes Host-C se descartan. Esto se debe a que el administrador habilitó el bloqueo del puerto del conmutador. Los paquetes Host-C se descartan porque habilitar el bloqueo del puerto del conmutador evita la suplantación.

Intento 2:

El inquilino C establece la dirección IP del Host-C en la dirección IP de VM-A (A_IP) y mantiene su C_MAC original.

El inquilino C indica al Host-C que envíe tráfico IP a un sistema remoto.

Resultado: Los paquetes Host-C se descartan. Esto se debe a que el administrador habilitó el bloqueo del puerto del conmutador, lo que impide la suplantación.

Ejemplo 3: Alojamiento web:

Escenario:

Alice es una administradora de infraestructura.

Uno de sus inquilinos, el inquilino B, aloja varios sitios web desde su VM, VM-B. Cada sitio web necesita una dirección IP distinta alojada en la misma interfaz de red virtual (VIF).

Alice reconfigura el VIF de Host-B para que se bloquee a un solo MAC pero a muchas direcciones IP.

Cómo funciona el bloqueo del puerto de conmutación

La función de bloqueo del puerto de conmutación le permite controlar el filtrado de paquetes en uno o más de dos niveles:

  • Nivel VIF. La configuración que configure en el VIF determina cómo se filtran los paquetes. Puede configurar el VIF para evitar que la máquina virtual envíe cualquier tráfico, restringir el VIF para que sólo pueda enviar tráfico utilizando su dirección IP asignada o permitir que la máquina virtual envíe tráfico a cualquier dirección IP de la red conectada al VIF.

  • Nivel de red. La red Citrix Hypervisor determina cómo se filtran los paquetes. Cuando el modo de bloqueo de un VIF se establece ennetwork_default, hace referencia a la configuración de bloqueo a nivel de red para determinar qué tráfico permitir.

Independientemente de la pila de red que utilice, la función funciona de la misma manera. Sin embargo, como se describe con más detalle en las secciones siguientes, el puente Linux no admite completamente el bloqueo de puertos conmutadores en IPv6.

Estados de modo de bloqueo VIF

La función de bloqueo del puerto del conmutador de Citrix Hypervisor proporciona un modo de bloqueo que le permite configurar VIFs en cuatro estados diferentes. Estos estados sólo se aplican cuando el VIF está conectado a una máquina virtual en ejecución.

! [Esta ilustración muestra cómo se comportan tres estados de modo de bloqueo VIF diferentes cuando el modo de bloqueo de red está establecido en desbloqueado y el estado de VIF está configurado. En la primera imagen, el estado VIF se establece como predeterminado, por lo que no se filtra tráfico de la VM. El VIF no envía ni recibe ningún paquete porque el modo de bloqueo está configuradodisabled en la segunda imagen. En la tercera imagen, el estado VIF se establece en bloqueado. Esto significa que el VIF sólo puede enviar paquetes si esos paquetes contienen la dirección MAC e IP correcta.] (/es-es/citrix-hypervisor/media/vif-switch-port-locking-modes.png)

  • Default de red. Cuando el estado del VIF se establece ennetwork_default, Citrix Hypervisor utiliza eldefault-locking-modeparámetro de la red para determinar si y cómo filtrar los paquetes que viajan a través del VIF. El comportamiento varía según si la red asociada tiene el parámetro de modo de bloqueo predeterminado de red establecido en deshabilitado o desbloqueado:

    -default-locking-mode=disabled, Citrix Hypervisor aplica una regla de filtrado para que el VIF deje todo el tráfico.

    -default-locking-mode=desbloqueado, Citrix Hypervisor elimina todas las reglas de filtrado asociadas con el VIF. De forma predeterminada, el parámetro de modo de bloqueo predeterminado se establece enunlocked.

    Para obtener información sobre eldefault-locking-mode parámetro, consulteComandos de red .

    El modo de bloqueo predeterminado de la red no tiene ningún efecto en VIFs conectados cuyo estado de bloqueo es distinto denetwork_default.

    Nota:

    No se puede cambiar eldefault-locking-mode de una red que tiene VIFs activos conectados a ella.

  • Cerrada. Citrix Hypervisor aplica reglas de filtrado para que sólo el tráfico enviado a/desde las direcciones MAC e IP especificadas pueda enviarse a través del VIF. En este modo, si no se especifica ninguna dirección IP, la máquina virtual no puede enviar ningún tráfico a través de ese VIF, en esa red.

    Para especificar las direcciones IP desde las que el VIF acepta tráfico, utilice las direcciones IP IPv4 o IPv6 mediante losipv4_allowed parámetrosipv6_allowed o. Sin embargo, si tiene configurado el puente Linux, no escriba direcciones IPv6.

    Citrix Hypervisor permite escribir direcciones IPv6 cuando el puente Linux está activo. Sin embargo, Citrix Hypervisor no puede filtrar según las direcciones IPv6 escritas. La razón es que el puente Linux no tiene módulos para filtrar paquetes Neighbor Discovery Protocol (NDP). Por lo tanto, no se puede implementar una protección completa y los invitados podrían hacerse pasar por otro invitado falsificando paquetes NDP. Como resultado, si especifica incluso una dirección IPv6, Citrix Hypervisor permite que todo el tráfico IPv6 pase a través del VIF. Si no especifica ninguna dirección IPv6, Citrix Hypervisor no permite que ningún tráfico IPv6 pase al VIF.

  • Desbloqueado. Todo el tráfico de red puede pasar a través del VIF. Es decir, no se aplican filtros a ningún tráfico que vaya hacia o desde el VIF.

  • Deshabilitado. No se permite el paso de tráfico a través del VIF. (Es decir, Citrix Hypervisor aplica una regla de filtrado para que el VIF deje todo el tráfico).

Configurar el bloqueo de puertos del switch

En esta sección se ofrecen tres procedimientos diferentes:

  • Restringir VIFs para usar una dirección IP específica

  • Agregue una dirección IP a una lista restringida existente. Por ejemplo, para agregar una dirección IP a un VIF cuando la máquina virtual se está ejecutando y conectado a la red (por ejemplo, si está desconectado temporalmente una red).

  • Eliminar una dirección IP de una lista restringida existente

Si el modo de bloqueo de un VIF está establecido enlocked, sólo puede utilizar las direcciones especificadas en losipv4-allowedparámetrosipv6-allowedo.

Debido a que, en algunos casos relativamente raros, los VIF pueden tener más de una dirección IP, es posible especificar varias direcciones IP para un VIF.

Puede realizar estos procedimientos antes o después de conectar el VIF (o iniciar la VM).

Cambie el modo de bloqueo predeterminado a bloqueado, si no está utilizando ya ese modo, ejecutando el siguiente comando:

xe vif-param-set uuid=vif-uuid locking-mode=locked

vif-uuid`` Representa el UUID del VIF que desea permitir enviar tráfico. Para obtener el UUID, ejecute elvif-list comando xe en el host. vm-uuid Indica la máquina virtual para la que aparece la información. El ID del dispositivo indica el número de dispositivo del VIF.

Ejecute elvif-param-set comando para especificar las direcciones IP desde las que la máquina virtual puede enviar tráfico. Realice una o varias de las siguientes acciones:

  • Especifique uno o más destinos de direcciones IP IPv4. Por ejemplo:

     xe vif-param-set uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
    
  • Especifique uno o más destinos de direcciones IP IPv6. Por ejemplo:

     xe vif-param-set uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
    

Puede especificar varias direcciones IP separándolas con una coma, como se muestra en el ejemplo anterior.

Después de realizar el procedimiento para restringir un VIF al uso de una dirección IP específica, puede agregar una o más direcciones IP que el VIF puede utilizar.

Ejecute elvif-param-add comando para agregar las direcciones IP a la lista existente. Realice una o varias de las siguientes acciones:

  • Especifique la dirección IP IPv4. Por ejemplo:

     xe vif-param-add uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
    
  • Especifique la dirección IP IPv6. Por ejemplo:

     xe vif-param-add uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
    

Si restringe un VIF para que utilice dos o más direcciones IP, puede eliminar una de esas direcciones IP de la lista.

Ejecute elvif-param-remove comando para eliminar las direcciones IP de la lista existente. Realice una o varias de las siguientes acciones:

  • Especifique la dirección IP IPv4 que desea eliminar. Por ejemplo:

     xe vif-param-remove uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
    
  • Especifique la dirección IP IPv6 que desea eliminar. Por ejemplo:

     xe vif-param-remove uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
    

Impedir que una máquina virtual envíe o reciba tráfico desde una red específica

El procedimiento siguiente impide que una máquina virtual se comunique a través de un VIF específico. A medida que un VIF se conecta a una red Citrix Hypervisor específica, puede utilizar este procedimiento para evitar que una máquina virtual envíe o reciba tráfico de una red específica. Esto proporciona un nivel de control más granular que deshabilitar una red completa.

Si utiliza el comando CLI, no necesita desconectar el VIF para establecer el modo de bloqueo del VIF. El comando cambia las reglas de filtrado mientras se ejecuta el VIF. En este caso, la conexión de red todavía parece estar presente; sin embargo, el VIF elimina cualquier paquete que la VM intente enviar.

Consejo:

Para encontrar el UUID de un VIF, ejecute elvif-list comando xe en el host. El ID del dispositivo indica el número de dispositivo del VIF.

Para evitar que un VIF reciba tráfico, deshabilite el VIF conectado a la red desde la que desea impedir que la VM reciba tráfico:

xe vif-param-set uuid=vif-uuid locking-mode=disabled

También puede deshabilitar el VIF en XenCenter seleccionando la interfaz de red virtual en la ficha Redes de la VM y haciendo clic en Desactivar.

Eliminar la restricción de un VIF a una dirección IP

Para volver al estado de modo de bloqueo predeterminado (original), utilice el procedimiento siguiente. De forma predeterminada, al crear un VIF, Citrix Hypervisor lo configura para que no se limite a utilizar una dirección IP específica.

Para revertir un VIF a un estado desbloqueado, cambie el modo de bloqueo predeterminado de VIF a desbloqueado. Si aún no está utilizando ese modo, ejecute el siguiente comando:

xe vif-param-set uuid=vif_uuid locking-mode=unlocked

Simplifique la configuración del modo de bloqueo VIF en la nube

En lugar de ejecutar los comandos VIF de modo de bloqueo para cada VIF, puede asegurarse de que todos los VIF están deshabilitados de forma predeterminada. Para ello, debe cambiar el filtrado de paquetes en el nivel de red. Al cambiar el filtrado de paquetes, la red Citrix Hypervisor determina cómo se filtran los paquetes, como se describe en la sección anterior Cómo funciona el bloqueo del puerto del conmutador.

Específicamente, ladefault-locking-mode configuración de una red determina cómo se comportan los nuevos VIF con configuración predeterminada. Siempre que un VIFlocking-mode está configurado endefault , el VIF se refiere al modo de bloqueo de red (default-locking-mode ) para determinar si y cómo filtrar los paquetes que viajan a través del VIF:

  • Desbloqueado. Cuando eldefault-locking-mode parámetro de red está establecido enunlocked , Citrix Hypervisor permite que la máquina virtual envíe tráfico a cualquier dirección IP de la red a la que se conecta VIF.

  • Deshabilitado. Cuando eldefault-locking-mode parámetro se establece endisabled , Citrix Hypervisor aplica una regla de filtrado para que el VIF borre todo el tráfico.

De forma predeterminada,default-locking-mode para todas las redes creadas en XenCenter y utilizando la CLI se establece enunlocked .

Al establecer el modo de bloqueo del VIF en su valor predeterminado (network_default), puede crear una configuración predeterminada básica (a nivel de red) para todos los VIFs recién creados que se conectan a una red específica.

Esta ilustración muestra cómo, cuando un VIFlocking-mode está establecido en su configuración predeterminada (network_default ), el VIF utiliza la reddefault-locking-mode para determinar su comportamiento.

 Esta ilustración muestra cómo un VIF, cuando se configura en su configuración predeterminada (locking-mode=network_default), comprueba la configuración asociada con el modo de bloqueo predeterminado. En esta ilustración, la red se establece en default-locking-mode=disabled para que ningún tráfico pueda pasar a través del VIF.

Por ejemplo, de forma predeterminada, los VIF se crean con sulocking-mode conjunto ennetwork_default . Si establecedefault-locking-mode= una reddisabled, se desactivarán los VIF nuevos para los que no haya configurado el modo de bloqueo. Los VIF permanecen deshabilitados hasta que (a) cambie ellocking-mode parámetro del VIF individual o (b) establezca explícitamente los VIF en `unlocked.locking-mode Esto resulta útil cuando confía lo suficiente en una máquina virtual específica para que no desee filtrar su tráfico en absoluto.

Para cambiar la configuración predeterminada del modo de bloqueo de una red:

Después de crear la red, cambie el modo de bloqueo predeterminado ejecutando el siguiente comando:

xe network-param-set uuid=network-uuid default-locking-mode=[unlocked|disabled]

Nota:

Para obtener el UUID de una red, ejecute elnetwork-list comando xe. Este comando muestra los UUID de todas las redes del host en el que ejecutó el comando.

Para comprobar la configuración predeterminada del modo de bloqueo de una red:

Ejecute uno de los siguientes comandos:

xe network-param-get uuid=network-uuid param-name=default-locking-mode

O BIEN

xe network-list uuid=network-uuid params=default-locking-mode

Usar la configuración de red para el filtrado de tráfico VIF

El procedimiento siguiente indica a un VIF en una máquina virtual que utilice ladefault-locking-mode configuración de red de Citrix Hypervisor en la propia red para determinar cómo filtrar el tráfico.

  1. Cambie el estado de bloqueo de VIF anetwork_default, si no está utilizando ya ese modo, ejecutando el siguiente comando:

    xe vif-param-set uuid=vif_uuid locking-mode=network_default
    
  2. Cambie el modo de bloqueo predeterminado aunlocked, si no está utilizando ya ese modo, ejecutando el siguiente comando:

    xe network-param-set uuid=network-uuid default-locking-mode=unlocked