Tag Archives: NSX

A deeper look at vCloud Director and NSX Distributed Logical Router and Firewall Services with Usage Meter feature detection

Posted on by
2

Need to work on my titles, but that’s what I have for now. I want to spend some time reviewing how NSX Distributed, Edge, and DLR Firewall services behave in respect to vCloud Director and vCloud Usage Meter.

Some may know vCloud Usage Meter provides automated feature detection on a per-VM basis – essentially allowing granular-level billing for tenants. For example, tenant ACME may have 5 VM’s that need Distributed Firewall out of 20 – why charge them for all if they aren’t using it? Since version 3.6 of Usage Meter, this feature has been applied on a per VM level, for the most part.

There are three different versions of NSX available in the Cloud Provider Program –

We can see that your basic fundamentals are available in SP Base: your distributed switching and routing, Edge Firewall services, NAT’ing, etc. Advanced adds in Distributed Firewalling, Service Insertion and other advanced functionality while Enterprise is adding in X-vCenter NSX, HW VTEP integration.

Second, let’s take a look at the chart for NSX Editions by Feature. This comes from our vCloud Usage Meter Feature Detection whitepaper. Don’t have it? Get on VMware Partner Central and grab a copy.

Take note at the statement of “All VMs on all networks serviced by the edge” – this means even if you have a VM on that edge that does not use that feature, it will charge for it since it still has access to it. For example, if you set up a L2VPN on an Edge, be aware that any other connected networks will be charged for NSX Enterprise even though they may not be able to traverse to that tunnel!

Lab Setup

I wanted to design a DLR environment within vCD along with using Edge and Distributed Firewall rules. I came up the following design in my 9.x environment:

  1. Creating an NSX Distributed Logical Router (DLR) is pretty easy. Select the Advanced Gateway box and check Enable Distributed Routing. You can also enable Distributed Routing on any existing Advanced Edge – 
  2. The great thing about how vCloud Director creates Distributed Routing is it’s actually two Edges – a standard perimeter edge along with the DLR southbound. The transit interface is created as a /30 while applying static routes for any connected DLR interface. DLR’s default gateway is the Edge transit interface. Below is what I can see inside of NSX. 

Using the NSX Distributed Logical Router is in the NSX Base bundle and covered by Advanced SP Bundle, which is great for providers. However, Edge Firewall services are only available in the NSX Base bundle, where some providers may want to provide “high-powered” firewalling services.

The key difference between Edge and Distributed Firewall services is we do not hairpin for forwarding decisions in the DFW model: the decision is made inside of the hypervisor before the packet ever egresses anywhere. Hence, provides better throughput and capability compared to Edge or traditional firewall services – check out Wissam’s discussion on DFW capabilities here. 

vCD Access to Edge Firewall vs Distributed Firewall

I think Tomas did a great job of summarizing vCD Firewall capabilities and pointing out some of the architecture differences between the two firewall technologies.

From a vCD UI access point of view, you have to access the firewall services in two different places.

  1. Edge Firewall services are accessed by right-clicking on the Edge Gateway and selecting Edge Services. Makes sense, right? 
  2. Now Distributed Firewall management is accessed by right-clicking on the organization VDC and clicking on Manage Firewall. Not my favorite and doesn’t state DFW, but this is how it’s accessed today in the Flex UI. 

NSX Distributed Firewall Changes

Okay, let’s get into a few scenarios and test out how Usage Meter will put up the changes.

  1. I freshly created my three vApps: T1-App-1, T1-DB-01, T1-DLR-tclinux-01/02a (Web Servers). We can run a VM History Report and pick them up and see they all have been associated with the Advanced Bundle initially. I will try to point out the vROps and NSX column in the following discussion, but we will be looking for a checkmark and an “A” that refers to Advanced usage. 
  2. So let’s go ahead and crack open the DFW and start carving up some rules. This is a simple 3-tier architecture so I’m going to lay out allowing web, web to app traffic, app to DB, allowing SSH to App and DB, and blocking everything else in Web, App, and DB Tiers. 
  3. As you can see, the Applied To for my deny rule is only applied to my three Distributed Routing tiers (or routed Org VDC Networks). Not only is this a good NSX practice, this cuts down on who gets charged for NSX Advanced!
  4. Now looking at the DFW rules from vCenter, I can see vCD created the tenant folder and applied the policies in order. Very streamlined. 
  5. Now let’s check to see if my new rules work. Yep, I can still SSH to my VM’s but do not receive any ICMP replies. Perfect! 

How did Usage Meter detect the changes?

  1. So let’s now take a look at the Usage Meter VM History Report. What’s fascinating is Usage Meter tracks every move called state change. We can see in my tclinux-vApp (or Web) that it tracked when it started using Base NSX usage, then switched to Advanced, then my vROPs Enterprise instance picked it up and added it to its inventory. All in a very short timespan. Very useful! 
  2. With the DB and App layers, we see something very similar – vROps Enterprise, however, picked up these VM’s first and then we see Advanced NSX usage. 
  3. Now, I can see a few new line items populated on my Customer Monthly Usage and Monthly Usage report. I now see Advanced Bundle with Networking, Advanced Bundle with Management, Advanced Bundle with Networking and Management.
  4. This is to be expected since my VM’s went through a few iterations – my Web VM’s initially went with NSX Advanced without vROps which falls in the Advanced with Management while DB/App started using NSX Advanced without vROps registration (Advanced with Networking bundle). Last of all, all three are now assigned to the Advanced w/Networking and Management since we are using NSX Advanced features along with vROps Enterprise.
  5. While I see the new line items, I don’t see any units to be reported. Why? Well, I have some very small VM’s (256MB in vRAM) and they just ran a few hours during this testing. Keep in mind Usage Meter averages out the usage over the entire calendar month (720 hours for a 30 day period or 744 hours in a 31 day period). Again, to be expected but was pleased that new categories were added immediately.

In summary, Usage Meter does a great job of detecting NSX feature usage and bills it accordingly based on a specific service – Distributed Firewall being one of them. Thanks!

-Daniel

vCloud Director – Key Differences in Edge Gateway Services (2 of 2)

Posted on by
Reply

vCloud Director – Key Differences in Edge Gateway Services (1 of 2) 

Okay, continuing my comparison to the vCloud Director (vCD) Edge Services UI capabilities.

IPsec/L2 VPN Services – Advantage: Advanced Gateway

Advanced Gateway

  1. Very modular interface similar to NSX that allows me to apply the necessary configurations to bring up a IPsec or L2 VPN tunnel. Remember, this is how we configure an L2 VPN tunnel for vCloud Director Extender!

Standard Gateway

  1. Well, I can set up an IPsec VPN. Nice feature, but no L2 VPN capability.

SSL VPN-Plus Services – Advantage: Advanced Gateway

Advanced Gateway

  1. Comprehensive capability of establishing SSL VPN+ capability inside of the vCD HTML5 UI. From your general settings to creating the installation package, it’s covered.

Standard Gateway

  1. I got nothing, Jim. Not available in the Flex UI for the Standard Gateway.

Miscellaneous Services – Advantage: Advanced Gateway

Standard Gateway

  1. Very basic capability from enabling HA for the edge to configuring IP settings (external, IP Pools, etc).
  2. I see a section for Syslog Server settings, but no way of changing it. This can be done through the API however. Also, no way of changing the admin account password through this interface (that I’m aware of).

Advanced Gateway

  1. As the name states, quite a bit more of available here.
    1. Edge Settings has the ability to enable/disable SSH, change the username/password, and set a login banner along with editing a single syslog server.
    2. We also have Statistics available from a Connections, IPsec VPN, and L2VPN perspective.
    3. Ability to upload/modify certificates from the UI.
    4. Last of all, Grouping Objects – ability to establish groups based on IP Sets, MAC Sets, Services, and Service Groups.
  2. As expected, very comprehensive and gives you a similar look and feel to NSX.

Summary

This should not come to any surprise, but the Advanced Gateway Services provide many more features in a very streamlined interface. For our NSX consumers, it’s very similar to what they see in the vSphere Flash Client today, but cleaner in my opinion.

There’s absolutely nothing wrong with the Standard Edge Services by the way. It’s an NSX Edge under the covers and what we went through here is what the UI presents from the Flex interface.

So why use the Standard Edge in comparison to the Advanced? First off, anything before vCD version 8.20 does not have the Advanced Edge available as it was released then. So if you’re on an older version, upgrade!

Second, there may be a consideration where the provider controls the managed services and provides basic network services. This could be good enough for the operating model and allows the provider to have complete control over the tenant/org environment.

Last of all, if you’re providing self-serviceability and advanced network services, you should be using the Advanced Gateway! I didn’t even discuss the granular Roles Based Access Control (RBAC) where I can present/unpresent specific configurations. For example, we can allow the tenant to manage their VPN tunnels while Routing is not available and controlled by the Provider.

Stay tuned for more updates on vCD, we got a lot of things cookin’. 🙂

-Daniel

 

 

vCloud Director – Key Differences in Edge Gateway Services (1 of 2)

Posted on by
1

Two-part vCD series since it was longer than I expected!

I had a question come in from a Cloud Provider on what are the actual key differences between a standard Edge Gateway Service and an Advanced Edge inside of the vCloud Director (vCD) User Interface (UI). While I could explain a few things on my own, I decided to do a little bit of legwork to confirm my suspicions. While some of you may already know the following, I thought this was an interesting exercise and wanted to share my results.

Before I get to that, I’m sure everyone is aware vCloud Director started off with vCloud Network and Security (VCNS) and this was the network backing before NSX. With recent versions of vCloud Director, everything is backed by NSX.

With that said, the Advanced Gateway experience is what VMware will eventually migrate to. Therefore, get used to the nice HTML5 intuitive and speedy UI! 🙂

Edges

In my vCD 9.x instance, I have two edges deployed:

  1. SiteB-T1-ESG is my advanced edge. I can verify this by right-clicking on the edge and seeing that I do not have an option to Convert to Advanced Gateway 
  2. Moreover, you can see I am running version 9.x of vCD – I can convert it to a Distributed Logical Router! 
  3. However, with my SiteB-T1-ESG-2, I can see it’s not an Advanced Gateway as I’m able to convert it 

Let’s get to the comparisons now. Again, this is going to be in the context of the UI – not going to talk about the API right now. Going to state the advantage based on service in the title.

Firewall Services – Advantage: Advanced Gateway

Advanced Gateway

  1. I can create granular firewall rules using grouping objects associated with the HTML5 interface.
  2. This provides a very similar experience to NSX within vCenter. To be honest, anyone that has used NSX should be able to figure this out very quickly.

Standard Gateway

  1. From the standard interface, I can only create rules from a IP/CIDR and key words such as “any, internal, external.”
  2. Pretty limited to say the least.

DHCP Services – Advantage: Advanced Gateway

Advanced Gateway

  1. From the DHCP subtab, I am able to establish pools, bindings, and relay configurations. Moreover, configuring IP Sets and DHCP Relay Agents.

Standard Gateway

  1. We have the ability to add a DHCP pool that’s applied on an internal network that’s connected to this ESG. Pretty basic capabilities, but works.

NAT Services – Advantage: Tie

Advanced Gateway

  1. Ability to establish Destination or Source NAT’s. I see the same options between both Advanced and the Standard gateway, so it’s hard to call an advantage either way.

Standard Gateway

  1. As stated with the Advanced Gateway, I have the ability to establish a DNAT or SNAT. Seems like the same options to me.

Routing Services – Advantage: Advanced Gateway

Advanced Gateway

  1. This seems like a night and day difference in routing options. I’m able to get an NSX-like experience from an HTML5 interface (that’s been around for over 1 year or so!)
  2. Ability to set ECMP, Routing ID’s, utilize OSPF, BGP, and Route Redistribution with prefixes to boot.
  3. If you’re used to NSX and applying routing configurations to an Edge, this is a very similar experience.

Standard Gateway

  1. Yeah, how do static routes sound to you? That’s all I can apply here from the UI.

Load Balancer – Slight Advantage: Advanced Gateway

Advanced Gateway

  1. The Advanced Gateway is very similar to what we see in NSX – just in an HTML5 format.
  2. We get to see our Global Configuration, Application Profiles, Monitoring, Rules, Pools and Virtual Servers.
  3. I also see we have additional algorithms available from an LB perspective. I wouldn’t say it’s a stark difference between Advanced and Standard, but more comprehensive than the Standard Gateway.

Standard Gateway

  1. Standard Gateway has very similar options as the Advanced UI, just in a different UI format.
  2. As stated above, we don’t have UDP available as a type and fewer algos for the Pool configuration. With that said, it’s very comparable, but giving a slight advantage to Advanced for some of the other options available.

More to come on Part 2 here.

A Deeper Look into NSX L2VPN with vCD Extender Orchestration

Posted on by
Reply

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.

Provider

  1. This is very similar to my warm migration setup, so I’m going to try not to duplicate material.
  2. I have my Acme-Cloud-Tier Org VDC Network that was converted to a Subinterface inside of vCD: 
  3. 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 – 
  4. 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

  1. Before we can create a Data Center Extension, we need two required fields for NSX deployments.
  2. 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.
  3. 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. 
  4. Once the DC Extension has been created, we would see a new Edge device under Networking & Security 

Tenant – DC Extension (L2VPN) Execution

  1. So what happens when we attempt to create a new DC Extension (or L2VPN Connection)? A few things:
    1. Creation of our trunk port for our specified subinterface
    2. Deployment of the new Edge device that will act as the L2VPN Client
    3. Reconfiguration of the trunk port (uses mcxt-tpg-l2vpn-vxlan-** prefix)
    4. Allowing NSX to do its magic along with L2VPN
  2. We can see within my task console what happened – 
  3. 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.
  4. 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.” 
  5. Last of all, the L2VPN configuration was completed and established as the Client. We can now see the tunnel is alive too. 
  6. 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.

Enjoy those cloud migrations!

-Daniel