Dieser Abschnitt erläutert die VMware NSX Edge-Appliance und bietet Informationen zur Fehlerbehebung für diese Appliance.

Um mit der NSX Edge-Appliance auftretende Probleme zu beheben, müssen Sie zunächst prüfen, ob die im Folgenden aufgeführten Schritte zur Fehlerbehebung für Ihre Umgebung relevant sind. Jeder Schritt enthält Anleitungen oder einen Link zu einem Dokument, mit denen Sie mögliche Ursachen beseitigen und korrigierende Maßnahmen wie erforderlich vornehmen können. Die Schritte werden in der für die Isolierung des Problems und für die Ermittlung der entsprechenden Lösung am geeignetsten erscheinenden Reihenfolge aufgeführt. Sie müssen alle Schritte durchführen.

Überprüfen Sie die Versionshinweise für aktuelle Versionen, ob das Problem bereits behoben ist.

Stellen Sie bei der Installation von VMware NSX Edge sicher, dass die Mindestsystemanforderungen erfüllt sind. Weitere Informationen finden Sie unter Installationshandbuch für NSX.

Installations- und Upgrade-Probleme

  • Stellen Sie sicher, dass das aufgetretene Problem kein „Würde blockieren“-Fehler ist. Weitere Informationen finden Sie unter https://kb.vmware.com/kb/2107951.

  • Wenn der Upgrade-Vorgang oder die erneute Bereitstellung erfolgreich durchgeführt wurde, aber keine Konnektivität mit der Edge-Schnittstelle besteht, müssen Sie die Konnektivität auf dem Backend-Schicht 2-Switch überprüfen. Weitere Informationen dazu finden Sie unter https://kb.vmware.com/kb/2135285.

  • Wenn die Bereitstellung oder das Upgrade von Edge mit folgender Fehlermeldung scheitert:

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

    ODER

  • Wenn die Bereitstellung oder das Upgrade erfolgreich ist, aber keine Konnektivität mit den Edge-Schnittstellen vorhanden ist:

  • Die Ausführung des Befehls show interface sowie die Edge-Support-Protokolle stellen Meldungen folgender Art dar:

    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
    

    In beiden Fällen ist der Host-Switch nicht bereit oder weist Probleme auf. Zur Behebung des Problems müssen Sie den Host-Switch überprüfen.

Konfigurationsprobleme

  • Erfassen Sie die Diagnoseinformationen zu NSX Edge. Weitere Informationen dazu finden Sie unter https://kb.vmware.com/kb/2079380.

    Filtern Sie die NSX Edge-Protokolle durch eine Suche nach dem String vse_die. Die Protokollinformationen in der Nähe dieses String enthalten eventuell Informationen über den Konfigurationsfehler.

Firewallprobleme

  • Treten Zeitüberschreitungsprobleme aufgrund von Inaktivität auf und befinden sich die Anwendungen eine Zeit lang im Leerlauf, erhöhen Sie mithilfe der REST-API den Wert für die Zeitüberschreitung durch Inaktivität in den Einstellungen. Weitere Informationen dazu finden Sie unter https://kb.vmware.com/kb/2101275.

Probleme durch das Verwerfen eines Edge-Firewall-Pakets

  1. Überprüfen Sie mit dem Befehl show firewall die Tabelle der Firewallregeln. Die Tabelle usr_rules stellt die konfigurierten Regeln dar.

    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
    

    Prüfen Sie, ob ein inkrementeller Wert einer DROP Invalid-Regel im Abschnitt POST_ROUTING des Befehls show firewall vorhanden ist. Typische Ursachen für diesen Fehler sind Probleme des asymmetrischen Routings oder TCP-basierte Anwendungen, die länger als eine Stunde inaktiv sind. Für Probleme des asymmetrischen Routings sprechen des Weiteren folgende Sachverhalte:

    • Der Ping-Befehl funktioniert nur in einer Richtung

    • Der Ping-Befehl funktioniert, aber nicht TCP

  2. Erfassen Sie die Ausgabe des Befehls 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. Aktivieren Sie mit der REST-API oder mit der Edge-Benutzeroberfläche die Protokollierung für eine bestimmte Firewall und überwachen Sie die Protokolle mit dem Befehl show log follow.

    Wenn keine Protokolle angezeigt werden, aktivieren Sie mithilfe der nachfolgend aufgeführten REST-API die Protokollierung in der DROP Invalid-Regel.

    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
    

    Suchen Sie mit dem Befehl show log follow nach Protokollen folgender Art:

    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. Prüfen Sie mit dem Befehl show flowtable rule_id, ob in der Statustabelle der Edge-Firewall einander entsprechende Verbindungen vorhanden sind:

    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
    

    Vergleichen Sie mit dem Befehl show flowstats die Anzahl der aktiven Verbindungen und die maximal zulässige Anzahl:

    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. Überprüfen Sie mit dem Befehl show log follow die Edge-Protokolle und suchen Sie nach verworfenen ALGs. Suchen Sie nach Strings in der Art von tftp_alg, msrpc_alg oder oracle_tns. Weitere Informationen dazu finden Sie unter:

Probleme der Edge-Routing-Konnektivität

  1. Starten Sie mithilfe des Befehls ping <destination_IP_address> einen gesteuerten Datenverkehr von einem Client.

  2. Erfassen Sie den Datenverkehr gleichzeitig an beiden Schnittstellen, schreiben Sie die Ausgabe in eine Datei und exportieren Sie diese mithilfe von SCP.

    Beispiel:

    Erfassen Sie mit folgendem Befehl den Datenverkehr an der Ingress-Schnittstelle:

    debug packet display interface vNic_0 –n_src_host_1.1.1.1

    Erfassen Sie mit folgendem Befehl den Datenverkehr an der Egress-Schnittstelle:

    debug packet display interface vNic_1 –n_src_host_1.1.1.1

    Für eine gleichzeitige Paketerfassung verwenden Sie das ESXi-Dienstprogramm pktcap-uw zur Paketerfassung in ESXi. Weitere Informationen dazu finden Sie unter https://kb.vmware.com/kb/2051814.

    Tritt das Verwerfen von Paketen dauerhaft auf, prüfen Sie, ob Konfigurationsfehler in folgenden Bereichen aufgetreten sind:

    • IP-Adressen und -Routen

    • Firewallregeln oder NAT-Regeln

    • Asymmetrisches Routing

    • RP-Filterüberprüfungen

    1. Überprüfen Sie mit dem Befehl show interface IP/-Subnetze für Schnittstellen.

    2. Wenn keine Routen auf der Datenebene vorhanden sind, führen Sie folgende Befehle aus:

      • show ip route

      • show ip route static

      • show ip route bgp

      • show ip route ospf

    3. Überprüfen Sie mit dem Befehl show ip forwarding die Routing-Tabelle auf erforderliche Routen.

    4. Wenn Sie über mehrere Pfade verfügen, führen Sie den Befehl show rpfilter aus.

      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
      
      

      Zur Überprüfung der RPF-Statistiken führen Sie den Befehl show rpfstats aus.

      nsxedge> show rpfstats
      RPF drop packet count: 484
      

    Tritt das Verwerfen von Paketen zufällig auf, prüfen Sie, ob Beschränkungen von Ressourcen vorhanden sind:

    1. Für die Nutzung von CPU und Arbeitsspeicher führen Sie folgende Befehle aus:

      • show system cpu

      • show system memory

      • show system storage

      • show process monitor

      • top

        Für ESXi führen Sie den Befehl esxtop n aus.

        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
        
        

Hohe CPU-Nutzung

Wenn Sie eine hohe CPU-Nutzung auf dem NSX Edge feststellen, überprüfen Sie mit dem Befehl esxtop die Leistung der Appliance auf dem ESXi-Host. Zusätzliche Informationen dazu finden Sie in folgenden Knowledgebase-Artikeln:

Weitere Erläuterungen erhalten Sie unter https://communities.vmware.com/docs/DOC-9279.

Ein hoher Wert für den ksoftirqd-Vorgang signalisiert eine hohe Rate eingehender Pakete. Stellen Sie sicher, dass die Protokollierung auf dem Datenpfad, z. B. für Firewallregeln, aktiviert ist. Ermitteln Sie mit dem Befehl show log follow, ob eine große Anzahl an Protokolltreffern ermittelt wurde.

NSX Manager- und Edge-Kommunikationsprobleme

NSX Manager kommuniziert mit NSX Edge über den VIX- oder den Nachrichtenbus. Dieser wird von NSX Manager bei der Edge-Bereitstellung ausgewählt und ändert sich nicht mehr.

Anmerkung:

VIX wird in NSX 6.3.0 und höher nicht unterstützt.

VIX

  • VIX wird für NSX Edge verwendet, wenn der ESXi-Host nicht vorbereitet wurde.

  • Der NSX Manager erhält die Hostanmeldedaten von vCenter Server, um zuerst eine Verbindung mit dem ESXi-Host herzustellen.

  • Der NSX Manager verwendet die Edge-Anmeldedaten für die Anmeldung bei der Edge-Appliance.

  • Der vmtoolsd-Vorgang auf dem Edge steuert die VIX-Kommunikation.

VIX-Fehler können aus folgenden Gründen auftreten:

  • Der NSX Manager kann keine Kommunikation mit dem vCenter Server herstellen.

  • Der NSX Manager kann keine Kommunikation mit den ESXi-Hosts herstellen.

  • NSX Manager weist interne Probleme auf.

  • Edge weist interne Probleme auf.

VIX-Debugging

Überprüfen Sie in den NSX Manager-Protokollen die VIX-Fehler VIX_E_<Fehler>, um die Fehlerursache einzugrenzen. Suchen Sie nach Fehlern folgender Art:

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

Tritt der Fehler zur selben Zeit für verschiedene Edges auf, liegt er im Allgemeinen nicht auf der Seite von Edge.

Edge-Diagnose

  • Überprüfen Sie mit folgendem Befehl, ob vmtoolsd ausgeführt wird:

    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
     ...
    
  • Überprüfen Sie mit folgendem Befehl, ob sich Edge in einem gültigen Zustand befindet:

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

    Darüber hinaus können Sie mit dem Befehl show eventmgr prüfen, ob der Abfragebefehl empfangen und verarbeitet wurde.

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

Edge-Wiederherstellung

Wenn vmtoolsd nicht ausgeführt wird oder sich NSX Edge in einem ungültigen Zustand befindet, starten Sie Edge neu.

Ein Neustart sollte ausreichend sein, um das Edge nach einem Absturz wiederherzustellen. Eine erneute Bereitstellung ist nicht erforderlich.

Anmerkung:

Notieren Sie alle Protokollinformationen aus dem alten Edge, wenn die erneute Bereitstellung abgeschlossen ist.

Für das Debugging eines Kernel-Absturzes ist Folgendes erforderlich:

  • Entweder die vmss-Datei (VM-Anhaltevorgänge) oder die vmsn-Datei (VM-Snapshot) für die Edge-VM im abgestürzten Zustand. Wenn eine vmem-Datei vorhanden ist, ist diese ebenfalls erforderlich. Mit diesen Dateien lässt sich eine Kernel-Core-Dump-Datei extrahieren, die der VMware-Support analysieren kann.

  • Das Edge-Support-Protokoll, das unmittelbar nach dem Neustart des abgestürzten Edge (ohne erneute Bereitstellung) generiert wird. Sie können darüber hinaus die Edge-Protokolle prüfen. Weitere Informationen dazu finden Sie unter https://kb.vmware.com/kb/2079380.

  • Ein Screenshot der Edge-Konsole ist ebenfalls hilfreich, auch wenn dieser in der Regel nicht den vollständige Absturzbericht enthält.

Debugging für den Nachrichtenbus

Der Nachrichtenbus wird für die NSX Edge-Kommunikation verwendet, wenn ESXi-Hosts vorbereitet sind. Beim Auftreten von Problemen können die NSX Manager-Protokolle Einträge folgender Art enthalten:

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

Dieses Problem tritt in folgenden Fällen auf:

  • Edge befindet sich in einem ungültigen Zustand

  • Die Verbindung des Nachrichtenbusses ist unterbrochen

Zur Beurteilung des Problems auf dem Edge führen Sie Folgendes aus:

  • Zur Prüfung der rmq-Konnektivität führen Sie folgenden Befehl aus:

    nsxedge> show messagebus messages
    -----------------------
    Message bus is enabled
    cmd conn state : listening
    init_req       : 1
    init_resp      : 1
    init_req_err   : 0
    ...
    
  • Zur Prüfung der vmci-Konnektivität führen Sie folgenden Befehl aus:

    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
    

    In diesem Beispiel zeigt die Ausgabe vmci_closed_by_peer: 8 an, wie oft die Verbindung durch den Hostagenten getrennt wurde. Nimmt diese Anzahl zu und ist vmci conn inaktiv, kann der Hostagent keine Verbindung mit dem RMQ-Broker herstellen. In show log follow suchen Sie nach wiederholt auftretenden Fehlern in den Edge-Protokollen: VmciProxy: [daemon.debug] VMCI Socket is closed by peer (VMCI-Socket wurde durch den Peer getrennt)

Zur Beurteilung des Problems auf dem ESXi-Host führen Sie Folgendes aus:

  • Zur Überprüfung, ob der ESXi-Host eine Verbindung mit dem RMQ-Broker herstellen kann, führen Sie folgenden Befehl aus:

    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 

Darstellen der Statistiken für verworfene Pakete

Ab der Version NSX for vSphere 6.2.3 können Sie mit dem Befehl show packet drops die Statistiken für verworfene Pakete mit folgenden Elementen anzeigen:

  • Schnittstelle

  • Treiber

  • L2

  • L3

  • Firewall

Zur Ausführung des Befehls melden Sie sich bei der NSX Edge-CLI an und wechseln Sie in den Basismodus. Weitere Informationen dazu finden Sie in der Befehlszeilenschnittstellen-Referenz zu NSX. Beispiel:

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

Erwartetes Verhalten beim Verwalten von NSX Edge

Wenn Sie in vSphere Web Client L2 VPN auf einem NSX Edge konfigurieren und Site-Konfigurationsdetails: (Site Configuration Details) hinzufügen, entfernen oder verändern, werden alle vorhandenen Verbindungen getrennt und erneut wiederhergestellt. Dies ist ein erwartetes Verhalten.