This topic provides information for understanding and troubleshooting the VMware NSX Edge.
To troubleshoot issues with an NSX Edge appliance, validate that each troubleshooting step below is true for your environment. Each step provides instructions or a link to a document, to eliminate possible causes and take corrective action as necessary. The steps are ordered in the most appropriate sequence to isolate the issue and identify the proper resolution. Do not skip a step.
Check the release notes for current releases to see if the problem is resolved.
Ensure that the minimum system requirements are met when installing VMware NSX Edge. See the NSX Installation Guide.
Installation and Upgrade issues
Verify that the issue you are encountering is not related to the "Would Block" issue. For more information, see https://kb.vmware.com/kb/2107951.
If the upgrade or redeploy succeeds but there is no connectivity for the Edge interface, verify connectivity on the back-end Layer 2 switch. See https://kb.vmware.com/kb/2135285.
If deployment or upgrade of the Edge fails with the error:
/sbin/ifconfig vNic_1 up failed : SIOCSIFFLAGS: Invalid argument
If the deployment or upgrade succeeds, but there is no connectivity on the Edge interfaces:
Running the show interface command as well as Edge Support logs displays entries similar to:
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 184.108.40.206/23 scope global vNic_0 inet6 fe80::250:56ff:fe32:503/64 scope link tentative dadfailed valid_lft forever preferred_lft forever
In both cases, the host switch is not ready or has some issues. To resolve, investigate the host switch.
Collect the NSX Edge diagnostic information. See https://kb.vmware.com/kb/2079380.
Filter the NSX Edge logs by searching for the string vse_die. The logs near this string might provide information about the configuration error.
High CPU Utilization
If you are experiencing high CPU utilization on the NSX Edge, verify the performance of the appliance using the esxtop command on the ESXi host. Review the following Knowledge Base articles:
A high value for the ksoftirqd process indicates a high incoming packet rate. Check whether logging is enabled on the data path, such as for firewall rules. Run the show log follow command to determine whether a large number of log hits are being recorded.
Displaying Packet Drop Statistics
Starting with NSX for vSphere 6.2.3, you can use the command show packet drops to display packet drop statistics for the following:
To run the command, log in to the NSX Edge CLI and enter basic mode. For more information, see the NSX Command Line Interface Reference. For example:
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
Expected Behavior When Managing NSX Edge
In vSphere Web Client, when you configure L2 VPN on an ESX Edge and add, remove, or modify Site Configuration Details, this action will cause all existing connections to be disconnected and reconnected. This behavior is expected.
NSX Edge is a virtual machine (VM) and consists of several files that are stored on a storage device. The key files are the configuration file, virtual disk file(s), NVRAM setting file, swap file, and log file. Based upon the VM Storage Profile applied or manual placement, the virtual machine configuration files, virtual disk file, swap file can be placed in the same location, or in separate locations on different datastores. In the case where the virtual machine files are present in different locations, NSX Manager shows and uses the datastore which has the VMX file for the VM deployment. During redeployment or upgrade operations, NSX Manager deploys the NSX Edge VM(s) on the configured datastore or the live datastore which hosts the VMX files. The datastore name and the datastore ID (which hosts VMX file of the VM) are returned as part of the
Applianceparameter, and is displayed on the UI or provided as response to REST API. You must refer to vCenter Server for details on the exact layout each of the NSX Manager VM files and one or more datastores where the files are placed. For more information, refer to the following documentation:
vSphere Virtual Machine Administrator .
vSphere Resource Management .
vCenter Server and Host Management .