PowerStore: el nodo de ESXi integrado no puede presentar ninguna terminal de protocolo en PowerStore X
Summary: PowerStore: el nodo de ESXi integrado no puede presentar ninguna terminal de protocolo en PowerStore X
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Symptoms
Cuando la unidad de transmisión máxima (MTU) configurada en los switches Ethernet no es igual o mayor que la MTU configurada en la red de administración de PowerStore, puede causar problemas de administración intermitentes.
En este ejemplo específico, la conectividad de PowerStore X VASA falla solo para uno de los hosts ESXi integrados (host ESXi instalado en el hardware del nodo B)
Cuando se habilitan tramas jumbo (por lo general, un tamaño de MTU de 9,000 bytes), se deben configurar de manera coherente de punto a punto. Los marcos gigantes configurados erróneamente pueden provocar fallas de conexión o un menor rendimiento de E/S.
Asegúrese de que el error en vvold.log sea err=Connection timed out y no err=SSL Exception. Si el error es una excepción de SSL, en su lugar, siga el artículo de la base de conocimientos 67744 de VMware.
Cuando pruebe la conectividad con tramas jumbo, reste el encabezado ICMP de 8 bytes y el tamaño mínimo del encabezado IP de 20 bytes. 9000 - 28 = 8972. Estos 2 encabezados se agregarán automáticamente para aumentar el tamaño del marco.
Estas pruebas de ping se ejecutaron desde una sesión ssh a los hosts ESXi. Consulte el 1003728 de la base de conocimientos de VMware para obtener más información sobre vmkping.
Parece que no podemos hacer ping a través del canal de puerto VLTi. Si los pings se realizan correctamente o no en los ejemplos anteriores, depende de la interfaz de origen que se elija, ya que cada interfaz de origen está conectada a un switch diferente.
En un switch OS10 u OS9 de Dell Networking, la MTU de todas las interfaces conectadas a PowerStore debe establecerse en 9216. El problema se debe a un error de configuración.
Hay un problema en las versiones de OS10 anteriores a 10.5.0 (agosto del 2019) donde el canal de puerto 1000 de la interfaz VLTi no pasa tramas con una MTU mayor que 1500 sin fragmentación. Se espera que de manera predeterminada VLTi transmita marcos de hasta 9216 MTU.
Después de corregir la incompatibilidad de MTU y reexaminar el almacenamiento en el host ESXi, podemos ver todos los terminales de protocolo según lo esperado.
En este ejemplo específico, la conectividad de PowerStore X VASA falla solo para uno de los hosts ESXi integrados (host ESXi instalado en el hardware del nodo B)
Cuando se habilitan tramas jumbo (por lo general, un tamaño de MTU de 9,000 bytes), se deben configurar de manera coherente de punto a punto. Los marcos gigantes configurados erróneamente pueden provocar fallas de conexión o un menor rendimiento de E/S.
Tabla de contenido
1. Problema
Estos errores de conectividad se pueden observar en /var/log/vvold.log del host ESXi afectado:2020-06-24T09:33:08.114Z info vvold[2104948] [Originator@6876 sub=Default] VasaSession::Initialize url is empty 20 20-06-24T09:33:08.114Z advertencia vvold[2104948] [Originator@6876 sub=Default] VasaSession::D oSetContext: ¡URL de VP vacía para VP (PowerStore)! 2020-06-24T09:33:08.114Z info vvold[2104948] [Originator@6876 sub=Default] Inicialización: No se pudo establecer la conexión https://xx.xx.xx.xx:8443/version.xml 2020-06-24T09:33:08.114Z error vvold[2104948] [Originator@6876 sub=Default] Inicialización: No se puede iniciar la sesión en el estado VP de PowerStore: 0 2020-06-24T09:33:08.117Z info vvold[2104947] [Originator@6876 sub=Default] VasaSession::GetEndPoint: with url https://xx.xx.xx.xx:8443/version.xml 2020-06-24T09:34:28.895Z warning vvold[2104947] [Originator@6876 sub=Default] VasaSession::GetEndPoint: failed to get endpoint, err=Connection timed out, con el valor predeterminado 2020-06-24T09:34:28.896Z info vvold[2104947] [Originator@6876 sub=Default] VasaSession::Initialize url is empty
Este es un ejemplo diferente del registro que aparece a continuación desde un sistema diferente. El siguiente registro corresponde a una falla del certificado, el cual es un problema totalmente diferente. Sin embargo, en el ejemplo anterior, se trata de un error de conectividad, aunque las partes más extensas del registro sean idénticas.
Estos errores de certificado se observan en /var/log/vvold.log en un host ESXi diferente para un problema diferente con distintos síntomas:
2019-12-26T16:57:03.396Z info vvold[2139844] [Originator@6876 sub=Default] VasaSession::GetEndPoint: with url https://xxxxxxxx.com:8443/version.xml 2019-12-26T16:57:03.401Z warning vvold[2139844] [Originator@6876 sub=Default] VasaSession::GetEndPoint: failed to get endpoint, err=EXCEPCIÓN SSL: Parámetros de verificación: --> PeerThumbprint: 0B:01:C4:F2:16:E0:10:C9:63:B5:F2:92:D3:36:B5:65:5C:59:DB:17 --> ExpectedThumbprint: --> ExpectedPeerName: xxxxxxxx.com --> El certificado del host remoto tiene los siguientes problemas: --> --> * El nombre de host no coincide con los nombres de asunto en el certificado., con el valor predeterminado 2019-12-26T16:57:03.401Z info vvold[2139844] [Originator@6876 sub=Default] VasaSession::Initialize url is empty 2019-12-26T16:57:03.401Z warning vvold[2139844] [Originator@6876 sub=Default] VasaSession::D oSetContext: ¡URL de VP vacía para VP (xxxxxxxxx)! 2019-12-26T16:57:03.401Z info vvold[2139844] [Originator@6876 sub=Default] Inicialización: No se pudo establecer la conexión https://xxxxxxxx.com:8443/version.xml 2019-12-26T16:57:03.401Z error vvold[2139844] [Originator@6876 sub=Default] Inicialización: No se puede iniciar sesión en el estado xxxxxxxxx del VP: 0
Asegúrese de que el error en vvold.log sea err=Connection timed out y no err=SSL Exception. Si el error es una excepción de SSL, en su lugar, siga el artículo de la base de conocimientos 67744 de VMware.
Cuando pruebe la conectividad con tramas jumbo, reste el encabezado ICMP de 8 bytes y el tamaño mínimo del encabezado IP de 20 bytes. 9000 - 28 = 8972. Estos 2 encabezados se agregarán automáticamente para aumentar el tamaño del marco.
[root@Powerstore1000X-host-2:~] vmkping -I vmk1 1.2.3.4 -s 8972 -c 2 PING 1.2.3.4 (1.2.3.4): 8972 bytes de datos 8980 bytes de 1.2.3.4: icmp_seq=0 ttl=64 time=0.327 ms 8980 bytes de 1.2.2. 3.4: icmp_seq=1 ttl=64 time=0,376 ms --- estadísticas de ping de 1.2.3.4 --- 2 paquetes transmitidos, 2 paquetes recibidos, 0 % de pérdida de paquetes round-trip min/avg/max = 0.327/0.352/0.376 ms [root@Powerstore1000X-host-2:~] vmkping -I vmk1 1.2.3.5 -s 8972 -c 2 PING 1.2.3.5 (1.2.3.5): 8972 bytes de datos --- estadísticas de ping de 1.2.3.5 --- 2 paquetes transmitidos, 0 paquetes recibidos, 100 % de pérdida de paquetes [root@Powerstore1000X-host-2:~] vmkping -I vmk2 1.2.3.5 -s 8972 -c 2 PING 1.2.3.5 (1.2.3.5): 8972 bytes de datos 8980 bytes de 1.2.3.5: icmp_seq=0 ttl=64 time=0.303 ms 8980 bytes de 1.2. 3.5: icmp_seq=1 ttl=64 time=0.411 ms --- estadísticas de ping de 1.2.3.5 --- 2 paquetes transmitidos, 2 paquetes recibidos, 0 % de pérdida de paquetes round-trip min/avg/max = 0.303/0.357/0.411 ms [root@Powerstore1000X-host-2:~] vmkping -I vmk2 1.2.3.4 -s 8972 -c 2 PING 1.2.3.4 (1.2.3.4): 8972 bytes de datos --- estadísticas de ping de 1.2.3.4 --- 2 paquetes transmitidos, 0 paquetes recibidos, 100 % de pérdida de paquetes
Estas pruebas de ping se ejecutaron desde una sesión ssh a los hosts ESXi. Consulte el 1003728 de la base de conocimientos de VMware para obtener más información sobre vmkping.
[root@Powerstore1000X-host-2:~] vmkping -I vmk2 1.2.3.4 -s 1472 -c 2 PING 1.2.3.4 (1.2.3.4): 1472 bytes de datos 1480 bytes de 1.2.3.4: icmp_seq=0 ttl=64 time=0.278 ms 1480 bytes de 1.2.2. 3.4: icmp_seq=1 ttl=64 time=0.296 ms --- estadísticas de ping de 1.2.3.4 --- 2 paquetes transmitidos, 2 paquetes recibidos, 0 % de pérdida de paquetes round-trip min/avg/max = 0.278/0.287/0.296 ms [root@Powerstore1000X-host-2:~] vmkping -I vmk2 1.2.3.5 -s 1472 -c 2 PING 1.2.3.5 (1.2.3.5): 1472 bytes de datos 1480 bytes de 1.2.3.5: icmp_seq=0 ttl=64 time=0.189 ms 1480 bytes de 1.2.2 3.5: icmp_seq=1 ttl=64 time=0.272 ms --- estadísticas de ping de 1.2.3.5 --- 2 paquetes transmitidos, 2 paquetes recibidos, 0 % de pérdida de paquetes round-trip min/avg/max = 0.189/0.231/0.272 ms [root@Powerstore1000X-host-2:~] vmkping -I vmk1 1.2.3.4 -s 1472 -c 2 PING 1.2.3.4 (1.2.3.4): 1472 bytes de datos 1480 bytes de 1.2.3.4: icmp_seq=0 ttl=64 time=0.218 ms 1480 bytes de 1.2. 3.4: icmp_seq=1 ttl=64 time=0.220 ms --- estadísticas de ping de 1.2.3.4 --- 2 paquetes transmitidos, 2 paquetes recibidos, 0 % de pérdida de paquetes round-trip min/avg/max = 0.218/0.219/0.220 ms [root@Powerstore1000X-host-2:~] vmkping -I vmk1 1.2.3.5 -s 1472 -c 2 PING 1.2.3.5 (1.2.3.5): 1472 bytes de datos 1480 bytes de 1.2.3.5: icmp_seq=0 ttl=64 time=0.188 ms 1480 bytes de 1.2.2 3.5: icmp_seq=1 ttl=64 time=0.173 ms --- estadísticas de ping de 1.2.3.5 --- 2 paquetes transmitidos, 2 paquetes recibidos, 0 % de pérdida de paquetes de ida y vuelta mín./promedio/máx. = 0.173/0.180/0.188 ms
Parece que no podemos hacer ping a través del canal de puerto VLTi. Si los pings se realizan correctamente o no en los ejemplos anteriores, depende de la interfaz de origen que se elija, ya que cada interfaz de origen está conectada a un switch diferente.
2. Solución
En un switch OS10 u OS9 de Dell Networking, la MTU de todas las interfaces conectadas a PowerStore debe establecerse en 9216. El problema se debe a un error de configuración.
Hay un problema en las versiones de OS10 anteriores a 10.5.0 (agosto del 2019) donde el canal de puerto 1000 de la interfaz VLTi no pasa tramas con una MTU mayor que 1500 sin fragmentación. Se espera que de manera predeterminada VLTi transmita marcos de hasta 9216 MTU.
SWITCH# ping -M do -s 8972 1.2.3.6 -c 3 PING 1.2.3.6 (1.2.3.6) 8972(9000) bytes de datos. ping: error local: Mensaje demasiado largo, mtu=1500 ping: error local: Mensaje demasiado largo, mtu=1500 ping: error local: Mensaje demasiado largo, mtu=1500 --- estadísticas de ping de 1.2.3.6 --- 3 paquetes transmitidos, 0 recibidos, +3 errores, 100 % de pérdida de paquetes, tiempo 2042ms SWITCH# ping -M do -s 2472 1.2.3.6 -c 3 PING 1.2.3.6 (1.2.3.6) 2472(2500) bytes de datos. ping: error local: Mensaje demasiado largo, mtu=1500 ping: error local: Mensaje demasiado largo, mtu=1500 ping: error local: Mensaje demasiado largo, mtu=1500 --- estadísticas de ping de 1.2.3.6 --- 3 paquetes transmitidos, 0 recibidos, +3 errores, 100 % de pérdida de paquetes, tiempo 2039ms SWITCH# ping -M do -s 1472 1.2.3.6 -c 3 PING 1.2.3.6 (1.2.3.6) 1472(1500) bytes de datos. 1480 bytes from 1.2.3.6: icmp_seq=1 ttl=64 time=1.05 ms 1480 bytes from 1.2.3.6: icmp_seq=2 ttl=64 time=0.966 ms 1480 bytes from 1.2.3.6: icmp_seq=3 ttl=64 time=1.00 ms --- 1.2.3.6 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 0.966/1.008/1.059/0.046 ms SWITCH#
- El switch -s se utiliza para definir el tamaño de la carga útil de la trama
- En la salida anterior, los envíos de un marco con una carga útil de 8972 que correspondan a una MTU de 9000 fallarán.
- Después de esto, se envía una carga útil de 2472 correspondiente a una MTU de 2500 que también falla
- Por último, una carga útil correcta de 1472 correspondiente a una MTU de 1500 no presenta problemas
- En este caso, se confirmó que la ruta de red no podía aceptar un marco con una MTU de más de 1500
- En este ejemplo específico, el problema era que el canal de puerto 1000 VLTi estaba entre dos S4148U-ON debido al problema de OS10 descrito anteriormente.
Después de corregir la incompatibilidad de MTU y reexaminar el almacenamiento en el host ESXi, podemos ver todos los terminales de protocolo según lo esperado.
Cause
NA
Resolution
NA
Affected Products
PowerStoreArticle Properties
Article Number: 000125860
Article Type: Solution
Last Modified: 19 Apr 2021
Version: 5
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.