You can upgrade only from version vShield 5.5 to NSX Edge 6.2.x. If you have a prior version of vShield Edge in your infrastructure, you must upgrade to version 5.5 before upgrading to version 6.2.x. For information on upgrading to version 5.5, see vShield Installation and Upgrade Guide version 5.5.
About this task
During the upgrade process, a new Edge virtual appliance is deployed alongside the existing one. When the new Edge is ready, the old Edge's vNICs are disconnected and the new Edge's vNICs are connected. The new Edge then sends gratuitous ARP (GARP) packets to update the ARP cache of connected switches. When HA is deployed, the upgrade process is performed two times.
This process can temporarily affect packet forwarding. You can minimizing the impact by configuring the Edge to work in ECMP mode.
OSPF adjacencies are withdrawn during upgrade if graceful restart is not enabled.
Verify vShield Manager has been upgraded to NSX Manager.
Understand the operational impact of the NSX Edge upgrade while the upgrade is in progress. See Operational Impacts of vCloud Networking and Security Upgrades.
Verify that there is a local segment ID pool, even if you have no plans to create NSX logical switches.
Verify the hosts have enough resources to deploy additional NSX Edge Services Gateway appliances during the upgrade, particularly if you are upgrading multiple NSX Edge appliances in parallel. See the System Requirements for NSX for the resources required for each NSX Edge size.
For a single NSX Edge instance, there will be two NSX Edge appliances of the appropriate size in the poweredOn state during upgrade.
Starting in NSX 6.2.3, when upgrading an NSX Edge instance with high availability, both replacement appliances are deployed before replacing the old appliances. This means there will be four NSX Edge appliances of the appropriate size in the poweredOn state during upgrade of a given NSX Edge. Once the NSX Edge instance is upgraded, either of the HA appliances could become active.
Prior to NSX 6.2.3, when upgrading an NSX Edge instance with high availability, only one replacement appliance is deployed at time while replacing the old appliances. This means there will be three NSX Edge appliances of the appropriate size in the poweredOn state during the upgrade of a given NSX Edge. Once the NSX Edge instance is upgraded, usually the NSX Edge appliance with HA index 0 becomes active.
If you have L2 VPN enabled on an NSX Edge you must delete the L2 VPN configuration before you upgrade. Once you have upgraded, you can reconfigure L2 VPN.
- In the vSphere Web Client, select .
- For each NSX Edge instance, double click the edge and check for the following configuration settings before upgrading.
- Click and check if L2 VPN is enabled. If it is, take note of the configuration details and then delete all L2 VPN configuration.
- Click and check if any static routes are missing a next hop setting. If they are, add the next hop before upgrading the NSX Edge.
- For each NSX Edge instance, select Upgrade Version from the Actions menu.
If the upgrade fails with the error message "Failed to deploy edge appliance," make sure that the host on which the NSX edge appliance is deployed is connected and not in maintenance mode.
After the NSX Edge is upgraded successfully, the Status is Deployed, and the Version column displays the new NSX version.
If an Edge fails to upgrade and does not rollback to the old version, click the Redeploy NSX Edge icon and then retry the upgrade.
NSX Edge firewall rules do not support sourcePort, so vShield Edge version 5.5 rules containing sourcePort are modified during the upgrade as follows.
If there are no applications used in the rule, a service is created with protocol=any, port=any and sourcePort=asDefinedInTheRule.
If there are applications or applicationGroups used in the rule, these grouping objects are duplicated by adding the sourcePort to them. Because of this, the groupingObjectIds used in the firewall rule change after the upgrade.
User firewall rules in NSX Edge 6.x do not generate internal IPSets and applicationSets based on input from REST APIs. Instead they will be retained in the raw format. During upgrade, the internally generated IPSet and applicationSets are used to create rules with raw data. The internal groupingObjects will no longer appear in the user firewallRules
What to do next
Reconfigure any L2 VPN configurations. See L2 VPN Overview in the NSX Installation Guide.