I’ve been rebuilding my vCloud Director (vCD) lab and running through a few connectivity scenarios. Moreover, I wanted to write and share my findings on orchestrating an on-prem NSX environment connecting to a vCD/Provider environment using vCloud Director Extender (VXLAN to VXLAN). In vCD Extender, this is also known as a DC Extension.
To back up, let’s talk about how NSX provides flexible architecture as it relates to Provider scalability and connectivity. My esteemed colleagues did some great papers from our vCloud Architecture Toolkit (vCAT):
Before I get started, I also think this is a good guide for planning out VXLAN <–> VXLAN VPN connectivity.
Let’s look at my lab design from a network / logical perspective –
As you can see above, I have my Acme-Cloud organization available on the left with a single VM in the 172.16.20.x/24 network that’s running on NSX/VXLAN.
On the right, we have “Acme DC” that’s also using NSX and has a logical switch named “Acme-Tier” with the same network subnet.
The orange Extender Deployed L2VPN Client is what’s deployed by vCD Extender on tunnel creation. We’re going to walk through how Extender creates this L2VPN tunnel within an on-prem NSX environment.
This is very similar to my warm migration setup, so I’m going to try not to duplicate material.
I have my Acme-Cloud-Tier Org VDC Network that was converted to a Subinterface inside of vCD:
We can see in the Edge Services, my L2VPN Server has been set up with a default site configuration. However, vCD Extender creates its own site configuration –
Extender generates a unique ID for the username and password. This is done when the DC Extension is executed by the tenant. I also established the egress optimization gateway address for local traffic.
Tenant – vCD Extender Setup
Before we can create a Data Center Extension, we need two required fields for NSX deployments.
First, we need to give the required information to successfully deploy a standalone Edge that will be running our L2VPN client service. This would include the uplink network along with an IP address, gateway, and VMware-specific host/storage information.
Second, we need to provide the required NSX Manager information. I’m sure this is to make the API calls required to deploy the Edge device(s) to the specified vCenter.
Once the DC Extension has been created, we would see a new Edge device under Networking & Security
Tenant – DC Extension (L2VPN) Execution
So what happens when we attempt to create a new DC Extension (or L2VPN Connection)? A few things:
Creation of our trunk port for our specified subinterface
Deployment of the new Edge device that will act as the L2VPN Client
Reconfiguration of the trunk port (uses mcxt-tpg-l2vpn-vxlan-** prefix)
Allowing NSX to do its magic along with L2VPN
We can see within my task console what happened –
Voila, we have a connected L2VPN tunnel. As you can see, the blue “E” stipulates that we have a local egress IP set. I did this since I wanted to route traffic to its local interface for traffic optimization.
So, what happens in the background? Well, let’s take a look at the Edge device. We can see the trunk interface was created while the subinterface is configured to point to my logical switch “Acme-Tier.”
Last of all, the L2VPN configuration was completed and established as the Client. We can now see the tunnel is alive too.
From the main vCD Extender page, we can also see traffic utilization over the tunnel. Pretty nice graph!
Just a quick ping test, yep! WebVM can access WebVM2.
In summary, NSX to NSX DC Extensions within vCD Extender works pretty similar to Provider/VXLAN to On-Prem/VLAN. The key difference is the on-prem vCD Extender has the embedded Standalone Edge to deploy to vCenter.
I am happy to state that I passed my VCAP-NV and will be achieving VCIX6-NV.
This was an exhausting test – and sometimes frustrating. I even had a PSOD on one of my hosts that I had to resolve (pretty sure that was not part of the lab test)!
I have many people to thank but there have been some great guides out there. I posted a blog article on links I collected for preparing for my VCAP-NV.
I’ll be the first to admit this was my second attempt at my VCAP-NV: the first attempt one just got to me. Not to make any excuses, but my background isn’t networking/routing, so many of these topics were green to me.
I dusted myself off and said I’ll knock the second attempt out of the park. As you can see, VMware does document the blueprint objectives you missed on the test.
So what did I do? Before I start that, here’s a summary of my experience:
This test will frustrate you. Yes, it is meant to. Accept it and embrace it.
It is a nested vPOD/Lab environment. ProTip – for East Coasters, schedule your test first thing in the morning before the West starts working – much more responsive!
It will attempt to confuse you. Take a deep breath and look at the overall question – what are you trying to accomplish?
Also, sometimes the simplest answer is all you need. Don’t overcomplicate things (I have a tendency to do this).
Do not spend too much time on a specific problem. If it’s not working as expected, make a note of it and move on.
This was my problem with the first attempt. I spent too much time on a specific set of questions and ran out of time.
Stay true to the Blueprint. If you practice and study using its guidelines, you will be okay.
First off, I wrote the entire Blueprint on my whiteboard with the main tasks. Excuse my handwriting, but you get the gist of what I was trying to accomplish here. I notated how many times I did a specific item.
After I didn’t make it the first attempt, I circled the sections I missed in black (even though half of them were because I just ran out of time). These were areas I focused on for the second attempt.
Lab, lab, and lab. This is a test you cannot dump your way through. I don’t see how it would be possible to pass this without hands-on experience, especially with routing protocols and how NSX interacts with them.
Labs of Focus
The VMware Hands-On Labs (HOL) is FREE! You would be crazy for not using these and getting some insight/guidance on how things work. I primarily used the 1803 and 1825 labs on VMware HOL – link here.
I thought Clinton’s VCAP6-NV was the most comprehensive guide out there. I used this as a rule of thumb and mimicked many of the things he documented in his blog series. DEFINITELY spend some time here.
There are probably others I’m missing, but definitely leverage what’s out in the community – thank you to those of you that have published and spent a significant amount of time documenting!
Practice and get involved. Read all of the publications out there on VMware’s site. Build out designs for customers. This will take time but provides further exposure and compounding of the topics.
Break stuff. You need to see how NSX works when you start “pulling cables” if you will. I spent countless hours just doing this. There are several troubleshooting topics so you’ll need to understand what happens when things go awry.
What’s next? I will continue to focus on VMware NSX, but may attempt one of the VCAP-DCV’s. I hope this post will benefit others – cheers!
This was something I ran into a week or so ago in an NSX design – obviously not thinking right!
As a friendly reminder, disable the Edge firewall if you will be using ECMP mode on VMware NSX! There isn’t any message or warning if you enable ECMP mode with the Edge Firewall still on.
Here’s my understanding – since the firewall is a stateful service (this also applies to NAT/Load Balancing), it cannot work with asymmetric routing. For example, the 2nd Edge cannot be aware of a session that was started on the 1st edge (no SYN), so the traffic is dropped.
In my testing, it seems this impacts traffic traversing North to South, but routing South to North seems to work.
I did a quick video of my testing with my current lab environment to depict the results I see – which is the loss of network connectivity and pings from another routed segment.