Guía de solución de problemas de NSX-T - VMware NSX-T Data ... · Guía de solución de problemas...

Guía de solución de problemas de NSX-TModificado el 5 de junio de 2018

VMware NSX-T Data Center 2.2

Puede encontrar la documentación técnica más actualizada en el sitio web de VMware:

https://docs.vmware.com/es/

Si tiene comentarios relacionados con esta documentación, envíelos a:

[email protected]

VMware, Inc.3401 Hillview Ave.Palo Alto, CA 94304www.vmware.com

VMware Spain, S.L.Calle Rafael Boti 262.ª plantaMadrid 28023Tel.: +34 914125000www.vmware.com/es

Copyright © 2017, 2018 VMware, Inc. Todos los derechos reservados. Información sobre el copyright y la marca comercial.

Guía de solución de problemas de NSX-T

VMware, Inc. 2

https://docs.vmware.com/es/

mailto:[email protected]

http://pubs.vmware.com/copyright-trademark.html

http://pubs.vmware.com/copyright-trademark.html

Contenido

Guía de solución de problemas de NSX-T 5

1 Solución de problemas de conectividad de capa 2 6Comprobar el estado del clúster de NSX Manager y de NSX Controller 6

Comprobar los puertos lógicos 7

Comprobar el estado del nodo de transporte 8

Comprobar el estado del conmutador lógico 8

Comprobar el CCP para el conmutador lógico 9

Comprobar el estado del plano de control local 10

Solucionar problemas de la sesión de configuración 10

Solucionar problemas de la sesión de capa 2 11

Solucionar problemas de plano de datos para un conmutador lógico superpuesto 12

Solucionar problemas de plano de datos para un conmutador lógico de VLAN 14

Solucionar problemas de ARP para un conmutador lógico superpuesto 14

Solucionar problemas de pérdida de paquetes para un conmutador lógico de VLAN o cuando se ha resuelto ARP 15

2 Solucionar problemas de instalación 17

3 Solución de problemas de enrutamiento 21

4 Solución de problemas del firewall 23Determinar las reglas de firewall que se aplican a un host ESXi 23

Determinar las reglas de firewall que se aplican a un host de KVM 26

Registros de paquetes de firewall 27

5 Registros y servicios 29Mensajes de registro 29

Configurar registros remotos 30

Identificadores de mensajes de registro 32

Solucionar problemas de syslog 33

Comprobación de servicios 34

Recopilar paquetes de soporte 36

6 Otros escenarios de solución de problemas 38Error al agregar o eliminar un nodo de transporte 38

El nodo de transporte tarda unos 5 minutos en conectarse a otro controlador 39

La máquina virtual de NSX Manager está degradada 40

VMware, Inc. 3

Se agota el tiempo de espera para que el agente NSX se comunique con NSX Manager 41

Error al agregar un host ESXi 42

Estado incorrecto de NSX Controller 42

No se puede tener acceso a direcciones IP de administración en máquinas virtuales de KVM con IPFIX habilitado 43


VMware, Inc. 4


La Guía de solución de problemas de NSX-T proporciona información sobre cómo solucionar problemas que podrían producirse en un entorno de NSX-T.

Público objetivoEsta guía es para administradores de sistemas de NSX-T. Se da por sentado que los administradores están familiarizados con operaciones de virtualización, redes y centro de datos.

Glosario de publicaciones técnicas de VMwarePublicaciones técnicas de VMware proporciona un glosario de términos que podrían resultarle desconocidos. Si desea ver las definiciones de los términos que se utilizan en la documentación técnica de VMware, acceda a la página http://www.vmware.com/support/pubs.

VMware, Inc. 5

http://www.vmware.com/support/pubs

Solución de problemas de conectividad de capa 2 1Si hay un error de comunicación entre dos interfaces virtuales que están conectadas al el mismo conmutador lógico, por ejemplo, no puede hacer ping a una máquina virtual desde otra, puede seguir los pasos descritos en esta sección para solucionar el error.

Antes de comenzar, asegúrese de que no haya ninguna regla de firewall que bloquee el tráfico entre los dos puertos lógicos. Se recomienda que siga el orden de los temas en esta sección para solucionar el problema de conectividad.

Este capítulo incluye los siguientes temas:

n Comprobar el estado del clúster de NSX Manager y de NSX Controller

n Comprobar los puertos lógicos

n Comprobar el estado del nodo de transporte

n Comprobar el estado del conmutador lógico

n Comprobar el CCP para el conmutador lógico

n Comprobar el estado del plano de control local

n Solucionar problemas de la sesión de configuración

n Solucionar problemas de la sesión de capa 2

n Solucionar problemas de plano de datos para un conmutador lógico superpuesto

n Solucionar problemas de plano de datos para un conmutador lógico de VLAN

n Solucionar problemas de ARP para un conmutador lógico superpuesto

n Solucionar problemas de pérdida de paquetes para un conmutador lógico de VLAN o cuando se ha resuelto ARP

Comprobar el estado del clúster de NSX Manager y de NSX ControllerCompruebe que el estado del clúster de NSX Manager y de NSX Controller sea normal, y que los controladores estén conectados a NSX Manager.

VMware, Inc. 6

Procedimiento

1 Ejecute el siguiente comando de la CLI en NSX Manager para asegurarse de que el estado sea estable.

NSX-Manager> get management-cluster status

Number of nodes in management cluster: 1

- 192.168.110.47 (UUID 45A8869B-BB90-495D-8A01-69B5FCC56086) Online

Management cluster status: STABLE

Number of nodes in control cluster: 3

- 192.168.110.201 (UUID 45A8869B-BB90-495D-8A01-69B5FCC56086)

- 192.168.110.202 (UUID 45A8869B-BB90-495D-8A01-69B5FCC56086)

- 192.168.110.203 (UUID 45A8869B-BB90-495D-8A01-69B5FCC56086)

2 Ejecute el siguiente comando de la CLI en NSX Controller para asegurarse de que el estado sea activo.

NSX-Controller1> get control-cluster status

uuid: db4aa77a-4397-4d65-ad33-9fde79ac3c5c

is master: true

in majority: true

uuid address status

0cfe232e-6c28-4fea-8aa4-b3518baef00d 192.168.110.201 active

bd257108-b94e-4e6d-8b19-7fa6c012961d 192.168.110.202 active

538be554-1240-40e4-8e94-1497e963a2aa 192.168.110.203 active

3 Ejecute el siguiente comando de la CLI en NSX Controller para asegurarse de que esté conectado a NSX Manager.

NSX-Controller1> get managers

- 192.168.110.47 Connected

Comprobar los puertos lógicosCompruebe que los puertos lógicos estén configurados en el mismo conmutador lógico y que su estado sea activo.

Procedimiento

1 En la GUI de NSX Manager, obtenga los UUID de los puertos lógicos.

2 Realice la siguiente llamada API para cada puerto lógico con el fin de garantizar que los puertos lógicos se encuentran en el mismo conmutador lógico.

GET https://<nsx-mgr>/api/v1/logical-ports/<logical-port-uuid>


VMware, Inc. 7

3 Realice la siguiente llamada API para cada puerto lógico para asegurarse de que el estado sea activo.

GET https://<nsx-mgr>/api/v1/logical-ports/<logical-port-uuid>/status

Comprobar el estado del nodo de transporteCompruebe el estado del nodo de transporte.

Procedimiento

u Realice la siguiente llamada API para obtener el estado del nodo de transporte.

GET https://<nsx-mgr>/api/v1/transport-nodes/<transport-node-ID>/state

Si la llamada devuelve el error Tiempo de espera de RPC, realice los siguientes pasos de solución de problemas:

n Ejecute /etc/init.d/nsx-opsAgent status para ver si se está ejecutando opsAgent.

n Ejecute /etc/init.d/nsx-mpa status para ver si se está ejecutando nsx-mpa.

n Para ver si nsx-mpa está conectado a NSX Manager, compruebe los registros de latido de nsx-mpa.

n Para ver si opsAgent está conectado a NSX Manager, compruebe el registro de nsx-opsAgent. Si opsAgent está conectado a NSX Manager, verá el siguiente mensaje.

Connected to mpa, cookie: ...

n Para ver si opsAgent tiene bloqueado el procesamiento de HostConfigMsg, compruebe el registro de nsx-opsAgent. Si es así, verá un mensaje de solicitud RMQ, pero la respuesta no se envía o se envía después de un prolongado retraso.

n Compruebe si opsAgent se bloqueó mientras se ejecutaba HostConfigMsg.

n Para ver si los mensajes RMQ demoran mucho tiempo en entregarse al host, compare las marcas de tiempo de los mensajes de registro en NSX Manager y el host.

Si la llamada devuelve el error partial_success, existen muchas causas posibles. Comience viendo los registros de nsx-opsAgent. En el host ESXi, compruebe hostd.log y vmkernel.log. En KVM, syslog contiene todos los registros.

Comprobar el estado del conmutador lógicoCompruebe el estado del conmutador lógico.


VMware, Inc. 8

Procedimiento

u Realice la siguiente llamada API para obtener el estado del conmutador lógico.

GET https://<nsx-mgr>/api/v1/logical-switches/<logical-switch-ID>/state

Si la llamada devuelve el error partial_success, la respuesta contendrá una lista de los nodos de transporte donde NSX Manager no pudo insertar la configuración de conmutador lógico o no obtuvo una respuesta. Los pasos de solución de problemas son similares a aquellos para el nodo de transporte. Compruebe lo siguiente:

n Todos los componentes requeridos están instalados y en ejecución.

n nsx-mpa está conectado a NSX Manager.

n nsxa está conectado a la conmutación vertical.

n Ejecute grep para el ID del conmutador lógico en nsxa.log y nsxaVim.log para ver si el nodo de transporte recibió la configuración del conmutador lógico.

n Compruebe el tiempo de actividad de nsxa y nsx-mpa. Averigüe cuándo se inició y se detuvo nsxa mediante grep de los mensajes de registro de nsxa en el archivo syslog.

n Averigüe el tiempo de conexión de nsxa para la conmutación vertical. Si la configuración del conmutador lógico se envía al host cuando nsxa no está conectado a la conmutación vertical, puede que la configuración no se entregue al host.

En KVM, no se inserta ninguna configuración de conmutador lógico en el host. Por lo tanto, es probable que la mayoría de los problemas de conmutador lógico esté en el plano de administración.

En ESXi, se asigna una red opaca al conmutador lógico. Para utilizar el conmutador lógico, los usuarios conectan máquinas virtuales a la red opaca mediante vCenter Server o VSphere API.

Comprobar el CCP para el conmutador lógicoCompruebe que el conmutador lógico esté en el plano de control central (CCP).

Procedimiento

u Ejecute el siguiente comando de la CLI en un NSX Controller para asegurarse de que el conmutador lógico está presente.

NSX-Controller1> get logical switches

VNI UUID Name

52104 feab22ec-94b2-46f4-88f8-f9d44a416272 ls1

Nota Este comando de la CLI no enumera conmutadores lógicos respaldados por VLAN.


VMware, Inc. 9

Comprobar el estado del plano de control localPara un conmutador lógico superpuesto, compruebe que el netcpa en el host está conectado al plano de control central.

Requisitos previos

Busque el controlador en el que se encuentra el conmutador lógico. Consulte Comprobar el CCP para el conmutador lógico.

Procedimiento

1 Utilice SSH para el controlador en el que se encuentra el conmutador lógico.

2 Ejecute el siguiente comando y compruebe que el controlador muestre los hipervisores que están conectados a este VNI.

get logical-switch 5000 connection-table

3 En los hipervisores, ejecute el comando /bin/nsxcli para iniciar la CLI de NSX.

4 Ejecute el siguiente comando para obtener las sesiones de CCP.

host1> get ccp-session

Session Index State Controller

Config 0 UP 10.33.74.163

L2 5000 UP 10.33.74.163

Debería ver una sesión de configuración en uno de los nodos CCP en el clúster CCP. Para cada conmutador lógico superpuesto, debe ver una sesión de capa 2 en uno de los nodos CCP en el clúster CCP. Para conmutadores lógicos de VLAN, no hay ninguna conexión de CCP.

Solucionar problemas de la sesión de configuraciónSi la sesión de la configuración de CCP no está activa, compruebe el estado de MPA y netcpa.

Procedimiento

1 Realice la siguiente llamada API para ver si MPA está conectado a NSX Manager.

GET https://<nsx-mgr>/api/v1/logical-ports/<logical-port-uuid>

2 En el hipervisor, ejecute el comando /bin/nsxcli para iniciar la CLI de NSX.

3 Ejecute el siguiente comando para obtener node-uuid.

host1> get node-uuid

0c123dd4-8199-11e5-95e2-73cc1cd9b614

4 Ejecute el siguiente comando para ver si NSX Manager insertó la información del CCP en el host.

cat /etc/vmware/nsx/config-by-vsm.xml


VMware, Inc. 10

5 Si config-by-vsm.xml tiene información del CCP, compruebe si hay un nodo de transporte configurado en el hipervisor.

NSX Manager envía el certificado de host del hipervisor en el paso de creación del nodo de transporte. El CCP debe tener el certificado de host antes de aceptar conexiones desde el host.

6 Comprueba la validez del certificado de host en /etc/vmware/nsx/host-cert.pem.

El certificado debe ser el mismo que el que tiene NSX Manager para el host.

7 Ejecute el siguiente comando para comprobar el estado de netcpa.

En ESXi:

/etc/init.d/netcpad status

En KVM:

/etc/init.d/nsx-agent status

8 Inicie o reinicie netcpa.

En ESXi, inicie netcpa en caso de que no se esté ejecutando, o reinícielo si está en ejecución.

/etc/init.d/netcpad start

/etc/init.d/netcpad restart

En KVM, inicie netcpa si no se está ejecutando, o reinícielo si está en ejecución.

/etc/init.d/nsx-agent start

/etc/init.d/nsx-agent restart

9 Si la sesión de configuración aún no está activa, recopile los paquetes de soporte técnico y póngase en contacto con el soporte de VMware.

Solucionar problemas de la sesión de capa 2Esto se aplica solo a conmutadores lógicos superpuestos.

Procedimiento

1 En el hipervisor, ejecute el comando /bin/nsxcli para iniciar la CLI de NSX.

2 Ejecute el siguiente comando para ver si el conmutador lógico está presente en el host.

host1> get logical-switches


VMware, Inc. 11

3 Compruebe que el estado del puerto no sea Administrador caído.

En ESXi, ejecute net-dvs y vea la respuesta. Por ejemplo,

port 63eadf53-ff92-4a0e-9496-4200e99709ff:

com.vmware.port.extraConfig.opaqueNetwork.id = … <- this should match the logical switch UUID

com.vmware.port.opaque.network.id = …. <- this should match the logical switch UUID

com.vmware.port.opaque.network.type = nsx.LogicalSwitch , propType = RUNTIME

com.vmware.common.port.block = false, ... <- Make sure the value is false.

com.vmware.vswitch.port.vxlan = …

com.vmware.common.port.volatile.status = inUse ... <- make sure the value is inUse.

Si el puerto lógico termina con el estado bloqueado, recopile los paquetes de soporte técnico y póngase en contacto con el soporte de VMware. Mientras tanto, ejecute el siguiente comando para obtener el nombre de DVS:

[root@host1:~] net-dvs | grep nsx-switch

com.vmware.common.alias = nsx-switch , propType = CONFIG

Ejecute el siguiente comando para desbloquear el puerto:

[root@host1:~] net-dvs -s com.vmware.common.port.block=false <DVS-NAME> -p <logical-port-ID>

En KVM, ejecute ovs-vsctl list interface y compruebe que está presente la interfaz con el UUID de la VIF correspondiente y que admin_state está activo. Puede ver el UUID de la VIF en OVSDB en external-ids:iface-id.

Solucionar problemas de plano de datos para un conmutador lógico superpuestoLos pasos descritos en esta sección son para la solución de problemas de conectividad entre máquinas virtuales en diferentes hipervisores a través del conmutador superpuesto, cuando los estados de configuración y tiempo de ejecución son normales.

Si las máquinas virtuales están en el mismo hipervisor, vaya a Solucionar problemas de ARP para un conmutador lógico superpuesto.

Procedimiento

1 Ejecute el siguiente comando en el controlador que tiene el conmutador lógico para ver si CCP tiene la lista correcta de VTEP:

controller1> get logical-switch 5000 vtep

2 En cada hipervisor, ejecute el siguiente comando de la CLI de NSX para ver si tiene la lista correcta de VTEP:

En ESXi:

host1> get logical-switch <logical-switch-UUID> tep-table


VMware, Inc. 12

Como alternativa, puede ejecutar el siguiente comando de shell para obtener la información de VTEP:

[root@host1:~] net-vdl2 -M vtep -s vds -n VNI

En KVM:

host1> get logical-switch <logical-switch-UUID or VNI> tep-table

3 Compruebe si los VTEP en los hipervisores pueden hacer ping entre sí.

En el indicador de shell de ESXi:

host1> ping ++netstack=vxlan <remote-VTEP-IP>

En el indicador de shell de KVM:

host1> ping <remote-VTEP-IP>

Si los VTEP no pueden hacer ping entre sí:

a Asegúrese de que la VLAN de transporte especificada al crear el nodo de transporte coincida con lo que se espera de la red. Si va a utilizar puertos de acceso en la red, la VLAN de transporte se debe establecer en 0. Si va a especificar una VLAN de transporte, los puertos del conmutador subyacente a los que se conectan los hipervisores deben configurarse para que acepten esta VLAN en modo de tronco.

b Compruebe la conectividad de la red.

4 Compruebe que las sesiones BFD entre los VTEP estén activas.

En ESXi, ejecute net-vdl2 -M bfd y vea la respuesta. Por ejemplo,

BFD count: 1

===========================

Local IP: 192.168.48.35, Remote IP: 192.168.197.243, Local State: up, Remote State: up, Local

Diag: No Diagnostic, Remote Diag: No Diagnostic, minRx: 1000000, isDisabled: 0

En KVM, busque la interfaz GENEVE para la dirección IP remota.

ovs-vsctl list interface <GENEVE-interface-name>

Si no conoce el nombre de la interfaz, ejecute ovs-vsctl find Interface type=geneve para devolver todas las interfaces de túnel. Busque información de BFD.

Si no puede encontrar una interfaz GENEVE para VTEP remoto, compruebe si se está ejecutando nsx-agent y si el puente de integración de OVS está conectado a nsx-agent.

[root@host1 ~]# ovs-vsctl show

96c9e543-fc68-448a-9882-6e161c313a5b

Manager "tcp:127.0.0.1:6632"

is_connected: true

Bridge nsx-managed


VMware, Inc. 13

Controller "tcp:127.0.0.1:6633"

is_connected: true

Controller "unix:ovs-l3d.mgmt"

is_connected: true

fail_mode: secure

Solucionar problemas de plano de datos para un conmutador lógico de VLANLos pasos descritos en esta sección son para la solución de problemas de conectividad entre máquinas virtuales en diferentes hipervisores a través de la VLAN configurada en la red, cuando los estados de configuración y de tiempo de ejecución son normales.

Si las máquinas virtuales están en el mismo hipervisor y todos los estados de configuración y de tiempo de ejecución son normales, vaya a Solucionar problemas de ARP para un conmutador lógico superpuesto.

Procedimiento

u Compruebe que la red esté configurada para la VLAN para el conmutador lógico en modo de tronco.

En ESXi, compruebe que la VLAN está configurada en el puerto lógico mediante la ejecución de net-dvs y la búsqueda del puerto lógico. Por ejemplo:

port 63eadf53-ff92-4a0e-9496-4200e99709ff:

com.vmware.common.port.volatile.vlan = VLAN 1000 propType = RUNTIME VOLATILE

En KVM, el conmutador lógico de la VLAN está configurado como una regla de Openflow en puente de integración. En otras palabras, para tráfico proveniente de la VIF, etiquételo con VLAN X y reenvíelo en el puerto de revisión hacia el puente PIF. Ejecute ovs-vsctl list interface y compruebe la presencia del puerto de revisión entre el puente administrado por NSX y el puente de conmutador de NSX.

Solucionar problemas de ARP para un conmutador lógico superpuestoLos pasos descritos en esta sección son para solucionar problemas en relación con paquetes que se pierden para un conmutador superpuesto.

Para un conmutador lógico respaldado por VLAN, vaya a Solucionar problemas de pérdida de paquetes para un conmutador lógico de VLAN o cuando se ha resuelto ARP.

Antes de realizar los siguientes pasos de solución de problemas, ejecute el comando arp -n en cada máquina virtual. Si ARP se resolvió correctamente en ambas máquinas virtuales, no es necesario realizar los pasos en esta sección. En su lugar, vaya a la siguiente sección Solucionar problemas de pérdida de paquetes para un conmutador lógico de VLAN o cuando se ha resuelto ARP.


VMware, Inc. 14

Procedimiento

u Si ambos endpoints son ESXi y el proxy ARP está habilitado en el conmutador lógico (solo se admite para conmutadores lógicos superpuestos), compruebe la tabla de ARP en el CCP y el hipervisor.

En el CCP:

controller1> get logical-switch 5000 arp-table

En el hipervisor, inicie la CLI de NSX y ejecute el siguiente comando:

host1> get logical-switch <logical-switch-UUID> arp-table

La recuperación de la tabla ARP solo nos indica si tenemos el estado correcto del proxy ARP. Si no se recibe respuesta de ARP a través del proxy, o si el host es KVM y no es compatible con proxy ARP, la ruta de datos debe transmitir la solicitud de ARP. Puede haber un problema con el reenvío de tráfico BUM. Realice los siguientes pasos:

n Si el modo de replicación para el conmutador lógico es MTEP, en la GUI de NSX Manager cambie este modo a SOURCE para el conmutador lógico. Esto podría solucionar el problema y el ping comenzará a funcionar.

n Agregue entradas de ARP estáticas y compruebe si funciona el resto de la ruta de datos.

Solucionar problemas de pérdida de paquetes para un conmutador lógico de VLAN o cuando se ha resuelto ARPPuede usar la herramienta Traceflow automatizada o hacer seguimiento manual de los paquetes para solucionar problemas de pérdida de estos.

Para ejecutar la herramienta Traceflow, en la interfaz gráfica de usuario de NSX Manager, desplácese hasta Herramientas > Traceflow. Para obtener más información, consulte la Guía de administración de NSX-T.

Procedimiento

u Para realizar un seguimiento manual de los paquetes:

En ESXi, ejecute net-stats -l para obtener el ID de puerto de conmutador de las VIF. Si las VIF de origen y destino están en el mismo hipervisor, ejecute los siguientes comandos:

pktcap-uw --switchport <src-switch-port-ID> --dir=0

pktcap-uw --switchport <dst-switch-port-ID> --dir=1

Si las VIF de origen y destino están en hipervisores diferentes, en el hipervisor que aloja la VIF de origen, ejecute los siguientes comandos:

pktcap-uw --switchport <src-switch-port-ID> --dir=0

pktcap-uw --uplink <uplink-name> --dir=1


VMware, Inc. 15

En el hipervisor que aloja la VIF de destino, ejecute los siguientes comandos:

pktcap-uw --uplink <uplink-name> --dir=0

pktcap-uw --switchport <dest-switch-port-ID> --dir=1

En KVM, si las VIF de origen y destino están en el mismo hipervisor, ejecute el siguiente comando:

ovs-dpctl dump-flows


VMware, Inc. 16

Solucionar problemas de instalación 2En esta sección, se incluye información sobre cómo solucionar problemas relacionados con la instalación.

Servicios de infraestructura básicosLos siguientes servicios deben ejecutarse en los dispositivos e hipervisores, así como en vCenter Server si se utiliza como un administrador de equipos.

n NTP

n DNS

Asegúrese de que el firewall no esté bloqueando el tráfico entre los componentes de NSX-T y los hipervisores. Compruebe que los puertos requeridos estén abiertos entre los componentes.

Para vaciar la caché DNS en NSX Manager, utilice SSH para iniciar sesión como usuario root en el administrador y ejecute el siguiente comando:

root@nsx-mgr-01:~# /etc/init.d/resolvconf restart

[ ok ] Restarting resolvconf (via systemctl): resolvconf.service.

A continuación, puede comprobar el archivo de configuración de DNS.

root@nsx-mgr-01:~# cat /etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)

# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

nameserver 192.168.253.1

search mgt.sg.lab

VMware, Inc. 17

Comprobar la comunicación del host al controlador y al administradorEn un host ESXi mediante comandos de la CLI de NSX-T:

esxi-01.corp.local> get managers

- 192.168.110.19 Connected

esxi-01.corp.local> get controllers

Controller IP Port SSL Status Is Physical Master Session State Controller

FQDN

192.168.110.16 1234 enabled connected true up NA

En un host de KVM mediante comandos de la CLI de NSX-T:

kvm-01> get managers

- 192.168.110.19 Connected

kvm-01> get controllers

Controller IP Port SSL Status Is Physical Master Session State Controller

FQDN

192.168.110.16 1234 enabled connected true up NA

En un host ESXi mediante comandos de la CLI de host:

[root@esxi-01:~] esxcli network ip connection list | grep 1234

tcp 0 0 192.168.110.53:42271 192.168.110.16:1234

ESTABLISHED 67702 newreno netcpa

[root@esxi-01:~]

[root@esxi-01:~] esxcli network ip connection list | grep 5671

tcp 0 0 192.168.110.253:11721 192.168.110.19:5671 ESTABLISHED 2103688

newreno mpa

tcp 0 0 192.168.110.253:30977 192.168.110.19:5671 ESTABLISHED 2103688

newreno mpa

En un host de KVM mediante comandos de la CLI de host:

root@kvm-01:/home/vmware# netstat -nap | grep 1234

tcp 0 0 192.168.110.55:53686 192.168.110.16:1234 ESTABLISHED 2554/netcpa

root@kvm-01:/home/vmware#


root@kvm-01:/home/vmware# netstat -nap | grep 5671

tcp 0 0 192.168.110.55:50108 192.168.110.19:5671 ESTABLISHED 2870/mpa

tcp 0 0 192.168.110.55:50110 192.168.110.19:5671 ESTABLISHED 2870/mpa

root@kvm-01:/home/vmware# tcpdump -i ens32 port 1234 | grep kvm-01

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes

<truncated output>

03:46:27.040461 IP nsxcontroller01.corp.local.1234 > kvm-01.corp.local.38754: Flags [P.], seq

3315301231:3315301275, ack 2671171555, win 323, length 44

03:46:27.040509 IP kvm-01.corp.local.38754 > nsxcontroller01.corp.local.1234: Flags [.], ack 44, win

1002, length 0


VMware, Inc. 18

^C

<truncated output>


root@kvm-01:/home/vmware# tcpdump -i ens32 port 5671 | grep kvm-01

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes

03:51:16.802934 IP kvm-01.corp.local.58954 > nsxmgr01.corp.local.amqps: Flags [P.], seq 1153:1222,

ack 1790, win 259, length 69

03:51:16.823328 IP nsxmgr01.corp.local.amqps > kvm-01.corp.local.58954: Flags [P.], seq 1790:1891,

ack 1222, win 254, length 101

^C

<truncated output>

Error de registro de hostSi NSX-T utiliza la dirección IP incorrecta, se producirá un error en el registro de host. Esto puede suceder cuando un host tiene varias direcciones IP. Al intentar eliminar el nodo de transporte, queda en el estado huérfano. Para resolver el problema, realice lo siguiente:

n Vaya a Tejido > Nodos > Hosts, edite el host y quite todas las direcciones IP, excepto la de administración.

n Haga clic en los errores y seleccione Resolver.

Problemas de host de KVMLos problemas del host de KVM en ocasiones se producen porque no hay suficiente espacio de disco. El directorio /boot puede llenarse rápidamente y provocar errores como los siguientes:

n No se puede instalar el software en el host.

n No hay más espacio en el dispositivo.

Puede ejecutar el comando df -h para comprobar el espacio de almacenamiento disponible. Si el directorio /boot está al 100 %, puede hacer lo siguiente:

n Ejecute sudo dpkg --list 'linux-image*' | grep ^ii para ver todos los kernels instalados.

n Ejecute uname -r para ver el kernel en ejecución actualmente. No elimine este kernel (imagen de Linux).

n Utilice apt-get purge para quitar las imágenes que ya no necesite. Por ejemplo, ejecute sudo apt-get purge linux-image-3.13.0-32-generic linux-image-3.13.0-33-generic.

n Reinicie el host.

n En NSX Manager, compruebe los errores y seleccione Resolver.

n Asegúrese de que las máquinas virtuales estén encendidas.


VMware, Inc. 19

Error de configuración al implementar una máquina virtual de EdgeDespués de implementar una máquina virtual de Edge, NSX Manager muestra el estado de la máquina virtual como Error de configuración. En el registro del administrador, aparece un mensaje similar al siguiente:

nsx-manager NSX - FABRIC [nsx@6876 comp="nsx-manager" errorCode="MP16027" subcomp="manager"] Edge

758ad396-0754-11e8-877e-005056abf715 is not ready for configuration error occurred, error detail is

NSX Edge configuration has failed. The host does not support required cpu features: ['aes'].

Si se reinician el servicio de ruta de datos de Edge y, a continuación, la máquina virtual, el problema debería resolverse.

Forzar la eliminación de un nodo de transportePuede quitar un nodo de transporte que está atascado en el estado huérfano realizando la siguiente llamada API:

DELETE https://<NSX Manager>/api/v1/transport-nodes/<TN ID>?force=true

NSX Manager no realizará ninguna validación en cuanto a si se dispone de máquinas virtuales activas en ejecución en el host. Usted es responsable de eliminar el N-VDS y los VIB. Si tiene el nodo agregado a través del administrador de equipos, elimine primero el administrador de equipos y, a continuación, elimine el nodo. También se eliminará el nodo de transporte.


VMware, Inc. 20

Solución de problemas de enrutamiento 3NSX-T tiene herramientas integradas para solucionar problemas de enrutamiento.

TraceflowPuede utilizar Traceflow para inspeccionar el flujo de paquetes. Puede ver los paquetes entregados, descartados, recibidos y reenviados. Si se descarta un paquete, se muestra un motivo. Por ejemplo, se puede descartar un paquete debido a una regla de firewall.

Comprobación de las tablas de enrutamientoPara ver la tabla de enrutamiento en un enrutador de servicio, ejecute los siguientes comandos:

edge01> get logical-router

Logical Route

UUID VRF LR-ID Name Type

Ports

736a80e3-23f6-5a2d-81d6-bbefb2786666 0 0 TUNNEL 3

c9393d0c-1fcf-4c34-889d-2da1eeee25b8 1 10 SR-t0-router SERVICE_ROUTER_TIER0 5

9333c94e-5938-46b4-8c7d-5e6ac2c8b7b5 2 8 DR-t1-router01 DISTRIBUTED_ROUTER_TIER1 6

c91eb7c5-0297-4fed-9c22-b96df1c9b80f 3 9 DR-t0-router DISTRIBUTED_ROUTER_TIER0 4

edge01> vrf 1

edge01(tier0_sr)> get route

Flags: c - connected, s - static, b - BGP, ns - nsx_static

nc - nsx_connected, rl - router_link, t0n: Tier0-NAT, t1n: Tier1-NAT

t1l: Tier1-LB VIP, t1s: Tier1-LB SNAT

Total number of routes: 25

b 10.10.20.0/24 [20/0] via 192.168.140.1

b 10.10.30.0/24 [20/0] via 192.168.140.1

b 10.20.20.0/24 [20/0] via 192.168.140.1

b 10.20.30.0/24 [20/0] via 192.168.140.1

b 30.0.0.0/8 [20/0] via 192.168.140.1

rl 100.64.80.0/31 [0/0] via 169.254.0.1

rl 100.64.80.2/31 [0/0] via 169.254.0.1

rl 100.64.80.4/31 [0/0] via 169.254.0.1

<TRUNCATED OUTPUT>

b 192.168.200.0/24 [20/0] via 192.168.140.1

VMware, Inc. 21

b 192.168.210.0/24 [20/0] via 192.168.140.1

b 192.168.220.0/24 [20/0] via 192.168.140.1

b 192.168.230.0/24 [20/0] via 192.168.140.1

b 192.168.240.0/24 [20/0] via 192.168.140.1

Para obtener la dirección IP de las interfaces, ejecute el siguiente comando:

edge01(tier0_sr)> get interfaces

Logical Router

UUID VRF LR-ID Name Type

c9393d0c-1fcf-4c34-889d-2da1eeee25b8 1 10 SR-t0-router SERVICE_ROUTER_TIER0

interfaces

interface : 977ac2eb-8ab7-40e9-8abe-782a438c749a

ifuid : 285

name : uplink01

mode : lif

IP/Mask : 192.168.140.3/24

MAC : 00:50:56:b5:d5:64

LS port : 14391f86-efef-4e3d-98c3-f291c17d13f8

urpf-mode : STRICT_MODE

admin : up

MTU : 1600

interface : 6af81d72-4d32-5f66-b7ae-403e617290e5

ifuid : 270

mode : blackhole

interface : 015e709d-6079-5c19-9556-8be2e956f775

ifuid : 269

mode : cpu

interface : 3f40f838-eb8a-4f35-854c-ea8bb872dc47

ifuid : 272

name : bp-sr0-port

mode : lif

IP/Mask : 169.254.0.2/28

MAC : 02:50:56:56:53:00

VNI : 25489

LS port : 770a208d-27fa-4f8d-afad-a9c41ca6295b

urpf-mode : NONE

admin : up

MTU : 1500

interface : 00003300-0000-0000-0000-00000000000a

ifuid : 263

mode : loopback

IP/Mask : 127.0.0.1/8

Anunciar rutas T1Se deben anunciar rutas T1 para que estén visibles en el enrutador T0 en adelante. Hay diferentes tipos de rutas que puede anunciar: conectada con NSX, NAT, estática, LB VIP y LB SNAT.


VMware, Inc. 22

Solución de problemas del firewall 4En esta sección se incluye información sobre cómo solucionar problemas relacionados con el firewall.


n Determinar las reglas de firewall que se aplican a un host ESXi

n Determinar las reglas de firewall que se aplican a un host de KVM

n Registros de paquetes de firewall

Determinar las reglas de firewall que se aplican a un host ESXiPara solucionar los problemas del firewall de un host ESXi, puede consultar las reglas de firewall que se aplican al host.

Obtenga la lista de dvfilters en el host ESXi:

[root@esxi-01:~] summarize-dvfilter

<TRUNCATED OUTPUT>

world 70181 vmm0:app-01a vcUuid:'50 35 9c 70 18 8e 99 1d-3c f9 8e cc 6b 27 4c 6f'

port 50331655 app-01a.eth0

vNic slot 2

name: nic-70181-eth0-vmware-sfw.2

agentName: vmware-sfw

state: IOChain Attached

vmState: Detached

failurePolicy: failClosed

slowPathID: none

filter source: Dynamic Filter Creation

world 70179 vmm0:web-02a vcUuid:'50 35 2b f3 4a 4b 10 83-54 72 50 f7 25 10 d8 64'

port 50331656 web-02a.eth0

vNic slot 2




vmState: Detached


slowPathID: none


VMware, Inc. 23

Busque dvfilter para una máquina virtual específica:

[root@esxi-01:~] summarize-dvfilter | less -p web

world 70179 vmm0:web-02a vcUuid:'50 35 2b f3 4a 4b 10 83-54 72 50 f7 25 10 d8 64'

port 50331656 web-02a.eth0

vNic slot 2




vmState: Detached


slowPathID: none


.

.

.

Determine las reglas de firewall que se aplican a un dvfilter específico (en este ejemplo, nic-70227-eth0-vmware-sfw.2 es el nombre del dvfilter):

[root@esxi-02:~] vsipioctl getrules -f nic-70227-eth0-vmware-sfw.2

ruleset mainrs {

rule 3072 at 1 inout protocol tcp from any to addrset 48822ec3-2670-497b-82f9-524618c16877 port 443

accept with log;

rule 3072 at 2 inout protocol tcp from any to addrset 48822ec3-2670-497b-82f9-524618c16877 port 80

accept with log;

rule 3074 at 3 inout protocol tcp from addrset 48822ec3-2670-497b-82f9-524618c16877 to addrset

8b9e75e7-bc62-4d7f-9a58-a872f393448e port 8443 accept with log;

rule 3074 at 4 inout protocol tcp from addrset 48822ec3-2670-497b-82f9-524618c16877 to addrset

8b9e75e7-bc62-4d7f-9a58-a872f393448e port 22 accept with log;

rule 3075 at 5 inout protocol tcp from addrset 8b9e75e7-bc62-4d7f-9a58-a872f393448e to addrset

b695c8df-9894-4068-a5e7-5504fe48d459 port 3306 accept with log;

rule 3076 at 6 inout protocol tcp from ip 192.168.110.10 to addrset rdst3076 port 443 accept with log;

rule 3076 at 7 inout protocol icmp typecode 8:0 from ip 192.168.110.10 to addrset rdst3076 accept

with log;



rule 2 at 10 inout protocol any from any to any accept with log;

}

ruleset mainrs_L2 {

rule 1 at 1 inout ethertype any stateless from any to any accept;

}

Obtenga la lista de conjuntos de direcciones que se utilizan en un dvfilter específico:

[root@esxi-02:~] vsipioctl getaddrsets -f nic-70227-eth0-vmware-sfw.2

addrset 48822ec3-2670-497b-82f9-524618c16877 {

ip 172.16.10.13,

mac 52:54:00:42:4d:38,

}

addrset 8b9e75e7-bc62-4d7f-9a58-a872f393448e {

}


VMware, Inc. 24

addrset b695c8df-9894-4068-a5e7-5504fe48d459 {

ip 172.16.30.11,

mac 52:54:00:64:0e:4f,

}

addrset rdst3076 {

ip 172.16.10.13,

ip 172.16.30.11,

mac 52:54:00:42:4d:38,

mac 52:54:00:64:0e:4f,

}

Compruebe los flujos de un dvfilter específico:

[root@esxi-02:~] vsipioctl getflows -f nic-75360-eth0-vmware-sfw.2

Count retrieved from kernel active(L3,L4)=20, active(L2)+inactive(L3,L4)=0, drop(L2,L3,L4)=0

a5d914f7a5b85fe5 Active tcp 0800 IN 3076 0 0 192.168.110.10:Unknown(51281) -> 172.16.10.11:ssh(22)

513 FINWAIT2:FINWAIT2 4304 5177 34 33

a5d914f7a5b86001 Active tcp 0800 OUT 2 0 0 172.16.10.11:http(80) -> 100.64.80.1:Unknown(60006) 457

SYNSENT:CLOSED 56 819 1 1

a5d914f7a5b86006 Active igmp 0800 IN 2 0 0 0.0.0.0 -> 224.0.0.1 36 0 1 0

a5d914f7a5b86011 Active tcp 0800 IN 3072 0 0 100.64.80.1:Unknown(60098) -> 172.16.10.11:http(80) 320

FINWAIT2:FINWAIT2 413 5411 9 6

a5d914f7a5b86012 Active tcp 0800 OUT 3074 0 0 172.16.10.11:Unknown(46001) ->

172.16.20.11:Unknown(8443) 815 FINWAIT2:FINWAIT2 7418 1230 10 9

a5d914f7a5b86013 Active udp 0800 OUT 2 0 0 172.16.10.11:Unknown(40080) -> 192.168.110.10:domain(53)

268 140 2 2

a5d914f7a5b86014 Active udp 0800 OUT 2 0 0 172.16.10.11:Unknown(59251) -> 192.168.110.10:domain(53)

268 140 2 2

a5d914f7a5b86015 Active ipv6-icmp 86dd OUT 2 0 0 fe80::250:56ff:feb5:a60e -> ff02::1:ff62:5ed4 135 0

0 72 0 1

a5d914f7a5b86016 Active ipv6-icmp 86dd OUT 2 0 0 fe80::250:56ff:feb5:a60e -> ff02::1:ff62:5ed4 135 0

0 72 0 1




172.16.20.11:Unknown(8443) 815 TIMEWAIT:TIMEWAIT 7314 1230 8 9



a5d914f7a5b8601a Active tcp 0800 OUT 3074 0 0 172.16.10.11:Unknown(46003) ->


a5d914f7a5b8601b Active tcp 0800 IN 3072 0 0 100.64.80.1:Unknown(60114) -> 172.16.10.11:http(80) 328

TIMEWAIT:TIMEWAIT 413 5451 9 7

a5d914f7a5b8601c Active tcp 0800 OUT 3074 0 0 172.16.10.11:Unknown(46004) ->

172.16.20.11:Unknown(8443) 815 TIMEWAIT:TIMEWAIT 7262 1218 7 9

a5d914f7a5b8601d Active tcp 0800 OUT 2 0 0 172.16.10.11:http(80) -> 100.64.80.1:Unknown(60060) 457

SYNSENT:CLOSED 56 819 1 1

a5d914f7a5b8601e Active tcp 0800 IN 3072 0 0 100.64.80.1:Unknown(60120) -> 172.16.10.11:http(80) 320

TIMEWAIT:TIMEWAIT 373 5411 8 6

a5d914f7a5b8601f Active tcp 0800 OUT 3074 0 0 172.16.10.11:Unknown(46005) ->



EST:EST 173 5371 3 5




VMware, Inc. 25

Determinar las reglas de firewall que se aplican a un host de KVMPara solucionar los problemas de firewall de un host de KVM, puede consultar las reglas de firewall que se aplican al host.

Obtenga la lista de VIF que están sujetos a reglas de firewall en el host de KVM:

# ovs-appctl -t /var/run/openvswitch/nsxa-ctl dfw/vif

Vif ID : da95fc1e-65fd-461f-814d-d92970029bf0

Port name : db-01a-eth0

Port number : 2

Si el resultado está vacío, busque problemas de conectividad entre el nodo y los controladores.

Obtenga la lista de reglas que se aplican a un VIF específico (en este ejemplo, da95fc1e-65fd-461f-814d-d92970029bf0 es el identificador de VIF):

# ovs-appctl -t /var/run/vmware/nsx-agent/nsxa-ctl dfw/rules da95fc1e-65fd-461f-814d-d92970029bf0

Distributed firewall status: enabled

Vif ID : da95fc1e-65fd-461f-814d-d92970029bf0

ruleset d035308b-cb0d-4e7e-aae5-a428b461db46 {

rule 3072 inout protocol tcp from any to addrset 48822ec3-2670-497b-82f9-524618c16877 port 443

accept with log;

rule 3072 inout protocol tcp from any to addrset 48822ec3-2670-497b-82f9-524618c16877 port 80 accept

with log;

rule 3074 inout protocol tcp from addrset 48822ec3-2670-497b-82f9-524618c16877 to addrset 8b9e75e7-

bc62-4d7f-9a58-a872f393448e port 8443 accept with log;

rule 3074 inout protocol tcp from addrset 48822ec3-2670-497b-82f9-524618c16877 to addrset 8b9e75e7-

bc62-4d7f-9a58-a872f393448e port 22 accept with log;

rule 3075 inout protocol tcp from addrset 8b9e75e7-bc62-4d7f-9a58-a872f393448e to addrset

b695c8df-9894-4068-a5e7-5504fe48d459 port 3306 accept with log;

}

ruleset 3027fed3-60b1-483e-aa17-c28719275704 {

rule 3076 inout protocol tcp from 192.168.110.10 to addrset b695c8df-9894-4068-a5e7-5504fe48d459

port 443 accept with log;

rule 3076 inout protocol icmp type 8 code 0 from 192.168.110.10 to addrset b695c8df-9894-4068-

a5e7-5504fe48d459 accept with log;





rule 3076 inout protocol tcp from 192.168.110.10 to addrset 8b9e75e7-bc62-4d7f-9a58-a872f393448e


rule 3076 inout protocol icmp type 8 code 0 from 192.168.110.10 to addrset 8b9e75e7-bc62-4d7f-9a58-

a872f393448e accept with log;





rule 3076 inout protocol tcp from 192.168.110.10 to addrset 48822ec3-2670-497b-82f9-524618c16877


VMware, Inc. 26


rule 3076 inout protocol icmp type 8 code 0 from 192.168.110.10 to addrset

48822ec3-2670-497b-82f9-524618c16877 accept with log;





}

ruleset 5e9bdcb3-adba-4f67-a680-5e6ed5b8f40a {

rule 2 inout protocol any from any to any accept with log;

}

ruleset ddf93011-4078-4006-b8f8-73f979d7a717 {

rule 1 inout ethertype any stateless from any to any accept;

}

Obtenga la lista de conjuntos de direcciones que se utilizan en un VIF específico:

# ovs-appctl -t /var/run/vmware/nsx-agent/nsxa-ctl dfw/addrsets da95fc1e-65fd-461f-814d-d92970029bf0

48822ec3-2670-497b-82f9-524618c16877 {

mac 52:54:00:42:4d:38,

ip 172.16.10.13,

}

8b9e75e7-bc62-4d7f-9a58-a872f393448e {

}

b695c8df-9894-4068-a5e7-5504fe48d459 {

mac 52:54:00:64:0e:4f,

ip 172.16.30.11,

}

Compruebe las conexiones a través del módulo Linux Conntrack. En este ejemplo, buscamos flujos entre dos direcciones IP específicas.

# ovs-appctl -t ovs-l3d conntrack/show | grep 192.168.110.10 | grep 172.16.10.13

ACTIVE

icmp,orig=(src=192.168.110.10,dst=172.16.10.13,id=1,type=8,code=0),reply=(src=172.16.10.13,dst=192.168

.110.10,id=1,type=0,code=0),start=2018-03-26T04:43:28.325,id=3122159040,zone=23119,status=SEEN_REPLY|

CONFIRMED,timeout=29,mark=3076,labels=0x1f

Registros de paquetes de firewallSi se habilita el registro de reglas de firewall, puede consultar los registros de paquetes de firewall para solucionar los problemas.

El archivo de registro es /var/log/dfwpktlogs.log para los hosts ESXi y de KVM.

# tail -f /var/log/dfwpktlogs.log

2018-03-27T10:23:35.196Z INET TERM 3072 IN TCP FIN 100.64.80.1/60688->172.16.10.11/80 8/7 373/5451

2018-03-27T10:23:35.196Z INET TERM 3074 OUT TCP FIN 172.16.10.11/46108->172.16.20.11/8443 8/9

1178/7366


VMware, Inc. 27

2018-03-27T10:23:35.196Z INET TERM 3072 IN TCP RST 100.64.80.1/60692->172.16.10.11/80 9/6 413/5411

2018-03-27T10:23:35.196Z INET TERM 3074 OUT TCP RST 172.16.10.11/46109->172.16.20.11/8443 9/7

1218/7262

2018-03-27T10:23:37.442Z 71d32787 INET match PASS 3074 IN 60 TCP 172.16.10.12/35770-

>172.16.20.11/8443 S

2018-03-27T10:23:38.492Z INET match PASS 2 OUT 1500 TCP 172.16.10.11/80->100.64.80.1/60660 A

2018-03-27T10:23:39.934Z INET match PASS 3072 IN 52 TCP 100.64.80.1/60720->172.16.10.11/80 S

2018-03-27T10:23:39.944Z INET match PASS 3074 OUT 60 TCP 172.16.10.11/46114->172.16.20.11/8443 S


>172.16.20.11/8443 S


>172.16.20.11/8443 S

2018-03-27T10:23:44.712Z INET TERM 3074 IN TCP RST 172.16.10.11/46109->172.16.20.11/8443 9/7 1218/7262

2018-03-27T10:23:44.712Z INET TERM 3074 IN TCP FIN 172.16.10.12/35766->172.16.20.11/8443 9/10

1233/7418

2018-03-27T10:23:44.712Z INET TERM 3074 IN TCP FIN 172.16.10.11/46110->172.16.20.11/8443 9/9 1230/7366

2018-03-27T10:23:44.712Z INET TERM 3074 IN TCP FIN 172.16.10.12/35767->172.16.20.11/8443 9/10

1233/7418

2018-03-27T10:23:44.939Z INET match PASS 3072 IN 52 TCP 100.64.80.1/60726->172.16.10.11/80 S

2018-03-27T10:23:44.957Z INET match PASS 3074 OUT 60 TCP 172.16.10.11/46115->172.16.20.11/8443 S


>172.16.20.11/8443 S

2018-03-27T10:23:45.480Z INET TERM 2 OUT TCP TIMEOUT 172.16.10.11/80->100.64.80.1/60528 1/1 1500/56


VMware, Inc. 28

Registros y servicios 5Los registros pueden ser útiles en muchas situaciones de solución de problemas. También es importante comprobar el estado de los servicios.


n Mensajes de registro

n Solucionar problemas de syslog

n Comprobación de servicios

n Recopilar paquetes de soporte

Mensajes de registroLos mensajes de registro de todos los componentes de NSX-T, incluidos los que se ejecutan en hosts ESXi, tienen el formato de syslog que se especifica en RFC 5424. Los mensajes de registro provenientes de los hosts de KVM tienen el formato de RFC 3164. Los archivos de registro están en el directorio /var/log.

En los dispositivos de NSX-T, puede ejecutar el siguiente comando de la CLI de NSX-T para ver los registros:

get log-file <auth.log | http.log | kern.log | manager.log | node-mgmt.log | syslog> [follow]

En los hipervisores, puede utilizar comandos de Linux como tac, tail, grep y more para ver los registros. También puede usar estos comandos en los dispositivos de NSX-T.

Para obtener más información sobre RFC 5424, consulte https://tools.ietf.org/html/rfc5424. Para obtener más información sobre RFC 3164, consulte https://tools.ietf.org/html/rfc3164.

RFC 5424 define el siguiente formato para los mensajes de registro:

<facility * 8 + severity> version UTC-TZ hostname APP-NAME procid MSGID [structured-data] msg

Un mensaje de registro de ejemplo:

<187>1 2016-03-15T22:53:00.114Z nsx-manager NSX - SYSTEM [nsx@6876 comp="nsx-manager"

errorCode="MP4039" subcomp="manager"] Connection verification failed for broker '10.160.108.196'.

Marking broker unhealthy.

VMware, Inc. 29

https://tools.ietf.org/html/rfc5424

https://tools.ietf.org/html/rfc3164

Cada mensaje contiene información de componentes (comp) y subcomponentes (subcomp) para ayudar a identificar el origen del mensaje.

NSX-T genera registros regulares (instalaciones local6, que tienen un valor numérico de 22) y registros de auditoría (instalaciones local7, que tienen un valor numérico de 23). Todas las llamadas de API activan un registro de auditoría.

Un registro de auditoría asociado con una llamada de API contiene la siguiente información:

n Un parámetro de ID de entidad entId para identificar el objeto de la API.

n Un parámetro de ID de solicitud req-id para identificar una llamada de API concreta.

n Un parámetro de ID de solicitud externa ereqId si la llamada de API contiene el encabezado X-NSX-EREQID:<string>.

n Un parámetro de usuario externo euser si la llamada de API contiene el encabezado X-NSX-EUSER:<string>.

El formato RFC 5424 define los siguientes niveles de gravedad:

Nivel de gravedad Descripción

0 Emergencia: el sistema no se puede utilizar

1 Alerta: se debe realizar una acción inmediatamente

2 Gravedad: condiciones graves

3 Error: condiciones de error

4 Advertencia: condiciones de advertencia

5 Notificación: indica una condición normal, pero importante

6 Informativo: mensajes informativos

7 Depuración: mensajes de nivel de depuración

Todos los registros con un nivel de gravedad de emergencia, alerta, gravedad o error contienen un código de error único en la parte de datos estructurados del mensaje de registro. El código de error está compuesto por una cadena y un número decimal. La cadena representa un módulo específico.

El campo MSGID identifica el tipo de mensaje. Para ver una lista de los identificadores de mensaje, consulte Identificadores de mensajes de registro.

Configurar registros remotosPuede configurar dispositivos e hipervisores NSX-T para enviar mensajes de registro a un servidor de registro remoto.

El registro remoto es compatible con NSX Manager, NSX Controller, NSX Edge y los hipervisores. Es necesario configurar el registro remoto en cada nodo de forma individual.

En un host de KVM, el paquete de instalación de NSX-T configura automáticamente el daemon rsyslog al colocar los archivos de configuración en el directorio /etc/rsyslog.d.


VMware, Inc. 30

Requisitos previos

n Configure un servidor de registro para recibir los registros.

Procedimiento

1 Para configurar el registro remoto en un dispositivo de NSX-T:

a Ejecute el siguiente comando para configurar un servidor de registro y los tipos de mensajes que se pueden enviar a dicho servidor. Varios recursos o ID de mensajes pueden especificarse en una lista separada por comas, sin espacios.

set logging-server <hostname-or-ip-address[:port]> proto <proto> level <level> [facility

<facility>] [messageid <messageid>] [certificate <filename>] [structured-data <structured-

data>]

Para obtener más información sobre este comando, consulte la referencia de la CLI de NSX-T. Puede ejecutar el comando varias veces para agregar varias configuraciones de servidores de registro. Por ejemplo:

nsx> set logging-server 192.168.110.60 proto udp level info facility syslog messageid

SYSTEM,FABRIC

nsx> set logging-server 192.168.110.60 proto udp level info facility auth,user

b Puede ver la configuración de registro con el comando get logging-server. Por ejemplo,

nsx> get logging-servers

192.168.110.60 proto udp level info facility syslog messageid SYSTEM,FABRIC

192.168.110.60 proto udp level info facility auth,user

2 Para configurar el registro remoto en un host ESXi:

a Ejecute los siguientes comandos para configurar syslog y enviar un mensaje de prueba:

esxcli network firewall ruleset set -r syslog -e true

esxcli system syslog config set --loghost=udp://<log server IP>:<port>

esxcli system syslog reload

esxcli system syslog mark -s "This is a test message"

b Puede ejecutar el siguiente comando para ver la configuración:

esxcli system syslog config get


VMware, Inc. 31

3 Para configurar el registro remoto en un host de KVM:

a Edite el archivo /etc/rsyslog.d/10-vmware-remote-logging.conf para su entorno.

b Agregue la siguiente línea al archivo:

*.* @<ip>:514;RFC5424fmt

c Ejecute el siguiente comando:

service rsyslog restart

Identificadores de mensajes de registroEn un mensaje de registro, el campo de identificador de mensaje identifica el tipo de mensaje. Puede usar el parámetro messageid en el comando set logging-server para filtrar los mensajes de registro que se envían a un servidor de registro.

Tabla 5-1. Identificadores de mensajes de registro

identificador de mensaje Ejemplos

FABRIC Nodo de host

Preparación del host

Nodo de Edge

Zona de transporte

Nodo de transporte

Perfiles de vínculo de carga

Perfiles de clúster

Clúster de Edge

Endpoints y clústeres de puente

SWITCHING Conmutador lógico

Puertos del conmutador lógico

Perfiles de conmutación

Funciones de seguridad del conmutador

ROUTING Enrutador lógico

Puertos del enrutador lógico

Enrutamiento estático

Enrutamiento dinámico

NAT

FIREWALL Reglas de firewall

Secciones de reglas de firewall

FIREWALL-PKTLOG Registros de conexión de firewall

Registros de paquete de firewall


VMware, Inc. 32

Tabla 5-1. Identificadores de mensajes de registro (continuación)

identificador de mensaje Ejemplos

GROUPING Conjuntos de direcciones IP

Conjuntos de direcciones MAC

grupos NSGroup

servicios NSService

Grupos de NSService

Grupo de VNI

Grupo de direcciones IP

DHCP Retransmisión DHCP

SYSTEM Administración de dispositivos (syslog remoto, ntp, etc.)

Administración de clústeres

Administración de confianza

Licencias

Usuarios y funciones

Administración de tareas

Instalar (NSX Manager, NSX Controller)

Actualizar (actualizaciones de paquetes de hosts, NSX Manager, NSX Controller y NSX Edge)

Realización

Etiquetas

MONITORING SNMP

Conexión de puertos

Traceflow

- El resto de los mensajes de registro

Solucionar problemas de syslogSi el servidor de registros remoto no recibe registros, realice los siguientes pasos.

n Compruebe la dirección IP del servidor de registros remoto.

n Verifique que la configuración del parámetro level sea correcta.

n Verifique que la configuración del parámetro facility sea correcta.

n Si el protocolo es TLS, establézcalo como UDP para determinar si hay un error de coincidencia de certificado.

n Si el protocolo es TLS, compruebe que el puerto 6514 esté abierto en ambos extremos.

n Quite el filtro de identificadores de mensajes y compruebe si el servidor recibe registros.

n Reinicie el servicio rsyslog con el comando restart service rsyslogd.


VMware, Inc. 33

Un archivo de configuración de rsyslog de muestra (/etc/rsyslog.conf):

### rsyslog config file. Customized by VMware.

### Do not edit this file by hand. Use the API to make changes.

$PreserveFQDN on

$ModLoad imklog

$ModLoad immark

module(load="imuxsock" sysSock.useSpecialParser="off")

$RepeatedMsgReduction on

$FileOwner syslog

$FileGroup adm

$FileCreateMode 0640

$DirCreateMode 0755

$Umask 0022

$ActionFileDefaultTemplate RSYSLOG_SyslogProtocol23Format

$IncludeConfig /etc/rsyslog.d/*.conf

$template RFC5424fmt,"<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID%

%STRUCTURED-DATA% %msg%\n"

$WorkDirectory /var/spool/rsyslog

$ModLoad imudp

$UDPServerAddress 127.0.0.1

$UDPServerRun 514

$PrivDropToUser syslog

$ActionQueueType LinkedList # nsx exporter: e7347687-8be7-4519-a8e1-73c5192c9b43

*.info @1.2.3.4:514;RFC5424fmt # nsx exporter: e7347687-8be7-4519-a8e1-73c5192c9b43

Comprobación de serviciosLos servicios que dejan de ejecutarse o no logran iniciarse pueden causar problemas. Es importante asegurarse de que todos los servicios se estén ejecutando con normalidad.

Para comprobar el estado del servicio NSX Manager:

nsxmgr> get services

Service name: cm-inventory

Service state: stopped

Service name: http


Session timeout: 1800

Connection timeout: 30

Redirect host: (not configured)

Service name: install-upgrade


Enabled: True

Service name: liagent


Service name: manager


Logging level: info


VMware, Inc. 34

Service name: mgmt-plane-bus

Service state: running

Service name: node-mgmt


Service name: nsx-message-bus


Service name: nsx-upgrade-agent


Service name: ntp


Service name: search


Service name: snmp


Start on boot: False

Service name: ssh


Start on boot: True

Service name: syslog


En el ejemplo anterior, se interrumpe el servicio http. Puede iniciar el servicio HTTP con el siguiente comando:

nsxmgr> start service http

Servicio SSHSi el servicio SSH no se habilitó al implementar el dispositivo, puede iniciar sesión en él como administrador y habilitarlo mediante el siguiente comando:

start service ssh

Puede configurar que SSH se inicie cuando se inicia el host con el siguiente comando:

set service ssh start-on-boot

Para habilitar el inicio de sesión en SSH raíz, puede iniciar sesión en el dispositivo como raíz, editar el archivo /etc/ssh/sshd_config y reemplazar la siguiente línea:

PermitRootLogin prohibit-password


VMware, Inc. 35

Opcionalmente, si desea habilitar el servicio SSH y el acceso de SSH raíz, apague el dispositivo y modifique sus propiedades de vApp.

Con lo siguiente:

PermitRootLogin yes

A continuación, reinicie el servidor sshd con el siguiente comando:

/etc/init.d/ssh restart

Recopilar paquetes de soporteEs posible recopilar paquetes de soporte de los clústeres y nodos de tejido y descargarlos en la máquina o cargarlos a un servidor de archivos.

Si decide descargar los paquetes en la máquina, obtendrá un único archivo de almacenamiento compuesto por un archivo de manifiesto y paquetes de soporte para cada nodo. Si opta por cargar los paquetes a un servidor de archivos, el archivo manifiesto y los paquetes individuales se cargan al servidor de archivos de forma independiente.

NSX Cloud Note Si desea recopilar el paquete de soporte para CSM, inicie sesión en CSM, vaya a Sistema > Utilidades > Paquete de soporte y haga clic en Descargar. El paquete de soporte para PCG está disponible en NSX Manager siguiendo estas instrucciones. El paquete de soporte para PCG también contiene registros para todas las máquinas virtuales de carga de trabajo.

Procedimiento

1 En un explorador, inicie sesión con privilegios de administrador en NSX Manager en https://nsx-manager-ip-address.

2 Seleccione Sistema > Utilidades en el panel de navegación.

3 Haga clic en la pestaña Paquete de soporte.

4 Seleccione los nodos de destino.

Los tipos de nodos disponibles son los nodos de administración, los nodos de controladores, las instancias de Edge, los hosts y las puertas de enlace de nube pública.

5 (opcional) Especifique el número de días de antigüedad del registro para excluir aquellos que sean más antiguos que el número especificado.

6 (opcional) Alterne el conmutador que indica si incluir o excluir archivos básicos y registros de auditoría.

Nota Los archivos básicos y registros de auditoría incluyen información confidencial, como contraseñas o claves cifradas.

7 (opcional) Seleccione una casilla de verificación para cargar los paquetes a un servidor de archivos.


VMware, Inc. 36

8 Haga clic en Iniciar recopilación de paquetes para comenzar a recopilar paquetes de soporte.

En función del número de registros, cada nodo puede tardar varios minutos.

9 Supervise el estado del procedimiento de recopilación.

El campo del estado muestra el porcentaje de nodos que completaron la recopilación de paquetes de soporte.

10 Haga clic en Descargar para descargar el paquete si la opción para enviarlo a un servidor de archivos no está configurada.


VMware, Inc. 37

Otros escenarios de solución de problemas 6Esta sección describe cómo solucionar problemas en diversos escenarios de error.


n Error al agregar o eliminar un nodo de transporte

n El nodo de transporte tarda unos 5 minutos en conectarse a otro controlador

n La máquina virtual de NSX Manager está degradada

n Se agota el tiempo de espera para que el agente NSX se comunique con NSX Manager

n Error al agregar un host ESXi

n Estado incorrecto de NSX Controller

n No se puede tener acceso a direcciones IP de administración en máquinas virtuales de KVM con IPFIX habilitado

Error al agregar o eliminar un nodo de transporteNo se puede eliminar o agregar un nodo de transporte.

Problema

Se produce el error en la siguiente situación:

1 Un host ESXi es un nodo de tejido y un nodo de transporte.

2 El host se elimina como nodo de transporte. Sin embargo, se produce un error en la eliminación del nodo de transporte. El estado del nodo de transporte es Huérfano.

3 El host se elimina inmediatamente como un nodo de tejido.

4 El host se agrega nuevamente como nodo de tejido.

5 El host se agrega como nodo de transporte con una nueva zona de transporte y conmutador. Este paso da como resultado el error Error/parcialmente correcto.

VMware, Inc. 38

Causa

En el paso 2, si espera unos minutos, la eliminación del nodo de transporte se realizará correctamente, porque NSX Manager volverá a intentarla. Cuando se elimina el nodo de tejido inmediatamente, NSX Manager no puede volver a intentarlo, debido a que el host se quitó de NSX-T. Esto da como resultado una limpieza incompleta del host, con la configuración del conmutador aún presente, lo que hace que el paso 5 genere error.

Solución

1 Elimine todos los vmknics de vCenter Server en el host que está conectado al conmutador de NSX-T.

2 Obtenga el nombre del conmutador mediante el comando de la CLI esxcfg-vswitch -l. Por ejemplo:

esxcfg-vswitch -l

Switch Name Num Ports Used Ports Configured Ports MTU Uplinks

vSwitch0 1536 4 128 1500 vmnic0

PortGroup Name VLAN ID Used Ports Uplinks

VM Network 0 0 vmnic0

Management Network 0 1 vmnic0

Switch Name Num Ports Used Ports Uplinks

nsxvswitch 1536 4

3 Elimine el nombre del conmutador mediante el comando de la CLI esxcfg-vswitch -d <switch-name> --dvswitch Por ejemplo:

esxcfg-vswitch -d nsxvswitch --dvswitch

El nodo de transporte tarda unos 5 minutos en conectarse a otro controladorCuando un controlador conectado de un nodo de transporte de ESXi deja de funcionar, el nodo de transporte tarda aproximadamente cinco minutos en conectarse a otro controlador.

Problema

Normalmente, un nodo de transporte de ESXi está conectado a un controlador específico en un clúster de controladores. Puede encontrar el controlador conectado con el comando de la CLI get controllers. Si el controlador conectado deja de funcionar, el nodo de transporte tarda aproximadamente cinco minutos en conectarse a otro controlador.

Causa

El nodo de transporte intenta volver a conectarse durante un tiempo al controlador que está inactivo antes de desistir y conectarse a otro controlador. Todo el proceso tarda aproximadamente cinco minutos. Este es el comportamiento esperado.


VMware, Inc. 39

La máquina virtual de NSX Manager está degradadaLa instancia de NSX Manager que está implementada en un host de KVM devuelve un error al ejecutar comandos de la CLI, como get service y get interface.

Problema

El comando get service de la CLI devuelve un error. Por ejemplo,

nsx-manager-1> get service

% An error occurred while processing the service command

Otros comandos de la CLI también podrían devolver un error. El comando get support-bundle indica que el directorio /tmp pasó a ser de solo lectura. Por ejemplo,

nsx-manager-1> get support-bundle file failed-to-get-service.tgz

% An error occurred while retrieving the support bundle: [Errno 30] Read-only file system: '/tmp/

tmpHzXF1u'

El registro /var/log/mensajes-<timestamp> tiene un mensaje como el siguiente:

Nov 17 07:26:48 no kernel: NMI watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [qemu-kvm:4386]

Causa

Uno o varios sistemas de archivos en el dispositivo de NSX Manager estaban dañados. Algunas de las posibles causas se documentan en https://access.redhat.com/solutions/22621.

Para solucionar el problema, puede reparar los sistemas de archivos dañados o realizar una restauración desde una copia de seguridad.

Solución

1 Opción 1: Reparar los sistemas de archivos dañados. Los siguientes pasos están destinados específicamente a la instancia de NSX Manager que se ejecuta en un host de KVM.

a Ejecute el comando virsh destroy para detener la máquina virtual de NSX Manager.

b Ejecute el comando virt-rescue en modo de escritura en la imagen qcow2. Por ejemplo,

virt-rescue --rw -a nsx-unified-appliance-2.0.0.0.0.6522097.phadniss-p0-DK-to-DGo-on-rhel-

prod_nsx_manager_1.qcow2

c En la línea de comandos virt-rescue, ejecute el comando e2fsck para corregir el sistema de archivos tmp. Por ejemplo,

<rescue> e2fsck /dev/nsx/tmp

d Si es necesario, ejecute nuevamente e2fsck /dev/nsx/tmp hasta que no existan más errores.

e Reinicie NSX Manager con virsh start.


VMware, Inc. 40

https://access.redhat.com/solutions/22621

2 Opción 2: Realizar una restauración desde una copia de seguridad.

Para obtener instrucciones, consulte la Guía de administración de NSX-T.

Se agota el tiempo de espera para que el agente NSX se comunique con NSX ManagerEn un entorno de gran escala con muchos nodos de transporte y máquinas virtuales en hosts ESXi, es posible que se agote el tiempo de espera para que los agentes NSX, que se ejecutan en hosts ESXi, se comuniquen con NSX Manager.

Problema

Algunas operaciones fallan, como cuando un vnic de máquina virtual intenta conectarse a un conmutador lógico. El archivo /var/run/log/nsx-opsagent.log tiene mensajes como el siguiente:

level="ERROR" errorCode="MPA41542"] [MP_AddVnicAttachment] RPC call [0e316296-13-14] to NSX

management plane timout

2017-05-15T05:32:13Z nsxa: [nsx@6876 comp="nsx-esx" subcomp="NSXA[VifHandlerThread:-2282640]"

tid="1000017079" level="ERROR" errorCode="MPA42003"] [DoMpVifAttachRpc] MP_AddVnicAttachment()

failed: RPC call to NSX management plane timout

Causa

En un entorno a gran escala, algunas operaciones podrían tardar más de lo habitual y presentar error debido a que se superan los valores de tiempo de espera predeterminados.

Solución

1 Aumente el valor de tiempo de espera del agente NSX.

a En el host ESXi, detenga el agente NSX opsAgent con el siguiente comando:

/etc/init.d/nsx-opsagent stop

b Edite el archivo /etc/vmware/nsx-opsagent/nsxa.json y cambie el valor de vifOperationTimeout de 25 a, por ejemplo, 55.

"mp" : {

/* timeout for VIF operation */

"vifOperationTimeout" : 25,

Nota Este valor de tiempo de espera debe ser menor que el valor de tiempo de espera de hostd que estableció en el paso 2.

c Inicie el agente NSX opsAgent con el siguiente comando:

/etc/init.d/nsx-opsagent start


VMware, Inc. 41

2 Aumente el valor de tiempo de espera de hostd.

a En el host ESXi, detenga al agente de hostd con el siguiente comando:

/etc/init.d/hostd stop

b Edite el archivo /etc/vmware/hostd/config.xml. En <opaqueNetwork>, quite el comentario de la entrada de <taskTimeout> y cambie el valor de 30 a, por ejemplo, 60.

<opaqueNetwork>









c Inicie al agente de hostd con el siguiente comando:

/etc/init.d/hostd start

Error al agregar un host ESXiNo es posible agregar un host ESXi al tejido de NSX-T.

Problema

En la GUI de NSX Manager, si se agrega un host ESXi, se genera el error A la ruta de acceso de archivo... la reclaman varios VIN sin superposición". El archivo de registro muestra mensajes como el siguiente:

Failed to install software on host. Failed to install software on host. 10.172.120.60 :

java.rmi.RemoteException: [DependencyError] File path of '/usr/lib/vmware/vmkmod/nsx-vsip' is claimed

by multiple non-overlay VIBs

Causa

Algunos VIB desde una instalación anterior todavía están en el host, probablemente debido a que no se produjo una desinstalación completa.

Solución

1 Desde el mensaje de error, obtenga los nombres de VIB que son la causa del error.

2 Utilice los comandos de ESXi para desinstalar los VIB.

Estado incorrecto de NSX ControllerAlgunos controladores en un clúster de NSX Controller informan un estado incorrecto para uno de los controladores.


VMware, Inc. 42

Problema

Después de que un controlador se enciende y se apaga varias veces, los otros controladores informan que está inactivo cuando está en funcionamiento.

Causa

A veces, cuando un controlador se enciende y se apaga, se produce un error interno que involucra al módulo de ZooKeeper, lo que genera un error de comunicación entre este controlador y los otros controladores del clúster.

Solución

u Elimine del clúster el nodo del controlador que se informa que está inactivo, elimine la configuración del clúster desde el nodo y vuelva a unir el nodo al clúster. Para obtener más información, consulte la sección "Reemplazar un miembro del clúster de NSX Controller" en la Guía de administración de NSX-T.

No se puede tener acceso a direcciones IP de administración en máquinas virtuales de KVM con IPFIX habilitadoCuando IPFIX está habilitado en varias máquinas virtuales en un host de KVM y la frecuencia de muestreo es de 100 %, no se puede tener acceso de forma intermitente a las direcciones IP de administración de algunas de las máquinas virtuales.

Problema

Cuando habilita IPFIX para varias máquinas virtuales en el mismo host y establece la frecuencia de muestreo en 100 %, puede haber una gran cantidad de tráfico IPFIX. Esto puede afectar al tráfico de administración, lo que hace que sea imposible acceder de forma intermitente a las direcciones IP de administración, incluso si el tráfico de producción y el de administración pasan por OVS diferentes.

Causa

La carga de trabajo es demasiado estresante para el host y las máquinas virtuales.

Solución

u Reduzca la carga en el host mediante la disminución de la cantidad de máquinas virtuales con IPFIX habilitado o la reducción de la frecuencia de muestreo.


VMware, Inc. 43

Guía de solución de problemas de NSX-T - VMware NSX-T Data ... · Guía de solución de problemas...

Documents

Transcript of Guía de solución de problemas de NSX-T - VMware NSX-T Data ... · Guía de solución de problemas...