Esta sección proporciona información para comprender y solucionar los problemas de los dispositivos de VMware NSX Edge.

Para solucionar los problemas con un dispositivo de NSX Edge, compruebe que cada paso especificado a continuación se puede aplicar a su entorno. Cada paso proporciona instrucciones o un enlace a un documento para eliminar posibles causas y realizar las acciones necesarias para corregirlas. Los pasos se ordenan en la secuencia más apropiada para aislar el problema e identificar la solución correcta. No se salte ningún paso.

Revise las notas de las versiones actuales para comprobar si ya se ha resuelto el problema.

Asegúrese que se cumplen los requisitos mínimos del sistema cuando se instale VMware NSX Edge. Consulte la Guía de instalación de NSX.

Problemas de instalación y actualización

  • Compruebe que el problema que se ha encontrado no está relacionado con el problema del "Would Block". Para obtener más información, consulte https://kb.vmware.com/kb/2107951.

  • Si se realiza correctamente la actualización o la reimplementación pero no existe conexión para la interfaz de Edge, compruebe la conectividad en el conmutador de Capa 2 back-end. Consulte https://kb.vmware.com/kb/2135285.

  • Si se produce el siguiente error en la implementación o la actualización de Edge:

    /sbin/ifconfig vNic_1 up failed : SIOCSIFFLAGS: Invalid argument

    O

  • Si se actualiza o se implementa correctamente, pero no hay conexión con las interfaces de Edge:

  • Ejecute el comando show interface si los registros de Edge Suport muestra entradas similares a:

    vNic_0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
        link/ether 00:50:56:32:05:03 brd ff:ff:ff:ff:ff:ff
        inet 21.12.227.244/23 scope global vNic_0
        inet6 fe80::250:56ff:fe32:503/64 scope link tentative dadfailed 
           valid_lft forever preferred_lft forever
    

    En ambos casos, el conmutador del host no está listo o tiene algún problema. Para solucionarlo, revisa el conmutador del host.

Problemas de configuración

  • Recopile la información del diagnóstico de NSX Edge. Consulte https://kb.vmware.com/kb/2079380.

    Filtre los registros de NSX Edge mediante la búsqueda la cadena vse_die. Los registros sobre esta cadena pueden proporcionar información sobre el error en la configuración.

Problemas del Firewall

  • Si existen problemas de tiempo de espera inactivo y observa que las aplicaciones están inactivas durante mucho tiempo, aumente la configuración del tiempo de espera inactivo mediante la API de REST. Consulte https://kb.vmware.com/kb/2101275.

Problemas en la colocación de paquetes del firewall

  1. Compruebe la tabla de reglas del firewall con el comando show firewall. La tabla usr_rules muestra las reglas configuradas.

    nsxedge> show firewall
    Chain PREROUTING (policy ACCEPT 3146M packets, 4098G bytes)
    rid    pkts bytes target     prot opt in     out     source               destination
    
    Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    rid    pkts bytes target     prot opt in     out     source               destination
    0     78903   16M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
    0         0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
    0      140K 9558K block_in   all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     23789 1184K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0      116K 8374K usr_rules  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0         0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0
    
    Chain FORWARD (policy ACCEPT 3146M packets, 4098G bytes)
    rid    pkts bytes target     prot opt in     out     source               destination
    
    Chain OUTPUT (policy ACCEPT 173K packets, 22M bytes)
    rid    pkts bytes target     prot opt in     out     source               destination
    
    Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    rid    pkts bytes target     prot opt in     out     source               destination
    0     78903   16M ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0
    0      679K   41M DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
    0     3146M 4098G block_out  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0         0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in tap0 --physdev-out vNic_+
    0         0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in vNic_+ --physdev-out tap0
    0         0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in na+ --physdev-out vNic_+
    0         0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            PHYSDEV match --physdev-in vNic_+ --physdev-out na+
    0     3145M 4098G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0      221K   13M usr_rules  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0         0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0
    
    Chain block_in (1 references)
    rid    pkts bytes target     prot opt in     out     source               destination
    
    Chain block_out (1 references)
    rid    pkts bytes target     prot opt in     out     source               destination
    
    Chain usr_rules (2 references)
    rid    pkts bytes target     prot opt in     out     source               destination
    131074 70104 5086K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set 0_131074-os-v4-1 src
    131075  116K 8370K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set 1_131075-ov-v4-1 dst
    131073  151K 7844K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0
    

    Revise si hay algún valor aumentado de alguna regla DROP invalid en la sección del comando POST_ROUTING show firewall. Las razones más frecuentes incluyen problemas de rutas asimétricas o aplicaciones basadas en TCP que se han mantenido inactivas durante más de una hora. Entre otras evidencias de problemas de rutas asimétricas podemos ver que:

    • el ping funciona en una dirección pero no en la otra

    • el ping funciona, pero el TCP no

  2. Recopile la salida del comando show ipset.

    nsxedge> show ipset
    Name: 0_131074-os-v4-1
    Type: bitmap:if (Interface Match)
    Revision: 3
    Header: range 0-64000
    Size in memory: 8116
    References: 1
    Number of entries: 1
    Members:
    vse (vShield Edge Device)
    
    Name: 0_131074-os-v6-1
    Type: bitmap:if (Interface Match)
    Revision: 3
    Header: range 0-64000
    Size in memory: 8116
    References: 1
    Number of entries: 1
    Members:
    vse (vShield Edge Device)
    
    Name: 1_131075-ov-v4-1
    Type: hash:oservice (Match un-translated Ports)
    Revision: 2
    Header: family inet hashsize 64 maxelem 65536
    Size in memory: 704
    References: 1
    Number of entries: 2
    Members:
    Proto=6, DestPort=179, SrcPort=Any    (encoded: 0.6.0.179,0.6.0.0/16)
    Proto=89, DestPort=Any, SrcPort=Any    (encoded: 0.89.0.0/16,0.89.0.0/16)
    
    Name: 1_131075-ov-v6-1
    Type: hash:oservice (Match un-translated Ports)
    Revision: 2
    Header: family inet hashsize 64 maxelem 65536
    Size in memory: 704
    References: 1
    Number of entries: 2
    Members:
    Proto=89, DestPort=Any, SrcPort=Any    (encoded: 0.89.0.0/16,0.89.0.0/16)
    Proto=6, DestPort=179, SrcPort=Any    (encoded: 0.6.0.179,0.6.0.0/16)
    
  3. Habilite el registro en una regla del firewall en particular a través de la API de REST o la interfaz del usuario de Edge y supervise los registros con el comando show log follow.

    Si los registros no están visibles, habilítelos en la regla DROP Invalid mediante la siguiente API de REST.

    URL : https://NSX_Manager_IP/api/4.0/edges/{edgeId}/firewall/config/global
    
    PUT Method 
    Input representation 
    <globalConfig>   <!-- Optional -->
    <tcpPickOngoingConnections>false</tcpPickOngoingConnections>   <!-- Optional. Defaults to false -->
    <tcpAllowOutOfWindowPackets>false</tcpAllowOutOfWindowPackets>    <!-- Optional. Defaults to false -->
    <tcpSendResetForClosedVsePorts>true</tcpSendResetForClosedVsePorts>    <!-- Optional. Defaults to true -->
    <dropInvalidTraffic>true</dropInvalidTraffic>    <!-- Optional. Defaults to true -->
    <logInvalidTraffic>true</logInvalidTraffic>     <!-- Optional. Defaults to false -->
    <tcpTimeoutOpen>30</tcpTimeoutOpen>       <!-- Optional. Defaults to 30 -->
    <tcpTimeoutEstablished>3600</tcpTimeoutEstablished>   <!-- Optional. Defaults to 3600 -->
    <tcpTimeoutClose>30</tcpTimeoutClose>   <!-- Optional. Defaults to 30 -->
    <udpTimeout>60</udpTimeout>             <!-- Optional. Defaults to 60 -->
    <icmpTimeout>10</icmpTimeout>           <!-- Optional. Defaults to 10 -->
    <icmp6Timeout>10</icmp6Timeout>           <!-- Optional. Defaults to 10 -->
    <ipGenericTimeout>120</ipGenericTimeout>    <!-- Optional. Defaults to 120 -->
    </globalConfig>
    Output representation 
    No payload
    

    Utilice el comando show log follow para buscar registros similares a:

    2016-04-18T20:53:31+00:00 edge-0 kernel: nf_ct_tcp: invalid TCP flag combination IN= OUT= 
    SRC=172.16.1.4 DST=192.168.1.4 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=43343 PROTO=TCP 
    SPT=5050 DPT=80 SEQ=0 ACK=1572141176 WINDOW=512 RES=0x00 URG PSH FIN URGP=0
    2016-04-18T20:53:31+00:00 edge-0 kernel: INVALID IN= OUT=vNic_1 SRC=172.16.1.4 
    DST=192.168.1.4 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=43343 PROTO=TCP SPT=5050 DPT=80 
    WINDOW=512 RES=0x00 URG PSH FIN URGP=0
    

  4. Compruebe las conexiones coincidentes en la tabla de estado del firewall de Edge con el comando show flowtable rule_id:

    nsxedge> show flowtable
    1: tcp  6 21554 ESTABLISHED src=192.168.110.10 dst=192.168.5.3 sport=25981 
    d port=22 pkts=52 bytes=5432 src=192.168.5.3 dst=192.168.110.10 sport=22 dport=259 
    81 pkts=44 bytes=7201 [ASSURED] mark=0 rid=131073 use=1
    2: tcp  6 21595 ESTABLISHED src=127.0.0.1 dst=127.0.0.1 sport=53194 
    dport=10 001 pkts=33334 bytes=11284650 src=127.0.0.1 dst=127.0.0.1 sport=10001 dport=5319 
    4 pkts=33324 bytes=1394146 [ASSURED] mark=0 rid=0 use=1
    

    Compare el número de conexiones activas y el número máximo permitido con el comando show flowstats:

    nsxedge> show flowstats
    Total Flow Capacity: 65536
    Current Statistics :
    cpu=0 searched=3280373 found=3034890571 new=52678 invalid=659946 ignore=77605 
    delete=52667 delete_list=49778 insert=49789 insert_failed=0 drop=0 early_drop=0 
    error=0 search_restart=0
    

  5. Compruebe los registros de Edge con el comando show log follow y busque cualquier colocación ALG. Busque cadenas similares a tftp_alg, msrpc_alg u oracle_tns. Para obtener información adicional, consulte:

Problemas de conectividad en red de Edge

  1. Inicie el tráfico controlado para un cliente utilizando el comando ping <destination_IP_address>.

  2. Capture el tráfico de forma simultánea en ambas interfaces, registre la salida en un archivo y expórtelo a través de SCP.

    Por ejemplo:

    Capte el tráfico en la interfaz de ingreso con este comando:

    debug packet display interface vNic_0 –n_src_host_1.1.1.1

    Capte el tráfico en la interfaz de salida con este comando:

    debug packet display interface vNic_1 –n_src_host_1.1.1.1

    Para captura de paquetes simultáneas, utilice la herramienta de captura de paquetes pktcap-uw en ESXi. Consulte https://kb.vmware.com/kb/2051814.

    Si la colocación de paquetes es constante, revise los errores de la configuración relacionados con:

    • la dirección y las rutas IP

    • las reglas de firewall o de NAT

    • las rutas asimétricas

    • las comprobaciones de los filtros RP

    1. Compruebe las interfaces de la IP y de las subredes con el siguiente comando show interface.

    2. Si no se encuentran algunas rutas en el plano de datos, ejecute los siguientes comandos:

      • show ip route

      • show ip route static

      • show ip route bgp

      • show ip route ospf

    3. Ejecute el comando show ip forwarding para revisar la tabla de enrutamiento para las rutas necesarias.

    4. Si tiene varias rutas, ejecute el comando show rpfilter.

      nsxedge> show rpfilter
      net.ipv4.conf.VDR.rp_filter = 0
      net.ipv4.conf.all.rp_filter = 0
      net.ipv4.conf.br-sub.rp_filter = 1
      net.ipv4.conf.default.rp_filter = 1
      net.ipv4.conf.lo.rp_filter = 0
      net.ipv4.conf.vNic_0.rp_filter = 1
      net.ipv4.conf.vNic_1.rp_filter = 1
      net.ipv4.conf.vNic_2.rp_filter = 1
      net.ipv4.conf.vNic_3.rp_filter = 1
      net.ipv4.conf.vNic_4.rp_filter = 1
      net.ipv4.conf.vNic_5.rp_filter = 1
      net.ipv4.conf.vNic_6.rp_filter = 1
      net.ipv4.conf.vNic_7.rp_filter = 1
      net.ipv4.conf.vNic_8.rp_filter = 1
      net.ipv4.conf.vNic_9.rp_filter = 1
      
      nsxedge> show rpfstats
      RPF drop packet count: 484
      
      

      Para revisar las estadísticas de RPF, ejecute el comando show rpfstats.

      nsxedge> show rpfstats
      RPF drop packet count: 484
      

    Si la colocación de paquetes aparece de forma aleatoria, compruebe las limitaciones del recurso:

    1. Para la CPU o el uso de la memoria, ejecute los siguientes comandos:

      • show system cpu

      • show system memory

      • show system storage

      • show process monitor

      • top

        Para ESXi, ejecute el comando esxtop n.

        PCPU USED(%): 2.5 5.0 3.7  77 AVG:  22
        PCPU UTIL(%): 0.5 2.7 3.3  92 AVG:  24
        
              ID      GID NAME             NWLD   %USED    %RUN    %SYS   %WAIT          
        98255269 98255269 esxtop.11224149     1   67.04   69.86    0.00    6.26       
               2        2 system            139    3.03    4.61    0.00 12053.58    
           86329    86329 app-01a             6    0.69    0.57    0.00  466.09    
           78730    78730 db-01a              6    0.48    0.67    0.00  441.44     
           90486    90486 app-02a             6    0.38    0.32    0.00  463.42      
            
         %VMWAIT    %RDY    %IDLE    %OVRLP    %CSTP   %MLMTD    %SWPWT
         11.01       -    0.39    0.00    0.09    0.00    0.00    0.00
         600.00   53.81    0.10   93.13    0.00    0.00    0.00    0.00
         13900.00       -   28.68    0.00    2.69    0.00    0.00    0.00
         600.00   53.81    0.10   93.13    0.00    0.00    0.00    0.00
         600.00    0.00    0.19  151.92    0.00    0.00    0.00    0.00
        
        

Uso elevado de CPU

Si está sometiendo a su CPU a un uso elevado en NSX Edge, compruebe el rendimiento del dispositivo mediante el comando esxtop en el host ESXi. Revise los siguientes artículos de la base de conocimientos:

Consulte también https://communities.vmware.com/docs/DOC-9279.

Un valor alto en el proceso ksoftirqd indica un valor alto del paquete de entrada. Revise si el registro está habilitado en la ruta de datos así como para reglas del firewall. Ejecute el comando show log follow para determinar si se están almacenando un gran número de registros.

Problemas de comunicación de NSX Manager y Edge

NSX Manager se comunica con NSX Edge a través de VIX o mensajería bus. NSX Manager lo elige cuando el Edge se implementa y nunca cambia.

Nota:

VIX no es compatible con NSX 6.3.0 y versiones posteriores.

VIX

  • VIX se usa para NSX Edge si el host ESXi no está preparado.

  • NSX Manager obtiene credenciales de los hosts desde vCenter Server para conectarse primero al host ESXi.

  • NSX Manager usa las credenciales de Edge para iniciar sesión en el dispositivo Edge.

  • El proceso vmtoolsd de Edge gestiona la comunicación VIX.

Los errores de VIX se producen por los siguientes motivos:

  • NSX Manager no se puede comunicar con vCenter Server.

  • NSX Manager no se puede comunicar con el host ESXi.

  • Existen problemas internos en NSX Manager.

  • Existen problemas internos en Edge.

Depuración de VIX

Revise los errores de VIX VIX_E_<error> en los registros de NSX Manager para delimitar la causa. Busque errores similares a los siguientes:

Vix Command 1126400 failed, reason com.vmware.vshield.edge.exception.VixException: vShield 
Edge:10013:Error code 'VIX_E_FILE_NOT_FOUND' was returned by VIX API.:null

Health check failed for edge  edge-13 VM vm-5025 reason: 
com.vmware.vshield.edge.exception.VixException: vShield Edge:10013:Error code 
'VIX_E_VM_NOT_RUNNING' was returned by VIX API.:null

En general, si se reproduce el fallo en varios dispositivos Edge al mismo tiempo, el problema no está en Edge.

Diagnóstico de Edge

  • Compruebe si se está ejecutando vmtoolsd con el siguiente comando:

    nsxedge> show process list
    Perimeter-Gateway-01-0> show process list
    %CPU %MEM    VSZ   RSZ STAT  STARTED     TIME COMMAND
     0.0  0.1   4244   720 Ss     May 16 00:00:15 init [3]
    ...
     0.0  0.1   4240   640 S      May 16 00:00:00 logger -p daemon debug -t vserrdd
     0.2  0.9  57192  4668 S      May 16 00:23:07 /usr/local/bin/vmtoolsd --plugin-pa
     0.0  0.4   4304  2260 SLs    May 16 00:01:54 /usr/sbin/watchdog
     ...
    
  • Compruebe si Edge está en buen estado ejecutando este comando:

    nsxedge> show eventmgr
    -----------------------
    messagebus     : enabled
    debug          : 0
    profiling      : 0
    cfg_rx         : 1
    cfg_rx_msgbus  : 0
    ...
    

    Del mismo modo, se puede utilizar el comando show eventmgr para comprobar que el comando de consulta se recibió y se está procesando.

    nsxedge> show eventmgr
    -----------------------
    messagebus     : enabled
    debug          : 0
    profiling      : 0
    cfg_rx         : 1
    cfg_rx_msgbus  : 0
    cfg_rx_err     : 0
    cfg_exec_err   : 0
    cfg_resp       : 0
    cfg_resp_err   : 0
    cfg_resp_ln_err: 0
    fastquery_rx : 0 fastquery_err : 0
    clearcmd_rx    : 0
    clearcmd_err   : 0
    ha_rx          : 0
    ha_rx_err      : 0
    ha_exec_err    : 0
    status_rx      : 16
    status_rx_err  : 0
    status_svr     : 10
    status_evt     : 0
    status_evt_push: 0
    status_ha      : 0
    status_ver     : 1
    status_sys     : 5
    status_cmd     : 0
    status_svr_err : 0
    status_evt_err : 0
    status_sys_err : 0
    status_ha_err  : 0
    status_ver_err : 0
    status_cmd_err : 0
    evt_report     : 1
    evt_report_err : 0
    hc_report      : 10962
    hc_report_err  : 0
    cli_rx         : 2
    cli_resp       : 1
    cli_resp_err   : 0
    counter_reset  : 0
    ---------- Health Status -------------
    system status  : good
    ha state       : active
    cfg version    : 7
    generation     : 0
    server status  : 1
    syslog-ng      : 1
    haproxy        : 0
    ipsec          : 0
    sslvpn         : 0
    l2vpn          : 0
    dns            : 0
    dhcp           : 0
    heartbeat      : 0
    monitor        : 0
    gslb           : 0
    ---------- System Events -------------
    

Recuperación de Edge

Si el comando vmtoolsd no se ejecuta o NSX Edge está en mal estado, reinicie Edge.

Para recuperarse de un bloqueo, debería bastar con reiniciarlo. No debería ser necesario volver a implementarlo.

Nota:

Anote toda la información de registro de la implementación anterior de Edge cuando realice una nueva implementación.

Para depurar un bloqueo del kernel, debe obtener:

  • El archivo vmss (suspensión máquina virtual) o vmsn (instantánea de máquina virtual) para la máquina virtual de Edge mientras siga estando bloqueada. Si hay un archivo vmem, también será necesario. Esto se puede utilizar para extraer un archivo de volcado de núcleo de kernel que el soporte técnico de VMware pueda analizar.

  • El registro de soporte técnico de Edge, generado justo después de que el Edge bloqueado se reiniciara (pero sin que se volviera a implementar). También puede comprobar los registros de Edge. Consulte https://kb.vmware.com/kb/2079380.

  • Una instantánea de la consola de Edge también sería útil, aunque esto no suele incluir el informe de errores completo.

Depuración de mensajería bus

La mensajería bus se utiliza para la comunicación de NSX Edge cuando el host ESXi está preparado. Cuando se encuentra algún problema, los registros de NSX Manager deben tener entradas similares a:

GMT ERROR taskScheduler-6 PublishTask:963 - Failed to configure VSE-vm index 0, vm-id vm-117, 
edge edge-5. Error: RPC request timed out

Este problema ocurre si:

  • Edge está en mal estado

  • se perdió la conexión de la mensajería bus

Para diagnosticar el problema en Edge:

  • Para comprobar la conexión mq, ejecute este comando:

    nsxedge> show messagebus messages
    -----------------------
    Message bus is enabled
    cmd conn state : listening
    init_req       : 1
    init_resp      : 1
    init_req_err   : 0
    ...
    
  • Para comprobar la conexión vmci, ejecute este comando:

    nsxedge> show messagebus forwarder
    -----------------------
    Forwarder Command Channel
    vmci_conn          : up
    app_client_conn    : up
    vmci_rx            : 3649
    vmci_tx            : 3648
    vmci_rx_err        : 0
    vmci_tx_err        : 0
    vmci_closed_by_peer: 8
    vmci_tx_no_socket  : 0
    app_rx             : 3648
    app_tx             : 3649
    app_rx_err         : 0
    app_tx_err         : 0
    app_conn_req       : 1
    app_closed_by_peer : 0
    app_tx_no_socket   : 0
    -----------------------
    Forwarder Event Channel
    vmci_conn          : up
    app_client_conn    : up
    vmci_rx            : 1143
    vmci_tx            : 13924
    vmci_rx_err        : 0
    vmci_tx_err        : 0
    vmci_closed_by_peer: 0
    vmci_tx_no_socket  : 0
    app_rx             : 13924
    app_tx             : 1143
    app_rx_err         : 0
    app_tx_err         : 0
    app_conn_req       : 1
    app_closed_by_peer : 0
    app_tx_no_socket   : 0
    -----------------------
    cli_rx             : 1
    cli_tx             : 1
    cli_tx_err         : 0
    counters_reset     : 0
    

    En el ejemplo, la salida vmci_closed_by_peer: 8 indica el número de veces que el agente host cerró la conexión. Si el número está aumentando y la vmci conn está baja, el agente host no puede conectarse al agente RMQ. En show log follow, busque errores repetidos en los registros de Edge: VmciProxy: [daemon.debug] VMCI Socket is closed by peer

Para diagnosticar el problema el host ESXi:

  • Para comprobar si el host ESXi se conecta al agente RMQ, ejecute el siguiente comando:

    esxcli network ip connection list | grep 5671
    
    tcp   0   0  10.32.43.4:43329  10.32.43.230:5671    ESTABLISHED     35854  newreno  vsfwd          
    tcp   0   0  10.32.43.4:52667  10.32.43.230:5671    ESTABLISHED     35854  newreno  vsfwd          
    tcp   0   0  10.32.43.4:20808  10.32.43.230:5671    ESTABLISHED     35847  newreno  vsfwd          
    tcp   0   0  10.32.43.4:12486  10.32.43.230:5671    ESTABLISHED     35847  newreno  vsfwd 

Mostrar estadísticas de colocación de paquetes

A partir de NSX for vSphere 6.2.3, puede utilizar el comando show packet drops para mostrar las estadísticas de colocación de paquetes en los siguientes elementos:

  • Interfaz

  • Controlador

  • Capa 2

  • Capa 3

  • Firewall

Para ejecutar el comando, inicie sesión en la CLI de NSX Edge e introduzca el modo básico. Para obtener más información, consulte la Referencia de la interfaz de línea de comandos de NSX. Por ejemplo:

show packet drops

vShield Edge Packet Drop Stats:

Driver Errors
=============
          TX      TX    TX   RX   RX      RX
Interface Dropped Error Ring Full Dropped Error Out Of Buf
vNic_0    0       0     0    0    0       0
vNic_1    0       0     0    0    0       0
vNic_2    0       0     0    0    0       2
vNic_3    0       0     0    0    0       0
vNic_4    0       0     0    0    0       0
vNic_5    0       0     0    0    0       0

Interface Drops
===============
Interface RX Dropped TX Dropped
vNic_0             4          0
vNic_1          2710          0
vNic_2             0          0
vNic_3             2          0
vNic_4             2          0
vNic_5             2          0

L2 RX Errors
============
Interface length crc frame fifo missed
vNic_0         0   0     0    0      0
vNic_1         0   0     0    0      0
vNic_2         0   0     0    0      0
vNic_3         0   0     0    0      0
vNic_4         0   0     0    0      0
vNic_5         0   0     0    0      0

L2 TX Errors
============
Interface aborted fifo window heartbeat
vNic_0          0    0      0         0
vNic_1          0    0      0         0
vNic_2          0    0      0         0
vNic_3          0    0      0         0
vNic_4          0    0      0         0
vNic_5          0    0      0         0

L3 Errors
=========
IP:
 ReasmFails : 0
 InHdrErrors : 0
 InDiscards : 0
 FragFails : 0
 InAddrErrors : 0
 OutDiscards : 0
 OutNoRoutes : 0
 ReasmTimeout : 0
ICMP:
 InTimeExcds : 0
 InErrors : 227
 OutTimeExcds : 0
 OutDestUnreachs : 152
 OutParmProbs : 0
 InSrcQuenchs : 0
 InRedirects : 0
 OutSrcQuenchs : 0
 InDestUnreachs : 151
 OutErrors : 0
 InParmProbs : 0

Firewall Drop Counters
======================

Ipv4 Rules
==========
Chain - INPUT
rid pkts bytes target prot opt in out source    destination
0    119 30517 DROP   all  --   *   * 0.0.0.0/0 0.0.0.0/0    state INVALID
0      0     0 DROP   all  --   *   * 0.0.0.0/0 0.0.0.0/0
Chain - POSTROUTING
rid pkts bytes target prot opt in out source    destination
0    101 4040  DROP   all   --  *   * 0.0.0.0/0 0.0.0.0/0    state INVALID
0      0    0  DROP   all   --  *   * 0.0.0.0/0 0.0.0.0/0

Ipv6 Rules
==========
Chain - INPUT
rid pkts bytes target prot opt in out source destination
0      0     0   DROP  all      *   * ::/0   ::/0            state INVALID
0      0     0   DROP  all      *   * ::/0   ::/0
Chain - POSTROUTING
rid pkts bytes target prot opt in out source destination
0      0     0   DROP  all       *   * ::/0   ::/0           state INVALID
0      0     0   DROP  all       *   * ::/0   ::/0

Comportamiento previsto cuando se administra NSX Edge

En vSphere Web Client, cuando configura una VPN de Capa 2 en una instancia de NSX Edge y agrega, elimina o modifica los Detalles de configuración del sitio (Site Configuration Details), esta acción hará que todas las conexiones existentes se desconecten y se vuelvan a conectar. Este comportamiento es correcto.