vRA and NSX Integration Series

Automation, NSX, Tech200, VMware, vRA7 Comments

It should be no surprise that VMware is putting a lot of time and energy around the benefits of vRealize Automation and NSX. The #BetterTogether campaign has taken off and just about anyone touching either of these solutions should be able to articulate that message by now. I’ve been focusing on the integrations between vRA and NSX partly because it’s within my charter, but primarily due to being huge believer in the transformative nature of the technology behind it. Whether at a VMUG, in a briefing, building internal content, or in my home office as my puppy, Millie, begs to go out and play just as I start recording a video (it’s like clockwork!), this has easily become one of my favorite topics.

While the benefits are easily articulated and demos [usually] go off without a hitch, much of the feedback I get suggests there’s a perceived complexity with the integration. “Not so!”, says I. While complex is a relative term, integrating vRA and NSX doesn’t have to be, especially if you have a basic understanding of the two solutions individually. Although I will agree on at least one thing — while documentation is generally getting better, there’s still a major gap in prescribed [how-to] content.…

vRA and NSX – Using Baseline Security Groups

Automation, NSX, VMware, vRA2 Comments

vRA and NSX came together back when vRA (a.k.a. vCAC) 6.0 was released, just as VMware was transitioning from vCNS to NSX. In vRA 6.x, inventory-collected security groups must be selected (checked) per Reservation prior to being available for consumption by a multi-machine blueprint (and only MMBP’s support NSX in vRA 6.x). As I’ve highlighted several times before, the latest release of vRealize Automation (7.x) delivers deeper integrations with NSX and unified service authoring capabilities to make delivering application-centric networks the new norm. See this post for how vRA and NSX are better together…I won’t repeat those details here.

With vRA 7’s deeper integration and broader use cases, one hugely powerful feature is the ability to incorporate one or more NSX Security Groups — either Pre-Existing or On-Demand — into your service design using the new Converged Blueprint Designer (CBP). You simply drag-and-drop the security group right on to the unified canvas and bind it to the desired machine components…

vra-cbp-nsx-sg

nsx security groups in vra

As a result, the provisioned machines are automatically added to the security group (Existing Security Group) or a new security group is dynamically created and bound to an existing security policy at request (On-Demand Security Group).…

vRealize Automation and NSX – Better Together

Automation, NSX, VMware, vRA4 Comments

One of the hottest topics in the world of software-defined everything is unequivocally NSX. This rocketship of a technology is fundamentally changing datacenter design — much like vSphere so effectively did (except at a greater pace). NSX redefines how networks are built, consumed, and managed. Even more importantly, security no longer has to be compromised due to the the prohibitive cost of per-application policies. And best of all, this all done with software. That’s a good thing since we’re at the start of a software-defined revolution, quickly breaking out of our hardware-defined chains.

I can go on and on, but this post isn’t about how awesome NSX is…not entirely anyway.

Making Awesome…Awesomer

So how do we take awesome up another notch? Easy…automate it (i’m sure you figured I’d say that). And not just automate in the “I’ll run a fancy custom script or workflow as soon as the request hits my desk”. While that’s neat — and congrats on putting in all the work for building those static processes (also, good luck handing those proprietary scripts over to the next admin when LinkedIn recruiters finally land you) — that’s not what I’m referring to. Automation in that sense has been around for decades and traditionally misses two of the worst choke points in IT — People and Process.…

NSX Uncovered – Part 2, Solution Overview

NSX, VMware

Network virtualization is by no means a new concept for VMware. Think about it for a moment — wherever vSphere (or any other VMware T1 or T2 hypervisor) has been implemented, a virtual switch exists and connects guest VMs to the physical world. That’s more than 500,000 customers globally, millions of vSphere hosts, and many more millions of virtual network ports backed by a standard (vSwitch) or distributed virtual switch (dvSwitch). In fact, if you count the network ports provisioned by vSphere and logically assigned to VM nics, one can argue that VMware is one of the top datalink providers on earth. Okay, perhaps that’s a stretch, but you get my point! VMware virtual networks have existed just about as long as VMware itself. And since the very beginning, there has been no shortage of innovation. The vSwitch has evolved in many ways, leading to new technologies, increased scope and scale, distributed architectures, open protocol support, ecosystem integration, and massive adoption. Over the years VMware has continued to introduce new networking technologies through organic maturity and strategic acquisition — ESXi platform security, dvSwitch (and associated services), vShield, vCloud Networking and Security (vCNS), etc. — and leveraged 3rd party integration into partner solutions, such as Cisco’s Nexus 1000v (a solution brought to market by tight collaboration between VMware and Cisco).…

ProTip – vCAC 6.1 and NSX 6.1 Integration

NSX, ProTip, VMware, vRA
vCAC 6.1 added a ton of integration with NSX 6.1 using a series of vCO Workflows, UI’s, and API integration. Although the logic is in the code, there are a few steps needed to get things going…

For starters, be sure to configure a vCO Endpoint (Infrastructure tab -> Endpoints -> Endpoints). In a POC or small environment you can point to the embedded vCO instances that ships with the vCAC VA. Otherwise point to an external vCO instance (note: if using an external instance, be sure to install the NSX 6.1 vCO plugin first).

Once the vCO Endpoint is configured, it’s time to add NSX support to the vSphere (vCenter) Endpoint. In vSphere (vCenter) Endpoint configuration, check the “Specify manager for network and security platform” box and enter the appropriate address / credentials for NSX. Be sure the account used has admin permissions (you can use the default admin account, or any account that has been added as NSX Admin users.

Check the logs to make sure no errors exist. You can also check data collection status (Compute Resources -> hover over appropriate cluster -> select Data Collection) and ensure “Network and Security Inventory” shows a successful collection.
…

NSX Uncovered – Part 1, Introduction

NSX, VMware4 Comments

VMware’s Network Virtualization Platform, NSX, is an immensely powerful technology that can transform a datacenter’s infrastructure and streamline network service delivery across the enterprise. NSX’s scope, scale, and capability will easily impress techies, CCIE’s, and IT stakeholders alike. NSX changes the topology of a traditional hardware-bound network by eliminating the dependency on all that “intelligence” baked into proprietary hardware. Instead, the logic and associated services are delivered through a software control plane. Separating the control and data planes effectively reduces the physical network to a glorified IP packet forwarder.

With that said, it is also important to understand that NSX is not a re-write of your network and the fundamental concepts it is built upon. The abstraction of the logic from the physical underpinnings is a modern approach to designing, building, and servicing network architectures, but the fundamentals — the protocols, tools, concepts, etc. — are still at play. And for that reason, i’m often baffled when I enter into a debate with a “traditional” network engineer about the ins-and-outs of physical vs. virtual networking technologies like NSX. What I quickly realize is they are not defending the concepts or technology, they are defending their skill set. It’s a fear or reluctance of straying from what they know best.…

vCloud Networking: Using vShield Edge for Firewall & Routing (without NAT)

Cloud, NSX, VMware
The Challenge: You are providing cloud services for a tenant using vCloud Director (obviously!) and want to provide a dedicated [routed] subnet and firewall services that are managed by the tenant admins.  Apps deployed in this cloud will be utilizing shared infrastructure services – LDAP, patching, scanning, etc – outside the cloud, so you’re trying to avoid NAT due to possible complications introduced by masking/translating source IPs.  Sound familiar?  Read on…
The release of vCloud Director (vCD) v1.5 along with vShield Edge (VSE) v5.0 provided a significant number of in-cloud networking enhancements that put a smirk on the faces of socially awkward cloud geeks everywhere.  Okay, I’ll admit it – the networking capabilities VMware has baked into vCloud Director have been one of the most intriguing components of the solution.  The combination of vCD 1.5 and VSE 5.0, riding on top of vSphere’s native networking capabilities, provide the framework for enhanced (and industry-leading) networking options for your cloud.  Check out the vCD 1.5 Technical Whitepaper for more info on these and other enhancements.
Here are the cliff notes for those who don’t care to read the marketing stuff:
  • improved network isolation at several levels within the cloud,
  • enhanced firewall capabilities,
  • baked-in VPN tunnels and the ability to securely stretch tenant networks across clouds,
  • enhanced NAT’ing flexibility,
  • the addition of static routes and layer-3 routing
Speaking of static routes and layer-3 routing (yep, that’s the best transition I can come up with), I have found many of my customers questioning what is actually possible with the use of these features.  
…