grosas's Accepted Solutions

To see the details of what is happening in the management plane during the operation, you  can tail -f /common/log/admin/app.log on the HCX Connector and HCX Cloud Managers.  1. Across both sites you will see the NE bridge become disabled  2a. The destination T1's gateway become connected.  2b. In parallel at the source, the original gateway/SVI etc should be manually disabled.         (this is a coordination with your network team, if you don't control the first hop gateways) 3a. The routing configuration in the new VCF should be able to advertise the newly connected subnet very quickly.  3b. The original route also needs to age out of be removed.  Mileage varies depending on the coordination of the activities and the overall routing configuration.  Recommendation is to run through the process end to end with a test network so you can understand route propagation/age out timings in your environment.  

Hi vmmedmed​ For those to populate correctly, you would need to complete the AD integration on the NSX Manager & add the Virtual Machines to the Activity Monitoring Data Collection Security Group.

Hi ChrisGrahamNoon    We inquired about this internally around May this year - it was said to us that is was planned in NSXv 6.4.  That may have changed - and I cannot speak for that team, but wanted to share my previous run in with this question. I don't know when 6.4 is due for release - Here is the historical cadence of releases, for context.. NSX 6.1 Sept 2014 NSX 6.2 Aug 2015 NSX 6.2.2 Mar 2016 NSX 6.2.3 Jun 2016 NSX 6.2.4 Aug 2016 NSX 6.2.5 05 Jan 2017 NSX 6.3.0 02 Feb 2017 NSX 6.3.1 28 Feb 2017 NSX 6.3.2 08 Jun 2017 NSX 6.3.3 10 Aug 2017 -- Gabe

*Definite* is a strong word to use in this context.  You would want to heavily pre-check and post-health check at each step.  For the NSX Manager component; reverting to a snapshot is very safe.   Edges don't play well with snapshots, if needed, they  be redeployed to the manager version via the redeploy operation.   For the Cluster install / DLR components; from my experience, your best bet honestly is to work through any hiccups.  A good plan B is to be familiar with uninstalling - reinstalling those particular components.

‌You're editing the IP Address on the edge's uplink interface right?    Have you tried configuring the new IP as a secondary IP first, then deleting the original afterwards?  is there a piece of configuration (perhaps the default gateway settings) that rely on the IP address getting deleted? If the suggestions above don't work, you should crack open the NSX manager CLI and (if version<=6.1.x show manager log follow, if >=6.2,  show log manager follow ... Capture the stack trace during the actual failure and post that. HTH

In your one host scenario you may never see encapsulation happening.  The 1600 MTU requirement is for encapsulation to work. I refer you to the following slide (the blue arrow is erroneously pointing to VM3) for an explanation of what happens within your one host. HTH!

The cluster placement is pretty much arbitrary as long as you have sufficient resources and the needed distributed port groups.  It might make sense to stick the DLR control VM with the edges since it is a type of edge appliance... Or it might make sense to move both your DLR and controller cluster into your Management cluster just based on the logical function..  that way the edge gateway data plane workloads haveore dedicated resources. With cluster placement, one's chief concern should be the availability of resources for the workloads placed in the cluster.  Secondarily, maybe prioritize the proximity of very heavy related workloads? Other considerations are really just aesthetic. Maybe it's a good idea to examine the way you carved out the clusters.  What was your goal behind that structure? Does that make sense?

For this: GET https://<vsm-ip>/api/4.0/edges/<edgeId>/sslvpn/config/layout/ PUT https://<vsm-ip>/api/4.0/edges/<edgeId>/sslvpn/config/layout/ Use this: GET https://<vsm-ip>/api/4.0/edges/<edgeId>/sslvpn/config/layout/portal/ PUT https://<vsm-ip>/api/4.0/edges/<edgeId>/sslvpn/config/layout/portal/ One more documentation issue that needs to be filed.

Hi hs77 "Distributed Firewall (DFW) rules are stored where.  Are they stored in NSX Controller or in NSX Manager or on the ESXi hosts."      Rule configuration operations (add, edit, delete, import, export) are all done through the NSX Manager.  Data plane execution of the rules is on the ESXi host, at the VM vNIC.           NSX Controllers are used for virtual network state management (VXLAN, Logical Routing).  They're not utilized with the Distributed Firewall. "Secondly can we use Microsegmentation with DFW without using VXLAN overlays."      Yes definitely.  Rule enforcement will happen regardless of the transport.  If VXLAN is in use, the enforcement will happen prior to encapsulation (or after decapsulation).