This document provides an overview and update on the latest NSX network virtualization capabilities from VMware. It discusses both current NSX features such as physical network integration, encapsulations, service chaining, and multi-site network virtualization as well as potential future directions. Key points covered include using Geneve as a tunneling protocol, handling elephant flows, and challenges around multi-site network virtualization across geographically dispersed data centers.
Report
Share
Report
Share
1 of 36
Download to read offline
More Related Content
Net1674 final emea
2. Disclaimer
• This presentation may contain product features that are currently under development.
• This overview of new technology represents no commitment from VMware to deliver these
features in any generally available product.
• Features are subject to change, and must not be included in contracts, purchase orders, or
sales agreements of any kind.
• Technical feasibility and market demand will affect final delivery.
• Pricing and packaging for any new technologies or features discussed or presented have not
been determined.
CONFIDENTIAL 2
3. Objectives
• Provide an update on latest NSX capabilities
• Provide some insight into future NSX direction
• Deepen your understanding of network virtualization and its value
3CONFIDENTIAL
4. Overview
• Network Virtualization in One Slide
• Physical Network Integration
• Encapsulations
• Service Chaining
• Multi-site Network Virtualization
• Summary
4CONFIDENTIAL
5. Network Virtualization – an Analogy
CONFIDENTIAL 5
Physical Compute & Memory
Hypervisor
Requirement: x86
Virtual
Machine
Virtual
Machine
Virtual
Machine
Application Application Application
x86 Environment
Physical Network
Network Virtualization Platform
Requirement: IP Transport
Virtual
Network
Virtual
Network
Virtual
Network
Workload Workload Workload
L2, L3, L4-7 Network Services
Decoupled
6. VLAN
L2
L3
Virtual Network
L2
NSX – Network Virtualization Platform
Physical Network
vSphere Host vSphere Host KVM Xen Server
NSX vSwitch NSX vSwitch Open vSwitch Open vSwitch
Hardware
Software
Controller Cluster
VLAN
VTEP API
HW Partner
Northbound
NSX API
Cloud Management
Platform
NSX Edge
7. API (OVSDB)
Tunnels (VXLAN)
Physical
Workloads
Controller Cluster
Hypervisor
vSwitch
Hypervisor
vSwitch
Hypervisor
vSwitch
Hypervisor
vSwitch
Logical network
Connecting the Physical to the Virtual
DB
VM MACS
PHYMACS
IP Underlay
(no mulitcast required)
10. Distributed L3
• The other paths (PV, VV, PP) are similar
– Router’s ARP reply always comes from nearby VTEP or vswitch
– That node then ARPs toward the ultimate destination
• Note that the LR is fully distributed among VTEPs and vswitches
– Any E-W traffic will travel directly between hypervisors
– No single device does all routing
CONFIDENTIAL 10
11. VTEP Futures
• BFD health monitoring
– Mitigate service node failures
– Provide overlay health monitoring/troubleshooting
• ACL configuration
• QoS – DSCP setting
• Higher layer services (e.g. ADCs)
11CONFIDENTIAL
12. Handling Elephant Flows
1. Detect Elephants
– Must be long-lived and high-bandwidth
– vSwitch ideally suited for task, maybe combine with central control
2. Do something with them:
– Mark the outer DSCP
– Put them in a queue separated from mice
– Route along their own path or network
– Convert to mice
CONFIDENTIAL 12
15. Tunneling
• Networking people love to argue about tunnel formats
• Primarily a low-level detail of the implementation
• But tunnel format matters:
– Interoperability (HW + SW endpoints)
– ECMP on current switches
– Extensibility
– Performance
– Visibility
• Current options (VXLAN, NVGRE, STT) all fall short somewhere
• Enter Geneve (Generic Network Virtualization Encapsulation)
– VMware, Microsoft, Red Hat, Intel (the x86 world)
CONFIDENTIAL 15
16. Tunnels are like cables
Physical
HypervisorHypervisor
WORLD
Virtual Network
STT
VXLAN VXLAN
Cable Cable
Cable
Copper Cable
Controller
Third party hardware
Geneve
Geneve Geneve
17. Geneve Header
MAC
IP
UDP
Geneve
Inner Eth
Inner IP
Inner L4
Payload
Options
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| Opt Len |O|C| Rsvd. | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CONFIDENTIAL 17
18. How the Options Are Used
• <Type, length, value> structure
– Type is structured to allow vendor-specific options
• “C” bit indicates “critical” options
• Example use:
– convey the source or dest of a packet when that info can’t be determined from other fields
• e.g. ARP request from a logical router could be from anywhere physically
• Mirrored packets might be sent somewhere other than dest address
– Indicate traceflow packets
– Carry logical port info for egress policy
– State versioning
– Service chaining
– etc.
CONFIDENTIAL 18
19. What about VXLAN, STT, etc.?
• Hardware that supports VXLAN and STT will be around for a long time
• If you’re buying switches today, they’ll support VXLAN
• VXLAN NIC offloads also available today
• Of course we’ll continue to support VXLAN & STT
– Easy for us to support multiple encapsulation types
– We mix & match STT & VXLAN (and GRE) today
• Geneve goal is that we don’t need another encap for a long time
19CONFIDENTIAL
20. Service Chaining
• Creating a graph of services (e.g. load balance, firewall, WAN optimize, etc.)
• Network virtualization provides a natural way to do this in automated manner
– Creating virtual topologies
• Often need to pass metadata along the chain
– e.g. make the results of a classification step available to a later node
– Ongoing argument about how to pass this metadata – Geneve provides a reasonable option
Partner
VNF
Firewall
VPN
IPsec/SSL
CONFIDENTIAL 20
21. Service Chaining Example: E-W Firewall & Routing
Logical View
Hypervisor1Hypervisor1
vSwitch
Hypervisor1Hypervisor2
vSwitch
3rd Party FW 3rd Party FW
Physical View
Web App
Web App
22. Multi-Site Network Virtualization
• We support some multi-site scenarios today (see NET1974)
– E.g. stretched metro cluster
– Snapshot, clone, restore across locations
• Important to think of the full picture, not just networking
– E.g. do you want to migrate a VM across the WAN without its data?
– Where does your Cloud Management Platform live? How many CMP instances?
• Lots of distinct use cases plenty of work ongoing
22
23. The Multi-Site Spectrum
23
Single DC
Federation
Geographically
Dispersed DCs
Metro Area
DCs
Sub-ms latency
High BW
Low-ms latency
High BW
100-ms latency
Constrained BW
CONFIDENTIAL
24. IP/MPLS CORE
PE
To Customer Sites
Connecting Virtualized Data Centers to the WAN
Hypervisor Hypervisor Hypervisor
NSX
Edge
vSwitch vSwitch vSwitch
25. Using “Option B” to Map Logical Networks to MPLS Labels
NSX
Edge
Logical Network Prefixes
advertised in MP-BGP with MPLS
labels
ASBRTo Customer Sites
MPLS Core
Treat interface like
inter-AS (RFC 4364)
MPLS Labelled Packets mapped
to/from logical networks
26. WAN
Multi-site using MP-BGP
Hypervisor Hypervisor Hypervisor
NSX
Edge
vSwitch vSwitch vSwitch
HypervisorHypervisorHypervisor
NSX
Edge
vSwitchvSwitchvSwitch
MP-BGP
27. WAN
Multi-site using MP-BGP
Hypervisor Hypervisor Hypervisor
NSX
Edge
vSwitch vSwitch vSwitch
HypervisorHypervisorHypervisor
NSX
Edge
vSwitchvSwitchvSwitch
MP-BGP
VM VM
NSX API NSX API
VM
28. NSX Controller NSX Controller NSX Controller NSX ControllerNSX Controller
Controller State Distribution
• All nodes active
• Workload sliced among nodes
• Logical network state – semantically rich
Node5Node4
WebService
API
Persistent
Storage
Logical
Network
Transport
Network
Node1 Node2 Node3
Controller
Cluster
29. NSX Controller NSX Controller NSX Controller NSX ControllerNSX Controller
Controller State Distribution
Node5Node4
WebService
API
Persistent
Storage
Logical
Network
Transport
Network
Node1 Node2 Node3
Controller
Cluster
30. Summary
• Network virtualization – not just for the bleeding edge
• Physical networks are part of the story
– Control the physical edge for non-virtualized workloads and north-south traffic
– Communicate with the underlay for congestion/elephant flow mitigation
– Keep moving up the stack
• Tunneling – a detail, but an important one
• Multi-site
– Consider use case & complete system
– Some solutions today, more soon
• Exciting times for networking!
30
32. Hands-on Labs
32
• SDC-1402 vSphere Distributed Switch from A to Z
• SDC-1403 Introduction to VMware NSX
• SDC-1420 OpenStack with VMware vSphere and NSX
• SDC-1423 vCloud Suite Basic Networking
• SDC-1424 VMware NSX and SDDC
• SDC-1425 VMware NSX Advanced
33. Advanced Technical Track - Networking
CONFIDENTIAL 33
• NET1949 VMware NSX for Docker, Containers & More
• NET1589 Reference Design for SDDC with NSX & vSphere
• NET1583 NSX for vSphere Logical Routing Deep Dive
• NET1974 Multi-Site Data Center Solutions with VMware NSX
• NET1966 Operational Best Practices for VMware NSX
• NET1592 Under the Hood: Network Virtualization with OpenStack Neutron & VMware NSX
Group Discussions - Networking
• NET3347-GD vSphere Distributed Switch
• NET3348-GD NSX Routing Design Best Practices
34. Technical Track - Networking
CONFIDENTIAL 34
• NET1846 Introduction to NSX
• NET1743 VMware NSX – A Technical Deep Dive
• NET1468 A Tale of Two Perspectives: IT Operations with VMware NSX
• NET1586 Advanced Network Services with NSX
• NET1560 The NSX Guide to Horizon View
• NET1401 vSphere Distributed Switch Best Practices for NSX
• NET1581 Reference Design for SDDC with NSX for Multi-Hypervisors
• NET2225 NSX Platform: Enabling 3rd Party Network & Security Solutions