At VMworld Europe 2016, we showed that network virtualization is mainstream and that NSX will illuminate the path to bring your data center into the future with robust security, speed, and agility.

One year later, NSX is out to show that it’s not just in the data center anymore… it’s everywhere. Beyond helping you master the data center, NSX is setting out to empower you to reign supreme over the cloud, remote and branch offices (ROBO), and even containers. To help you get there, VMworld Europe 2017 has 70+ networking and security sessions and 60+ NSX customers to share expertise and direct experience with NSX. And on top of all of that, VMware will be presenting an exciting new security product to help ensure your applications stay secure!

Check out the list of the top, not-to-be-missed networking and security sessions below. You should also explore the schedule builder on VMworld.com to reserve your spot in the top networking and security sessions as well as to discover the whole range of introductory and deep dive NSX sessions covering the entire use case spectrum.

See you in sunny Barcelona at VMworld Europe 2017!

The post Top 10 Networking and Security Sessions at VMworld Europe appeared first on Network Virtualization.

If you’ve been working in IT for the past few years, you know how much the security landscape has changed recently. Application infrastructures — once hosted in on-premises data centers — now sit in highly dynamic public and private multicloud environments. With the rise of mobile devices, bring-your-own-device (BYOD) policies, and Internet of Things (IoT), end-user environments are no longer primarily about corporately managed desktops. And attackers are growing more sophisticated by the day.

In such an atmosphere, traditional network perimeter security ceases to provide adequate protection.

That’s where the VMware solutions come in. At the heart of the solutions is a ubiquitous software layer across application infrastructure and endpoints that’s independent of the underlying physical infrastructure or location. To really understand how it works, you need to experience it for yourself. And the Transform Security track at vForum Online Fall 2017 on October 18th is the perfect opportunity. As our largest virtual conference, vForum Online gives IT professionals like yourself the chance to take a deep dive into VMware products with breakout sessions, chats with experts, and hands-on labs — all from the comfort of your own desk.

With this free half-day event just weeks away, it’s time to give you a sneak peek of the Transform Security track. Here are five reasons that make this track a must-attend for any IT professional:

1. Provide Security Everywhere, from the Mobile Device into the Data Center

Data breaches are expensive. Period. As attackers become more sophisticated and easy-to-use attacker toolkits allow even novices to profit from cybercrime, companies need pervasive protection. Security must reach beyond the perimeter to provide defense everywhere — from the mobile device into the data center.

In the “How VMware Is Transforming IT Security” breakout session, we’ll walk you through how VMware products — including VMware Workspace ONE^TM, VMware AirWatch^®, VMware Horizon^®, VMware NSX^®, AppDefense, VMware vSphere^®, VMware vSAN^TM, and vRNI — help IT offer protection at all levels of the business.

2. Get to Know Security with Micro-Segmentation and VMware NSX

You’ve likely heard of micro-segmentation, but what is it really? How does it bolster security, and where can it be applied?

In our “Introduction To VMware NSX & AppDefense For Security,” we’ll introduce you to the concept of micro-segmentation. We’ll walk you through various applications of micro-segmentation and real examples of how customers use NSX to better secure their environments. We will also take a closer look at VMware’s newest security solution AppDefense. AppDefense allows organizations to create least privilege environments around their applications running in virtualized or cloud systems.

During the “Automate Your Security Using Micro-segmentation And Third-Party Integrations With NSX” session, we’ll take a look at NSX Distributed Firewall and review use cases for micro-segmentation, such as Skype for Business, virtual desktop environment, SAP and ClearPass. We’ll also review the NSX integration with advanced services, like McAfee and Palo Alto Networks.

3. Learn to Accelerate BYOD Security

The workforce has grown increasingly centered on BYOD over the last few years, and this trend shows no sign of slowing down anytime soon. In our breakout session “Use NSX To Enhance Security Across Your Digital Workspace With Workspace ONE, Horizon And AirWatch” we’ll talk about how NSX has extended micro-segmentation to identity management, enterprise mobility management (EMM), and virtual desktop infrastructure (VDI) through integrations with Workspace ONE, VMware Horizon^®, and AirWatch^®. We’ll also cover how these integrations enhance protection and smarter security for BYOD and VDI deployments.

4. Chat with the Experts

Want to learn more about how VMware transforms security? Dying to get your micro-segmentation questions answered? Want to know what AppDefense is all about? Or just want to get into the nitty-gritty details of NSX? Then our “Chat with Experts” sessions will be right up your alley.

Hosted by VMware pros, these sessions are your chance to comment and talk through issues live.

5. Hands-On Labs for vSphere 6.5 Security Features and NSX

There’s nothing quite like experiential learning. That’s why vForum Online is once again offering hands-on labs. During these labs, you’ll receive an overview of how to get started with NSX and get familiar with the newest vSphere 6.5 security features including VM Encryption, Audit Quality Logging, Encrypted vMotion, and Key. You’ll also get an introduction to distributed firewall and micro-segmentation with NSX.

Don’t miss this chance to join us as we tackle today’s top security issues and solutions. Register for vForum Online Fall 2017 today. 

The post 5 Reasons Why Attending the Transform Security Track at vForum Online is a Must appeared first on Network Virtualization.

authors – Geoff Wilmington, Mike Lonze

Healthcare organizations are focusing more and more on securing patient data.  With Healthcare breaches on the rise, penalties and fines for lost or stolen PHI and PII data is not only devastating to the patients but to the Healthcare organization as well.  The Ponemon Institute Annual Benchmark Study on Privacy & Security of Healthcare Data has shown that nearly 50 percent of Healthcare organizations, up 5 percent from a previous study, have been breached and that criminal attacks are the leading cause of Healthcare breaches.  [1]  With breaches on the rise and Healthcare organizations feeling the pain, how can we help Healthcare start layering security approaches on their most critical business applications that contain this highly critical data?

The principle of least privilege is to provide only the necessary minimal privileges for a process, user, or program to perform a task.  With NSX, we can provide a network least privilege for the applications that run on the vSphere hypervisor using a concept called Micro-segmentation. NSX places a stateful firewall at the virtual network card of every virtual machine allowing organizations to control very granularly how virtual machines communicate or don’t communicate with each other.

Figure 1 – NSX Restricts to Necessary Communications

Working with Epic Systems jointly, VMware and Epic created an NSX Service Composer blueprint for an Epic Electronic Health Records system.  This blueprint is injectable into the VMware NSX platform and has the necessary firewall rule sets, ports, and protocols to provide a least privilege security posture for a customer’s Epic install.  Very quickly, NSX can help provide the least privilege security posture around the Epic infrastructure systems and provide another layer of defense against threats.

Those familiar with the Epic Electronic Health Records system know that there are many moving parts and data flows between the application servers that comprise the entire system.  In order to provide a principle of least privilege on this Electronic Health Records system, customers need a quick way that enables them to do so, in a non-disruptive and prescriptive way.  VMware understands the risk to Healthcare systems and built out a method to shorten the amount of time to provide a least privilege security posture much faster.

To start working and securing such a large application as Epic, it makes sense to break the system down into its functional tiers.  We broke Epic down into the following logical tiers:

• Presentation – representing the frontend of the system with multiple applications from Hyperspace Web itself to the mobile applications like Haiku and Cantu
• Reporting – representing the reporting-based services of Epic consisting of BCA, Cogito, and Clarity
• Service – representing Web BLOB, Epic Print Services, monitoring services such as System Pulse
• Database – representing the Operational Database on Cache’ and the many clones of production such as SUP, REL, and training database instances.

Figure 2 – NSX Service Composer Breakdown of Epic Application Tiers

With these different tiers broken out, we can move to providing only the necessary communications that the Epic applications require to function properly.

Figure 3 – Anatomy of an NSX Security Policy

Taking a look at Figure 3, the process for how we leverage this blueprint to secure a portion of the Epic application follows this workflow:

• The Kuiper NSX Security Tag is placed on the Kuiper Virtual Machine
• The Kuiper NSX Security Group contains all machines with the Kuiper NSX Security Tag placed on it
• The Kuiper Services create created in NSX
• The Kuiper Services are placed into a Kuiper Services Group
• These items are used to create the Kuiper NSX Security Policy which will use these objects to create the Distributed Firewall Rulesets necessary for Kuiper to function and communicate with the rest of the Epic Electronic Health Records system

The end result is what you see here for the Kuiper application in Epic.  This same process is followed for all of the other applications that make up the Epic Electronic Health Records system.

Figure 4 – Epic Kuiper NSX Distributed Firewall Rule Example

With a strategy that’s proven in the field, getting to a Day 2 least privilege security model around a Healthcare organization’s Epic Electronic Health Records system, is much simpler, cost-effective, and fast.

VMware and Rapid City Regional Health discussed how they leveraged this process to secure their new Epic Electronic Health Records system at VMworld US 2017.  If you’d like to hear a customer experience in their security journey, you can view that session here.  If you’d like a more in-depth discussion on how to leverage this blueprint for helping secure your Healthcare organizations Epic system, please reach out to your VMware representative.

References

[1] http://www.ponemon.org/blog/sixth-annual-benchmark-study-on-privacy-security-of-healthcare-data

https://www2.idexpertscorp.com/sixth-annual-ponemon-benchmark-study-on-privacy-security-of-healthcare-data-incidents

The post Micro-segmentation of the Epic Electronic Health Records System with VMware NSX appeared first on Network Virtualization.

I wrote this post prior on my personal blog at HumairAhmed.com. You can also see many of my prior blogs on multisite and Cross-vCenter NSX here on the VMware Network Virtualization blog site. This post expands on my prior post, Multi-site Active-Active Solutions with NSX-V and F5 BIG-IP DNS. Specifically, in this post, deploying applications in an Active-Active model across data centers is demonstrated where ingress/egress is always at the data center local to the client, or in other words localized ingress/egress.

Again, I want to thank my friend Kent Munson from F5 Networks who helped me get this up and running in my NSX Multi-site lab. Kent also presented with me in the US VMworld 2017 Session: Multisite Networking and Security with Cross-VC NSX: Part 2 [NET1191BU]; make sure to check it out.

I’ll keep this post short, because I explain in detail as I step through a demo in the video embedded further below. I also showed this demo in the US VMworld 2017 Session: Multisite Networking and Security with Cross-VC NSX: Part 2 [NET1191BU] and explained how the solution can be used for DR solutions as well in the Europe VMworld 2017 Session: Disaster Recovery Solutions with NSX [NET1188BE]. You can watch the recordings of all US and Europe VMworld 2017 sessions I presented in at the links below.

US VMworld 2017:

NET1188BU: Disaster Recovery Solutions with NSX

NET1190BU: Multisite Networking and Security with Cross-VC NSX – Part 1

NET1191BU: Multisite Networking and Security with Cross-VC NSX – Part 2

Europe VMworld 2017:

NET1188BE: Disaster Recovery Solutions with NSX

The goal of the demo shown in the video embedded below was to show an application running on NSX and spanning between two sites where ingress/egress for the application is handled locally from where the client connects. Cross-VC NSX provides for the multi-site platform the application runs on and provides for consistent networking, consistent security, and inherent automation across sites.

F5 BIG-IP DNS is used to provide for GSLB functionality which handles local ingress/egress for the application. Additionally, I decided to leverage Palo Alto Networks security to demonstrate how advanced 3rd party security can be leveraged in such a multi-site solution. The latest release of PAN-OS (8.0), allows for managing multiple NSX Managers from one Panorama, and Panorama can be deployed in active-standby mode across sites for high availability.

The lab setup is shown in the diagram below. The two sites in my setup are Palo Alto, CA and San Jose, CA, but these sites could also be much further apart or even within different countries.

Figure 1: NSX Multi-site Lab Setup

In the setup I have a web application where the web app consists of four Web VMs (WebF5, WebF5 2, WebF5 3, WebF5 4) which are spanning across the two sites. As shown below, initially, only the WebF5 VM is at Site 1 Palo Alto and the other three VMs are at Site 2 San Jose. All Web VMs are on the same subnet, 172.60.0.0/24, and same Universal Logical Switch, Universal Web – F5.

Figure 2: Active-Active: Web Servers Spanning Both Sites

Logging into the active site 1 F5 LTM where SNAT is being done and the Virtual IP is 10.100.9.14, it can be confirmed the LTM sees that in the application pool, only WebF5 is active at Site 1.

Figure 3: Site 1 LTM: Application Pool Members and Status

Logging into the active site 2 F5 LTM where SNAT is being done and the Virtual IP is 10.200.9.14, it can be confirmed the LTM sees that in the application pool, WebF5 2, WebF5 3, and WebF5 4 are active at Site 2.

Figure 4: Site 2 LTM: Application Pool Members and Status

In above scenario the LTM is monitoring the web servers in the application pool via configured HTTP GET request. As shown below, using NSX DFW rules, I ensure the Site 2 San Jose LTMs cannot communicate to the Site 1 Palo Alto Web VMs. I identify the Web VMs at each site using NSX Universal Security Tags.

Figure 5: NSX DFW Rules at Site 1

Vice-versa, using NSX DFW rules, I ensure the Site 1 Palo Alto LTMs cannot communicate to the Site 2 San Jose Web VMs.

Figure 6: NSX DFW Rules at Site 2

Logging into the Site 1 Palo Alto F5 BIG-IP DNS, it can be seen an A record has been setup with the address of demoweb.nsxlab18.local.

Figure 7: A Record Defined on Site 1 Palo Alto F5 BIG-IP DNS

Looking at the Pool List members, I can see all four of the LTMs; there are two LTMs at each site. One LTM is currently active at each site because an active Web VM currently exists at each site. The other two LTMs are the standby LTMs at each respective site. It can also be seen that the load balancing method deployed is Topology, meaning the VIP of the LTMs that are local to the client request will respond.

Figure 8: Pool List Members on Site 1 Palo Alto F5 BIG-IP DNS

In the GSLB configuration, two regions have also been created and associated with respective data centers. There are well known allocated IP address ranges/subnets for respective regions/countries that can be used, but customization as shown below is also possible. The custom PA_REGION region is mapped to the Palo Alto data center and the custom SJ_REGION region is mapped to the San Jose region.

Figure 9: Site 1 Palo Alto F5 GSLB Record Configuration

Looking at the Palo Alto region, PA_REGION, any client within the listed subnet/IP Range falls under this region.

Figure 10: Defining Palo Alto Region on Site 1 F5 GSLB

The San Jose region, SJ_REGION, is also defined in the same manner.

Figure 11: Defining San Jose Region on Site 2 F5 GSLB

Now when a nslookup is done from a respective client in the Site 1 region, the correct VIP for site 1 F5 LTMs is returned.

Figure 12: nslookup on Palo Alto Region Client

Using the web client, it can also be confirmed that the correct server sitting at Site 1 responds. Since there is only one web server at Site 1, the response is always from the respective Web Server 1.

Figure 13: Palo Alto Region Client: Web Browser Access to Web Application

Doing a nslookup from a respective client in the Site 2 region, returns the correct VIP for Site 2 F5 LTMs.

Figure 14: nslookup on San Jose Region Client

Similarly, using the web client, it can also be confirmed that the correct server sitting at Site 2 responds. Since there is only three web servers at Site 2, the response can be from any one of the three web servers. The F5 LTMs have been configured to do Round Robin load balancing locally, so as new tabs are opened and new and requests made, the next web server responds as shown below.

Site 2 San Jose Web Client Request 1:

Figure 15: San Jose Region Client: Web Browser Access to Web Application – Request 1

Site 2 San Jose Web Client Request 2:

Figure 16: San Jose Region Client: Web Browser Access to Web Application – Request 2

Site 2 San Jose Web Client Request 3

Figure 17: San Jose Region Client: Web Browser Access to Web Application – Request 3

Next, in the demo, I use Palo Alto Networks Panorama to show how the same Panorama instance can talk to multiple NSX Managers and push down security policies across both sites. For management HA purposes, Panorama can be deployed in Active/Standby mode across the sites as shown below. Additionally, I demonstrate how Panorama can auto-generate redirection rules for both NSX Managers based on the configured Panorama security policies.

Figure 18: Palo Alto Networks Panorama HA Active/Standby Setup in NSX Multi-site Environment

In the demo, I use Panorama to push down a security policy that blocks all communication to the Web servers at Site 1, thus, now when a client at Site 1 makes a DNS request, the VIP at Site 2 is returned since the Web VM at Site 1 is no longer reachable. I also demonstrate vMotioning VMs across sites and how the F5 BIG-IP DNS always returns the correct VIP based on the status of the Web VMs and application pools.

In affect this demo shows the powerful capabilities of NSX as a platform for multi-site solutions.

Figure 19: VMware NSX: Platform for Multi-site Solutions

Learn more by watching the complete demo in the video below:

The post Demo: Multi-site Active-Active with NSX, F5 Networks GSLB, and Palo Alto Networks Security appeared first on Network Virtualization.

For those of you unable to attend future:net 2017 in Las Vegas, NV last month, fear not—what happens in Vegas doesn’t always stay in Vegas!

That’s right, thanks to the wonder that is YouTube, there are video recordings available of the amazing keynote speakers and presentations that took place at this year’s future:net conference, which brought together the technical and networking leaders shaping new network strategies, solutions and innovations for the future of digital transformation.

To cure you of any FOMO you may have, check out a recap of future:net presentations below, including links to their videos and a brief description of the speakers and topics discussed during each.

• Welcome Opening & CTO Perspective – Check out the presentation that kicked off future:net 2017! Pere Monclus, CTO of NSBU at VMware, offers his expert perspective and lays out his thoughts on the future of networking.
• Opening Keynote: Network Engineers Can Uncross Their Fingers by Emulating Hardware and Software Engineers – CEO & Co-Founder of Intentionet Ratul Mahajan argues that intent-based networking can be realized by borrowing and adapting approaches that have enabled hardware and software engineers to tame their own engineering complexity in his insightful opening keynote speech.
• What Is the Identity of Your Running Code? How Netflix Keeps Control of Identity and Stays Agile – YouTube and chill with this presentation from Manish Mehta, Senior Security Engineer at Netflix, on how Netflix builds identities for all services and jobs within their cloud and ultimately uses them for end-to-end security and fine-grained authorization.
• Software Networking Section Q&A – Moderated by Bruce Davie, VP and CTO of APJ at VMware, this section Q&A featured a host of expert software networking speakers fielding questions from audience members and offering their unique insights.
• The Role of Hardware and IO Processors in the Ongoing Network Transformation – In this panel, moderated by Vice President Chief Technology Officer of Telco/NFV at VMware Constantine Polychronopoulos, a host of networking leaders explore and discuss different hardware and software models, abstractions and capabilities needed to push the networking industry into the next phase.
• Network Security Challenges in Enterprise Grade Public Cloud – Pradeep Vincent, Architect at Oracle, discusses multi-tenancy and cloud provider managed operations of the public cloud, along with the unique security challenges that come with it. Hear his thoughts on how to transform network architecture to solve these challenges.
• End-User Perspective Section Q&A – Moderated by Martin Casado, General Partner at Andreessen Horowitz, this section Q&A gathered end-user perspective experts who answered audience questions around the cloud and the future of networking.
• Open19 – The Data Center Edge Future Is Now – Principal Engineer, Data Center Architecture at LinkedIn & President and Chairman of the Board at Open19 Foundation Yuval Bachar delivers a forward-looking presentation around Open19’s open source initiative to meet the need for larger, more scalable and reliable data centers as the explosion of connected devices continues to grow.
• Mega Clouds Section Q&A – Moderated by Guido Appenzeller, Chief Technology Strategy Officer of Networking and Security at VMware, this section Q&A saw a bright group of mega-cloud experts answer the audience’s pressing questions about any and all things cloud-related.
• The Rise of Programmable Networks – Brenden Blanco, Staff Engineer at VMware, takes a look at how networking development has evolved over the past 10 years, moving from once-a-year product releases to continuous open source development.

Bruce Davie at future:net

• Network Verification from Algorithms to the Real World – Co-Founder and CTO at Veriflow Brighten Godfrey reviews key research advances in network verification and discusses which principle ideas preserved, the surprises he encountered and how verification is solving real-world problems and laying the foundation for future technologies.
• How Hybrid/Multi-Cloud Enterprise Strategy Is Shaping the Future of Networking in the Public Cloud – Prajakta Joshi, Product Manager at Google, highlights the opportunity for innovation and the networking challenges facing a hybrid and multi-cloud world, both for public cloud providers and enterprises.
• Brave New World of Infrastructure Automation – Armon Dadgar, Co-Founder and CTO at HashiCorp, discusses the necessary changes needed in how we deploy and manage our applications, provision core infrastructure and ensure application and data security.
• Layer 7 Is the New Layer 4: Cilium – Layer 7 Aware Networking & Security with BPF – Get an introduction to Cilium, a platform providing application networking, security and load-balancing in collaboration with orchestrations systems like Kubernetes and Istio from Thomas Graf, Co-Founder & CTO at Covalent IO.
• Finding the Tao of Container Networking – Twelve Factor Networking – Learn about networking with containers running on orchestrators such as Kubernetes and Mesos, and how technologies like Istio, Envoy, Calico and SnapRoute transform the network from a monolithic “pet” to an agile “cattle” in this presentation from Frans Van Rooyen, Infrastructure Architect at Adobe.
• Using SDN to Bring Cellular Connectivity to Rural Tribal Lands – Martin Casado, General Partner at Andreessen Horowitz, discusses their approach toward providing broadband access and connectivity in remote areas of the world for educational purposes.
• Reduce, Reuse, Recycle – Simplifying and Cleaning Up Networking in Market Data Delivery – Truman Boyes, CTO Office, Head of Networks at Bloomberg, delivers a talk about the transformative efforts taken to streamline complex enterprise networking and service delivery while highlighting the challenges faced and lessons learned.
• How Can I Trust the Network to Correctly Implement My Intent? – Brandon Heller, Co-Founder and CTO at Forward Networks, demonstrates how fast, accurate and scalable network modeling is not just a way to improve efficiency and uptime, but helps transition to, and fully realize, intent-based networking as well.
• Transformation to Vendor – Agnostic Intent – Based Networking – David Cheriton, Founder and Chief Scientist at Apstra, describes how intent-based networking is the key to making the network an agile, yet highly reliable platform with much lower operational and capital expenditure.
• Intent Based Networking Section Q&A – Hear from David Cheriton, Brighten Godrey and Brandon Heller as they answer audience questions around the future of networking in this Q&A panel moderated by Martin Casado.
• The Impacts of Cloud Computing and Open Source on the Networking Industry – In this session, Peyton Koran, Director of Technical Engagement at Electronic Arts, highlights how out of date the supporting ecosystem for the networking industry is and discusses how the industry, individual groups and companies are starting to see the value of an open source ecosystem that allows them to participate in communities that help them develop for their network and work on the compute they really want.
• Closing Keynote: Network as a Service in Massive Scale Cloud & Hybrid Computing – Vice President of Global Infrastructure at Amazon Peter DeSantis delivers a glimpse of the future as Network as a Service (NaaS) continues to evolve, providing customers and partners greater flexibility and choice to similarly deconstruct and customize network characteristics in order to innovate and advance applications across cloud and hybrid environments. 

Whether you attended the event or not, these videos really sum up the glory that is future:net, and continue to spark new conversations. Got thoughts to share on this year’s sessions? Tell us, by tweeting to us @vmwarensx.

The post Recapping the Incredible Presentations at future:net 2017 appeared first on Network Virtualization.

We’ve all seen the VMware PKS announcement at VMworld 2017, and we are all excited about it. The idea of provisioning Kubernetes clusters in an easy way, with day-2 operations, inside your datacenters, has been a request from most of the VMware customers who are starting their journeys into the brave new cloud-native world. As we saw also from the announcement, PKS is currently under development by VMware, Google and Pivotal and is targeted for GA Q4 this year.

Until then, what if we have a solution today that you can start piloting right away without waiting? And what if it is based on the VMware solutions that you’ve grown to use and love. Better yet, what if we can add to that mix a solid networking and security capabilities to run your Kubernetes clusters in a self-service and IT governance to maintain your existing operational models?

Figure 1: Solution Overview

I’ve just started a new blog series that I named “Kubernetes in the Enterprise” which answers all those questions in a form of an enterprise-grade solution. This solution is very grounded to the real-world and business challenges, and driven by many discussions that I have been having with my VMware customers across three continents so far.  I am very excited to start exploring this series with you which will consist of 5 parts:

Part one: Overview of the solution

Part two: Kubernetes introduction for the VMware users

Part three: The design guide.

Part four: The deployment guide.

Part five: The operations guide.

The first part of this is already published on my personal blog and you can start reading it along with a demo on the solution.

Figure 2: NSX-T’s networking & security from a Kubernetes context

You will notice that the technical solution has a great emphasis on NSX-T’s networking and security with Kubernetes which I can fairly say is the biggest differentiator from any other solution out there. We will explore more of those details in the future blog posts, so stay tuned for the upcoming articles.

The post Kubernetes in the enterprise with VMware NSX-T and vRealize Automation appeared first on Network Virtualization.

Pivotal Cloud Foundry (PCF) is the leading PaaS solution for enterprise customers today, providing a fast way to convert their ideas from conception to production. This is achieved by providing a platform to run their code in any cloud and any language taking care of all the infrastructure “stuff” for them.

From building the container image, compiling it with the required runtime , deploying it in a highly available mode and connecting it to the required services, PCF allows dev shops to concentrate on developing their code.

While the platform is providing developers with the most simplified experience conceivable, under the hood there are many moving parts that make that happen and plumbing all these parts can be complex. That’s where customers are really enjoying the power of VMware’s SDDC, and the glue between the PaaS and SDDC layers is NSX, it is the enabler that makes it all work.

In this blog post I detail some of the main uses cases customers have already deployed NSX for PCF on top of vSphere and how PCF and NSX are much better together in the real world.

The use cases customers are deploying with NSX for PCF are varied and ill divide them into 3 main categories:

1. Security and Isolation
2. Day 1 operations
3. Day 2 operations

Security and Isolation

When customers are deploying PCF on traditional infrastructure and want to secure and isolate either a PCF Foundation from another Foundation (PCF deployments are called Foundations) or some deployed applications from the rest of the application running on the platform, usually they will have to use a physical Firewalls to do so. That creates operational and performance challenges.

From an operational perspective, the physical firewalls are managed separately from PCF and by different teams, every new application that requires a level of compliance and isolation, needs to be set up in multiple physical firewalls. That can slow down deployment of apps immensely and contradicts the whole purpose of buying in to a PaaS such a PCF that its main driver is speed and agility. We have customers that use physical firewalls today and are either already migrated or looking to migrate to NSX to remove the shackles from their development operations.

NSX provides an ability to manage policies dynamically based on BOSH managed NSX groups, BOSH is part of PCF responsible for deploying VMs, monitoring their health, configurating and managing their day 2 operations, and it automatically populates those NSX security groups that it creates with membership of the PCF components. These groups are then can be used in the Distributed FW (DFW) rules and policies. See here the NSX security groups created and managed by BOSH:

Screenshot of teh BOSH managed NSX Security Groups

These DFW policies provide isolation and control between applications segments and between PCF internal components in highly secure environments.

From a performance point of view when packets are sent to be inspected at the physical FW the network flow is slowed down and sent up the stream, which in many case can be multiple hops away and back. This is sub optimal to say the least as It elongates the time of communication and can add harmful latency. The more an application scales and the more it is network sensitive the more this becomes a problem. Here’s a simplified representation of such topology where the physical FW is a shared resource and the implications on internal platform communication:

Internal Communication flow with a Physical FW

With NSX we can use the DFW to inspect the packet at the vNIC level of the source and destination VMs where the application instances (containers) run. If the NSX load balancer is also being leveraged it removes a lot of the hopping north bound and provides a much better performance and much more flexible design. We can now create PCF Isolation segments and place applications there to isolate them easily from the rest of the pack which is also helpful for compliance purposes as well while creating policies to control access between different components of PCF and provided services that are inspected at the source.

The following image is a representation of where the enforcement is done at the source and not up in a physical FW:

DFW protecting a PCF Foundation

Another use case that can be  much simplified with NSX and provides performance benefits is the ability to isolate foundation from foundation on the same hardware using logical edge gateways, for example having a test foundation separated from prod and controlled with ACL to each one. By doing so our customers gain much stronger control on access to each foundation and because it is a logical FW not only we can control its placement in the physical topology in relations to the Load balancer, switch and routing layout, or putting it closer to the workloads, combined with vSphere it provides a simple way of utilizing hardware much better.

In the following diagram is the logical representation of a customer implantation where 3 foundations are sharing the same hardware, and isolated by resource pools and logical firewall

Multi-Foundation Multi-Rack

In addition to all of that goodness I have detailed above, by being able to create virtual network switches and networks in software out of thin air allows us to isolate different components of PCF like services, isolation segments and deployment networks from one another easily and to set the topology based on the applications requirements. For example, at one customer they deploy one foundation for a high performance high security app with one logical configurations that includes a switch for every service and separate LB constructs while for the rest of the applications they have shared networks and shared LB VIPs etc.

There are many more design choices customers choose to deploy side by side due to the logical nature of the SDDC and I’ll detail that in another blog post.

Day 1 automation

As I previously mentioned, PCF simplifies the life of the developers while under the hood it can be quite complex, it requires IPs for the dozens or even hundreds of VMs a foundation is compiled of, load balancing configuration and FW rules. With NSX we can simplify all of that by using automation (NSX is software based and programmatically controlled) and by being able to utilize virtual NAT GW to deploy overlapping ip schemes if customer chose to.

Deployment time of a new foundation can be reduced from a matter of weeks to hours with much less room for human error. Here is an example of a deployment model where NSX is laid out automatically and PCF on top in a matter of a few hours using concourse pipeline. Security conscience customers can build their own automation easily for their own consumption. This is a ling to the NSX/PCF automated Pipeline github page https://github.com/cf-platform-eng/nsx-ci-pipeline

Deploying PCF and NSX automatically using the Concourse Pipeline

Day 2

As mentioned above day 2 is one of the main reasons why customers choose PCF and NSX separately. With the integration between BOSH and NSX introduced in PCF 1.11, BOSH creates NSX security groups and automatically populates them with PCF internal jobs. These groups are than used for DFW source and destination configuration as explained above but also for the NSX load balancing pools, that means that the security groups are nested in the resource pools. When there is a need to scale a load balanced component like the Go routers who provide access to the applications internally, The added resource would be added to the NSX security group and consequentially to the load balancing pool. Automatic scaling of the NSX load balancer based on scaling of PCF. This is also very helpful when creating new Isolation segments and scaling those as well.

Autoscaling the LB using BOSH managed Security Groups

As you can see NSX provides the required design flexibility which enables many use cases for our customers. This shows how valuable the SDDC is for the application transformation to enhance agility, security and operations of PCF using NSX.

The post Real World Use Cases for NSX and Pivotal Cloud Foundry appeared first on Network Virtualization.

Introduction

When Bob Dylan wrote back in the 60’s “times they are a-changin” it’s very possible he knew how true that would be today.  Last week, we saw a few things announced in the container technology space during the DockerCon event in Copenhagen – but one thing that I believe came as a surprise to many was Docker’s announcement to begin including Kubernetes in Docker Enterprise edition sometime in early 2018.  This doesn’t concede or mark the death of Docker’s own scheduling and orchestration platform, Docker Swarm, but it does underscore what we’ve heard from many of our customers for quite some time now – almost every IT organization that is using/evaluating containers has jumped on the Kubernetes bandwagon.  In fact, many of you are probably already familiar with the integration supported today with NSX-T 2.0 and Kubernetes from the post that Yves did earlier in the year…

In the past few years, we’ve heard a lot about this idea of digital transformation and what it means for today’s enterprise.  Typically, a part of this transformation is something called infrastructure modernization, and this happens because most IT environments today have some hurdles that need to be overcome to align with goals of digital transformation.  In modern times, the “app-centric world”, the provisioning of network and security services is often very slow and requires some manual intervention.  Additionally, complex processes and varying IT architectures hamper today’s developers.  Therefore, these IT environments prevent the speedy delivery of modern applications, which today means cloud-native or container based apps.

The software defined data center (SDDC) stack has been embraced for compute and storage functionalities, and for network virtualization (here in late 2017) we’ve come a long way as well.  NSX has played a key role in redefining and modernizing networking in the data center.  NSX subsequently has emerged as the industry leader in software-defined networking (SDN) by providing a network virtualization and security platform for the enterprise, which has enabled customers to make this transition to the digital era.  Digital transformation starts with IT… and for more and more organizations, the lightbulb moment has occurred – the network, as it’s known today is dead.  So when IT receives infrastructure sounding goals and objectives like security of on-prem and cloud applications and data, speed of delivery, and application high availability, this network needs to be rearchitected and thought about completely differently.  Our goal is to align with many new key business priorities, as well as meet the demands of new approaches in application development and new application architectures (containers, microservices, PaaS) as we move into 2018 and beyond.

VMware NSX is designed to address these emerging application frameworks and architectures that have heterogeneous endpoints and technology stacks.  NSX allows IT and development teams to choose the technologies best suited for their particular applications.  NSX is designed for management, operations, and consumption by development organizations – also for IT.  As developers embrace these newer technologies like containers, and the percentage of workloads running in public clouds increases, network virtualization must expand to offer a full range of networking and security services, native, in these environments.  And that’s exactly where we are with NSX – a network virtualization solution for multi-cloud and multi-hypervisor environments.  By providing seamless network virtualization and security for workloads running on either VMs or containers, NSX supports cloud and container environments:

F5 Networks, the global leader in Application Delivery Networking (ADN), also addresses many emerging IT trends by providing secure, reliable, and fast delivery of applications.  F5’s framework and architecture enables community-driven innovation that helps organizations enhance IT agility.  F5’s vision of unified application and data delivery redefines the management of IT (application, server, storage, network) resources, streamlining application delivery and reducing costs.  Customers from all segments (globals, service and cloud providers, and web 2.0 providers) also trust F5 to keep their business moving forward into the digital era.

The Integration

In our demo setup, we will deploy three simple applications into the Kubernetes cluster.  An NSX setup has already been deployed and configured.  We have also deployed a BIGIP as a VM (but this could also be a physical appliance, it’s the same code).  The topology and applications being deployed are the following:

1. Nsx-demo Application – a simple container that is running flask.  Contains an embedded port-scan application
2. Guestbook Application – another multi-container based app that deploys a PHP Guestbook allowing users to sign or log their visitation or comments, much like a guestbook at a rental property.  The architecture calls for a frontend container, and both redis-master and redis-slave database containers to be deployed
3. Yelb Application – a simple multi-container based app that allows users to vote on a set of data (restaurants) and dynamically updates pie charts based on the number of votes received.  Architecturally, it deploys a yelb-ui nginx frontend container, a yelb-appserver ruby container, and a redis-server database container

The first step to get this integration going, before we deploy our applications, is to deploy the F5 BIG-IP Controller for Kubernetes (aka the F5 Container Connector).  The F5 BIG-IP Controller for Kubernetes is a container that runs in a Kubernetes Pod. It uses F5 Resources to determine:

• what objects to configure on the BIG-IP system
• which Kubernetes Service said objects belong to

The k8s-bigip-ctlr container watches the Kubernetes API for the creation, modification, or deletion of Kubernetes objects.  For some Kubernetes objects, the BIG-IP Controller responds by creating, modifying, or deleting objects in the BIG-IP system:

Deploying the BIG-IP Controller is simple:

Next, we will create our no NAT (routed mode) namespace called “f5-demo”:

Now it’s time to deploy our first application in the newly created namespace:

Then, using the Container Connector, we build a virtual server on the BIG-IP for this app:

This definition file is where we describe the nsx-demo app and BIG-IP VIP attributes:

Now, let’s verify the BIG-IP configuration.  First, the virtual server:

Second, verify the appropriate pool members based on the number of k8s Pods running:

Last but not least, let’s verify the application (and the load balancing) is working correctly:

In terms of deploying our second and third applications, the entire workflow works in a very similar manner.  First, let’s create our new NAT namespace “nsx-demo”:

Next, let’s deploy the multi-tier applications into the newly created namespace:

After the application is successfully built and deployed, we again need to create the virtual servers on the BIG-IP appliance:

Let’s again verify the configuration on the BIG-IP appliance:

And that’s it – now let’s verify that our container based applications are up and running:

Conclusion

The solution leveraging VMware NSX and F5 addresses many of the requirements/demands of these emerging cloud-native and new application architectures.  The integration between these solutions provides customers many potential benefits, such as the ability to leverage existing investment in their load balancing resources, provides a solution to address the microsegmentation of microservices and container based applications, all while reducing the deployment time of applications and simplifying operations for application layer, security, and network availability services.  The solution eliminates the network as a stalling point in application deployment, so that both the application services and the network aren’t inhibiting the goals/expectations of the business:

We know that a blog and screenshots can only go so far – and if you’re into technology, we understand that today is a very busy day with lots happening to occupy your time.  TV enthusiasts are eating eggo waffles and binge watching Stranger Things 2, tech and gadget enthusiasts are busy pre-ordering the iPhone X, and gaming enthusiasts are diving into the first major Mario themed release for the Nintendo Switch console.  But if you’re like me and one of the many visual learners out there, please give us about three minutes of your very busy Friday… we’d like to take the opportunity to show you a demo of how this integration works from a live setup we used at VMworld 2017, so that you too can understand why more and more organizations are choosing to #RunNSX.

Below you will find a short demonstration of this powerful integration between NSX and F5 available on our youtube channel:

The post VMware NSX/Kubernetes and F5 – A Cloud Native App Integration appeared first on Network Virtualization.

By Milin Desai, Vice President of Products, NSBU

It feels like only yesterday when we started our journey into networking at VMware. Even from the early beginnings in 2011, it became clear to some of us that the abstraction and operations model of virtualization for compute and memory, which completely transformed the modern data center, was something we needed to extend to networking. We understood that that a network based on software and abstraction in the long run would extend beyond our customers’ data centers to public clouds and ultimately to the Edge.

We’ve been executing on this vision for almost eight years; reinventing data center networking and enabling our customers to be smarter about how they secure, manage and connect their applications and users.

Starting with the Data Center

The Nicira acquisition, alongside our internal innovations, resulted in the release of VMware NSX in 2013. VMware NSX made network virtualization a mainstream possibility for the data center. The goal was simple — abstract the application from the physical network and deliver the networking attributes in software at machine speeds. After four years, multiple thousands of customers and the creation of a billion-dollar run rate business, we have transformed the networking and security model in the data center. Customers are driving business value through increased automation, enhanced security and getting greater availability with application continuity leveraging NSX and our ecosystem.

The arrival of the Public Cloud

While on-premises data centers have been evolving to the software-defined data center, our customers have been working through another disruptive shift in IT – the emergence of  cloud. Applications that typically sit in the data center now are now delivered as software-as-a-service or run in public clouds. Understanding this trend, and with the mindset of delivering value for networking closest to the applications, we too have been working with our customers to address the networking and security changes brought about by the multi-cloud strategies we increasingly see in our customer base. We have been working in this area on three fronts:

• First, we started with some of our VMware Cloud Provider partners, and empowered them to use NSX as a strategic lever to create new and differentiated offerings for their customers. Expedient, ARMOR, and iLand and others are now offering new security and DR-as-a-Service offerings based on NSX.
• Next, we worked with some of our largest global Cloud Provider partners to make NSX a strategic component of complete SDDC service offerings. CenturyLink, Fujitsu, IBM Cloud, NTTcom, OVH and Rackspace all offer complete SDDC as a service offerings underpinned by NSX. Our networking stack is also a key differentiator to our own VMware Cloud™ on AWS
• Finally, we are making NSX available as a cloud service to support applications running natively in leading public clouds, starting with AWS today, and in the future Azure. We are also working Google and Pivotal to deliver a Kubernetes-based container service Pivotal Container Service (PKS).

The Intelligent Edge: With VeloCloud, we will expand our approach to the WAN

The data center is no longer the central control point to enforce policy for networking and security control. The dynamics of distributed application above in conjunction with end users wanting improved experiences is changing how we connect end users to applications going forward.

As we move from a model of data centers to centers of data, it was the right time to execute on extending our approach to the wide-area network (WAN). With our announcement of our signing of a definitive agreement to acquire VeloCloud Networks, we will bring together a solution that will help us connect and secure islands of data with the same automation, security and visibility that we bring with NSX within each center of data.

Once closed, this acquisition will enable our customers with:

The time to engage is NOW

We revolutionized data center networking and extended enterprise controls to the cloud. Next we will bridge the in-between with software-defined-WAN and provide a true fabric from the data center to the cloud to the edge. Since we will have the foundations of connecting and securing everything, it’s time to get engaged in driving the next era of networking with VMware and our ecosystem.

We are excited about what we plan to bring to the marketplace so stay tuned, you ain’t seen nothing yet.

The post Abstract, Automate & Secure — From Data Center to Cloud to Edge appeared first on Network Virtualization.

In the year 2017, news comes at you fast. So, it’s easy to miss the important or informational items that just weren’t on your radar when they first arrived. While we believe VMware NSX should be firmly on everyone’s virtualization radar, we understand that you may miss a few items from time to time. That’s why we’re putting together this VMware NSX news round-up.

This news round-up recaps the latest NSX-related material you may have missed over the past few months for you peruse at your leisure. We’ll compile these posts again from time to time, so be sure to keep your eye on this space for more VMware NSX news rounds-ups and informational posts!

Real World Use Cases for NSX and Pivotal Cloud Foundry

From the post: Pivotal Cloud Foundry (PCF) is the leading PaaS solution for enterprise customers today, providing a fast way to convert their ideas from conception to production. This is achieved by providing a platform to run their code in any cloud and any language taking care of all the infrastructure “stuff” for them.

From building the container image, compiling it with the required runtime, deploying it in a highly available mode and connecting it to the required services, PCF allows dev shops to concentrate on developing their code.

Kubernetes in the enterprise with VMware NSX-T and vRealize Automation

From the post: The idea of provisioning Kubernetes clusters in an easy way, with day-2 operations, inside your datacenters, has been a request from most of the VMware customers who are starting their journeys into the brave new cloud-native world. As we saw also from the announcement, PKS is currently under development by VMware, Google and Pivotal and is targeted for GA Q4 this year.

Until then, what if we have a solution today that you can start piloting right away without waiting? And what if it is based on the VMware solutions that you’ve grown to use and love…

Micro-segmentation of the Epic Electronic Health Records System with VMware NSX

From the post: The Ponemon Institute Annual Benchmark Study on Privacy & Security of Healthcare Data has shown that nearly 50 percent of Healthcare organizations, up 5 percent from a previous study, have been breached and that criminal attacks are the leading cause of Healthcare breaches.

With breaches on the rise and Healthcare organizations feeling the pain, how can we help Healthcare start layering security approaches on their most critical business applications that contain this highly critical data?

Demo: Multi-Site Active-Active with NSX, F5 Networks GSLB, and Palo Alto Networks Security

From the post: The goal of the demo shown in the video embedded below was to show an application running on NSX and spanning between two sites where ingress/egress for the application is handled locally from where the client connects. Cross-VC NSX provides for the multi-site platform the application runs on and provides for consistent networking, consistent security, and inherent automation across sites.

Your view into the Incredible Presentations at future:net 2017

From the post: For those of you unable to attend future:net 2017 in Las Vegas last month, fear not—what happens in Vegas can sometimes be brought to you on this blog.

Looking for content that’s a little more localized to South America? You can find our Spanish-based portal here and our Portuguese-based portal here. Be sure to give both a look-through, even if you’re a non-native speaker, because they’re chock-full of great advice and tips. If you need a translation, Google Translate can help.

The post Top 5 From The Last 3 Months appeared first on Network Virtualization.

Remote user authentication and role based access control (RBAC) is an important requirement when deploying new systems in an organization, particularly in the networking world. For that matter, systems typically leverage RADIUS or Active Directory (AD) servers, to name a few.

NSX-T integrates with VMware Identity Manager (vIDM) to get the following benefits related to user authentication:

• Support for extensive AAA Systems, including
  • AD-based LDAP, OpenLDAP
  • RADIUS
  • SmartCards / Common Access Cards
  • RSA Secure ID
• Enterprise Single Sign-On
  • Common authentication platform across multiple VMware solutions
  • Seamless single sign-on experience

This blog post covers the main steps required to integrate NSX-T with vIDM and to configure roles that grant different privileges to different users. It does not cover deployment and hardening of VMware Identity Manager (vIDM). At the end of the post, there is a link to a demo showing how to do the configuration and several role-based access tests.

Assuming that both NSX-T Manager and vIDM appliances are deployed, powered on and configured with the basic management details (IP address, admin users, etc.), the integration requires the following steps:

1. Creating a OAuth client ID for the NSX-T Manager in vIDM
2. Getting the vIDM appliance thumbprint
3. Registering NSX-T Manager with vIDM using the client created
4. Adding an Active Directory (AD) server to vIDM
5. Configuring different roles in NSX-T for the users retrieved from AD via vIDM

Creating a OAuth client ID for the NSX-T Manager in vIDM

The first step is to create an OAuth client ID entry for NSX-T in vIDM. This will allow to later register NSX-T and to establish the communication channel between both components.

To create the OAuth client ID for NSX-T (you may need vIDM administrator privileges):

1. Access vIDM admin console at https://vIDM_FQDN
2. Click on the small triangle in the Catalog tab and select Settings on the drop-down menu

3. On the left menu, select Remote App Access and then click on the Create Client button:

4. On the Create Client window:
   • Select Access Type = Service Client Token
   • In Client ID, enter a meaningful name that should allow to identify the NSX-T manager when reviewing the list of clients in vIDM
   • Click on the triangle close to Advanced
   • Click on Generate Shared Secret
   • Leave all other parameters with default values or modify them to match your needs
   • When finished, click on Add
     
     Note: write down the Client ID and Shared Secret as they will be required at a later step

5. A new window with the configuration details of the client will be presented. Click on Back to Clients List
6. On the clients list there will be a new entry for the NSX-T Manager. Its status will show Not Activated. That is expected and normal behaviour.
   

Get the VMware Identity Manager appliance certificate thumbprint

vIDM thumbprint is required for configuring the integration from the NSX-T console. In order to retrieve it:

1. Access the vIDM CLI with the sshuser ID
2. Obtain root privileges
3. Move to the /usr/local/horizon/conf directory
4. Issue the following command openssl x509 -in vidm.corp.local_cert.pem -noout -sha256 -fingerprint
   
   
   Note: write down the vIDM fingerprint as it will be required at a later step

Registering NSX Manager with vIDM using the client just created

Once we have the OAuth Client ID, its Shared Secret and the vIDM thumbprint, we can proceed to the NSX-T Manager console to register NSX with vIDM. For that:

1. 1. On the left menu, select System and then Users
   2. Once on the Users window, select the Configuration tab and click on the EDIT link in the top right corner
      
   3. On the window that pops-up:
      • Enable VMware Identity Manager Integration
      • Enter the FQDN of the vIDM appliance
      • Enter the OAuth Client ID created in vIDM previously
      • Enter the Shared Secret associated with the OAuth Client ID
      • Enter the SHA-256 thumbprint of the vIDM appliance obtained previously
      • Enter the FQDN of the NSX-T Manager appliance
      • Click on Save
        
        Note: What is entered on the NSX Manager Appliance field must be used for accessing NSX after the integration. If you enter the FQDN but then try to access the NSX Manager through its IP address, remote user authentication will fail with a “Must provide a matching redirect uri” error message.
   4. Back on the Configuration window, vIDM connection shows as Up and vIDM Integration as Enabled.
      
   5. At this stage, there is successful communication between the NSX-T Manager and the VMware Identity Manager appliance.

Adding an Active Directory (AD) server to vIDM

We are assuming we are using a newly deployed vIDM appliance. As such, it does not have any directory configuration yet. Let’s see how to register vIDM with Active Directory, which is one of the most popular options.

Back on the vIDM admin console:

1. Click on the Identity & Access Management tab
2. Then click on the Add Directory button and select Add Active Directory over LDAP/IWA from the drop-down menu
   
3. On the next screen:
   • Provide a meaningful Directory Name, to identify the AD server
   • If your directory supports DNS Service Location, leave the option checked. Otherwise, uncheck it and enter the server IP address and port.
   • Provide Bind User Details and click on Test Connection to check if communication is successful
   • Once it is OK, click on Save & Next
     
4. On the new screen, select the domains you want to work with and click Next.
5. On the next step you can choose to modify the mapping of user attributes. Defaults should work for most of the cases, so you can click Save.
   
   Note: Be aware that User name, First name, Last name and e-mail are required fields. The users to be sync’d must have such fields completed, otherwise synchronization will fail.
6. After that, specify the Distinguished Name (DN) of the groups to be synchronized and click on Find Groups.
   
7. The system will return the list of groups that match the DN entered. You can either select all of them of specify which ones to sync. Click Next once done. In the example below, there is only the nsx-users
   
8. The screen that follows allows you to synchronize users which are part not of the previous groups. You can specify any or leave it blank.
9. Finally, you are presented a summary of the Active Directory users and groups that are about to be sync’d by vIDM. In the example below, one group containing 3 users will be synchornized. If you agree with the information, click on Sync Directory.
   
10. Directory synchronization starts. Click on Refresh Page to get updated information. Wait until you get a green checkmark, indicating that synchronization has been successful
    
11. As a last step, navigate to the Users & Groups tab and confirm the users you expected to sync are visible.
    

Configuring different roles in NSX for the users retrieved from AD via vIDM

Once VMware Identity Manager has retrieved the specified users from Active Directory, we can assign them different roles in NSX. For that:

1. On the NSX-T Manager web console, navigate to System -> Users, and select the Role Assignments Click on the + ADD button:
   
2. On the window that pops-up, select one user or group to be assigned a role. A minimum of 3 characters are required, NSX will then autocomplete the possible names. Once the right user/group is selected, assign it one or more roles from the list below. Click Save when finished.
   
3. Repeat the process to assign roles to more users and/or groups
   
   Note: Privileges are calculated per feature. Users with no explicit role assigned will inherit the role(s) of their group. Users with explicit roles assigned enjoy the highest privileges of any of them. A detailed list of Roles and Permissions is available on the NSX-T Admin Guide https://docs.vmware.com/en/VMware-NSX-T/2.0/com.vmware.nsxt.admin.doc/GUID-26C44DE8-1854-4B06-B6DA-A2FD426CDF44.html
4. Log out from the NSX web interface.
5. After integration with vIDM, the NSX-T login page offers and option for remote user authentication. Select it and enter your user ID.
   
6. Then you will be redirected to vIDM for entering the user password.
   
7. Once authentication is successful, the user is taken to the NSX home screen
   
8. Take some time to explore the different access levels for each user. Depending on their roles, they will or will not be able to add/delete/modify logical switches, logical routers and/or firewall rules.

Finally, the video below shows the step-by-step configuration of how to integrate NSX-T with VMware Identity Manager, including some tests to check the different user  privileges. I hope you find it interesting!

Additional info:

VMware Identity Manager Documentation: https://docs.vmware.com/en/VMware-Identity-Manager/index.html

VMware NSX-T Documentation: https://docs.vmware.com/en/VMware-NSX-T/index.html

All VMware Documentation: https://docs.vmware.com

VMware NSX YouTube Channel: https://www.youtube.com/VMwareNSX

VMware Official Site: https://www.vmware.com/

VMware News and Customer Stories: https://www.vmware.com/radius/

The post Remote User Authentication and RBAC with NSX-T appeared first on Network Virtualization.

Microservices is the philosophy of designing software programs by breaking what used to be a singular function or command into multiple components, known as services.  The ultimate goal is to reduce complexity and increase speed (basically the goal of anything nowadays).

Think of Thanksgiving.  A traditional approach would have the same person cook the entire meal.  And likely even do all the dishes.  Think of a world instead where you can assign different individuals (and ovens!) for cooking the turkey, gravy, mashed potatoes, stuffing and anything else that may grace your table.

Microservices delivers on this dream but also takes the principle to the next level.  Not just breaking up the request (multi-course dinner) into multiple services (turkey, salad, not burning the garlic bread) but making them really really minute.

“Services” that used to be inherently linear can now happen concurrently.  To go back to our Thanksgiving example, you could have the potatoes peeled at the same time they’re being mashed.  If we were able to avoid running into one another (part of the magic of software over families in kitchens) everything would become very efficient.

Want to learn more?  Check out these sources:

• https://en.wikipedia.org/wiki/Microservices (although you probably could have found this on your own)
• https://blogs.vmware.com/cloudnative/2017/05/09/microservices-meets-micro-segmentation-delivering-developer-ready-infrastructure-modern-application-development-2/
• https://blogs.vmware.com/cloudnative/2017/03/13/kubo-enterprise-adoption-microservices-architectures/
• https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/cloudnative/vmware-accelerate-digital-transformation-through-cloud-native-application.pdf

Terminology Tuesday is a new blog series.  What would you like to hear defined?  Let us know in the comments or, as always, reach out to @vmwarensx.

The post Terminology Tuesday Presents: Microservices appeared first on Network Virtualization.

Introduction

As businesses evaluate their applications in the constantly evolving world of IT, new strategies are emerging for delivery. These strategies include keeping applications on-premises or moving them to one or more public cloud providers.

These public clouds come with their own networking and security constructs and policy management. This results in a new set of technology siloes that increases expense, complexity and risk:

This blog series will discuss the challenges of providing consistent networking and security policies for native cloud workloads, the value of VMware NSX Cloud, and walk through the process of securing and connecting applications running natively in the public cloud.

VMware NSX Cloud

VMware’s strategy is to enable businesses to create and deliver applications. To support new delivery strategies, VMware NSX Cloud provides consistent networking and security for native applications running in multiple public and private clouds. Utilizing a single management console and a common application programming interface, VMware NSX Cloud offers numerous benefits:

• Unified Micro-Segmentation Security Policies – VMware NSX Cloud provides control over East-West traffic between native workloads running in public clouds. Security policies are defined once and applied to native workloads. These policies are supported in multiple AWS accounts, regions, and VPCs. Policies are dynamically applied based on a rich set of constructs, such as workload attributes and user-defined tags. Rogue or compromised workloads can also be automatically quarantined.
• Network Control and Portability – VMware NSX Cloud provides consistency and control over network policies, while also offering portability. Precise control is given over networking topologies and addressing, providing capabilities such as stretching subnets across availability zones. Provisioning and management of networking and security policies across cloud accounts can be greatly simplified and standardized through the use of templates.
• Increased Visibility Across Clouds – VMware NSX Cloud improves the visibility and analytics for native workloads in public clouds using existing and familiar network management tools. Flow, packet and event information is available via standard tools and interfaces such as IPFIX, syslog, port mirroring and Traceflow.
• Consistent operations – VMware NSX Cloud brings a standardized and consistent operational model to applications running natively in public clouds. A single management console and common APIs allows cloud teams to simplify their operations and scale across a growing number of public cloud environments leveraging existing automation tools. Existing Day 2 operations tools can be used to provide end-to-end monitoring, troubleshooting and auditing.

Getting Started

VMware NSX Cloud is offered as a service to enable customers to quickly deploy and secure their native cloud workloads. To provide these capabilities, VMware NSX Cloud uses NSX-T components (NSX Manager and Controllers) and integrates them with public cloud providers.

Additional components are part of a VMware NSX Cloud deployment:

• NSX Cloud Service Customer Dashboard provides a single User Interface for customers to see the status of their deployment, high level inventory, and maintenance notifications.
• NSX Cloud Services Manager (CSM) integrates with NSX Manager and public cloud accounts to provide a unified view of cloud inventory, onboard cloud environments by automating the deployment of the NSX Public Cloud Gateway, and manages quarantine policies. NSX Cloud Services Manager also layers NSX status over the cloud inventory.
• NSX Public Cloud Gateway (PCG) acts as a local NSX control plane within each public cloud VPC, provides Edge Gateway functions for North-South traffic, and enforces quarantine policy.
• NSX Public Cloud Agent provides the distributed data path functions for workloads managed by NSX. It enforces distributed firewall policies and performs logical routing and switching for overlay traffic.

Each customer gets their own dedicated NSX Cloud management infrastructure, which is managed by VMware. Customers bring their own AWS accounts and VPCs to be managed by NSX Cloud network and security policies.

VMware will ensure the uptime of the service and is responsible for the installation and upgrade of the NSX Cloud service. The NSX Cloud Service Customer Dashboard is activated for each customer after installation. NSX Manager and NSX Cloud Services Manager access is available through the dashboard.

The next step is to add a customer cloud account to CSM to provide access to the public cloud inventory. In the case of AWS, a CloudFormation template is available to quickly configure the necessary account permissions. This policy creates two AWS roles that are used by NSX Cloud, one to support the gathering of AWS inventory and another to support the deployment of the Public Cloud Gateway in a VPC.

The account inventory is displayed after the AWS account has been successfully added. At this point the customer cloud environment (AWS VPC) is ready to be configured for NSX Cloud network and security management.

In the next blog, we’ll dig into how to setup your AWS VPC for management by VMware NSX Cloud.

For More Information

Get started with VMware NSX Cloud by visiting https://cloud.vmware.com

Watch VMware NSX Cloud videos on YouTube

Watch the VMware NSX Cloud Sessions presented at VMworld:

• Using VMware NSX for Enhanced Networking and Security for AWS Native Workloads: Part 1 [MMC2046BU]
• Using VMware NSX for Enhanced Networking and Security for AWS Native Workloads: Part 2 [MMC1532BU]

The post Securing Native Cloud Workloads with VMware NSX Cloud Blog Series – Part 1: Getting Started appeared first on Network Virtualization.

Think of Blockchain as primarily two things.  1) A peer-to-peer technology 2) A way of keeping a public record.

The technological backing of Blockchain is the ability to have many (many) computers host the same information.  Snippets of code (known as blocks) are duplicated and maintained in so many different places rendering fraud impossible.  The fact that each of these blocks is timestamped and unique makes it increasingly challenging to outsmart.  If you’re interested in learning more about the technological specifics there are a number of great resources online including this presentation by Binh Nguyen, IBM’s Blockchain Fabric Chief Architect.

Today, Blockchain is most commonly thought of in connection to Bitcoin as it describes the technology and process that we’ve all come to know as being so secure.  Bitcoin’s past affiliations with illegalities of all sorts have given a bad name to Blockchain but there are many benefits to secure transactions all with a public record as our purchases and currency become increasingly digital.

Want to learn more?  Check out these sources:

• https://blogs.vmware.com/industry-solutions/2017/10/17/financial-services-blockchain-revolution-just-beginning/
• https://www.economist.com/news/leaders/21677198-technology-behind-bitcoin-could-transform-how-economy-works-trust-machine
• https://www.reddit.com/r/Bitcoin/comments/4yp5q1/could_you_please_eli5_the_blockchain_technology/
• https://en.wikipedia.org/wiki/Blockchain
• http://ir.vmware.com/overview/press-releases/press-release-details/2017/Banking-Industry-Embracing-Emerging-Technology-According-to-New-VMware-Survey/default.aspx
• https://www.sdxcentral.com/articles/news/vmware-plans-pilot-blockchain-technology-2018/2017/11/

Terminology Tuesday is a new blog series.  What would you like to hear defined?  Let us know in the comments or, as always, reach out to @vmwarensx

The post Terminology Tuesday Presents: Blockchain appeared first on Network Virtualization.

We’ll be at AWS re:INVENT in Las Vegas all week (Nov 27 – Dec 1, 2017)!

Come say hi to the NSX Team at the VMware booth (#900 right as you walk in the main entrance) in the Expo Hall at the Venetian Hotel.  Stop by our booth to…

• Check out a quick demo on VMware NSX Cloud
• Attend a 30-minute in-booth session about VMware NSX Cloud (Thursday, Nov 30 at 11:30am)
• Grab some swag
• Play one of our booth games and win a prize – Apple iPhone 8, AWS Credits, Amazon Echo, T-Shirts, and more!

As always, continue the conversation with us on Twitter @vmwarensx or use the hashtag #RunNSX or #NSXMindset‏. We hope to see you at the show!

The post Come Visit Us at AWS re:Invent! appeared first on Network Virtualization.

Application architectures are evolving. That shouldn’t be news to anyone. Today, emerging app architectures that leverage container-based workloads and microservices are becoming mainstream, moving from science projects in development labs to enterprise production deployments at scale. The benefits are clear. Developers and the application lifecycle, become faster, more productive, more agile, and more responsive to the needs of the business.

Today we’re announcing NSX-T 2.1, which will enable advanced networking and security across these emerging app architectures, just as it does for traditional 3-tier apps. More specifically, NSX-T 2.1 will serve as the networking and security platform for the recently announced VMware Pivotal Container Service (PKS), a Kubernetes solution jointly developed by VMware and Pivotal in collaboration with Google. NSX-T 2.1 will also introduce integration with the latest 2.0 release of Pivotal Cloud Foundry (PCF), serving as the networking and security engine behind PCF. In these environments, NSX-T will provide Layer 3 container networking and advanced networking services such as load balancing, micro-segmentation, and more.

For development teams, these integrations mean that they will be able to operate quickly and consume infrastructure as code. Meanwhile, their workflows will remain the same — fast and efficient — because NSX-T will integrate tightly with these application platforms, connecting directly into the Container Networking Interface (CNI), fitting into the existing application development tools that developers are already using. The result is that as developers are deploying code, advanced networking and security services will automatically be provisioned to support their containers and microservices, creating a truly full stack developer cloud.

In parallel, IT teams still need operational control of and visibility into the broader heterogeneous environments that they manage, whether they be on-premises or in the public cloud. NSX-T will provide a common management interface for containers and microservice architecture applications, as well as traditional VM-based ones across all environments, allowing IT teams the oversight they need without inhibiting the ability of developers to quickly develop, deploy, and iterate on their applications.

We recognize that in this new world, endpoints are heterogeneous and infrastructure consumption models are changing. To that end, we specifically designed and optimized NSX-T to enable organizations across all industries to hit the gas on their ongoing digital transformation journeys. NSX-T 2.1 is the next step in this drive for VMware, and we invite you to join us for the ride!

NSX-T 2.1 will be generally available in Q4 of VMware’s FY’18. Also, make sure you subscribe to this blog and keep an eye out for the technical details of the new PKS and PCF 2.0 support with NSX-T 2.1, which will be coming in the next few weeks.

Head over to the PKS blog and PCF 2.0 blog to get a more in-depth discussion of each solution. 

The post Introducing NSX-T 2.1 with Pivotal Integration appeared first on Network Virtualization.

ZTP stands for Zero Touch Provisioning.  And, as a quick google search will quickly reveal, many other things as well.

Back to our ZTP.  ZTP is the process by which new network switches can be configured without much human involvement.   Notice that I said “much” and not “any”.  ZTP is not it’s not truly zero because something (someone!) needs to put the first components of the network together in order for the rest of the network to be built in a ZTP fashion.

Where provisioning many switches could have quite a while through ZTP processes it’s down to a matter of minutes.  Switches can also be updated automatically with any need for physical intervention.

The beauty of ZTP is the continued march towards more and more robust automation solutions.  Delightfully, once folks aren’t mired in the repetitive manual work they can move onto tasks that bring innovation to businesses and, more importantly, make jobs more enjoyable.  We also can’t ignore the fact that it renders moot a lot of the specialized skills that traditionally defined the role of a network engineer.  If you’re interested in hearing more about that debate I highly recommend reading the excellent piece by  Tech Target exploring how this shift to greater automation isn’t removing the need for network expertise but rather evolving what those skills are to fit a world of ML (machine learning), AI and of course IOT.

Want to learn more?  Check out these sources:

• http://searchitoperations.techtarget.com/definition/zero-touch-provisioning-ZTP
• https://blog.digitalocean.com/zero-touch-provisioning-how-to-build-a-network-without-touching-anything/
• https://www.reddit.com/r/networking/comments/6xopp9/zero_touch_provsioning/

Terminology Tuesday is a new blog series.  What would you like to hear defined?  Let us know in the comments or, as always, reach out to @vmwarensx.

The post Terminology Tuesday Presents: ZTP appeared first on Network Virtualization.

As applications and data continue to be distributed more broadly from the data center to the edge, customers are increasingly relying on software-defined wide-area networks (SD-WANs) versus traditional networking for flexible, secure connectivity.  It’s for this reason that I am pleased to share that we officially closed our acquisition of VeloCloud Networks today, bringing their industry-leading, cloud-delivered SD-WAN solution to our growing software-based networking portfolio. The acquisition of VeloCloud significantly advances our strategy of enabling customers to run, manage, connect and secure any application on any cloud to any device.

VMware NSX was a game changer in the industry, and it has become the industry-leading implementation of network virtualization. Customers choose NSX because it delivers network and security services closest to the application. By adding VeloCloud’s SD-WAN solutions to our portfolio, we are extending our value in the enterprise and increasing our relevance with service providers by offering end-to-end automation, application continuity and security from data center to cloud edge. VeloCloud will bring the same properties to the wide-area network with an SD-WAN solution that provides full visibility, metrics, control and automation of all endpoints, resulting in better performance and availability for enterprise and cloud applications.

If you are a business that needs to securely support application growth, network agility, and simplified branch and end-point implementations while delivering high-performance, reliable access to cloud services, private data centers and SaaS-based enterprise applications, I encourage you to reach out to your VMware representative to learn more about our new SD-WAN solution.

And service provider partners, including those currently using the VeloCloud SD-WAN solution, talk with us about how together we can help you increase competitiveness and service innovation. With VeloCloud, we can help you by delivering elastic transport, performance for cloud applications and a software-defined edge that can orchestrate multiple services to meet your customers’ needs.

Beginning immediately, you now have access to a proven SD-WAN solution from VMware, and I encourage you to reach out to your VMware rep to start learning how VMware’s Cloud-Delivered SD-WAN can start paying immediate dividends to your business.

Jeff Jennings
SVP and GM, Networking and Security Business Unit
VMware

The post VMware Closes Acquisition of VeloCloud Networks appeared first on Network Virtualization.

I prior shared this post on the LinkedIN publishing platform and my personal blog at HumairAhmed.com. There has been a lot of interest in the VMware Cloud on AWS  (VMC on AWS) service since its announcement and general availability. Writing this brief introductory post, the response  received confirmed the interest and value consumers see in this new service, and I hope to share more details in several follow-up posts.

VMware Software Defined Data Center (SDDC) technologies like vSphere ESXi, vCenter, vSAN, and NSX have been leveraged by thousands of customers globally to build reliable, flexible, agile, and highly available data center environments running thousands of workloads. I’ve also discussed prior how partners leverage VMware vSphere products and NSX to offer cloud environments/services to customers. In the VMworld Session NET1188BU: Disaster Recovery Solutions with NSX, I discussed how VMware Cloud Providers like iLand and IBM use NSX to provide cloud services like DRaaS. In 2016, VMware and AWS announced a strategic partnership, and, at VMworld this year, general availability of VMC on AWS was announced; this new service, and, how NSX is an integral component to this service, is the focus of this post.

With VMC on AWS, customers can now leverage the best of both worlds – the leading compute, storage, and network virtualization stack enabling enterprises for SDDC can now all be enabled with a click of a button on dedicated, elastic, bare-metal, and highly available AWS infrastructure. That’s pretty cool, and, since it’s a managed service by VMware (customers don’t have root access to hosts/management components), customers can focus on the apps and let VMware handle the management/maintenance of the infrastructure and SDDC components.

Figure 1: Create SDDC on VMC on AWS

Deploying a vSphere environment with ESXi, vCenter, vSAN, NSX all included, configured, and working has never been so easy. Once you are setup with VMC access and have ability to deploy SDDCs, you will see a screen like the below. From here it’s as simple as clicking the Create SDDC button, linking to your AWS account and making some very basic selections such as VPC and subnet to link to/use with the SDDC.

Just like that, a SDDC is deployed and available complete with all infrastructure components and configuration – vSphere ESXi hypervisors, vCenter, NSX Manager, NSX Controllers, NSX Edges, and vSAN.

Once deployment is complete, you will see a new SDDC under the SDDCs tab with a brief summary view of the resource utilization of the respective SDDC. Below you can see I have already deployed a SDDC in the US West (Oregon) region.

Today, two AWS regions are available, US West (Oregon) and US East (N. Virginia) with more regions planned for the near future. The US East (N. Virginia) region was announced recently at AWS re:Invent 2017. Some pretty heavy duty servers are provided with a minimum of 4 hosts per SDDC. Each host has 2 CPUs, 36 cores, 72 hyper-threads, 512GB RAM, NVMe attached flash storage (3.6 TB cache plus 10.7 TB raw capacity tier).

Figure 2: Deployed SDDC(s) on VMC

Clicking the title of the SDDC takes you to the summary dashboard view of the SDDC as shown below.

Figure 3: Deployed SDDC “VMC SDDC 1” on VMC

Clicking the Network tab you can see from the auto-generated diagram that initially VMC is connected to the respective AWS VPC configured but no connectivity is yet configured to any on-prem environment. From further below on the same Network tab additional configuration can be done for firewall, NAT, VPN, etc. What’s important to note here is all these networking services used by VMC on AWS are enabled by NSX – you get NSX logical networks, firewall/security capabilities, NAT, VPN, etc. Some of this configuration will be covered later in the post. Note below, the default Deny All firewall policies configured within the environment for a zero-trust security model.

Figure 4: VMC Default Setup

In the below screen shot, you can see I have setup connectivity to on-prem. In this example, I leverage IPSEC VPN to connect to on-prem. You can see I have two IPSEC VPN connections – one for management/ESXi traffic and one for compute/workload traffic. Within VMC, a seperate NSX Edge is used for both the Management (MGW) and Compute (CGW) Gateway.

Figure 5: VMC IPSEC Setup

For the MGW IPSEC VPN configuration shown below, it can be seen that the Local Gateway IP is the public IP address assigned to the MGW Edge during SDDC creation time. The Remote Gateway Public IP is the public IP address for the on-prem VPN endpoint. The Local Network is the local VMC network that will be reachable from on-prem and the Remote Networks is what is reachable from VMC to on-prem. The respective traffic will still need to be allowed through MGW Edge firewall.

Note, the vCenter Management rule allowing for VMC vCenter management access from an external client; the external client in this case has the IP address of 204.237.202.117. The CGW IPSEC VPN configuration will be covered later in this post.

Figure 6: VMC MGW IPSEC Configuration

I can also configure Hybrid Linked Mode (HLM) between VMC and my on-prem vCenter to allow for cold migration of workloads over IPSEC VPN; in this case the cold migration traffic would traverse the MGW IPSEC VPN connection.

Figure 7: VMC HLM Setup

At AWS re:Invent 2017 new capabilities of L2VPN and AWS Direct Connect were also announced. See here for additional details.

The below screenshot from my lab environment show my VMC vCenter; it can be seen I have created three logical networks or VXLAN-backed networks: VMC_Web, VMC_App, and VMC_DB.

Figure 8: Created NSX Logical Networks on VMC

A logical network can be created by simply clicking the Add button and specifying the respective network info as shown below.

When a logical network is created, the connectivity and routing is all automated. The networks are automatically connected to the Compute Gateway distributed logical router (DLR) – a logical interface (LIF) is automatically configured on the DLR, and the routes to reach the logical networks are automatically configured in the Compute Gateway DLR/NSX Edge for both East/West and North/South connectivity. Since the topologies in VMC are prescriptive, all of this can be automated and there is no need for a DLR Control VM or routing protocols inside the VMC environment.

I have also deployed VMs in VMC and placed them on the respective NSX logical networks created above. Below I show the VMs VMC_Web_VM_1 and VMC_App_VM_1 on their respective logical networks.

Figure 10: “VMC_Web_VM_1” Deployed on Host “esx-2.sddc-35-162-46-174.vmc.vmware.com”

Figure 11: “VMC_App_VM_1” Deployed on Host “esx-2.sddc-35-162-46-174.vmc.vmware.com”

Above, you can see that the VMC_Web_VM_1 and VMC_App_VM_1 are currently on the same VMC ESXi host, esx-2.sddc-35-162-46-174.vmc.vmware.com. Below I vMotion the VMC_App_VM_1 VM to VMC ESXi host esx-0.sddc-35-162-46-174.vmc.vmware.com and ensure it is vMotioned to the same NSX logical network which is spanning across all ESXi hosts to ensure consistent networking.

Figure 12: Migrating “VMC_App_VM_1” VM

Below, I select the VMC destination ESXi host esx-0.sddc-35-162-46-174.vmc.vmware.com as the destination.

Figure 13: vMotioning “VMC_App_VM_1 VM” to Host “esx-0.sddc-35-162-46-174.vmc.vmware.com”

I ensure the destination network is the same and click through the rest of the workflow to initiate the vMotion.

Figure 14: Selecting Destination Network for VMotion

Below, I show that the VMC_App_VM_1 VM has been vMotioned to VMC ESXi host esx-0.sddc-35-162-46-174.vmc.vmware.com.

Figure 15: “VMC_App_VM_1” VM vMotioned to VMC ESXi Host “esx-0.sddc-35-162-46-174.vmc.vmware.com”

Below, from my VMC_Web_VM_1 VM on the VMC_Web logical network, you can see I can ping the the VMC_App_VM_1 on the VMC_App logical network as expected.

Figure 16: “VMC_Web_VM_1” VM Pinging “VMC_App_VM_1” VM

Since I have connected VMC to on-prem via IPSEC VPN, I can also communicate to my workloads on-prem. My current setup using IPSEC VPN for the MGW and CGW gateways is shown below.

Figure 17: Lab Setup Using IPSEC VPN for the MGW and CGW Gateways

On-Prem I have VMs that need to be able to communicate to the Web VMs on the VMC VMC_Web logical network.

In this setup, the MGW IPSEC VPN connection is used for management and ESXi traffic and the CGW IPSEC VPN connection is used for compute/workload traffic. With VMC, policy-based IPSEC VPN is used. Thus, in my CGW IPSEC VPN configuration, I expose the VMC_Web as the Local Network as shown below so my on-prem workloads can communicate with my compute workloads on the VMC_Web network in VMC.

Also, note, for this test I also allow for ICMP traffic through the CGW Edge firewall for the respective workloads. The Remote Networks is the compute/workloads reachable from VMC to on-prem. Similar to MGW, the Local Gateway IP is the public IP address assigned to the CGW Edge during SDDC creation time, and the Remote Gateway Public IP is the public IP address for the on-prem VPN endpoint.

Figure 18: VMC CGW IPSEC Configuration

On-prem, I have a VM (10.114.223.70) on a VLAN-backed network. Below it can be seen the on-prem VM can communicate to the VMC_Web_VM_1 (10.61.4.1) on the VMC_Web network.

Figure 19: Communication Between On-prem VM and the “VMC_Web_VM_1” VM on the “VMC_Web” network

My on-prem VMs are now able to communicate to my Web VMs on VMC. I can also enable VMs/workloads on VMC to communicate directly out to the Internet. I do this by first requesting a Public IP address within VMC and then configuring NAT. In this case, I configure a 1:many NAT rule for my entire VMC_Web CIDR block. I also ensure the correct security policies are applied to allow for DNS and communication via HTTP/HTTPS.

Figure 20: VMC CGW – NAT 1:Many Configuration

Figure 21: VMC CGW – Request Public IP Address

You can see below I’m able to access the VMware.com website from my VMC_Web_VM_1 (10.61.4.1) VM.

Figure 22: “VMC_Web_VM_1” VM Communication to Internet

For more information on VMC on AWS, and how to get started check-out the VMC on AWS Documentation page.

The post VMware SDDC with NSX Expands to AWS appeared first on Network Virtualization.

Data Gravity is a concept first coined by Dave McCrory to describe the tendency of data to attract more data, applications and services.  As you may have guessed from the name, this principle has many parallels to Newton’s Theory of Universal Gravitation.

The basic premise is that a singular piece of data isn’t meaningful but with more data (metadata as it’s generally called) additional context (and therefore more meaning) can be derived.  When all that data is bundled with more applications and services, one can harness a considerable amount of power as evidenced by today’s trends towards data and analytics.

For example, let’s take this piece of data: 0.  Although we know what zero means conceptually, we don’t have any way to determine how we should feel about it.  Without any context just knowing the number 0 is essentially worthless.  If, for instance you were to know the additional data of “inventory of toy Elmos” + [insert where you live] you’d know that you need to make an only order and ASAP.

Data for larger institutions is just like this, except the concept of “friction” plays a larger role.  Data Friction refers to the challenge in moving data once it’s stored in one location.  That friction becomes stronger the more data is stored (similar to inertia).  Once you have your data stored somewhere, clustered with data points that make it meaningful, it’s unlikely that you’d move it to another location.

Dave McCrory does an excellent job connecting this theory of Data Gravity to larger scientific concepts so I highly recommend reading the links in the “learn more” section.

Want to learn more?  Check out these sources:

• https://datagravity.org/
• https://www.youtube.com/watch?v=9KmkTW0wpIE&feature=youtu.be
• https://www.tableau.com/about/blog/2017/3/what-data-gravity-anyway-67725

Welcome to Terminology Tuesday.  Our weekly blog   What would you like to hear defined?  Let us know in the comments or, as always, reach out to @vmwarensx.

The post Terminology Tuesday Presents: Data Gravity appeared first on Network Virtualization.