Customer interest is increasing well beyond just what our standalone products offer. In fact, customer don’t care about the products, they care about the solution. IaaS with SDN as a solution is extremely popular. Therefore, this is focused on joint solution of vRA, vRO, NSX-v and 3rd party options.

1. 1
Éamon Ryan Prasenjit Sarkar
Senior Solutions Architect Staff Solutions Architect
IaaS with SDN
The Good, Bad and Confusing

2. 2
Purpose and Audience
Purpose
• Customer interest is increasing well beyond just what our standalone products offer
• In fact – customer don’t care about the products, they care about the solution
• IaaS with SDN as a solution – extremely popular
• Therefore, focus on joint solution: vRA, vRO, NSX-v and 3rd party options
Intended Audience
• Anyone dealing with this joint solution

3. 3
Learning Outcomes

4. 4
Life of a Network Engineer!!! ;-)
Not everything in life is fair

5. 5
Distributed Switch
 A network path defines where exactly a VM would connect.
 You cannot use routed or NATed Profiles without vCNS or
NSX. Only External Profiles would be used
Without NSX, DvPortgroup
becomes Network path
MMBP1 MMBP2
What is Network Path for vRealize Automation? Without NSX-V

6. 6
To Core Switches
Distributed-Router-01
Perimeter-Gateway-01
 The External Network Profile has to be associated on the Logical Switch connected on the Uplink of
the DLR
Associate External Network profile here
Distributed Router Model

7. 7
To Core Switches
Distributed-Router-01
Perimeter-Gateway-01  The External Network Profile has to be associated on
the Logical Switch connected on the Uplink of the DLR
Associate External Network profile here
Advantage of this model:
 You can automatically redistribute Connected
Routes on DLR into OSPF
 You can make use of ECMP
Distributed Router Model – Difference in behavior for Routed Profile

8. 8
To Core Switches
Perimeter-Gateway-01
 The External Network Profile has to be associated on the Logical Switch connected on the Internal
Interface of the Perimeter Edge
Associate External Network profile here
Perimeter Edge Model

9. 9
To Core Switches
Perimeter-Gateway-01  The External Network Profile has to be associated on
the Logical Switch connected on the Uplink of the DLR
Associate External Network profile here
One Drawback in this Model:
 You cannot automatically advertise networks below the
application edge to devices located upwards(Perimeter
GW, Core Switches)
 Cannot make use of ECMP
Perimeter Edge Model – Difference in behavior for Routed Profile

10. 10
Workload Distributed
Switch
MMBP1
Transit Logical Switch Core DvPortgroup
Distributed Router 01
Perimeter GW 01
Mgmt Distributed Switch
What is Network Path for vRealize Automation? With NSX-V

11. 11
Transit-Logical-switch
Transit-Logical-switch-01
Network Path:
Ext-DLR->Distributed Gateway
Network Path:
Ext-ESG->Perimeter-Gateway-01
Test-Routed-Profile Test-NAT-Profile
To Core Switches
Distributed-Router-01
Perimeter-Gateway-01Perimeter-Gateway-02Perimeter-Gateway-03
The Complete Story

12. 12
NSX with vRA – On Demand Deployment Model
Provider Logical
Router (HA)
External
Networks
 2 Tiers of Routing
• Distributed Logical Router or NSX
Edge for Application Router
• NSX Edge for Provider Router
 Dynamic Routing externally
 Dynamic Routing (DLR), Static
Routing or NAT internally
(Edge)
Dynamic Routing
(OSPF, BGP)
Transit Uplink 192.168.10.0/24 (External Network Profile)
Static Route added
automatically
 On Demand Model is typically used for more
dynamic Test/Dev style workloads, particularly
when there is a requirement for overlapping IP
addresses
Dynamic Routing
(OSPF, BGP)
Web Logical
Switch
(Routed)
DB Logical
Switch
(Routed)
MMS 1
Routed
App LS
(Routed)
172.16.10.0/29 172.16.10.8/29 172.16.10.16/29
Web Logical
Switch (Routed) App LS (Routed) DB LS (Routed)
MMS 2
Routed
172.16.20.0/29 172.16.20.8/29 172.16.20.16/29
Web Logical
Switch
(NAT)
App LS (Private) DB LS (Private)
MMS 3
NAT & Private
172.16.100.0/24 172.16.101.0/24 172.16.102.0/24
Web Logical
Switch
(NAT) App LS (Private) DB LS (Private)
MMS 4
NAT & Private
172.16.100.0/24 172.16.101.0/24 172.16.102.0/24
DLR

13. 13
NSX with vRA – Pre Created Deployment Model
Dynamic Routing
(OSPF, BGP)
External
Networks
 2 Tiers of Routing
• Distributed Logical Router for
Application Router
• NSX Edge for Provider Router
 Dynamic Routing
 Use existing LS as external
network profiles
 One Arm Load Balancing
on demand (vCNS Edge in 6.0,
NSX Edge in 6.1)
Prod-01
Logical Switch
Dev-01
Logical Switch
LB LB
LB
Dynamic Routing
(OSPF, BGP)
Transit Uplink
192.168.10.0/24
(External Network Profile)
Scale Out Provider
Logical Router (NSX 6.1)
MMS 1 VMs
MMS 2 VMs
MMS 3 VMs
 Pre-Created model is typically used with Production or more
static workloads and the application topology is multi-tier on a
single network
Prod Web SG A Prod App SG A Prod DB SG A Dev Web SG A Dev App SG A Dev DB SG A
Dev Web SG B
Dev App SG B
Dev DB SG B
Distributed Logical Router
Prod Web SG B Prod App SG B
Prod DB SG B
MMS 4 VMs
LB
172.16.50.0/24 (External Network) 172.16.60.0/24 (External Network)
Dynamic Routing
(OSPF, BGP)
with ECMP
Dynamic Routing
(OSPF, BGP)
with ECMP
Provider Logical
Router (NSX 6.1)

14. 14
NSX Security Groups & Security Policies
 End-Users and Cloud Admins are able to select pre-defined security policies already
approved by the Security Admin in NSX
 Security policies are applied to one or more security groups where workloads are
members
 These security groups are created on-demand by vRA at deployment time
WHAT
you want
to protect
HOW you
want to
protect it
SECURITY GROUP
SECURITY POLICY
Members (VM, vNIC)
and Context (user
identity, security
posture)
“Standard Web”
 Firewall – allow
inbound HTTP/S,
allow outbound ANY
 IPS – prevent
DOS attacks,
enforce acceptable
use
Services (Firewall,
antivirus, IPS etc.) and
Profiles (labels
representing specific
policies)

15. 15
NSX Security Tags
 NSX Security Tags can be used to define IF/THEN workflows for security services, e.g. IF
user selects a “Finance” application, THEN place the VM in the “Finance” security group
INFRASTRUCTURE
APPS
Security Admin
“Finance Policy”
 IF Tag =
Finance THEN
add VM to
Security Group
“Finance” with
Security Policy
“Finance”
Step 1: Security Admin pre-defines a
Security Group and a Security Policy with
dynamic membership based on a Security
Tag
“Finance App”
 Set Tag
“Finance”
Cloud Admin
Multi-
Machine
Blueprint
Step 2: Cloud Admin creates a Multi-
Machine Blueprint which sets a Security
Tag. Cloud Admin needs no knowledge
of Security Groups or Security Policies.

16. 16
NSX Security Tags
 NSX Security Tags can be used to define IF/THEN workflows for security services, e.g. IF
user selects a “Finance” application, THEN place the VM in the “Finance” security group
INFRASTRUCTURE
APPS
Requests
“Finance App”
Service
Catalog
Step 3: End-User requests Application
via the Service Catalog
Cloud
Consumer
Step 4: VM is automatically deployed
with its Security Tag WHAT
you want
to protect
Step 5: VM is dynamically assigned to
the relevant pre-defined Security
Group
SG=Finance

17. 17
vRA Feature Set Supporting NSX
Feature vRA 7.0 Future
Day 1: Automated Routed, NAT, LB and security for single machines blueprints R R
Day 1: Automated Routed, NAT, LB and security for application stack (micro-segmentation) R R
Visual topology in blueprint: Drag-and-drop of networks, LB and security objects in Canvas and map relationships R R
Day 1 and 2: Enhance NSX NAT with features for SNAT, DNAT, port forwarding and PAT monitors in network profile
and add Day 2 updates
Q R
Day 2: Update NSX security groups, tags and policies applied to VMs Q R
Day 1 and 2: Enhance NSX LB with features for port, algorithm, persistence, IP address pool, health check monitors
in blueprint and add Day 2 updates
Q R
NSX Multi-vCenter Feature Support (IP and MAC set security groups) Q R
Day 1 and 2: Support for enabling HA on NSX Edges Q R
Day 1 and 2: Define NSX firewall rules for the app in blueprint and Day 2 add/change/remove firewall rules on VMs
Q R
Day 2: Change network adapters, IP address, DHCP, DNS, etc. on VM Q R
Request time: Change Network, LB and Security settings Q R
Direct support for IPAM solutions Q R
Support NSX functionality in vCloud Air Q R

18. 18
vRealize Automation 7.0
What’s changing that helps here?

19. 19
vRealize Automation 7.0 – Changes
• Easier setup
• Graphical canvas
• Relationship Mapping
• Networking components as first class
• Manageable Items
• More support for on-demand networking objects
• Single machines with advanced networking
• Orchestrator
• Event broker system
Relevant to IaaS with SDN

20. 20
vRealize Automation 7.0 – Easier Setup
NSX Integration for Blueprint Authoring & Deployment
• Automated connectivity
to existing or on-
demand networks
• Micro-segmentation for
application stack
• Automated security
policy enforcement thru
NSX security policies,
groups and tags
• On-demand dedicated
NSX load balancer

21. 21
vRealize Automation 7.0 – Single Machine Networking
• vCAC 5.2 -> Custom properties
• vRA 6.x -> GUI based network options for MMBP only
• vRA 7.0 -> GUI based network options for all (but all are now one – no single/MMBP difference)

22. 22
vRealize Automation 7.0 – Orchestrator
The vRO 7.0 Control Center
• Embedded + External
• New modern UI for vRO setup, configuration,
workflow monitoring, troubleshooting, and other
useful information.
• Collect metrics for workflow execution
• Analyze running workflows
• General troubleshooting
• Manage, Import/Export central DB
• WAY more slick than previous “legacy” UI

23. 23
NSX vRealize Orchestrator Plugin
Abstracting with vRO
Benefits
• Ability to support multiple product versions
(vCNS, NSX) transparently to vRA
• Network and security workflows are decoupled
from policy engine, enabling more rapid release
and update to workflows
• Ability to deliver fixes and updates more rapidly
• Easier to extend/customize workflows by adding
your own logic or leveraging other systems
• Provide Self Service access to NSX vRO
workflows through Advanced Service Designer
• Can be used without vRA
Warning: Supported for the vRA workflows ONLY

24. 24
NSX vCenter Dynamic Types Plugin
Abstracting with vRO
Benefits
• Has been built by Christophe Decanini and offers
additional workflows the official plugin doesn’t
cover.
• It’s FREE !
• Designed to be used in XaaS context
• Source code available at https://flowgrab.com or
in the VMware communities
• https://communities.vmware.com/docs/DOC-29032
• Can be extended easily, through the NSX REST
API as it’s built leveraging the dynamic types
plugin generator
• Great learning opportunity (vRO and NSX) !
Warning: Not Supported by VMware

25. 25
NSX-vRO Plugin 1.1.0 or 2.0.0
Feature
Continued support for interoperability between vRA, vRO and NSX
Expanded support and bug fixes for use of the plugin with vRA ASD / XaaS
Enhance NSX NAT with features for SNAT, DNAT, port forwarding and PAT monitors in network profile and add Day 2 updates
Support full management (CRUD) of NSX security groups, tags and policies applied to VMs
Support for Enhanced NSX LB management with features such as LB port, algorithm, persistence, IP address pool, health check
monitors
Support for advanced NSX Edge features (HA, Logging, etc.)
NSX firewall rule management (CRUD operations)
Full documentation of the NSX-vRO plugin for general consumption
Better scale and performance requirements
Support for NSX Transformers (Crosshairs target)

26. 26
vCAC 6.0.x and NSX Integration
NSX vSphere (NSX-v)
vCloud Automation Center
vCenter Server vSphere Host (ESXi)
vCNS Model
NSX API (REST)
VIM API (SOAP) AMQP

27. 27
vRealize Automation and NSX Integration
NSX vSphere (NSX-v)
vRealize Automation
vCenter Server vSphere Host (ESXi)
vCNS Model
NSX API (REST)
VIM API (SOAP) AMQP
vRealize Orchestrator
vRO API (REST)
NSX Plugin

28. 28
vRealize Automation 7.0 – Event Broker
• New event broker system
• Allows blocking task style implementations
• Dozens of notification possibilities
• Ability to wire any of these to vRealize Orchestrator
• Therefore ability to use vRO to influence NSX at any of these points
• Standard machine stub callouts will still exist

29. 29
DEMO: Cross site vMotion with vSphere, vRA and NSX
Oooh!

30. 30
Review of Learner Objectives
You should be able to meet the following objectives:
• Understand the benefits of the integration between NSX and vRealize Automation
• Be able to articulate to customers the value of the joint solution
• Create NSX network and security components to be consumed by vRealize Automation
• Configure Network Profiles
• Configure a multi-machine blueprint with networking and security
• Deploy a multi-tier application from the vRealize Automation catalog with networking and security
components.

31. 31
Key Takeaways
The NSX and vRealize Automation integration allows for the
automation of multi-tier applications with networking and security
components
There are many different deployment options with the joint NSX and
vRealize Automation solution. Understand your customer
requirements and prescribe the appropriate deployment options.

32. 32
Q&A