Over the past few weeks, Wissam Mahmassani, Abhinav Mishra, and I have created a few walkthrough videos on setting up Cross-VDC networking inside of vCloud Director 9.5.
Unfamiliar with Cross-VDC networking in vCD? Check out this series of blog posts that review the capabilities and design considerations:
Getting Started with Cross-VDC
Design Considerations and Conclusion
The intent of these videos is to discuss setting up Cross-VDC networking in vCloud Director but also have a live chat on items we’ve learned along the way with working with it. Quite frankly, it was an open discussion between the team on the inner workings on vCD/NSX and what our development team has done in the backend.
Video Walkthrough
In the first video, we discuss the pre-requisites before we can start configuring vCloud Director for Cross-VDC networking. In essence, the assumption is cross-vCenter NSX has already been established and we have the primary and secondary NSX managers registered.
Next, we review the concept of creating a Datacenter group and what are the different egress options. This is very important as it explicitly controls how traffic exits the overlay environment.
Here, we discuss how BGP weights control our active/passive egress points and what vCD automates in the backend. The key is this is all done without provider/tenant configuration – vCD automates this process.
As a final wrap-up of the BGP weights, we review creation of the stretched networks inside of vCloud Director along with operational management inside of the vCD H5 UI.
Last of all, we demonstrate testing of Cross-VDC and failover of my “Daniel-App” between the two sites. What’s interesting is the ability to migrate egress points without any loss of connectivity. Unintended failover is managed by BGP weights, which the default timer is 60 seconds and could be revised if required.
As stated before, this shows the requirement of having a mirror Edge configuration, especially for NAT configuration and failover testing between sites.
This was a fun experience with the team while reviewing and having open discussions on Cross-VDC networking. We are hoping these are valuable for those of you that are interested in bringing this as a new service inside of vCloud Director.
Thanks!
-Daniel
Great Blog posts!
We built that in our LAB. When we create a Datacenter Group on Site-A with one Datacenter from Site-B, shouldn’t the Datacenter Group in Site-B also be displayed?
We can see the datacenter group in vCD Site-A, but in Site-B, Groups are empty?
Hi there, that is to be expected in 9.5 – you will only see the DC Group on the primary site. This is in the backlog to extend the UI capability at secondary sites. Note that you should see this via the API.
-Daniel
Hi,
thanks for your blog post.
Is it possible to add Edge Gateways to this stretched network with services like DHCP or IPSEC?
I can only define a static ip pool, but nothing else on this stretched network.
You need to add edge services at the northbound attached edge. The stretched network does not have this capability as it’s just a logical switch.
Hello Daniel, thanks for your post, I try this with a colleague on a lab and we found that the UDLR used by vCD for tenant deploys a Control VM on primary site but not on secondary site. In the event of a failure how is created this Control VM on secondary site? Is a manual procedure or an automated procedure done by vCD?
Thanks for your help.
Cheers
Hi Nelson, thanks! This would be a manual process as you would need to promote the secondary site as primary. vCD does not automate this today.
HI ,
Thanks for the blog. It is well written. we have a customer that is using the multisite feature in VCD 9.7 and cross nsx is configured. will there be any impact on the customer if we vmotion the UDLR from edge cluster to the production cluster
Hi Maliha, while you might be able to vMotion the UDLR control VM, this breaks the configuration established when setting up the resource path inside of vCloud Director. If redeployed, it will result in the UDLR being deployed to that specific resource pool.
Hi Daniel,
what will happen if we vmotion the UDLR configured through the VCD to another cluster in the vsphere?
will there be any effect or not?
Answered on the other thread. Please configure it with the appropriate resource pool that is desired.
Thanks for the reply. Basically this is the bigger picture
In our environment we have ESXI version 6.5.0 update 13635690 , NSX 6.4.3 and VCD 9.7.0.13634630. We have tenants that are deployed through the VCD. In our production data centre we have two cluster IAASEMEDGE101 and IAASEMPRD101 both have their separate VDS and prepared for the VXLAN traffic respectively. Now the requirement is to have one vDS across both the cluster. As the NSX environment is cross so we are using the UDLR feature from the VCD. The ESG’s are deployed through the VCD and using the external vxlan network that is created on vDS in edge cluster. So in the change the vDS in edge cluster will be unprepared for vxlan, the host uplinks will be connected to the vDS in the payload cluster and then the edge cluster will be again prepared for the vxlan with the vds in the payload cluster
Now the questions related to this change are
1- As it is a cross NSX environment with VCD which site to do first the Primary or the secondary. Keeping in mind that the tenants are deployed through VCD and we are also using the UDLR from the VCD
2- As the VCD is using the external networks which are basically logical switches created on the vds_edge. Can we edit the properties of the external network and change the logical switch that is on the vds_edge to the logical switch which is on the vds_payload. Note: as there is a transport zone that is spanning both the clusters, so when a logical switch is created it is created on both the vDS. ( what will be downtime if the external network is change or impact)
3- Is there any other dependency on the VCD that needs to be looked upon other than the external network and what will be the proper steps to remove the external network dependency in VCD
4- The NSX Edges that are using the vxlan interfaces. What is the proper step to remove the VXLAN dependency either by starting all the configuration from the scratch, or by vmotion to the production cluster, do the change and then vmotion it to the old cluster or by redeploying? Which is the safest method.
5- what will be the effect on the UDLR that is deployed through the VCD how can we vmotion or redeploy to another cluster and what will be the effect on the VCD
6- what will be the effect on the UDLR that is deployed through the VCD how can we vmotion or redeploy to another cluster and what will be the effect on the VCD. The HA status of all the UDLR that are deployed from the down. The UDLR is not active at the secondary site. If we vmotion it to the other cluster what will be the effect and vice versa.
7- Any effect on the transport zone.?
We did this change in our other cloud last year but at that time there were no UDLR configured at that time and no ESG’s were deployed through the VCD. Now this time we have tenants that are deployed through VCD and using UDLR ( which is also configured through the VCD).