Notas de la versión de VMware NSX-T 1.1

|

Actualizado: 15 de febrero de 2017

VMware NSX-T | 2 de febrero de 2017 | Compilación 4789008

Compruebe regularmente las adiciones y actualizaciones relativas a estas notas de la versión.

Contenido de las notas de la versión

Las notas de la versión contienen los siguientes temas:

Novedades

NSX-T 1.1 presenta una nueva arquitectura de plataforma que satisface las necesidades de los clientes en lo referente a una infraestructura de seguridad y red flexible, escalable y ágil.
Las nuevas funciones y mejoras indicadas a continuación ya están disponibles como parte de la versión NSX-T 1.1.

Nuevas funciones de NSX-T

Servidor DHCP
La función Servidor DHCP (DHCP Server) admite direcciones IP dinámicas y el enlace de direcciones IP estáticas a direcciones MAC.

Servidor proxy de metadatos (Metadata Proxy Server)
La función Servidor proxy de metadatos (Metadata proxy server) permite a las VM recuperar rápidamente metadatos específicos de instancias desde un servidor Openstack Nova.

Geneve
El protocolo de Encapsulación de virtualización de red genérica (Geneve) se utiliza para establecer túneles a lo largo de los nodos de transporte con el fin de transportar el tráfico de superposición. Geneve reemplaza el protocolo STT utilizado en la versión anterior.

Aprendizaje MAC (MAC Learning)
La capacidad Aprendizaje MAC (MAC Learning) en un conmutador lógico proporciona conectividad de red a implementaciones en las que varias direcciones MAC se configuran tras un puerto de conmutador lógico, como, por ejemplo, en una implementación de hipervisores anidados.

IPFIX
Compatibilidad con la configuración de IPFIX granular. Habilite IPFIX a la granularidad de conmutador lógico o puerto lógico.

Reflejo de puertos
Permite capturar tráfico en un nodo de transporte para la solución de problemas. El usuario puede implementar un analizador de protocolos (sniffer) en una máquina virtual que se ejecuta en un nodo de transporte y, a continuación, configurar el reflejo de puertos para enviar tráfico de vínculo superior o de máquina virtual para la solución de problemas.

Copia de seguridad y restauración
Permite realizar copias de seguridad automatizadas. Le permite definir un plan de copias de seguridad periódicas para enviar los archivos de copia de seguridad a un servidor remoto.

Paquete de apoyo técnico
Lugar central para recopilar paquetes de registros desde NSX Manager, NSX Controller y nodos de transporte para la solución de problemas.

Espec./esquema de la API
La especificación Open API/Swagger permite a terceros generar enlaces de lenguajes y otras herramientas, como componentes de PowerShell y recolección de Postman. Los usuarios pueden desarrollar procesos automatizados en torno a la función NSX-T con los lenguajes de programación que deseen.

Mejoras de NSX-T

Agrupamiento, etiquetado y búsqueda
Las mejoras realizadas en lo relativo a las funciones de agrupamiento, etiquetado y búsqueda hacen que sea fácil organizar y buscar objetos en el entorno NSX-T.

Enrutamiento
Las mejoras incluyen la compatibilidad de BFD en vínculos superiores de nivel 0 para detectar rápidamente fallos en los nodos o en las rutas de acceso. Compatibilidad con Mapa de ruta para establecer atributos de ruta de acceso de BGP, como weight, AS Path Prepend y MED.

Conectividad de puerto
Mejora realizada en la interfaz de usuario de conectividad de puerto que representa la conectividad de los nodos de transporte con el conmutador para parte superior del rack físico. Esta información de conectividad se recopila a través del protocolo de detección de nivel de vínculo (LLDP, del inglés "Link Level Discovery Protocol").

Traceflow
Mejoras realizadas en la interfaz de usuario de flujo de seguimiento, donde puede seleccionar VM como origen o destino en la lista desplegable, en lugar de identificadores de puertos lógicos.

Mejoras en los registros y paquete de contenido de Log Insight
Su marco de trabajo de registros coherentes con códigos de error ayuda a identificar rápidamente los problemas que haya en la plataforma. El paquete de contenido de Log Insight utiliza estos códigos de error y proporciona un panel de supervisión y solución de problemas para el entorno NSX-T.

Compatibilidad y requisitos del sistema

Para ver información sobre los requisitos del sistema y la compatibilidad, consulte la Guía de instalación de NSX-T.

Problemas conocidos

Los problemas conocidos se dividen en las siguientes categorías:

Problemas generales

  • El clúster de administración únicamente admite un clúster de un solo nodo.

  • A veces, la recopilación de paquetes de apoyo desde la interfaz de usuario podría fallar en nodos de NSX Edge.
    Recopilar paquetes de apoyo desde la interfaz de usuario de NSX Manager podría fallar y generar un mensaje de error que indique que no se puede acceder a los nodos NSX Edge.

    Solución alternativa: Inicie sesión en NSX Manager y reinicie la aplicación del paquete de apoyo.

  • El estado de un nodo de NSX Controller podría pasar a estar inactivo debido a un problema conocido de Zookeeper.
    Tras activar y desactivar varias veces un nodo de NSX Controller, este podría pasar a estar inactivo. Consulte https://issues.apache.org/jira/browse/ZOOKEEPER-1549

    Solución alternativa: Complete los pasos indicados a continuación.

    1. Elimine del clúster el nodo que presente este problema.
      detach control-cluster <IP_controlador>
    2. Desactive la configuración de agrupación en clústeres en el nodo.
      deactivate control-cluster
    3. Una el nodo al clúster de control.
      join control-cluster thumbprint <huella_digital>
    4. Active el clúster de control en el nodo.
      activate control-cluster

  • vMotion de una máquina virtual conectada a un conmutador lógico falla debido a un error de red no accesible
    vMotion de una VM puede fallar en los siguientes escenarios:

    1. El estado de NSX-T vSwitch es inactivo (down).
    2. El estado de NSX-T vSwitch cambió de inactivo (down) a activo (up), pero no se reflejó el cambio.

    Solución alternativa: En el primer caso, se prevé el fallo.
    En el segundo caso, invoque la API Refresh NetworkSystem mediante la interfaz de usuario de Virtual Center NGC en el host ESXi en el que se implemente la VM.

  • Problemas en el proyecto swagger-codegen de código abierto que afecta a NSX-T OpenAPI.
    Debido a errores abiertos en el proyecto swagger-codegen de código abierto https://github.com/swagger-api/swagger-codegen, la especificación de NSX-T OpenAPI alinea todas las definiciones de tipo a excepción de las definiciones de tipo de nodo hoja en la jerarquía de la herencia. La NSX-T OpenAPI no incluye el supertipo mediante una directiva de esquema allOf JSON, sino que copia todas las propiedades de superclase en la subclase para cualquier clase que sea supertipo de otra clase. Cuando se solucione este problema en swagger-codegen, se publicará una especificación NSX-T OpenAPI actualizada en el sitio web de descargas de VMware.

  • Deshabilitar la configuración de BFD desde el enrutador externo crea un agujero negro en el tráfico.
    Si se elimina o deshabilita la configuración de BFD desde el enrutador externo, el enrutador físico envía un mensaje ADMIN_DOWN. NSX Edge no elimina la ruta estática, al contrario que el enrutador externo, que sí lo hace, lo cual crea un agujero negro en el tráfico en NSX Edge.
    Este problema solo se produce en caso del mensaje ADMIN_DOWN.

    Solución alternativa: Elimine manualmente la ruta estática de NSX Edge antes de eliminar la configuración de BFD desde el enrutador externo.

Problemas de instalación

  • Tras instalar correctamente un nodo de tejido desde la interfaz de usuario de NSX Manager, el estado podría mostrar "Error en la instalación" (Installation Failed) durante un período de tiempo considerable antes de cambiar a "Instalación correcta" (Installation Successful).

    Solución alternativa: No se requiere ninguna. Espere a que cambie el estado a "Instalación correcta" (Installation Successful).

  • Cuando se habilita la regla htmlClient en el host ESXi, no se puede realizar el registro/anulación de registro en NSX Manager.
    Los comandos register-node y deregister-node en ESXi utilizan el puerto TCP 443 en el clúster de NSX Manager. Por tanto, se agrega una regla al firewall de ESXi con allowedip=all para habilitar el tráfico saliente al puerto TCP 443. Sin embargo, hay otra regla en el firewall ESXi denominada htmlClient. De forma predeterminada, esta regla tiene allowedip=all y no está habilitada. No obstante, si el usuario tiene que habilitar esta regla y especificar una lista de direcciones IP permitidas, el firewall de ESXi asocia todo el tráfico destinado al puerto TCP 443 a esta regla. De este modo puede descartar el tráfico destinado al clúster de NSX Manager, lo que da lugar al fallo en el registro/anulación de registro del nodo de NSX Manager.

    Solución alternativa: Deshabilite la regla de firewall htmlClient y cualquier regla que aplique filtros al puerto TCP 443.

  • Los dispositivos NSX Manager y NSX Controller deben utilizar direcciones IP estáticas.
    Los dispositivos NSX Manager y NSX Controller deben utilizar direcciones IP estáticas. No se permite cambiar la dirección IP de un NSX Manager o NSX Controller.

    Solución alternativa: Si instala un dispositivo NSX Manager o NSX Controller sin una configuración de IP estática y obtiene una dirección IP desde DHCP, debe instalar un nuevo dispositivo. No cambie la dirección IP del dispositivo.

  • El mensaje de error del comando detach management-plane indica Recuperar la copia más reciente del objeto (Fetch the latest copy of the object).
    El comando detach management-plane podría fallar y devolver el siguiente mensaje de error:
    No se pudo anular el registro del nodo %: 'Otra persona modificó el objeto desconocido. Recupere la copia más reciente del objeto y vuelva a intentarlo' (% Node deregistration failed: 'The object unknown was modified by somebody else. Fetch the latest copy of the object and retry operation'.)

    Solución alternativa: No es necesario que recupere la copia más reciente del objeto. Ejecute de nuevo el comando detach management-plane para desasociar el nodo del plano de administración.

  • A los nodos de NSX Edge les falta deployment_type
    A los nodos de NSX Edge les falta deployment_type en la respuesta de esta solicitud API: https://<NSX_Manager>/api/v1/fabric/nodes/<id_de_nodo>. No se puede realizar la configuración de NSX Edge porque no se cumplen los requisitos del sistema.

    Solución alternativa: Instale NSX Edge en hardware con una CPU basada en Westmere o Sandy Bridge. Si desea obtener información detallada, consulte los requisitos del sistema.

  • vSphere Client no permite configurar propiedades de configuración adicionales de OVF, como la dirección IP, cuando está conectado directamente a ESXi
    Si está utilizando ESXi sin vCenter e implementa un dispositivo NSX-T con vSphere Client, no puede editar las propiedades de configuración adicionales de OVF.

    Solución alternativa: Si tiene que instalar dispositivos NSX Edge, NSX Manager y NSX Controller en ESXi sin vCenter, utilice el comando ovftool. Solo en el caso de NSX Edge se puede instalar con vSphere Client y, a continuación, iniciar sesión en la CLI y configurar manualmente las interfaces de red.

  • Los hipervisores KVM requieren la configuración manual de la puerta de enlace si residen en segmentos diferentes de Capa 2.
    Si configura un grupo de direcciones IP en NSX Manager y utiliza dicho grupo de direcciones IP para crear nodos de transporte, los cuadros de KVM de Ubuntu no muestran una ruta para la puerta de enlace que se configuró en la configuración del grupo de direcciones IP. Como resultado, falla el tráfico de superposición entre las VM que residen en hipervisores que están en segmentos distintos de Capa 2, dado que el host de tejido subyacente no sabe cómo llegar a los nodos de tejido en segmentos remotos.

    Solución alternativa: Añada una ruta para la puerta de enlace a fin de que pueda dirigir el tráfico a otros hipervisores que residan en otros segmentos. Si esta configuración no se realizase manualmente, el tráfico de superposición fallaría, puesto que el nodo de tejido no sabe cómo llegar a los nodos de tejido remotos.

  • La configuración de host para Ubuntu no admite el abastecimiento de archivos de configuración de la interfaz.
    Si la interfaz pnic no está en el archivo /etc/network/interfaces, MTU no está configurado correctamente en el archivo de configuración de red. Por este motivo, se pierde la configuración de MTU en el puente de transporte tras cada reinicio.

    Solución alternativa: Mueva la configuración de la interfaz PNIC a /etc/network/interfaces.

Problemas conocidos de NSX Manager

  • NSX Manager puede generar una advertencia de vulnerabilidad de ataque de tipo "poisoning" en la memoria caché durante un análisis de seguridad.
    NSX Manager podría generar una advertencia de vulnerabilidad de ataque de tipo "poisoning" en la memoria caché durante un análisis de seguridad debido a que NSX Manager utiliza el encabezado de solicitud HTTP de host para construir la respuesta de redireccionamiento.
    Por ejemplo:
    GET /nsxapi/ping.json?_dc=1474040351698 HTTP/1.1
    Host: 10.32.41.238
    User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Cookie: JSESSIONID=DE5258CE9FAD8C160B2BC94E2A63EC0C
    Connection: keep-alive

    El riesgo de ataques de tipo "poisoning" en la memoria caché se reduce impidiendo que las respuestas HTTP sean persistentes en las memorias caché intermedias.

  • La base de datos de NSX Manager se puede dañar como consecuencia de un evento de apagado
    A veces, NSX Manager no se puede iniciar tras un evento de apagado. El estado de NSX Manager no aparece como ESTABLE (STABLE) ni siquiera después de 5 minutos.
    El siguiente mensaje de registro aparece en el archivo nsxapi.log: [nsx comp="nsx-manager" errorCode="MP4113" subcomp="manager"] GemFire is in illegal state, restating Proton process com.vmware.nsx.management.container.dao.gemfire.GemFireInitializationException: java.lang.NullPointerException

    Solución alternativa: Restaure la copia de seguridad más reciente de NSX Manager.

  • La GUI de NSX Manager no funciona en Internet Explorer 11 en el modo de compatibilidad.

    Solución alternativa: Vaya a Herramientas (Tools) > Configuración de Vista de compatibilidad (Compatibility View Settings) y compruebe que Internet Explorer no muestra la GUI de NSX Manager en el modo de compatibilidad.

Problemas conocidos de NSX Edge

  • Configurar el grupo de direcciones IP de VTEP de NSX Edge y el perfil de vínculo superior justo después de reiniciar NSX Edge hace que no se pueda acceder a la sesión de BFD de VTEP.
    Tras reiniciar NSX Edge, el agente necesita algo de tiempo para restablecer las conexiones de NSX Edge.

    Solución alternativa: Espere unos cinco minutos después de reiniciar NSX Edge para que el agente tenga tiempo de restablecer las conexiones de NSX Edge.

  • Ruta estática creada con Nexthop como IP VIP no insertada en el nodo de NSX Edge.
    Ruta estática creada con Nexthop com IP VIP no insertada en el nodo de NSX Edge cuando la subred de VIP es distinta a la subred de la interfaz de vínculo superior.

    Solución alternativa: En el caso de una ruta estática con VIP, utilice siempre la dirección IP de VIP a partir de una de las IP de subred de vínculo superior existentes.

  • Las interfaces del kernel que crea NSX Edge para transferir paquetes de la ruta de acceso a los datos al kernel de Linux solo admiten MTU de hasta 1600.
    Las interfaces del kernel entre la ruta de acceso a los datos y el kernel no admiten la trama gigante. El demonio de BGP trunca y descarta los paquetes de BGP de tamaño superior a 1600. Los paquetes SPAN de tamaño superior a 1600 se truncan y la utilidad de captura de paquetes muestra una advertencia. La carga no se trunca y sigue siendo válida.

    Solución alternativa: Ninguna.

  • Si se reemplaza un perfil de servidor DHCP por un nodo de NSX Edge desde otro clúster, cambian las direcciones IP proporcionadas a las VM por el servidor DHCP.
    Este problema se debe a una falta de coordinación entre el nodo que se reemplaza y el nuevo nodo.

    Solución alternativa: Ninguna.

  • Establecer un retraso de reenvío en un nodo de NSX Edge individual hace que se muestre un estado de enrutamiento incorrecto.
    Al ejecutar una instancia de NSX Edge como un nodo de NSX Edge individual (no en un par de alta disponibilidad —HA—), configurar un retraso de reenvío podría dar lugar a un informe incorrecto sobre el estado del enrutamiento. Una vez que se haya configurado el retraso de reenvío, el estado de enrutamiento se muestra correctamente como INACTIVO (DOWN) hasta que caduque el temporizador de reenvío. Si la convergencia del enrutador se completó, pero no caducó aún el temporizador del retraso de reenvío, la ruta de acceso a los datos de sur a norte sigue fluyendo según lo previsto aunque el estado de enrutamiento se muestre como INACTIVO (DOWN). Puede ignorar este mensaje de forma segura.

  • No se puede clonar la VM de NSX Edge que ya está registrada con el clúster de NSX Manager.
    No se permite clonar una VM de NSX Edge una vez que esté registrada en el clúster de NSX Manager. En su lugar, se debe implementar una imagen nueva.

    Solución alternativa: Ninguna.

  • Las reglas de redistribución no son compatibles con configuraciones LE o GE en la lista de prefijos.
    Las reglas de redistribución no son compatibles con configuraciones LE o GE en la lista de prefijos. NSX Manager no valida esta configuración y NSX Edge no lo admite. Como resultado, el usuario puede ver que no está teniendo efecto la configuración.

    Solución alternativa: No utilice configuraciones LE ni GE en la lista de prefijos de IP.

  • Eliminar o cambiar los índices de miembros del clúster de NSX Edge remitidos por el puerto de vínculo de enrutador lógico de nivel 1 deteriora el tráfico de norte a sur.

  • No se pueden editar los detalles del clúster de NSX Edge en un enrutador de nivel 1 asociado a un enrutador de nivel 0.
    Si habilitó NAT en un enrutador lógico de nivel 1, debe especificar un nodo de NSX Edge o clúster de NSX Edge antes de conectar el enrutador de nivel 1 a un enrutador de nivel 0. NSX no permite editar los detalles del clúster de NSX Edge en un enrutador de nivel 1 que ya está asociado a un enrutador de nivel 0.

    Solución alternativa: Para editar los detalles del clúster de NSX Edge en un enrutador de nivel 1 que ya está asociado a un enrutador de nivel 0, desconecte el enrutador de nivel 1 del enrutador de nivel 0, haga los cambios y vuelva a establecer la conexión.

Problemas conocidos de las redes lógicas

  • El plano del clúster de NSX Controller podría mostrar la dirección IP interna 172.17.0.1 en vSphere Client, en lugar de la dirección IP real.
    En vSphere Client, la dirección IP de las instancias de NSX Controller se muestra incorrectamente como 172.17.0.1 en lugar de la dirección IP real. Para NSX Manager, la dirección IP se muestra correctamente.

    Solución alternativa: No se necesita. Este problema intrascendente no afecta a ninguna funcionalidad.

  • No se permite cambiar la dirección IP del nodo de NSX Controller.

    Solución alternativa: Reimplementar el clúster de NSX Controller.

  • Habilitar el protocolo de árbol de expansión (STP, del inglés "Spanning Tree Protocol") en una VLAN puenteada hace que el estado del clúster de puentes se muestre como inactivo (down).
    Si STP está habilitado en redes VLAN que se utilizan para puentear con formación de equipos de LACP, el puerto-canal del conmutador físico se bloquea, lo que hace que el estado del clúster de puentes del host ESX se muestre como inactivo (down).

    Solución alternativa: Deshabilite STP o habilite el filtro BDPU y la protección BDPU.

  • El enrutador lógico de nivel 0 no agrega las rutas, sino que las redistribuye de forma individual.
    El enrutador lógico de nivel 0 no realiza la agregación de rutas para un prefijo que no cubre todos los subprefijos conectados a él. En su lugar, el enrutador lógico redistribuye las rutas por separado.

    Solución alternativa: Ninguna.

  • No se puede eliminar un antiguo grupo de direcciones IP después de haber actualizado el nodo de transporte con un nuevo grupo de direcciones IP.

    Solución alternativa: Elimine toda la configuración del enrutador lógico y aplique el nuevo grupo de direcciones IP a todos los nodos de transporte.

  • No se permite copiar VM desde un host ESX a otro host ESX que esté asociado al mismo conmutador lógico.
    La red de Capa 2 falla cuando se copia una VM desde un host ESX y se registra la misma VM en otro host ESX.

    Solución alternativa: Utilice la clonación de VM si el host ESX forma parte de Virtual Center.
    Si copia una VM entre hosts ESX, el identificador externo debe ser único en el archivo .vmx de la VM para que funcione la red de capa 2.

  • Si se elimina cualquier vínculo superior de la interfaz de LAG, se inhabilita todo el protocolo de BFD y se oscilan las rutas de BGP.
    Cuando se elimina alguna interfaz de la interfaz de LAG configurada, se inhabilita todo el protocolo de BFD y se oscilan las rutas de BGP, lo cual afecta al tráfico.

    Solución alternativa: Ninguna.

  • BGP deja de anunciar todos los prefijos de IP PERMITIR (PERMIT) cuando se agrega una ruta en la dirección de SALIDA (OUT) con una lista de prefijos de IP en una única secuencia sin las opciones de GE y LE proporcionadas.
    BGP deja de anunciar todos los prefijos de IP PERMITIR (PERMIT). Cuando se establece un prefijo de IP como PERMITIR (PERMIT) y otro prefijo de IP se establece como DENEGAR (DENY), la acción de secuencia única de la lista de prefijos de IP en el mapa de ruta se establece como PERMITIR (PERMIT) y ese mapa de ruta en el filtro de vecinos de BGP se encuentra en la dirección de SALIDA (OUT).

    Solución alternativa: Puede realizar una de las siguientes tareas:

    • En lugar de un mapa de ruta, puede utilizar la lista de prefijos de IP en el filtro de vecinos de BGP.
    • Utilice las opciones de GE y LE al agregar uno de los prefijos de IP a la lista de prefijos de IP en el mapa de ruta.
    • Cree una lista de prefijos de IP independiente para cada prefijo de IP y agréguelos al mapa de ruta en secuencias independientes.

  • Eliminar el mapa de ruta agregado en la dirección de SALIDA (OUT) del filtro de vecinos de BGP produce un error de aserción y oscila las rutas de BGP.

    Solución alternativa: No es necesaria ninguna solución alternativa porque la conexión de BGP se vuelve a establecer en cuestión de segundos.

  • El número máximo de conmutadores lógicos compatibles con el servicio MDProxy es de 1024.
    Configurar más de 1024 conmutadores lógicos con el servicio MDProxy no permite al servicio MDProxy backend iniciar el servidor web nginx.

    Solución alternativa: Puede agregar más de 1024 conmutadores lógicos en todas las instancias de NSX Edge que sean compatibles con el servicio MDProxy.

    1. Vaya a /etc/init.d/nsx-edge-mdproxy con privilegios raíz.
    2. Elimine la línea ulimit -n 1024.
    3. Vaya a etc/init/nsx-edge-nsxa.conf con privilegios raíz.
    4. Agregue la línea limit nofile 20000 20000.
    5. Reinicie el servicio MDProxy en la consola de administración.
      restart service local-controller

  • El puerto del enrutador lógico se puede eliminar aunque haya rutas estáticas existentes configuradas en dicho puerto.
    Cuando elimina un puerto de enrutador lógico con rutas estáticas configuradas, las rutas estáticas permanecen en el sistema.

    Solución alternativa: Puede eliminar manualmente las rutas estáticas o, dado que no causan daño alguno, dejarlas en el sistema.

  • Se pueden eliminar hipervisores como nodos de transporte aunque tengan VM en la red NSX-T.
    NSX-T no le impide eliminar un nodo de transporte aunque haya varias VM en el nodo que formen parte de NSX-T. Las VM pierden conectividad una vez que se elimina el nodo de transporte.

    Solución alternativa: Tanto para hosts ESXi como KVM, vuelva a crear el nodo de transporte con el mismo nombre de conmutador de host.

  • En un entorno a gran escala, algunos hosts podrían pasar a tener un estado fallido.
    En un entorno a gran escala con al menos 200 nodos de host tras ejecutarse durante cierto tiempo, algunos hosts podrían perder conectividad con NSX Manager y el registro contiene mensajes de error como este:
    2016-12-09T00:57:58Z mpa: [nsx@6876 comp="nsx-esx" subcomp="mpa" level="WARN"] Unknown routing key: com.vmware.nsx.tz.*

    Solución alternativa: Reinicie el proceso de MPA en los hosts que fallaron.

  • En un entorno de KVM, si está configurada la creación de reflejo de puertos y está habilitado el truncado, los paquetes gigantes del origen se envían en fragmentos, pero se vuelven a ensamblar en el destino del reflejo.

    Solución alternativa: No es necesaria ninguna solución alternativa porque el reensamblado lo realiza el controlador vNIC de la VM de destino.

  • En un entorno de zona de multitransporte, tras eliminar una de las zonas de transporte de un nodo de transporte, las VM de las zonas de transporte eliminadas siguen pudiendo participar en la red de NSX-T.

    Solución alternativa: Antes de eliminar una zona de transporte de un nodo de transporte, desconecte las VM de los conmutadores lógicos que estén en la zona de transporte.

  • Entre pares de BGP, cuando se configura un mapa de ruta para que anteponga ASN, el modo de espera no puede anteponerlo de inmediato.
    Entre pares de BGP de 2 bytes, cuando se configura un mapa de ruta para que anteponga ASN de 4 bytes, el modo de espera necesita 15 segundos para poder anteponer el ASN de 4 bytes correctamente.
    Entre pares de BGP de 4 bytes, cuando se configura un mapa de ruta para que anteponga ASN de 2 bytes, el modo de espera necesita 15 segundos para poder anteponer el ASN de 2 bytes correctamente.

    Solución alternativa: Ninguna.

  • El enlace de direcciones IP debe configurarse con SpoofGuard para puertos en un perfil de conmutador lógico.
    Si está habilitado SpoofGuard para puertos en un perfil de conmutador lógico, también debe configurarse el enlace de direcciones IP en los puertos de la VM que pertenecen al conmutador lógico. Esto es especialmente importante en el caso de los puertos que conectan a las VM de vCenter, porque, si no se ha configurado el enlace, el tráfico en los puertos de la VM podría perderse por un agujero negro debido a una configuración de lista blanca vacía con SpoofGuard.

    Solución alternativa: Ninguna.

  • Cambiar la conexión de una zona de transporte de un enrutador lógico por otro conjunto de conmutadores lógicos produce un error de coincidencia.
    El enrutador lógico solo admite una zona de transporte de superposición individual para puertos de vínculo inferior. Por lo tanto, si no se eliminan los puertos de vínculo inferior o de vínculo de enrutador existentes, no se puede cambiar una conexión de una zona de transporte a otro conjunto de conmutadores lógicos.

    Solución alternativa: Complete los pasos indicados a continuación.

    1. Elimine todos los puertos de vínculo de enrutador o vínculo inferior existentes.
    2. Espere a que pase un poco de tiempo para que el sistema se actualice.
    3. Vuelva a intentar cambiar la conexión de la zona de transporte por otro conjunto de conmutadores lógicos.

  • La CLI de NSX-T get logical-switches enumera los conmutadores lógicos con estado ACTIVO (UP), incluso después de que se haya eliminado el nodo de transporte.
    La CLI de NSX-T podría hacer creer al usuario que hay un conmutador lógico operativo. Aunque se vean conmutadores lógicos, no están operativos. El conmutador opaco se deshabilita al eliminar el nodo de transporte, por lo que no pasa a través suyo tráfico alguno.

    Solución alternativa: Ninguna.

  • Después de crear un conmutador lógico, NSX Controller podría no mostrar la información del conmutador lógico recién creado.

    Solución alternativa: Espere 60 segundos tras crear el conmutador lógico para comprobar la información del conmutador lógico en NSX Controller.

  • Tras crear y eliminar un conmutador lógico, no se puede reducir el rango de grupos de VNI.
    No se puede reducir el rango porque las VNI no se publican inmediatamente tras eliminar un conmutador lógico. Las VNI se publican transcurridas 6 horas. El objetivo es impedir que se vuelvan a utilizar las VNI al crear otro conmutador lógico. Por este motivo, no se pueden reducir ni modificar los rangos hasta que hayan pasado 6 horas tras haber eliminado el conmutador lógico.

    Solución alternativa: Para modificar el rango desde el que se asignaron las VNI a conmutadores lógicos, espere que pasen 6 horas tras haber eliminado los conmutadores lógicos. También puede utilizar otros rangos del grupo de VNI o reutilizar el mismo rango sin reducirlo ni eliminarlo.

  • Las NIC Intel 82599 tienen una limitación de hardware en el contador Queue Bytes Received Counter (QBRC) que da lugar a un desbordamiento después de que el total de bytes recibidos supere 0xFFFFFFFFF.
    Debido a esta limitación de hardware, la salida de la CLI de get dataplane physical-port stats no concuerda con el número real si se produce el desbordamiento.

    Solución alternativa: Ejecute una vez la CLI de tal modo que se restablezca el contador y se vuelva a ejecutar en períodos más cortos.

Problemas conocidos de los servicios de seguridad

  • Una configuración no segura de TLS en NSX Controller permite a los atacantes leer o modificar el tráfico entre NSX Controller y el hipervisor, y viceversa.
    El agente de escucha de TLS en el puerto 1234 está configurado para admitir TLS 1.0, que es vulnerable a ataques externos.

    Solución alternativa: Proteja físicamente la red entre NSX Controller y los hipervisores.

  • Tras aplicar un filtro a una regla de firewall, no se puede deshabilitar la regla.
    En la interfaz de usuario de NSX Manager, si aplica un filtro a una regla, la interfaz de usuario no le permite deshabilitarla.

    Solución alternativa: Elimine el filtro primero y después deshabilite la regla.

  • La sincronización de Grupos NS con NSX Controller puede tardar cierto de tiempo tras ejecutar un reinicio.
    Después de reiniciar un nodo en el plano de administración, la sincronización de los Grupos NS con NSX Controller podría tardar unos 30 minutos o más dependiendo del número de Grupos NS.

    Solución alternativa: Ninguna.

  • La comunicación DHCP entre cliente y servidor no está cifrada.

    Solución alternativa: Use IPSEC para mejorar la seguridad de la comunicación.

  • Los datos de IPFIX se envían a través de la red en texto sin formato.
    La opción de recopilar flujos de IPFIX está deshabilitada de forma predeterminada.

    Solución alternativa: Ninguna.

  • La conexión entre el servidor proxy de metadatos y el servidor Nova no está cifrada o autorizada.

    Solución alternativa: Ninguna.

  • El tráfico de túnel de Geneve (UDP) es rechazado en KVM.

    Solución alternativa: Lleve a cabo los pasos indicados a continuación para permitir el tráfico de túnel de Geneve.
    Si KVM está utilizando firewalld, cree un agujero en el firewall con el siguiente comando:
    # firewall-cmd --zone=public --permanent --add-port=6081/udp
    Si KVM está utilizando directamente IPtables, cree un agujero con el siguiente comando:
    # iptables -A INPUT -p udp --dport 6081 -j ACCEPT
    Si KVM está utilizando UFW, cree un agujero con el siguiente comando:
    # ufw allow 6081/udp

  • En RHEL 7.1 kernel 3.10.0-229 y versiones anteriores, FTP ALG no puede abrir el puerto negociado en el canal de datos.
    Para una sesión FTP, en la que tanto cliente como servidor residen en máquinas virtuales en el mismo hipervisor, la puerta de enlace de nivel de aplicación FTP (ALG) no abre el puerto negociado para el canal de datos. Este problema es específico de Red Hat y está presente en RHEL 7.1 kernel 3.10.0-229. Los kernel de RHEL posteriores no se ven afectados.

    Solución alternativa: Ninguna.

  • Advertencia necesaria de que los puertos lógicos seleccionados en la sección Ethernet solo se aplican dentro de la misma red de Capa 2.
    Para el firewall distribuido de NSX-T, en la sección Ethernet, cuando se introduce cualquier puerto lógico o dirección MAC en la sección de origen/destino, se debería mostrar una advertencia que indique que las direcciones MAC o los puertos lógicos deberían pertenecer a puertos de VM de la misma red de Capa 2 (asociados al mismo conmutador lógico). En la actualidad, no hay ningún mensaje de advertencia.

    Solución alternativa: Ninguna.

Problemas conocidos de las operaciones y los servicios de supervisión

  • Las herramientas Conexión de puerto (Port Connection) y Traceflow tardan mucho tiempo en detectar las VM.
    En un escenario en el que una implementación de NSX-T comience con un número reducido de hosts (10 o menos) y crezca hasta alcanzar un número elevado de hosts y NSX Manager o el servicio proton no se haya reiniciado desde el número reducido inicial de hosts, si NSX Manager pierde la conexión con un número alto de hosts por cualquier motivo sin que se reinicie el servicio proton, deberá transcurrir mucho tiempo para que NSX Manager se sincronice con esos hosts y detecte las VM que se ejecutan en ellos. El archivo de registro de proton tiene mensajes como el siguiente: Procesar las solicitudes sync_init, tamaño de lote <tamaño de lote calculado>.

    Solución alternativa: Reinicie el servicio proton. No necesita reiniciar NSX Manager.

  • Mover una VM de un conmutador no administrado por NSX-T a uno administrado por NSX-T podría deshabilitar el firewall en la VM.
    Mover una VM implementada a través de los flujos de trabajo de NSX-T de un conmutador no administrado por NSX-T a uno administrado por NSX-T podría deshabilitar el firewall en la VM.

    Solución alternativa: Apagar y encender la VM.

  • Tras eliminar una VM de arrendatario en un host ESXi y el nodo de transporte de host correspondiente, no se puede eliminar el host ESXi.
    Eliminar un nodo de host conlleva la reconfiguración de varios objetos y puede tardar como mínimo varios minutos.

    Solución alternativa: Espere varios minutos e intente eliminar de nuevo el nodo de host. Repita la operación si fuese necesario.

  • No se pudo conectar la vNIC de una VM a un conmutador lógico de NSX.T tras registrar la VM.
    Si se utiliza un archivo vmx existente para registrar una VM en un host ESXi, la operación de registro ignora los siguientes errores específicos de la vNIC:

    • vNIC que se configuran con un respaldo de red inválido.
    • Fallos de asociación de VIF para vNIC conectadas a un conmutador lógico de NSX-T.

    Solución alternativa: Complete los pasos indicados a continuación.
    1. Cree un grupo de puertos temporal en un vSwitch estándar.
    2. Asocie las vNIC que estén en estado desconectado con el nuevo grupo de puertos y márquelas como conectadas.
    3. Asocie las vNIC a un conmutador lógico de NSX-T válido.

  • Rara vez, el clúster de NSX Controller se queda inactivo tras ejecutarse varios días.
    Cuando se queda inactivo el clúster de NSX Controller, todos los nodos de transporte y NSX Edge pierden la conexión con las instancias de NSX Controller y no se pueden realizar cambios en la configuración. Sin embargo, el tráfico de datos no se ve afectado.

    Solución alternativa: Complete los pasos indicados a continuación.

    • Si hay problemas de latencia de disco, soluciónelos.
    • Reinicie el servicio cluster-mgmt en todas las instancias de NSX Controller.

  • El recuento de bytes descartados no se incluye en el informe Estado del puerto y Estadísticas (Port Status and Statistics).
    Al utilizar /api/v1/logical-ports/<lport-id>/statistics o NSX Manager para ver las estadísticas y el estado de los puertos lógicos, hay un recuento de paquetes descartados con un valor de 0. Este valor no es preciso. Independientemente del número de paquetes descartados, el número que se muestra aquí siempre está en blanco.

    Solución alternativa: Ninguna.

Problemas conocidos de las redes de KVM

  • En un entorno de KVM, el rendimiento de red es bajo para el tráfico de túnel con kernel de Linux más antiguos.
    NSX-T 1.1 utiliza Geneve en lugar de STT que se utilizó en las versiones previas para la encapsulación. Los kernels anteriores de Linux no fueron optimizados para Geneve.
    Solución alternativa: Ejecute la versión compatible de Ubuntu o la versión de RHEL que tenga la versión más reciente del kernel de Linux.

  • La API de resolución POST /api/v1/error-resolver?action=resolve_error no resuelve los errores después de que no pueda agregarse un host RHEL KVM al tejido.
    Después de que no pueda agregarse un host RHEL KVM al tejido y la interfaz de usuario de NSX Manager muestre el estado de instalación como fallido (failed), la API de resolución POST /api/v1/error-resolver?action=resolve_error se ejecuta para resolver los errores. Sin embargo, agregar el host al tejido de nuevo da lugar a los siguientes mensajes de error:
    Failed to install software on host. Un-handled deployment plug-in perform-action.
    Install command failed.


    Solución alternativa: Complete los pasos indicados a continuación.

    1. Elimine manualmente los siguientes paquetes.
      rpm -e glog-0.3.1-1nn5.x86_64
      rpm -e json_spirit-v4.06-1.el6.x86_64
      rpm -e kmod-openvswitch-2.6.0.4557686-1.el7.x86_64
      rpm -e nicira-ovs-hypervisor-node-2.6.0.4557686-1.x86_64
      rpm -e nsx-agent-1.1.0.0.0.4690847-1.el7.x86_64
      rpm -e nsx-aggservice-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-cli-1.1.0.0.0.4690892-1.el6.x86_64
      rpm -e nsx-da-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-host-1.1.0.0.0.4690932-1.x86_64 rpm -e nsx-host_node_status_reporter-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-lldp-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-logical_exporter-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-mpa-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-netcpa-1.1.0.0.0.4690924-1.el7.x86_64 rpm -e nsx-sfhc-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-support-bundle-client-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsx-transport_node_status-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e nsxa-1.1.0.0.0.4690845-1.el7.x86_64
      rpm -e openvswitch-2.6.0.4557686-1.x86_64
      rpm -e openvswitch-selinux-policy-2.6.0.4557686-1.noarch
      rpm -e python-simplejson-3.3.3-1.el7.x86_64
      Si se produce cualquier error durante la ejecución del comando rpm -e , incluya la marca --noscripts en el comando.
    2. Ejecute la API de resolución POST /api/v1/error-resolver?action=resolve_error.
    3. Vuelva a agregar el host KVM al tejido.

  • KVM no admite la formación de equipos de equilibrio de carga.

  • Las VM de un nodo de transporte no pueden acceder a las VM ubicadas en otro nodo de transporte.
    Cuando se utilizan varios grupos de direcciones IP para VTEP que pertenecen a redes diferentes, la VM del host KVM podría no acceder a la VM implementada en otros hosts que tengan direcciones IP de VTEP de otro grupo de direcciones IP.

    Solución alternativa: Agregue rutas para que el nodo de transporte de KVM pueda acceder a todas las redes utilizadas para VTEP en otros nodos de transporte.
    Por ejemplo, si tiene dos redes 25.10.10.0/24 y 35.10.10.0/24 y el VTEP local tiene las direcciones IP 25.10.10.20 con la puerta de enlace 25.10.10.1, puede utilizar el siguiente comando a fin de agregar la ruta para otra red:
    ip route add dev nsx-vtep0.0 35.10.10.0/24 via 25.10.10.1

  • Las API Ops/BFD pueden notificar información inusual
    La información de Ops que se recopila a partir de la implementación BFD/túnel de todas las plataformas en las plataformas ESXi, NSX Edge o KVM no es consistente.

    • NSX Edge y KVM mantienen viva la sesión de BFD/túnel de forma indefinida.
    • ESXi destruye estas sesiones cuando no son necesarias y las crea a petición.
    Por este motivo, podría darse un estado de BFD poco corriente donde un extremo muestre que el túnel está inactivo y el otro extremo no tenga dicho túnel. Además, BFD no ayuda en la depuración porque, al eliminar una sesión de BFD, la última causa del error es la pérdida.

    Solución alternativa: Ninguna

  • El seguimiento de conexiones de tráfico subyacente reduce la memoria disponible.
    Al establecer un número elevado de conexiones entre máquinas virtuales, puede experimentar los siguientes síntomas.
    En el archivo /var/log/syslog o /var/log/messages, verá entradas parecidas a estas:
    Apr 26 11:45:44 prmh-nsx-perf-server149 kernel: [1625289.950872] net_ratelimit: 239 callbacks suppressed
    Apr 26 11:45:44 prmh-nsx-perf-server149 kernel: [1625289.950875] nf_conntrack: table full, dropping packet
    Apr 26 11:45:44 prmh-nsx-perf-server149 kernel: [1625289.958436] nf_conntrack: table full, dropping packet
    El problema parece manifestarse cuando se configuraron reglas de firewall predeterminadas. El problema no se manifiesta si no se configuraron reglas de firewall (por ejemplo: los conmutadores lógicos se colocan en la lista de exclusión del firewall).
    Nota: Los extractos de registro mostrados anteriormente solo son ejemplos. Las variables de entorno, fecha y hora podrían ser distintas dependiendo de su entorno.

    Solución alternativa: Agregue una regla de firewall para deshabilitar el seguimiento de conexiones de UDP en el puerto 6081 en dispositivos subyacentes.
    A continuación se muestra un comando de ejemplo:
    # iptables -A PREROUTING -t raw -p udp --dport 6081 -j CT --notrack
    Este debería configurarse para que se ejecutara durante el arranque. Si la plataforma también tiene un administrador de firewall habilitado (Ubuntu: UFW; RHEL: firewalld), la regla equivalente debería configurarse a través del administrador de firewall. Consulte el artículo relacionado de la KB 2145463.

Problemas conocidos de interoperabilidad de soluciones

  • Poner hosts ESXi en modo de bloqueo deshabilita el usuario nsx-user.
    Cuando un host ESXi se pone en modo de bloqueo, el usuario vpxuser es el único usuario que puede autenticarse con el host o ejecutar comandos. NSX-T se basa en otro usuario, nsx-user, para realizar todas las tareas relacionadas con NSX-T en el host.

    Solución alternativa: No utilice el modo Bloqueo (Lockdown). Consulte Modo Bloqueo (Lockdown) en la documentación de vSphere.

Problemas conocidos de la API

  • La API GET https://<NSX-Manager>/api/v1/fabric/nodes/<node-id>/modules no funciona con Ubuntu.
    La API GET https://<NSX-Manager>/api/v1/fabric/nodes/<node-id>/modules funciona con ESXi y RHEL, pero no con Ubuntu.

    Solución alternativa: Ninguna

  • La API GET https://<NSX-Manager>/api/v1/fabric/nodes/status devuelve un error.
    La API GET https://<NSX-Manager>/api/v1/fabric/nodes/status , que obtiene el estado de varios nodos, podría devolver un error.
    Solución alternativa: Use GET https://<NSX-Manager>/api/v1/fabric/nodes/<node-id>/status para obtener el estado de nodos individuales.

  • Al realizar una llamada a la API para cambiar las directivas de autenticación, los cambios no tienen efecto.
    Cuando realiza la llamada a la API PUT https://<NSX-Manager>/api/v1/node/aaa/auth-policy para cambiar cualquiera de las siguientes directivas, los cambios no tienen efecto.

    • api_failed_auth_lockout_period
    • api_failed_auth_reset_period
    • api_max_auth_failures
    • minimum_password_length

    Solución alternativa: Reinicie el servicio de proxy.

  • Los registros de la API NSX-T de syslog muestra llamadas a la API internas del sistema. Los registros NSX-T muestran tanto llamadas a la API invocadas por el usuario como llamadas a la API invocadas por el sistema en syslog.
    El registro de un evento de llamada a la API en syslog no demuestra que un haya un usuario llamando directamente a la API NSX-T. En los registros puede ver las llamadas a la API de las instancias de NSX Controller y NSX Edge, aunque estos dispositivos de NSX-T no tengan un servicio de API expuesto públicamente. Otros servicios de NSX-T, como la CLI de NSX-T, utilizan estos servicios de API privados.

    Solución alternativa: Ninguna.

  • La vertical de la prueba se devuelve mediante la API de configuración de frecuencia de sondeo GET /api/v1/hpm/features
    GET /api/v1/hpm/features devuelve la lista de todas las funciones para las que se puede configurar la frecuencia de sondeo. Esta API devuelve algunas funciones internas solo de prueba. No existe ningún impacto funcional en el usuario aparte del ruido adicional.

    Solución alternativa: Ignore la respuesta extraña de la API.

  • La llamada Rest a POST/hpm/features/<feature-stack-name?action=reset_collection_frequency> no restaura el valor de collection_frequency para las estadísticas de sobrescritura.
    Si intenta restablecer la frecuencia de recopilación predeterminada mediante esta llamada REST, no se restablecerá.
    Solución alternativa: Utilice PUT /hpm/features/<feature-stack-name> y establezca el nuevo valor de collection_frequency.

  • Las solicitudes de estadísticas y el estado a petición pueden fallar de forma intermitente. El código de error HTTP no es consistente.
    En determinadas situaciones, las solicitudes a petición fallan. A veces estas solicitudes fallan y generan un error HTTP 500 en lugar de un error HTTP 503, aunque la llamada a la API se realice correctamente al reintentarlo.
    Para las API de estadísticas, la condición de tiempo de espera puede dar lugar a registros de errores de enrutamiento de mensajes falsos. Estos se producen porque la respuesta regresa después de que se haya agotado el tiempo de espera.
    Por ejemplo, podrían producirse errores como los siguientes: java.lang.IllegalArgumentException: Controlador de mensajes desconocido para el tipo com.vmware.nsx.management.agg.messaging.AggService$OnDemandStatsResponseMsg.
    Para las API de estado, una respuesta devuelta una vez transcurrido el tiempo de espera podría hacer que la memoria caché se actualizara antes de tiempo.

    Solución alternativa: Vuelva a realizar la solicitud API.

Erratas de la documentación y adiciones

  • Dos interfaces en la misma subred
    El tráfico de túnel puede fugarse hasta la interfaz de administración si el endpoint de túnel está en la misma subred que la interfaz de administración. Esto sucede porque los paquetes de túnel pueden pasar por la interfaz de administración. Asegúrese de que las interfaces de administración estén en una subred independiente de las interfaces de endpoint de túnel.

  • La solicitud API da lugar a un error 403 Prohibido (403 Forbidden), Token XSRF incorrecto (Bad XSRF token).
    Mientras tenga iniciada la sesión en la interfaz de usuario web de NSX Manager, la cookie de NSX Manager solo se podrá utilizar dentro de la interfaz de usuario web. Si envía solicitudes API mediante una aplicación que utiliza el mismo origen de cookies (por ejemplo, una extensión del explorador), obtendrá una respuesta 403 Prohibido/Token XSRF incorrecto.
    {
    "module_name": "common-service",
    "error_message": "Bad XSRF token",
    "error_code": "98"
    }


    Solución alternativa: Debe cerrar la sesión en la interfaz de usuario web de NSX Manager o utilizar un cliente REST que utilice otro origen de cookies.
    Por ejemplo, utilice un explorador para acceder a la interfaz de usuario web y una extensión en otro explorador para acceder a la API. También puede obtener cookies de sesión que no requieren el encabezado XSRF. Consulte la sección Autenticación basada en sesión de la Guía de la API NSX-T para obtener más información.

  • Desconecte las VM asociadas de los conmutadores lógicos antes de realizar determinados cambios en los nodos de transporte y en las zonas de transporte.
    Antes de realizar los siguientes procedimientos, desconecte las VM asociadas del conmutador lógico.

    • Antes de desconectar un conmutador lógico de un nodo de transporte.
    • Antes de mover un nodo de transporte de una zona de transporte a otra zona de transporte.
    • Antes de eliminar una zona de transporte.

  • Los puertos lógicos seleccionados en la sección Ethernet solo se aplican dentro de una misma red de Capa 2.
    Si crea una regla de firewall con un puerto lógico o una dirección MAC para el origen o el destino y aplica la regla de firewall distribuida en la sección Ethernet, las direcciones MAC o los puertos lógicos deben pertenecer a puertos de VM que estén en la misma red de Capa 2. En otras palabras, deben estar asociadas al mismo conmutador lógico.

  • IPFIX en ESXi y KVM realizan el muestreo de los paquetes de túnel de formas distintas.
    En ESXi, se realiza el muestreo del paquete de túnel según dos registros:
    Registro de paquetes externo con alguna información del paquete interno.

    • SrcAddr, DstAddr, SrcPort, DstPort y Protocol hacen referencia al paquete exterior.
    • Contiene entradas empresariales para describir el paquete interno.
    Registro de paquete interno.
    • SrcAddr, DstAddr, SrcPort, DstPort y Protocol hacen referencia al paquete interior.
    En KVM, el muestreo del paquete de túnel se realiza en forma de un registro:
    El registro del paquete interno con alguna información del túnel externo.
    • SrcAddr, DstAddr, SrcPort, DstPort y Protocol hacen referencia al paquete interior.
    • Contiene algunas entradas empresariales para describir el paquete externo.

  • Posible degradación del rendimiento al utilizar IPFIX.
    Ciertas configuraciones de IPFIX pueden degradar el rendimiento en los hipervisores de KVM y ESXi. Por ejemplo, establecer valores bajos para el tiempo de espera de inactividad, el tiempo de espera de flujo o los flujos máximos, combinado con valores altos para la probabilidad de muestreo, puede dar lugar a una degradación del rendimiento. Al realizar la configuración de IPFIX, supervise el impacto que tiene en el rendimiento de los hipervisores.

  • Rango de direcciones IP 100.64.0.0/10 utilizado para la red de tránsito externo.
    No configure el rango de direcciones IP 100.64.0.0/10 en la interfaz de vínculo superior de un enrutador lógico de nivel 0. Este rango de direcciones IP se utiliza para la red de tránsito externo en NSX Edge. Para obtener más información, consulte RFC 6598.

  • El paquete de apoyo contiene información de auditorías, que incluye nombres de usuarios.
    Puede generar un paquete de apoyo que contenga información de dispositivos NSX-T que pueda utilizar el servicio de soporte técnico de VMware para diagnosticar los problemas notificados por los clientes. Este paquete de apoyo contiene información de auditorías, incluyendo nombres de usuarios válidos del dispositivo.

  • Para cambiar el tiempo de espera de conexión HTTP de NSX Manager o el tiempo de espera de la sesión, es necesario reiniciar.
    Para cambiar el tiempo de espera de conexión HTTP de NSX Manager o el tiempo de espera de la sesión, es necesario reiniciar. Esto no se trata en la documentación de NSX. Puede reiniciar el servicio HTTP a través de la API o la CLI.
    API: POST /api/v1/node/services/http?action=restart
    CLI: restart service http

Información de referencia de la API

La información de referencia más reciente de la API se encuentra en el Centro de información de NSX-T. Utilice la información de referencia más reciente de la API en lugar de la versión disponible desde la interfaz de usuario de NSX Manager.

Llamadas y propiedades obsoletas de la API

Las siguientes llamadas y propiedades de la API están obsoletas. Están marcadas como obsoletas en la información de referencia de la API. Puede seguir utilizándolas como desee, pero tenga en cuenta que se eliminarán de NSX-T en una versión futura.

Llamadas API obsoletas

Llamada API disponible Llamada API obsoleta
POST /api/v1/licenses PUT /api/v1/license
GET /api/v1/licenses GET /api/v1/license
POST /api/v1/dhcp/relay-profiles con el esquema DhcpRelayProfile POST /api/v1/service-profiles
GET /api/v1/dhcp/relay-profiles con el esquema DhcpRelayProfileListResult GET /api/v1/service-profiles
PUT /api/v1/dhcp/relay-profiles/ con el esquema DhcpRelayProfile PUT /api/v1/service-profiles/
DELETE /api/v1/dhcp/relay-profiles/ DELETE /api/v1/service-profiles/
GET /api/v1/dhcp/relay-profiles/ con el esquema DhcpRelayProfile GET /api/v1/service-profiles/
POST /api/v1/dhcp/relays con el esquema DhcpRelayService POST /api/v1/services
GET /api/v1/dhcp/relays con el esquema DhcpRelayServiceListResult GET /api/v1/services
DELETE /api/v1/dhcp/relays/ DELETE /api/v1/services/
PUT /api/v1/dhcp/relays/ con el esquema DhcpRelayService PUT /api/v1/services/
GET /api/v1/dhcp/relays/ con el esquema DhcpRelayService GET /api/v1/services/

Propiedades API obsoletas

API obsoleta Descripción
Propiedad obsoleta en BgpConfig (tipo)
  • as_number (en su lugar use as_num ).
Propiedades obsoletas en BgpNeighbor (tipo)
  • filter_in_ipprefixlist_id (en su lugar use address_family).
  • filter_in_routemap_id (en su lugar use address_family).
  • filter_out_ipprefixlist_id (en su lugar use address_family).
  • filter_out_routemap_id (en su lugar use address_family).
  • remote_as (en su lugar use remote_as_num).
  • source_address (en su lugar use source_addresses).
Propiedad obsoleta en HostSwitch (tipo)
  • static_ip_pool_id (en su lugar use ip_assignment_spec).
Propiedad obsoleta en TransportNode (tipo)
  • host_switches (en su lugar use host_switch_spec instead).
Propiedad obsoleta en PortConnectionHypervisor (tipo)
  • pnics
Propiedad obsoleta en AddControllerNodeSpec (tipo)
  • control_plane_server_certificate