Category Archives: NSX

vCloud Director SP 8.20 – NSX Advanced Networking Overview

Many, including myself thought that the day would never come where we would be talking about a new UI for vCloud Director…but a a month on from the 8.20 release of vCloud Director SP (which was the 8th major release of vCD) I’m happy to be writing about the new Advanced Networking features of 8.20 based on NSX-v. Full NSX compatibility and interoperability has been a long time coming, however the wait has been worthwhile as the vCloud Director team opted to fully integrate the network management into the vCD Cloud Cells over the initial approach that had a seperate appliance acting as a proxy between the NSX Manager and vCD Cells.

But before I dive into the new HTML5 goodness, I thought it would be good to recap the Advanced Networking Services of vCD and how we got to where we are today…

No More vShield…Sort Of:

As everyone should know by now, the vCloud Networking & Security was made end of life late last year and from the release of vCD SP 8.10 vShield Edges should have been upgraded to their NSX equivalents. These Edges will remain as basic Edges within vCloud Director and even though at the backend they would be on NSX-v versioning, no extra features or functionality beyond what was available in the existing vCD portal would be available to tenants.

  • DHCP
  • NAT
  • Firewall
  • Static Routing
  • IPSec VPN
  • Basic Load Balancer

The version of NSX-v deployed dictates the build number of the NSX Edge, however as can be seen below it’s still listed as a vShield Edge in vCenter.

As anyone who has worked closely would know, NSX-v has a lot of vShield DNA in it and in truth it’s more vShield than NSX when talking about the features that pertain to vCloud Director. However the power of NSX-v can be taken advantage of once an basic edge is upgraded to an Advanced Edge.

Advanced Edge Services:

Before the major UI additions that came with vCD SP 8.20 the previous 8.10 version did give us a taste of what was to come with the introduction of a new menu option when you right clicked on an Edge Gateway.

This option was greyed out unless you where running the initial beta of the Advanced Networking Services or ANS. The option can be executed by anyone with the rights to upgrade the edge gateway, but by default this can only be done by a System Administrator or the Org Admin. So it’s worthwhile double checking the roles you have allocated to your tenant’s to ensure that these upgrades can be controlled.

Once you click on the Convert to Advanced Gateway option you get a warning referring to a VMwareKB that warns you about an API change that may make previous calling methods obsolete. Something to take note of for anyone automating this process. On execution of this conversion there is no physical change to the Virtual Machine, however if you now click on the Edge Gateway Services option of the Edge Gateway you will be taken to the new HTML5 Web Interface for NSX Advanced Networking Services to access all the advanced features:

  • Firewall
  • DHCP
  • NAT
  • Routing (Dynamic)
  • Load Balancer (Advanced)
  • SSL VPN Plus
  • Certificates
  • Grouping Objects
  • Statistics
  • Edge Settings

All new Advanced Networking features are configured from the new HTML5 web interface which retains the base vCD URL but now adds:

/tenant/network-edges/{ID}?org=ORGNAME

Everything is self contained the tenant doesn’t have to authenticate again to get to the new user interface. However, if you just upgrade the Edge and go to configure the Advanced Network Services out of the box you will only see a couple of the items listed above.

In order to use the new features a System Administrator must use the vCloud API to grant the new rights that the organisation requires. This process has been explained very well by my good friend Giuliano Bertello here. This process uses the vCloud API to Grant Distributed Firewall and Advanced Networking Services Rights to roles in vCloud Director 8.20 using the new granular role based access control mechanisms that where introduced in 8.20. Once configured your tenant’s can now see all the services listed above to configure the Edge Gateway.

Organisational Distributed Firewall:

Something that is very much new in the 8.20 release is the ability to take advantage of mircosegmentation using the NSX-v Distributed Firewall service. The ability to configure organisation wide rules logically, without the need for a virtual Edge Gateway is a significant step forward for vCD tenants and I hope that this feature enhancement is exposed by service providers and it’s value sold to their tenants. To access the Distributed Firewall, in the Virtual Datacenters windows of the Administration tab, right click on the Virtual Datacenter name and select Manage Firewall.

Once again you will be taken to the new HTML5 user interface and once the correct permissions have been applied to the user you can enable the Distributed Firewall and start configuring your rules. The URL is slightly different to the Edge Gateway URL:

/tenant/dwf/{ID}?org=ORGNAME

But the look and feel is familiar.

Conclusion:

vCloud Director SP 8.20 has finally delivered on the what most members of the vCloud Air Network had wanted for some time…that is, full NSX interoperability and feature set access as well as a new user interface. Over the next few weeks, I am going to expand on all the features of the Advanced and Distributed Networking features of vCD and NSX and walk through how to configure elements through the UI and API as well as give a looks into what’s happening at the backend in terms of how NSX stores rules and policy items for vCD tenant use.

Compatibility with vSphere 6.5 and NSX-v 6.3.x:

vCloud Director SP 8.20 is compatible with vSphere 6.5 and NSX 6.3.0 and supports full interoperability with other versions as shown in the VMware Product Interoperability Matrix. As of vCD 8.20 GA, vCD 8.20 passed the functional interoperability test and limited scale testing for these versions:

  • vCD 8.20 with vSphere 6.0 and NSX 6.3.0
  • vCD 8.20 with vSphere 6.5 and NSX 6.3.0

References:

https://kb.vmware.com/kb/2149042
https://kb.vmware.com/kb/2147625

Released: vCloud Director SP 8.20 with HTML5 Goodness!

This week, VMware released vCloud Director SP version 8.20 (build 5070630) which marks the 8th Major Release for vCloud Director since 1.0 was released in 2010. Ever since 2010 the user interface give or take a few minor modifications and additions has been the same. It also required flash and java which has been a pain point for a long time and in someways unfairly contributed towards a negative perception around vCD on a whole.  It’s been a long time coming but vCloud Director finally has a new web UI built on HTML5 however this new UI is only exposed when accessing the new NSX integration which is by far and away the biggest addition in this release.

This NSX integration has been in the works for a while now and has gone through a couple of iterations within the vCloud product team. Initially announced as Advanced Networking Services which was a decoupled implementation of NSX integration we now have a fully integrated solution that’s part of the vCloud Director installer. And while the UI additions only extend to NSX for the moment it’s brilliant to see what the development team have done with the Clarity UI (tbc). I’m going to take a closer look at the new NSX features in another post, but for the moment here are the release highlights of vCD SP 8.20.

New Features:

  • Advanced Edge Gateway and Distributed Firewall Configuration – This release introduces the vCloud Director Tenant Portal with an initial set of controls that you can use to configure Edge Gateways and NSX Distributed Firewalls in your organization.
  • New vCloud Director API for NSX – There is a new a proxy API that enables vCloud API clients to make requests to the NSX API. The vCloud Director API for NSX is designed to address NSX objects within the scope of a vCloud Director tenant organization.
  • Role Administration at the Organization Level – From this release role objects exist in each organization. System administrators can use the vCloud Director Web Console or the vCloud API to create roles in any organization. Organization administrators can use the vCloud API to create roles that are local to their organization.
  • Automatic Discovery and Import of vCenter VMs – Organization VDCs automatically discover vCenter VMs that exist in any resource pool that backs the vDC. A system administrator can use the vCloud API to specify vCetner resource pools for the vDC to adopt. vCenter VMs that exist in an adopted resource pool become available as discovered vApps in the new vDC.
  • Virtual Machine Host Affinity – A system administrator can create groups of VMs in a resource pool, then use VM-Host affinity rules to specify whether members of a VM group should be deployed on members of a vSphere host DRS Group.
  • Multi-Cell Upgrade – The upgrade utility now supports upgrading all the cells in your server group with a single operation.

You can see above that this release has some major new features that are more focused on tenant usability and allow more granular and segmented controls of networks, user access and VM discovery. The Automatic VM discovery and Import is a significant feature that goes along with the 8.10 feature of live VM imports and helps administrators import VM work loads into vCD from vCenter.

“VMware vCloud Director 8.20 is a significant release that adds enhanced functionality.  Fully integrating VMware NSX into the platform allows edge gateways and distributed firewalls to be easily configured via the new HTML5 interface.  Additional enhancements such as seamless cell upgrades and vCenter mapping illustrate VMware is committed to the platform and to vCloud Air Network partners.”

A list of known issues can be found in the release notes and i’d like to highlight the note around Virtual Machine memory for the vCD Cells…I had my NestedESXi lab instances crash due to memory pressures due to the fact the VMs where configured with only 5GB of RAM. vCloud Director SP 8.20 needs at least 6GB so ensure your cells are modified before you upgrade.

Well done the the vCloud Director Product and Development team for this significant release and I’ll look to dig into some of the new feature in detail in upcoming posts. You can also read the offical vCloud Blog release post here. I’m looking forward to what’s coming in the next release now…hopefully more functionality placed into the HTML5 UI and maybe integration with VMwareonAWS 😉

References:

http://pubs.vmware.com/Release_Notes/en/vcd/8-20/rel_notes_vcloud_director_8-20.html

https://www.vmware.com/support/pubs/vcd_sp_pubs.html

https://blogs.vmware.com/vcloud/2017/02/vmware-announces-general-availability-vcloud-director-8-20.html

NSX Bytes: NSX-v 6.3 Host Preparation Fails with Agent VIB module not installed

NSX-v 6.3 was released last week with an impressive list of new enhancements and I wasted no time in looking to upgrades my NestedESXi lab instance from 6.2.5 to 6.3 however I ran into an issue that at first I thought was related to a previous VIB upgrade issue caused by VMware Update Manager not being available during NSX Host upgrades…in this case it presented with the same error message in the vCenter Events view:

VIB module for agent is not installed on host <hostname> (_VCNS_xxx_Cluster_VMware Network Fabri)

After ensuring that my Update Manager was in a good state I was left scratching my head…that was until some back and forth in the vExpert Slack #NSX channel relating to a new VMwareKB that was released the same day as NSX-v 6.3.

https://kb.vmware.com/kb/2053782

This issue occurs if vSphere Update Manager (VUM) is unavailable. EAM depends on VUM to approve the installation or uninstallation of VIBs to and from the ESXi host.

Even though my Upgrade Manager was available I was not able to upgrade through Host Preparation. It seem’s like vSphere 6.x instances might be impacted by this bug but the good news is there is a relatively easy workaround as mentioned in the VMwareKB that bypasses the VUM install mechanism. To enable the workaround you need to enter into the Managed Object Browser of the vCenter EAM by going to the following URL and entering in vCenter admin credentials.

https://vCenter_Server_IP/eam/mob/ 

Once logged in you are presented with a (or list of) agencies. In my case I had more than one, but I selected the first one in the list which was agency-11

The value that needs to be changed is the bypassVumEnabled boolean value as shown below.

To set that flag to True enter in the following URL:

https://vCenter_Server_IP/eam/mob/?moid=agency-x&method=Update

Making sure that the agency number matches your vCenter EAM instance. From there you need to change the existing configuration for that value by removing all the text in the value box and invoking the value listed below:

Once invoked you should be able to go back into the Web Client and click on Resolve under the Cluster name in the Host Preparation Tab of the NSX Installation window.

Once done I was in an all Green state and all hosts where upgraded to 6.3.0.5007049. Once all hosts have been upgraded it might be a useful idea to reverse the workaround and wait for an official fix from VMware.

References:

https://kb.vmware.com/kb/2053782

NSX Bytes: NSX for vSphere 6.3 and NSX-T 1.1 Release Information

VMware’s NSX has been in the wild for almost three years and while the initial adoption was slow, of recent times there has been a calculated push to make NSX more mainstream. The change in licensing that happened last year has not only been done to help drive adoption by traditional VMware customers running vSphere that previously couldn’t look at NSX due to price but also the Transformers project has looked to build on Nicira’s roots in the heterogeneous hypervisor market and offer network virutalization beyond vSphere and beyond Open source platforms and into the public cloud space. The vision for VMware with NSX is to manage security and connectivity for heterogeneous end points through:

  • Security
  • Automation
  • Application Continuity

NSX has seen significant growth for VMware over the past twelve to eighteen months driven mostly from customer demand focusing around micro-segmentation, IT automation and efficiency and also the need to have extended multiple data centre locations that can be pooled together. To highlight the potential that remains with NSX-v less that 5% of the total available vSphere install base has NSX-v installed…and while that could have something to do with the initial restrictions and cost of the software it still represents enormous opportunity for VMware and their partners.

Last week the NSX vExpert group was given a first look at what’s coming in the new releases…below is a summation of what to expect from both NSX-v 6.3 and NSX-T 1.1. Note that we where not given an indication on vSphere 6.5 support so, like the rest of you we are all waiting for the offical release notes.

[Update] vSphere 6.5 will be supported with NSX-v 6.3

Please note that VMware vSphere 6.5a is the minimum supported version with NSX for vSphere 6.3.0. For the most up-to-date information, see the VMware Product Interoperability Matrix. Also, see 2148841.

NSX for vSphere 6.3 Enhancements:

Security:

  • NSX Pre-Assessment Tool based on vRealize Network Insight
  • Micro-Segmentation Planning and application visibility
  • New Security Certifications around ICSA, FIPS, Common Criteria and STIG
  • Linux Guest VM Introspection
  • Increase performance in service chaining
  • Larger scalability of VDI up to 50K desktops
  • NSX IDFW for VDI
  • Active Directory Integration for VDI at scale

Automation:

  • Routing Enhancements
  • Centralized Dashboard for service and ops
  • Reduced Upgrade windows with rebootless upgrades
  • Integration with vRA 7.2 enhancing LB,NAT
  • vCloud Director 8.20 support with advanced routing, DFW, VPN
  • VIO Updates to include multi-vc deployments
  • vSphere Integrated Container Support
  • New Automation Frameworks for PowerNSX, PyNSXv, vRO

Application Continuity:

  • Multi-DC deployments with Cross VC NSX enhancements for security tags
  • Operations enhancements with improved availability
  • L2VPN performance enhancements for cross DC/Cloud Connectivity

Where does NSX-T Fit:

Given there was some confusion about NSX-v vs. NSX-t in terms of everything going to a common code base starting from the transformers release it was highlighted that VMware’s primary focus for 2017 hasn’t shifted away from NSX for vSphere and will still be heavily invested in to add new capabilities in and beyond 6.3 and that there will be a robust roadmap of new capabilities in future releases with support extended will into the future.

NSX-t’s main drivers related to new data centre and cloud architectures with more hetrogeneality driving a different set of requirements to that of vSphere that focuses around multi-domain environments leading to a multi-hypervisor NSX platform. NSX-t is highly extensible and will address more endpoint heterogeneity in future releases including containers, public clouds and other hypervisors. As you can see before the existing use cases for NSX-t are mainly focused around devops, micro-segmentation and multi-tenant infrastructure.

NSX-T 1.1 Brief Overview:

Again the focus is around private IaaS and multi-hypervisor support for development teams using dev clouds and employing more devops methodologies. There isn’t too much to write home about in the 1.1.0 release but there is some extended hypervisor support for KVM and ESXi, more single or multi-tenant support and some performance and resiliency optimizations.

Conclusion:

There is a lot to like about where VMware is taking NSX and both product streams offer strong network virtualization capabilities for customers to take advantage of. There is no doubt in my mind that the release of NSX-v 6.3 will continue to build on the great foundation laid by the previous NSX versions. When the release notes are made available I will do take a deeper look into all the new features and enhancements and tie them into what’s most useful for service providers.

Top Posts 2016

2016 is pretty much done and dusted and it’s been an good year for Virtualization is Life! There was a more modest 70% increase in site visits this year compared to 2015 and a 2600% increase in visits since I began blogging in 2012. In 2016 I managed to produce 124 posts (including this one) which was slightly up on the 110 I produced in 2015 and in doing so passed 300 total blogs since I started here. I was fairly consistent in getting out at least eight blogs per month with June being my most prolific month with sixteen blog posts published.

Looking back through the statistics generate via JetPack, I’ve listed the Top 10 Blog Posts from the last 12 months. This year the opinion pieces seemed to be of interest to my readers and there is still vCloud Director and NSX representation in the top ten with my Veeam articles doing well. Again it was interesting to see that two of the most generic (older posts) and certainly basic posts took out two of the top three spots. It shows that bloggers should not be afraid of blogging around simple topics as there is an audience that will appreciate the content and get value out of the post.

  1. NSX Edge vs vShield Edge: Part 1 – Feature and Performance Matrix
  2. Quick Post: E1000 vs VMXNET3
  3. vSphere 6.0 vCenter Server Appliance: Upgrading from 5.x
  4. ESXi Bugs – VMware Can’t Keep Letting This Happen!
  5. Nutanix Buying PernixData: My Critical Analysis
  6. New NSX License Tier Thoughts and Transformers
  7. CBT Bugs – VMware Can’t Keep Letting This Happen!
  8. Veeam 9 Released: Top New Features
  9. Veeam’s Next Big Thing – Veeam has Arrived!
  10. vCloud Director 8: New Features And A New UI Addition…

I was honoured to have this blog voted #44 in the TopvBlog2016 and even with all the controversy around the voting I still hold that as a significant outcome of which I am very proud and I’d like to thank the readers and supporters of this blog for voting for me! And thanks must also go to my site sponsors who are all listed on the right hand side of this page.

With me moving across to vendor land it’s going to be interesting to see if I can keep up the variety of posts as I “narrow” down my core focus…however I fully intend to keep on pushing this blog by keeping it strong to it’s roots of vCloud Director and core VMware technologies like NSX and vSAN. I have the Home lab and the drive to continue to produce content around the things I am passionate about…and that includes all things hosting and cloud now with a touch of availability 🙂

Stay tuned for an even bigger 2017!

#LongLivevCD

NSX Bytes: Important Bug in 6.2.4 to be Aware of

[UPDATE] In light of this post being quoted on The Register I wanted to clarify a couple of things. First off, as mentioned there is a fix for this issue (the KB should be rewritten to clearly state that) and secondly, if you read below, you will see that I did not state that just about anyone running NSX-v 6.2.4 will be impacted. Greenfield deployments are not impacted.

Here we go again…I thought maybe we where over these, but it looks like NSX-v 6.2.4 contains a fairly serious bug impacting VMs after vMotion operations. I had intended to write about this earlier in the week when I first became aware of the issue, however the last couple of days have gotten away from me. That said, please be aware of this issue as it will impact those who have upgraded NSX-v from 6.1.x to 6.2.4.

As the KB states, the issue appears if you have the Distributed Firewall enabled (it’s enabled and inline by default) and you have upgraded NSX-v from 6.1.x to 6.2.3 and above, though for most this should be applicable to 6.2.4 upgrades due to all this issues in 6.2.3. If VM’s are migrated between upgraded hosts they will loose network connectivity and require a reboot to bring back connectivity.

If you check the vmkernal.log file you will see similar entries to that below.

Cause

This issue occurs when the VSIP module at the kernel level does not handle the export_version deployed in NSX for vSphere 6.1.x correctly during the upgrade process.

The is no current resolution to the issue apart from the VM reboot but there is a workaround in the form of a script that can be obtained via GSS if you reference KB2146171. Hopefully there will be a proper fix in future NSX releases.

<RANT>

I can’t believe something as serious as this was missed by QA for what is VMware’s flagship product. It’s beyond me that this sort of error wasn’t picked up in testing before it was released. It’s simply not good enough that a major release goes out with this sort of bug and I don’t know how it keeps on happening. This one specifically impacted customers and for service providers or enterprises that upgraded in good faith, it puts egg of the faces of those who approve, update and execute the upgrades that results in unhappy customers or internal users.

Most organisations can’t fully replicate production situations when testing upgrades due to lack or resources or lack of real world situation testing…VMware could and should have the resources to stop these bugs leaking into release builds. For now, if possible I would suggest that people add more stringent vMotion tests as part of NSX-v lab testing before promoting into production moving forward.

VMware customers shouldn’t have to be the ones discovering these bugs!

</RANT>

[UPDATE] While I am obviously not happy about this issue coming in the wake of previous issues, I still believe in NSX and would recommend all shops looking to automate networking still have faith in what the platform offers. Bug’s will happen…I get that, but I know in the long run there is huge benefit in running NSX.

References:

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2146171

NSX Bytes: Updated – NSX Edge Feature and Performance Matrix

A question came up today around throughput numbers for an NSX Edge Services Gateway and that jogged my memory back to a previous blog post where I compared features and performance metrics between vShield Edges and NSX Edges. In the original post I had left out some key metrics, specifically around firewall and load balance throughput so thought it was time for an update. Thanks to a couple of people in the vExpert NSX Slack Channel I was able to fill some gaps and update the tables below.

A reminder that VMware has announced the End of Availability (“EOA”) of the VMware vCloud Networking and Security 5.5.x that kicked in on the September  of 19, 2016 and that vCloud Director 8.10 does not support vShield Edges anymore…hence why I have removed the VSE from the tables.

As a refresher…what is an Edge device?

The Edge Services Gateway (NSX-v) connects isolated, stub networks to shared (uplink) networks by providing common gateway services such as DHCP, VPN, NAT, dynamic routing, and Load Balancing. Common deployments of Edges include in the DMZ, VPN Extranets, and multi-tenant Cloud environments where the Edge creates virtual boundaries for each tenant.

Below is a list of services provided by the NSX Edge.

Service Description
Firewall Supported rules include IP 5-tuple configuration with IP and port ranges for stateful inspection for all protocols
NAT Separate controls for Source and Destination IP addresses, as well as port translation
DHCP Configuration of IP pools, gateways, DNS servers, and search domains
Site to Site VPN Uses standardized IPsec protocol settings to interoperate with all major VPN vendors
SSL VPN SSL VPN-Plus enables remote users to connect securely to private networks behind a NSX Edge gateway
Load Balancing Simple and dynamically configurable virtual IP addresses and server groups
High Availability High availability ensures an active NSX Edge on the network in case the primary NSX Edge virtual machine is unavailable
Syslog Syslog export for all services to remote servers
L2 VPN Provides the ability to stretch your L2 network.
Dynamic Routing Provides the necessary forwarding information between layer 2 broadcast domains, thereby allowing you to decrease layer 2 broadcast domains and improve network efficiency and scale. Provides North-South connectivity, thereby enabling tenants to access public networks.

Below is a table that shows the different sizes of each edge appliance and what (if any) impact that has to the performance of each service. As a disclaimer the below numbers have been cherry picked from different sources and are subject to change…I’ll keep them as up to date as possible.

NSX Edge (Compact) NSX Edge (Large) NSX Edge (Quad-Large) NSX Edge (X-Large)
vCPU 1 2 4 6
Memory 512MB 1GB 1GB 8GB
Disk 512MB 512MB 512MB 4.5GB
Interfaces 10 10 10 10
Sub Interfaces (Trunk) 200 200 200 200
NAT Rules 2000 2000 2000 2000
FW Rules 2000 2000 2000 2000
FW Performance 3Gbps 9.7Gbps 9.7Gbps 9.7Gbps
DHCP Pools 25 25 25 25
Static Routes 2048 2048 2048 2048
LB Pools 64 64 64 64
LB Virtual Servers 64 64 64 64
LB Server / Pool 32 32 32 32
IPSec Tunnels 512 1600 4096 6000
SSLVPN Tunnels 50 100 100 1000
Concurrent Sessions 64,000 1,000,000 1,000,000 1,000,000
Sessions/Second 8,000 50,000 50,000 50,000
LB Throughput L7 Proxy) 2.2Gbps 2.2Gbps 3Gbps
LB Throughput L4 Mode) 6Gbps 6Gbps 6Gbps
LB Connections/s (L7 Proxy) 46,000 50,000 50,000
LB Concurrent Connections (L7 Proxy) 8,000 60,000 60,000
LB Connections/s (L4 Mode) 50,000 50,000 50,000
LB Concurrent Connections (L4 Mode) 600,000 1,000,000 1,000,000
BGP Routes 20,000 50,000 250,000 250,000
BGP Neighbors 10 20 50 50
BGP Routes Redistributed No Limit No Limit No Limit No Limit
OSPF Routes 20,000 50,000 100,000 100,000
OSPF Adjacencies 10 20 40 40
OSPF Routes Redistributed 2000 5000 20,000 20,000
Total Routes 20,000 50,000 250,000 250,000

Of interest from the above table it doesn’t list any Load Balancing performance number for the NSX Compact Edge…take that to mean that if you want to do any sort of load balancing you will need NSX Large and above. To finish up, below is a table describing each NSX Edge size use case.

Use Case
NSX Edge (Compact) Small Deployment, POCs and single service use
NSX Edge (Large) Small/Medium DC or mult-tenant
NSX Edge (Quad-Large) High Throughput ECMP or High Performance Firewall
NSX Edge (X-Large) L7 Load Balancing, Dedicated Core

References:

https://www.vmware.com/files/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf

https://pubs.vmware.com/NSX-6/index.jsp#com.vmware.nsx.admin.doc/GUID-3F96DECE-33FB-43EE-88D7-124A730830A4.html

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2042799

First Look: vRealize Network Insight (Arkin)

Last year Arkin burst onto the scene offering a solution that focused on virtual and physical deep network analytics. Arkin was recognised at VMworld 2015 by nearly taking out the best of show and fast forward twelve months, Arkin was acquired by VMware with the product later rebadged as vRealize Network Insight. One of the products main strengths that attracted VMware into making the acquisition was it’s tight integration into NSX by way of a simple and intuitive user interface that lets admins easily manage and troubleshoot NSX while offering best practice checks that can guide users through VXLAN and firewall implementations and alert them to any issues in their design and implementation of NSX.

Arkin removes barriers to SDDC adoption and operation by providing converged visibility, and contextual analytics across virtual and physical, an ability to implement newer security models such as micro-segmentation, and by ensuring application uptime, while letting IT collaborate better. The platform helps IT organizations plan, operate, visualize, analyze, and troubleshoot their complex software-defined data center environments.

As vRealize Network Insight the key benefits are:

  • East-west traffic analytics for security and micro-segmentation design
  • Control and tracking to meet audit and compliance requirements for virtual distributed firewalls
  • 360 Overlay-underlay visibility and topology mapping
  • Extensive 3rd party physical switch integrations
  • VXLAN to VLAN logical path mappings
  • Advanced NSX Operations Management
  • Natural language search and enhanced user experience for rapid troubleshooting

What I was surprised to find when I was able to dig into the product was that it offered more than just Network insights…in fact it offered surprisingly deep analytics and metrics for Hosts and Virtual Machines that rival most similar products out on the market today.

Installation Overview:

To install Network Insight you download two OVA’s from MyVMware and deploy the two appliances into vCenter. It’s got an interesting setup that’s shown below and after deployment you are left with two appliances, a Platform, and a Proxy that have the following specifications.

Platform OVA

  • 6 CPU cores (reservation 3072) Mhz
  • 32 GigaBytes RAM (reservation)
  • 600 Gigabytes HDD (thin provisioned)

Proxy OVA

  • 2 CPU cores (reservation 1024 Mhz)
  • 4 Gigabytes RAM (reservation 4GB)
  • 100 Gigabytes HDD (thin provisioned)

A note before continuing…only Chrome is supported as a browser at this stage.

You start the install by deploying the Platform appliance…once the Platform OVA is deployed and the appliance VM settings have been configured you can hit the IP specified in the OVA deployment process and continue the installation.

After the license key has been validated you are then asked to Generate a shared secret that is used to pair the Platform with the Proxy appliance.

From here you can initiate the deployment of the Proxy appliance. During the OVA deployment you are asked to enter in the shared key before continuing to configure the appliance networking and naming. As shown below, the configuration wizard waits to detect the deployed Proxy appliance at which point the installation is complete and you can login.

The default username name is [email protected] with a password of admin.

When you login for the first time you are presented with a Product Evaluation pop up letting you know you are in NSX Assessment Mode and that you can switch to Full Product Mode at the bottom right of the window. NSX Assessment Mode is an interesting feature that looks like it will be used to install Network Insight as part of an on boarding or discovery engagement and produce reports on what is happening inside an NSX environment.

In either mode you need to register at least one vCenter and, if in a site with NSX, register the NSX Manager as well. As mentioned in the opening you can also plug into a small subset of popular physical networking equipment such as Cisco, Arista, DELL, Brocade and Juniper.

Once the vCenter has been connected and verified you then have the option to select the vDS and PortGroups you want to have monitored. This enabled Netflow (IPFIX) across all PortGroups selected…it does these changes live so be wary of any possible breaks in vDS traffic flow just in case.

Due to a rather serious PSOD bug in previous version of ESXi when Netflow is enabled, the configurator blocks any host that doesn’t meet the minimum ESXi builds as shown below.

Below is the minimum requirements for Network Insight to be configured and start collecting and analyzing.

Infrastructure

  • vCenter 5.5 or above
  • ESXi 5,5, update 2 (build 2068190) and above
  • ESXi 6.0, update 1b (3380124) and above
  • NSX for vSphere 6.1 or greater
  • Netflow enabled on vDS

Reading through the FAQ, you get to learn about IPFIX and how it’s used with the vDS to collect network traffic data…it’s worth spending some time going through the FAQ however I’ve pulled an overview on how it all works below.

IPFIX is an IETF protocol for exporting flow information. A flow is defined as a set of packets transmitted in a specific timeslot, and sharing 5-tuple values – source IP address, source port, destination IP address, destination port, and protocol. The flow information may include properties such as timestamps, packets/bytes count, Input/output interfaces, TCP Flags, VXLAN Id, Encapsulated flow information and so on.

 

Network Insight uses VMware VDS IPFIX to collect network traffic data. Every session has two paths. For example: Session A↔C has A→C packets and C→A packets. To analyze the complete information of any session, IPFIX data about packets in both the directions is required. Refer following diagram where VM-A is connected to DVPG-A and is talking to VM-C. Here DVPG-A will only provide data about the C→A packets, and DVPG-Uplink will provide data about A→C packets. To get the complete information of A’s traffic, Ipfix should be enabled on DVPG-A, DVPG-uplink

That wraps up this post…I’ll be looking at doing a followup post that looks at the Network Insight user interface and what information about network traffic, flows and routing can be viewed and analysed as well as taking a look at the surprisingly good VM, Host and Cluster level metrics

References:

http://www.arkin.net/

https://www.vmware.com/products/vrealize-network-insight.html

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vmware-vrealize-network-insight-faq.pdf

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vmware-vrealize-network-insight-user-guide.pdf

NSX Bytes: vCloud Director Can’t Deploy NSX Edges

Over the weekend I was tasked with the recovery of a #NestedESXi lab that had vCloud Director and NSX-v components as part of the lab platform. Rather than being a straight forward restore from the Veeam backup I also needed to downgrade the NSX-v version from 6.2.4 to 6.1.4 for testing purposes. That process was relatively straight forward and involved essentially working backwards in terms of installing and configuring NSX and removing all the components from vCenter and the ESXi hosts.

To complete the NSX-v downgrade I deployed a new 6.1.4 appliance and connected it back up to vCenter, configured the hosts, setup VXLAN, transport components and tested NSX Edge deployments through the vCenter Web Client. However, when it came time to test Edge deployments from vCloud Director I kept on getting the following error shown below.

Checking through the NSX Manager logs there was no reference to any API call hitting the endpoint as is suggested by the error detail above. Moving over to the vCloud Director Cells I was able to trace the error message in the log folder…eventually seeing the error generated below in the vcloud-container-info.log file.

As a test I hit the API endpoint referenced in the error message from a browser and got the same result.

This got me thinking that the error was either DNS related or permission related. After confirming that the vCloud Cells where resolving the NSX Manager host name correctly, as suggested by the error I looked at permissions as the cause of the 403 error. vCloud Director was configured to use the service.vcloud service account to connect to the previous NSX/vShield Manager and it dawned on me that I hadn’t setup user rights in the Web Client under Networking & Security. Under the Users section of the Manage Tab the service account used by vCloud Director wasn’t configured and needed to be added. After adding the user I retried the vCD job and the Edge deployed successfully.

While I was in this menu I thought I’d test what level of NSX User was required to for that service account to have in order to execute operations against vCloud Director and NSX. As shown below anything but NSX or Enterprise Administrator triggered a “VSM response error (254). User is not authorized to access object” error.

At the very least to deploy edges, you require the service account to be NSX Administrator…The Auditor and Security Administrator levels are not enough to perform the operations required. More importantly don’t forget to add the service account as configured in vCloud Director to the NSX Manager instance otherwise you won’t be able to have vCloud Director deploy edges using NSX-v.

 

 

NSX Bytes: NSX-v 6.2.4 Released …Important Upgrade!

NSX-v 6.2.4 was released the week before VMworld US so might have gotten somewhat lost in the VMworld noise…For those that where fortunate enough to not upgrade to or deploy a greenfield 6.2.3 site you can now safely do so without the nasty bugs that existed in the 6.2.3 build. In a nutshell this new build delivers all the significant features and enhancements announced in 6.2.3 without the dFW or Edge Gateway bugs that forced the build being pulled from distribution a few weeks back.

In terms of how and when to upgrade from previous versions the following table gives a great overview of the pathways required to get to 6.2.4.

The take away from the table above is that if possible you need to get onto NSX-v 6.2.4 as soon as possible and with good reason:

  • VMware NSX 6.2.4 provides critical bug fixes identified in NSX 6.2.3, and 6.2.4 delivers a security patch for CVE-2016-2079 which is a critical input validation vulnerability for sites that uses NSX SSL VPN.
  • For customers who use SSL VPN, VMware strongly recommends a review of CVE-2016-2079 and an upgrade to NSX 6.2.4.
  • For customers who have installed NSX 6.2.3 or 6.2.3a, VMware recommends installing NSX 6.2.4 to address critical bug fixes.

Prior to this release if you had upgraded to NSX-v 6.1.7 you where stuck and not able to upgrade to 6.2.3. The Upgrade matrix is now reporting that you can upgrade 6.1.7 to 6.2.4 as shown below.

I was able to validate this in my lab going from 6.1.7 to 6.2.4 without any issues.

NSX-v 6.1.4 is also fully supported by vCloud Director SP 8.0.1 and 8.10

References:

http://pubs.vmware.com/Release_Notes/en/nsx/6.2.4/releasenotes_nsx_vsphere_624.html

http://www.theregister.co.uk/2016/07/22/please_dont_upgrade_nsx_just_now_says_vmware/

« Older Entries