Administrar redes

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

Crear redes en un servidor independiente

Como las redes externas se crean para cada PIF durante la instalación del host, la creación de redes adicionales normalmente solo se requiere para:

• Use una red privada

• Admite operaciones avanzadas como VLAN o vinculación NIC

Para obtener información sobre cómo agregar o eliminar redes mediante XenCenter, consulte Agregar una nueva red en la documentación de XenCenter.

Abra la consola de texto del servidor de 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
<!--NeedCopy-->

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 la misma cantidad de NIC físicas. Este requisito no se aplica estrictamente cuando un host se une a un grupo. Una de las NIC siempre se designa como interfaz de administracióny se utiliza para el tráfico de administración de Citrix Hypervisor.

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

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

Creación de VLAN

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

Abra la consola del servidor de Citrix Hypervisor.

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

xe network-create name-label=network5
<!--NeedCopy-->

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

xe pif-list
<!--NeedCopy-->

Cree un objeto de VLAN que especifique la etiqueta de VLAN y PIF físicas deseadas en todas las máquinas virtuales que se conectarán 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
<!--NeedCopy-->

Conecte VIF de VM a la nueva red. Para obtener más información, consulte Crear redes en un servidor independiente.

Crear vínculos NIC en un host independiente

Recomendamos usar XenCenter para crear vínculos NIC. Para obtener más información, consulte Configuración de NIC.

En esta sección se describe cómo usar la CLI xe para unir interfaces NIC en servidores de Citrix Hypervisor que no están en un grupo. Para obtener información sobre el uso de la CLI xe para crear vínculos NIC en servidores de Citrix Hypervisor que comprenden una agrupación de recursos, consulte Creación de vínculos NIC en agrupaciones de recursos.

Crear un vínculo NIC

Cuando une una NIC, la unión absorbe la PIF/NIC en uso como interfaz de administración. La interfaz de gestión se traslada automáticamente al PIF de vínculos.

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

   xe network-create name-label=bond0
   <!--NeedCopy-->
   

2. Utilice el comando pif-list para determinar los UUID de los PIF que se utilizarán en el enlace:

   xe pif-list
   <!--NeedCopy-->
   

3. Lleve a cabo una de las siguientes acciones:

   • Para configurar el enlace en modo activo-activo (predeterminado), utilice el comando bond-create para crear el enlace. Con 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
      <!--NeedCopy-->
     

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

   • Para configurar el enlace en modo activo-pasivo o enlace LACP, utilice la misma sintaxis, agregue el parámetro mode opcional 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
      <!--NeedCopy-->
     

Controlar la dirección MAC del vínculo

Cuando se une la interfaz de administración, se subsume el PIF/NIC en uso como interfaz de administración. Si el host usa 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 vínculo para que sea diferente de la dirección MAC de la NIC de la interfaz de administración (actual). Sin embargo, a medida que se habilita el enlace 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 vínculo de dos maneras:

• Se puede especificar un parámetro mac opcional en el comando bond-create. Puede utilizar este parámetro para establecer la dirección MAC de enlace en cualquier dirección arbitraria.

• Si no se especifica el parámetro mac, 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 administración no forma parte del vínculo, pero sí lo es otra interfaz de administración, el vínculo utiliza la dirección MAC (y también la dirección IP) de esa interfaz de administración. Si ninguna de las NIC del vínculo es una interfaz de administración, el vínculo utiliza el MAC de la primera NIC nombrada.

Revertir vínculos NIC

Al revertir el servidor de Citrix Hypervisor a una configuración no vinculada, el comando bond-destroy configura automáticamente la NIC principal como interfaz para la interfaz de administración. Por lo tanto, todas las VIF se trasladan a la interfaz de administración. Si la interfaz de administración de un host está en una interfaz enlazada de VLAN etiquetada, al bond-destroyejecutarla, la VLAN de administración se mueve a la NIC principal.

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

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

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

3. La primera NIC denominada. Puede averiguar cuál es ejecutando lo siguiente:

   xe bond-list params=all
   <!--NeedCopy-->
   

Crear vínculos NIC en grupos de recursos

Siempre que sea posible, cree vínculos de NIC como parte de la creación inicial del grupo de recursos, antes de unir más hosts al grupo o de crear máquinas virtuales. Esto permite que la configuración de enlace se replique automáticamente en los hosts a medida que se unen al grupo y reduce la cantidad de pasos requeridos.

Agregar un vínculo NIC a un grupo existente requiere una de las siguientes opciones:

• Usar 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.

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

Para simplificar y evitar errores de configuración, recomendamos usar XenCenter para crear enlaces NIC. Para obtener más información, consulte Configuración de NIC.

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

Advertencia:

No intente crear vínculos de red cuando la alta disponibilidad esté habilitada. El proceso de creación de vínculos perturba los latidos del corazón de alta disponibilidad en curso y hace que los anfitriones se autocerquen (se apaguen). Los hosts pueden no reiniciarse correctamente y pueden necesitar el comando host-emergency-ha-disable para recuperarse.

Selecciona el host que quieres que sea el maestro. El host maestro pertenece a un grupo sin nombre de forma predeterminada. Para crear una agrupación de recursos con la CLI, cambie el nombre del grupo sin nombre existente:

xe pool-param-set name-label="New Pool" uuid=pool_uuid
<!--NeedCopy-->

Cree el vínculo NIC como se describe en Crear un vínculo NIC.

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

xe pool-join master-address=host1 master-username=root master-password=password
<!--NeedCopy-->

La información de red y vínculos se replica automáticamente en el nuevo host. La interfaz de administración se mueve automáticamente de la NIC del host en la que se configuró originalmente al PIF enlazado. Es decir, la interfaz de administración ahora se absorbe en el vínculo para que todo el vínculo funcione como interfaz de administración.

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

xe host-list
<!--NeedCopy-->

Advertencia:

No intente crear vínculos de red mientras la alta disponibilidad esté habilitada. El proceso de creación de vínculos perturba los latidos del corazón de alta disponibilidad en curso y hace que los anfitriones se autocerquen (se apaguen). Los hosts pueden no reiniciarse correctamente y es posible que deba ejecutar el comando host-emergency-ha-disable para recuperarse.

Configurar una NIC de almacenamiento dedicada

Puede usar XenCenter o la CLI xe para asignar una dirección IP a una NIC 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 mediante la creación de una interfaz secundaria. (La NIC habilitada para IP que Citrix Hypervisor utiliza para la administración se conoce como interfaz de administración).

Cuando quiera dedicar una interfaz secundaria para un propósito específico, asegúrese de que se haya implementado la configuración de red adecuada. Esto es para garantizar que la NIC se utilice únicamente para el tráfico deseado. Para dedicar una NIC al tráfico de almacenamiento, configure la NIC, el destino de almacenamiento, el conmutador y la VLAN de modo que solo se pueda acceder al destino a través de la NIC asignada. Si su 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 el controlador 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 quiere configurar dos interfaces secundarias más para el almacenamiento, necesitará 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 de su tráfico de almacenamiento, puede considerar el uso de LACP en lugar de la vinculación de puente de Linux. Para usar la vinculación LACP, debe configurar el vSwitch como su pila de redes. Para obtener más información, consulte Redes de vSwitch.

Nota:

Al seleccionar una NIC para configurarla como interfaz secundaria para usarla con SR iSCSI o NFS, asegúrese de que la NIC dedicada utilice una subred IP independiente que no se pueda redirigir desde la interfaz de administración. Si no se aplica, es posible que el tráfico de almacenamiento se dirija 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 que la redirección esté configurada para adaptarse a su topología de red para forzar el tráfico deseado a través del PIF seleccionado.

Configure una configuración de IP para el PIF, agregando los valores apropiados para el parámetro mode. Si usa 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
<!--NeedCopy-->

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

xe pif-param-set disallow-unplug=true uuid=pif-uuid
<!--NeedCopy-->

xe pif-param-set other-config:management_purpose="Storage" uuid=pif-uuid
<!--NeedCopy-->

Si quiere utilizar una interfaz secundaria para el almacenamiento que también se puede redirigir 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. Use los comandos xe pbd-unplug y xe pbd-plug para reinicializar las conexiones de almacenamiento en el host. Este comando reinicia la conexión de almacenamiento y la redirige a través de la interfaz correcta.

• Alternativamente, puede usar xe 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 la configuración manual de redes de Linux.

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 función física (PF), mientras que los demás se conocen como funciones virtuales (VF). El hipervisor puede asignar una o más VF a una máquina virtual (VM): el huésped puede usar el dispositivo como si se hubiera asignado directamente.

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

Beneficios del SR-IOV

Un VF SR-IOV tiene un rendimiento mejor que el VIF. Puede garantizar la segregación basada en hardware entre el tráfico de diferentes VM a través de la misma NIC (sin pasar por la pila de red de Citrix Hypervisor).

Con esta función, puede:

• Habilite SR-IOV en las NIC que admiten SR-IOV.

• Inhabilite SR-IOV en las NIC que admiten SR-IOV.

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

• Asigne VF de SR-IOV a una VM.

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

• Realice pruebas para confirmar si SR-IOV se admite 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 redirección (ARI)

• Servicios de traducción de direcciones (ATS)

• Servicios de control de acceso (ACS)

Consulte la documentación que acompaña al 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, use el asistente Nueva red en 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, en el nivel de VM, use el asistente Agregar interfaz virtual en la ficha Redes para agregar una red habilitada para SR-IOV como interfaz virtual para esa VM. Para obtener más información, consulte Agregar una red nueva.

NIC e invitados compatibles

Para obtener una lista de las plataformas de hardware y NIC compatibles, consulte Lista de compatibilidad de hardware. Consulte la documentación proporcionada por el proveedor para un huésped en particular 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 inhabilitar SR-IOV en estos dispositivos.

• Solo los huéspedes HVM son compatibles con SR-IOV.

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

• Es posible que una VF SR-IOV y una 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 utilice el patrón de VF a VF o de VIF a VIF, y no de VF a VIF.

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

• La migración en vivo, la suspensión y el punto de control no se admiten en las máquinas virtuales que utilizan una VF SR-IOV.

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

• 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 usar esta función de XenCenter.

• Si su VM tiene una VF SR-IOV, las funciones que requieren migración en vivo no son posibles. Esto se debe a que la VM está directamente vinculada a la VF NIC habilitada para SR-IOV física.

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

• La SR-IOV se puede usar en un entorno que hace uso de la alta disponibilidad. Sin embargo, la SR-IOV no se considera en la planificación de la capacidad. Las máquinas virtuales que tienen asignadas VF de SR-IOV se reinician según el mejor 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 VF SR-IOV para controladores heredados

Por lo general, la cantidad máxima de VF que admite una NIC se puede determinar 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 del controlador. Es posible que el límite deba ajustarse manualmente. Para ajustarlo al máximo, abra el archivo con un editor y cambie la línea que comienza:

## VFs-maxvfs-by-user:
<!--NeedCopy-->

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
<!--NeedCopy-->

Notas:

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

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

• Realice los cambios antes de habilitar SR-IOV.

CLI

Consulte Comandos de SR-IOV para obtener instrucciones de la CLI sobre cómo crear, eliminar y mostrar redes SR-IOV y asignar una VF de SR-IOV a una VM.

Controlar la velocidad de los datos salientes (QoS)

Para limitar la cantidad de datos salientes que una VM 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 de transmisión máxima para los paquetes salientes en kilobytes por segundo.

El valor de Calidad de servicio limita la velocidad de transmisión desde la VM. La configuración de Calidad de servicio no limita la cantidad de datos que la VM puede recibir. Si se quiere un límite de este tipo, recomendamos limitar la velocidad de los paquetes entrantes más arriba en la red (por ejemplo, en el nivel del conmutador).

Según la pila de red configurada en el grupo, puede establecer el valor de Calidad de servicio en las interfaces virtuales (VIF) de VM en uno de dos lugares. Puede establecer este valor mediante la CLI xe o en XenCenter.

• 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 la calidad de servicio mediante la CLI mediante los comandos de la sección siguiente.

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 el comando vif-param-set:

xe vif-param-set uuid=vif_uuid qos_algorithm_type=ratelimit
xe vif-param-set uuid=vif_uuid qos_algorithm_params:kbps=100
<!--NeedCopy-->

Nota:

El parámetro kbps indica kilobytes por segundo (Kbps), no kilobits por segundo (kbps).

Cambiar las opciones de configuración de redes

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

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

• Agregar o eliminar servidores DNS

• Cambiar las direcciones IP

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

• Agregar una nueva NIC física al servidor

• Adición de un propósito a una red

• Activación del filtrado ARP (bloqueo del puerto del conmutador)

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 todo el grupo y se cambia mediante el comando xe host-set-hostname-live de la CLI de la siguiente manera:

xe host-set-hostname-live host-uuid=host_uuid host-name=host-name
<!--NeedCopy-->

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 de Citrix Hypervisor, ejecute el comando pif-reconfigure-ip. Por ejemplo, para un PIF con una IP estática:

xe pif-reconfigure-ip uuid=pif_uuid mode=static DNS=new_dns_ip IP=IP netmask=netmask
<!--NeedCopy-->

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, use el comando pif-reconfigure-ip de la CLI. Consulte pif-reconfigure-ip para obtener más información sobre los parámetros del comando pif-reconfigure-ip. Consulte la siguiente sección para obtener información sobre cómo cambiar las direcciones IP del host en los grupos de recursos.

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

Los servidores de Citrix Hypervisor de los grupos de recursos tienen una única dirección IP de administración que se utiliza para la administración y la comunicación hacia 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 maestros y otros hosts.

Nota:

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

Utilice el comandopif-reconfigure-ip CLI para establecer la dirección IP como quiera. Consulte pif-reconfigure-ip para obtener más información sobre los parámetros del comando pif-reconfigure-ip. :

xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP
<!--NeedCopy-->

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

xe host-list
<!--NeedCopy-->

Cambiar la dirección IP del servidor de Citrix Hypervisor maestro requiere pasos adicionales. Esto se debe a que cada miembro del grupo utiliza la dirección IP anunciada del maestro del 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 probablemente no cambie durante la vida útil del grupo para los maestros de grupo.

Utilice el comando de la interfaz de línea de comandos pif-reconfigure-ip para configurar la dirección IP como quiera:

xe pif-reconfigure-ip uuid=pif_uuid mode=DHCP
<!--NeedCopy-->

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

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

xe pool-recover-slaves
<!--NeedCopy-->

Interfaz de administración

Al instalar Citrix Hypervisor en un host, una de sus NIC se designa como interfaz de administración: la NIC utilizada para el tráfico de administración de Citrix Hypervisor. La interfaz de administración se usa para XenCenter y otras conexiones de API de administración al host (por ejemplo, Citrix Virtual Apps and Desktops) y para la comunicación de host a host.

Utilice el comando pif-list 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
<!--NeedCopy-->

Utilice el comando pif-param-list para verificar la configuración de direccionamiento 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
<!--NeedCopy-->

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

xe host-management-reconfigure pif-uuid=pif_uuid
<!--NeedCopy-->

Utilice el comando network-list 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 todo el grupo.

xe network-list
<!--NeedCopy-->

Utilice el comando network-param-list para obtener los UUID PIF de todos los hosts del grupo. Utilice el comando pif-param-list para verificar la configuración de direccionamiento IP para el PIF de 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
<!--NeedCopy-->

Use el comando pool-management-reconfigure de la CLI para cambiar el PIF utilizado para la interfaz de administración que se muestra en la lista Redes.

xe pool-management-reconfigure network-uuid=network_uuid
<!--NeedCopy-->

Restringir el uso del puerto 80

Puede usar HTTPS a través del puerto 443 o HTTP a través del puerto 80 para comunicarse con Citrix Hypervisor. Por motivos de seguridad, puede cerrar el puerto TCP 80 de la interfaz de administración. De forma predeterminada, el puerto 80 sigue abierto. Si lo cierra, cualquier cliente externo que use la API de administración debe usar HTTPS a través del puerto 443 para conectarse a Citrix Hypervisor. Sin embargo, antes de cerrar el puerto 80, compruebe si todos sus clientes de API (en particular Citrix Virtual Apps and Desktops) pueden usar HTTPS a través del puerto 443.

Para cerrar el puerto 80, consulte el comando https-only de la CLI de xe o Cambiar las propiedades del grupo en la documentación de XenCenter.

Desactivar el acceso de

Para inhabilitar por completo el acceso remoto a la consola de administración, utilice el comando de la interfaz de línea de comandos host-management-disable.

Advertencia:

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

Agregar una nueva NIC física

1. Instale una nueva NIC física en el servidor de Citrix Hypervisor de la manera habitual.
2. Reinicie el servidor Citrix Hypervisor.

3. Enumere todas las NIC físicas de ese servidor Citrix Hypervisor mediante el siguiente comando:

   xe pif-list host-uuid=<host_uuid>
   

4. Si no ve la NIC adicional, busque nuevas interfaces físicas mediante el siguiente comando:

   xe pif-scan host-uuid=<host_uuid>
   

   Este comando crea un nuevo objeto PIF para la nueva NIC.

5. Vuelva a enumerar las NIC físicas del servidor Citrix Hypervisor para comprobar que la nueva NIC esté visible:

   xe pif-list host-uuid=<host_uuid>
   

6. El nuevo PIF aparece inicialmente como desconectado (currently-attached ( RO): false). Para que aparezca, usa el siguiente comando:

   xe pif-plug uuid=<uuid_of_pif>
   

Como alternativa, puede usar XenCenter para volver a buscar nuevas NIC. Para obtener más información, consulte Configuración de NIC en la documentación de XenCenter.

Eliminar una NIC física

Antes de quitar la NIC, asegúrese de conocer el UUID del PIF correspondiente. Retire la NIC física del servidor de Citrix Hypervisor de la manera habitual. Después de reiniciar el servidor, ejecute el comando pif-forget uuid=<UUID> xe de la CLI para destruir el objeto PIF.

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
<!--NeedCopy-->

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
<!--NeedCopy-->

Actualmente, los valores disponibles para el propósito de la red son nbd y insecure_nbd. Para obtener más información, consulte la Guía de seguimiento de bloques cambiados de Citrix Hypervisor.

Usar el bloqueo del puerto del conmutador

La función de bloqueo de puertos del conmutador Citrix Hypervisor le permite controlar el tráfico enviado desde máquinas virtuales desconocidas, que no son de confianza o potencialmente hostiles al limitar su capacidad de simular que tienen una dirección MAC o IP que no se les asignó. Puede usar los comandos de bloqueo de puertos para bloquear todo el tráfico en una red de forma predeterminada o definir direcciones IP específicas desde las que una VM individual puede enviar tráfico.

El bloqueo de puertos de conmutador es una función diseñada para los proveedores de servicios de nube pública en entornos preocupados por las amenazas internas. Esta funcionalidad ayuda a los proveedores de servicios en la nube pública que tienen una arquitectura de red en la que cada VM tiene una dirección IP pública conectada a Internet. Como los arrendatarios de la nube no son de confianza, puede usar medidas de seguridad, como la protección contra la suplantación, para garantizar que los arrendatarios no puedan atacar otras máquinas virtuales en la nube.

El uso del bloqueo de puertos de switch le permite simplificar la configuración de la red al permitir que todos sus arrendatarios o invitados usen 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 de fingir que tiene una dirección MAC o IP que en realidad no posee. Específicamente, puede usar estos comandos para evitar que un invitado:

• Reclamar una dirección IP o MAC que no sean las que el administrador de Citrix Hypervisor ha especificado que puede usar

• Interceptar, falsificar o interrumpir el tráfico de otras VM

Requisitos

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

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

• Cuando ejecuta los comandos de bloqueo del puerto del conmutador, las redes pueden estar en línea o fuera de línea.

• En los huéspedes de Windows, el icono de red desconectada solo aparece cuando XenServer VM Tools está instalado en el huésped.

Notas

Sin ninguna configuración de bloqueo del puerto del conmutador, las VIF se establecen en “network_default” y las redes en “unlocked”. “

No se admite la configuración del bloqueo del puerto del conmutador cuando se utilizan controladores de terceros en el entorno.

El bloqueo de puertos de switch no impide que los arrendatarios de la nube:

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

• Recursos de red agotadores.

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

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

Notas de implementación

Puede implementar la funcionalidad de bloqueo de puertos 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 puede ser el uso de la API.

Ejemplos

En esta sección se proporcionan ejemplos de cómo el bloqueo de puertos de switch puede prevenir ciertos tipos de ataques. En estos ejemplos, VM-c es una máquina virtual que un arrendatario hostil (Arrendatario C) arrienda y utiliza para los ataques. La máquina virtual a y la máquina virtual b son máquinas virtuales arrendadas por arrendatarios no atacantes.

Ejemplo 1: Cómo el bloqueo del puerto del conmutador puede evitar la suplantación de identidad 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. Para lograr este objetivo, el atacante envía mensajes ARP falsos (falsificados) a una LAN Ethernet.

Caso:

La máquina virtual A (VM-a) quiere enviar tráfico IP desde la máquina virtual a la máquina virtual B (VM-b) dirigiéndolo a la dirección IP de la máquina virtual B. El propietario de la máquina virtual C quiere usar la suplantación de ARP para simular que su VM, VM-c, es en realidad VM-b.

1. La VM-c envía un flujo especulativo de respuestas ARP a la VM-a. Las respuestas ARP afirman que la dirección MAC en la respuesta (c_MAC) está asociada a la dirección IP, b_IP

   Resultado: Como el administrador habilitó el bloqueo del puerto del conmutador, todos estos paquetes se descartan porque al habilitar el bloqueo del puerto del conmutador se evita la suplantación de identidad.

2. La VM-b envía una respuesta ARP a la VM-a, afirmando que la dirección MAC en la respuesta (b_MAC) está asociada a la dirección IP, b_IP.

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

Ejemplo 2: Prevención de la 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.

Caso:

El arrendatario C intenta realizar un ataque de denegación de servicio utilizando su host, Host-C, en un sistema remoto para disimular su identidad.

Intento 1:

El arrendatario C establece la dirección IP y la dirección MAC del Host-C en las direcciones IP y MAC de la máquina virtual (a_IP y a_MAC). El arrendatario 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 al habilitar el bloqueo del puerto del conmutador se evita la suplantación de identidad.

Intento 2:

El arrendatario C establece la dirección IP del Host-C en la dirección IP de la máquina virtual a (a_IP) y conserva su C_mac original.

El arrendatario 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 evita la suplantación de identidad.

Ejemplo 3: Alojamiento web:

Caso:

Alice es administradora de infraestructuras.

Uno de sus arrendatarios, el arrendatario 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 la VIF de Host-B para que se bloquee en una sola MAC pero en muchas direcciones IP.

Cómo funciona el bloqueo de puertos de conmutación

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

• Nivel VIF. Los ajustes que configure en el VIF determinan cómo se filtran los paquetes. Puede configurar el VIF para evitar que la máquina virtual envíe tráfico, restringir el VIF para que solo pueda enviar tráfico mediante 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 se establece el modo de bloqueo de un VIF en network_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 de Linux no admite completamente el bloqueo de puertos de conmutador en IPv6.

Estados del modo de bloqueo de VIF

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

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

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

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

  Para obtener información sobre el parámetro default-locking-mode, consulte Comandos de red.

  El modo de bloqueo predeterminado de la red no afecta a las VIF conectadas cuyo estado de bloqueo es distinto de network_default.

  Nota:

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

• Bloqueado. Citrix Hypervisor aplica reglas de filtrado para que solo 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 especifican direcciones IP, la VM no puede enviar tráfico a través de esa 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 los parámetros ipv4_allowed o ipv6_allowed. Sin embargo, si tiene configurado el puente de Linux, no escriba direcciones IPv6.

  Citrix Hypervisor le permite escribir direcciones IPv6 cuando el puente de Linux está activo. Sin embargo, Citrix Hypervisor no puede filtrar en función de las direcciones IPv6 escritas. La razón es que el puente de Linux no tiene módulos para filtrar paquetes de Neighbor Discovery Protocol (NDP). Por lo tanto, no se puede implementar una protección completa y los invitados podrían hacerse pasar por otro huésped 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 de la VIF. Si no especifica ninguna dirección IPv6, Citrix Hypervisor no permite que el tráfico IPv6 pase a través de la VIF.

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

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

Configurar el bloqueo del puerto del conmutador

En esta sección se describen tres procedimientos diferentes:

• Restringir las VIF para que usen 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 una VIF cuando la máquina virtual se está ejecutando y está conectada a la red (por ejemplo, si está desconectando una red temporalmente).

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

Si el modo de bloqueo de un VIF está establecido en locked, solo puede usar las direcciones especificadas en los parámetros ipv4-allowed o ipv6-allowed.

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

Puede realizar estos procedimientos antes o después de que se conecte la VIF (o se inicie la VM).

Cambie el modo de bloqueo predeterminado a bloqueado, si aún no lo está utilizando, ejecutando el siguiente comando:

xe vif-param-set uuid=vif-uuid locking-mode=locked
<!--NeedCopy-->

vif-uuid representa el UUID del VIF que quiere permitir el envío de tráfico. Para obtener el UUID, ejecute el comando vif-list xe en el host. vm-uuid Indica la máquina virtual para la que aparece la información. La ID del dispositivo indica el número de dispositivo de la VIF.

Ejecute el comando vif-param-set 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
   <!--NeedCopy-->
  

• 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
   <!--NeedCopy-->
  

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 una VIF para que use una dirección IP específica, puede agregar una o más direcciones IP que la VIF puede usar.

Ejecute el comando vif-param-add 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
   <!--NeedCopy-->
  

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

   xe vif-param-add uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
   <!--NeedCopy-->
  

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

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

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

   xe vif-param-remove uuid=vif-uuid ipv4-allowed=comma separated list of ipv4-addresses
   <!--NeedCopy-->
  

• Especifique la dirección IP IPv6 que quiere eliminar. Por ejemplo:

   xe vif-param-remove uuid=vif-uuid ipv6-allowed=comma separated list of ipv6-addresses
   <!--NeedCopy-->
  

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

El siguiente procedimiento evita que una máquina virtual se comunique a través de una VIF específica. A medida que una 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 la desactivación de una red completa.

Si utiliza el comando de la CLI, no necesita desconectar la VIF para establecer el modo de bloqueo de la VIF. El comando cambia las reglas de filtrado mientras se ejecuta el VIF. En este caso, la conexión de red aún parece estar presente, sin embargo, el VIF descarta todos los paquetes que la máquina virtual intenta enviar.

Sugerencia:

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

Para evitar que un VIF reciba tráfico, inhabilite el VIF conectado a la red desde la que quiere impedir que la máquina virtual reciba tráfico:

xe vif-param-set uuid=vif-uuid locking-mode=disabled
<!--NeedCopy-->

También puede inhabilitar la VIF en XenCenter seleccionando la interfaz de red virtual en la ficha Redes de la máquina virtual y haciendo clic en Desactivar.

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

Para volver al estado del modo de bloqueo predeterminado (original), utilice el procedimiento siguiente. De forma predeterminada, cuando se crea una VIF, Citrix Hypervisor la configura para que no se limite a usar 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
<!--NeedCopy-->

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

En lugar de ejecutar los comandos del modo de bloqueo de VIF para cada VIF, puede asegurarse de que todos los VIF estén inhabilitados de forma predeterminada. Para hacerlo, debe cambiar el filtrado de paquetes a nivel de red. Cambiar el filtrado de paquetes hace que la red de Citrix Hypervisor determine cómo se filtran los paquetes, como se describe en la sección anterior Cómo funciona el bloqueo de puertos de conmutación.

Específicamente, el parámetro default-locking-mode de una red determina cómo se comportan los nuevos VIF con configuración predeterminada. Siempre que el locking-mode de un VIF se establece en default, el VIF hace referencia al modo de bloqueo de red (default-locking-mode) para determinar si se filtran los paquetes que viajan a través del VIF y cómo hacerlo:

• Desbloqueado. Cuando el parámetro default-locking-mode de red está establecido en unlocked, 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.

• Inhabilitado. Cuando el parámetro default-locking-mode se establece en disabled, 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 que utilizan la línea de comandos están configuradas en unlocked.

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

Esta ilustración muestra cómo, cuando el locking-mode de una VIF se establece en su configuración predeterminada (network_default), la VIF utiliza la red default-locking-mode para determinar su comportamiento.

Por ejemplo, de forma predeterminada, los VIF se crean con su locking-mode establecido en network_default. Si establece el default-locking-mode= de una reddisabled, se inhabilitarán todas las VIF nuevas para las que no haya configurado el modo de bloqueo. Las VIF permanecen inhabilitadas hasta que (a) cambie el parámetro locking-mode de la VIF individual o (b) establezca explícitamente el locking-mode de las VIF en `unlocked. Esto es útil cuando confías lo suficiente en una VM específica como para no querer filtrar su tráfico en absoluto.

Para cambiar la configuración del modo de bloqueo predeterminado 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]
<!--NeedCopy-->

Nota:

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

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

Ejecute uno de los siguientes comandos:

xe network-param-get uuid=network-uuid param-name=default-locking-mode
<!--NeedCopy-->

O BIEN:

xe network-list uuid=network-uuid params=default-locking-mode
<!--NeedCopy-->

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 la configuración de default-locking-mode 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 a network_default, si aún no está utilizando ese modo, ejecutando el siguiente comando:

   xe vif-param-set uuid=vif_uuid locking-mode=network_default
   <!--NeedCopy-->
   

2. Cambie el modo de bloqueo predeterminado a unlocked, si aún no lo está utilizando, ejecutando el siguiente comando:

   xe network-param-set uuid=network-uuid default-locking-mode=unlocked
   <!--NeedCopy-->