Redeploy NSX Edge

If NSX Edge services do not work as expected after a force sync, you can redeploy the NSX Edge instance.

Note: Redeploying is a disruptive action. First apply a force sync and check whether the problem is fixed. It is a good practice to download the tech support bundle for the Edge and troubleshoot the issue. If the problem is still not fixed, then redeploy.

Redeploying an NSX Edge instance results in the following actions:

Edge appliances are deleted and freshly deployed with the latest configuration applied.
Logical routers are deleted from the controller and then recreated with the latest configuration applied.
Distributed logical router instances on hosts are deleted and then recreated with the latest configuration applied.

OSPF adjacencies are withdrawn during redeploy if graceful restart is not enabled.

The following good practices can help in preventing traffic loss when redeploying edges:

Enable graceful restart when OSPF or BGP timers are large and high availability (HA) is enabled on both distributed logical routers (DLR) and edge services gateways (ESG).
Use aggressive OSPF or BGP timer values and floating static routes when a DLR in HA is peered with multiple ESGs (ECMP).

Important: In a cross-vCenter NSX environment, you must first redeploy the NSX Edge instance on the primary NSX Manager. After that is complete, redeploy the NSX Edge instance on the secondary NSX Managers. It is required that the NSX Edge instances on both the primary and the secondary NSX Managers are redeployed.

Prerequisites

Verify that the hosts have enough resources to deploy additional NSX Edge Services Gateway appliances during the redeploy operation. See the System Requirements for NSX Data Center for vSphere for the resources required for each NSX Edge size.
- For a single NSX Edge instance, there are two NSX Edge appliances of the appropriate size in the poweredOn state during redeploy.
- For an NSX Edge instance with high availability enabled, both replacement appliances are deployed before replacing the old appliances. This means that there are four NSX Edge appliances of the appropriate size in the poweredOn state during the upgrade of a given NSX Edge. After the NSX Edge instance is redeployed, either of the HA appliances can become active.

Verify that the host clusters listed in the configured location and live location for the NSX Edge appliances you redeploy are prepared for NSX, and that their messaging infrastructure status is GREEN.

Verify that the host clusters listed in the configured location and live location for all NSX Edge appliances are prepared for NSX and that their messaging infrastructure status is GREEN. If the status is green, the hosts are using the messaging infrastructure to communicate with NSX Manager instead of VIX.
If the configured location is not available, for example, because the cluster has been removed since the NSX Edge appliance was created, then verify the live location only.
- Find the ID of the original configured location (configuredResourcePool > id) and the current live location (resourcePoolId) with the GET https://NSX-Manager-IP-Address/api/4.0/edges/{edgeId}/appliances API request.
- Find the host preparation status and the messaging infrastructure status for those clusters with the GET https://NSX-Manager-IP-Address/api/2.0/nwfabric/status?resource={resourceId} API request, where resourceId is the ID of the configured and live location of the NSX Edge appliances found previously.
  - Look for the status corresponding to the featureId of com.vmware.vshield.vsm.nwfabric.hostPrep in the response body. The status must be GREEN.
```
<nwFabricFeatureStatus>
  <featureId>com.vmware.vshield.vsm.nwfabric.hostPrep</featureId>
  <featureVersion>6.3.1.5124716</featureVersion>
  <updateAvailable>false</updateAvailable>
  <status>GREEN</status>
  <installed>true</installed>
  <enabled>true</enabled>
  <allowConfiguration>false</allowConfiguration>
</nwFabricFeatureStatus>
```
  - Look for the status corresponding to the featureId of com.vmware.vshield.vsm.messagingInfra in the response body. The status must be GREEN.
```
<nwFabricFeatureStatus>
  <featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
  <updateAvailable>false</updateAvailable
  <status>GREEN</status>
  <installed>true</installed>
  <enabled>true</enabled>
  <allowConfiguration>false</allowConfiguration>
</nwFabricFeatureStatus>
```
If the hosts are not prepared for NSX, do the following:
- Navigate to Installation and Upgrade > Host Preparation and prepare the hosts for NSX.
- Verify that the messaging infrastructure is GREEN.
- Redeploy the NSX Edges on the host.

Procedure

Log in to the vSphere Web Client.
Click Networking & Security > NSX Edges.
Select an NSX Edge instance.
Click Actions > Redeploy.
It is a good practice to download the tech support bundle for the Edge and troubleshoot the problem. If the problem persists, redeploy the Edge.

Results

The NSX Edge virtual machine is replaced with a new virtual machine and all services are restored. If redeploy does not work, power off the NSX Edge virtual machine and redeploy NSX Edge again.

Note: Redeploy might not work in the following cases.

The resource pool on which the NSX Edge was installed is no longer in the vCenter inventory or its Managed Object ID (MoId) has changed.
The datastore on which the NSX Edge was installed is corrupted/unmounted or in-accessible.
The dvportGroups on which the NSX Edge interfaces were connected are no longer in the vCenter inventory or their MoId (identifier in vCenter Server) has changed.

If any of these cases is true, you must update the MoId of the resource pool, datastore, or dvPortGroup using a REST API call. See NSX API Guide.

If FIPS mode is enabled on NSX Edge and something goes wrong, NSX Manager does not allow you to redeploy the NSX Edge. You must resolve infrastructure issues for communication failures instead of redeploying the edge.