VXLAN Overview

Architecting Scalable Clouds using VXLAN
and Nexus 1000V

BRKVIR-2014
Lawrence Kreeger
Distinguished Engineer, Cloud Networking and
Services Group
Agenda
Session Is Broken Into 3 Main Parts
 Part 1: VXLAN Overview

– What is a VXLAN? Why VXLANs?
– What is VMware vCloud Director? What is a vApp?
 Part 2: Deeper Dive
– Data Plane Model, Packet Format, Day in the life of a VXLAN
– What’s New for VXLAN on Nexus 1000V
– Comparison with other Network Virtualization technologies
 Part 3: Deployment Considerations
– ESX Host Infrastructure Configuration
– Underlying Network Infrastructure Configuration
– VXLAN Configuration (with and without vCloud Director)
BRKVIR-2014 © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Part 1: VXLAN Overview
What Is A VXLAN?
 A VLAN with an X in the middle 
 A VXLAN provides the same service to End Systems as a VLAN
 The X stands for eXtensible
– Scale!
– More layer 2 segments than VLANs
– Wider stretch than VLANs
 VXLANs are an Overlay Network technology
– MAC Over UDP/IP
 A draft specifying VXLAN was submitted to the IETF by Cisco, VMware and
several other hypervisor and network equipment vendors (draft-mahalingam-
dutt-dcops-vxlan)
– Currently sponsored by an IETF Area Director and being sheparded for publishing as
an RFC
Overlay Networks
SFO
MXP
Air Traffic Control System
Ethernet Frames
V V
M M
1 4
IP Addr IP Addr
1.1.1.1 2.2.2.2
V Virtual IP Network Virtual V
M M
2 Switch Switch 5
V V
M UDP/IP Packets M
3 6
Hypervisor Hypervisor
VXLAN Data Plane High Level Overview
 VM to VM Ethernet traffic on different access switches is encapsulated in
a VXLAN header + UDP + IP
 The VXLAN header contains a 24 bit VXLAN Network Identifier
 VM MAC to access switch IP address mappings are learned by receiving
encapsulated packets
– Similar to Ethernet bridge flood and learn behavior
 VXLAN uses IP multicast to deliver bcast/mcast/unknown destination VM
MAC addresses to all access switches participating in a given VXLANs
 Known destination VM MAC addresses are carried over point to point
tunnels between access switches
Why VXLANs?
Pain Points in Scaling Cloud Networking
 Use of server virtualization and cloud computing is stressing the network

infrastructure in several ways:
- Server Virtualization increases demands on switch MAC address tables
- Multi-tenancy and vApps driving the need for more than 4K VLANs
- Static VLAN trunk provisioning doesn’t work well for Cloud Computing and VM mobility
- Limited reach of VLANs using STP constrains use of compute resources
Server Virtualization and MAC Addresses
Comparison of Physical vs. Virtualized Servers
 Assume each server has 2 NICs (e.g. front end and management)
 A physical server uses only 1 MAC addresses per NIC (2 MACs)
 Virtualized servers have a MAC address for each Virtual NIC (VNIC)
– Multiple kernel VNICs are used by the hypervisor itself (e.g. management, iSCSI,
vMotion, Fault Tolerance, VXLAN VTEP etc) (e.g. 6 MACs)
– Each VM may have multiple VNICs (e.g. 2)
 Assume 1 RU servers with 16 cores (32 threads), and hundreds of GB of
memory
– e.g. 32 VMs with 2 VNICs each = 64 MACs (This number will only be rising)
 Physical with 2 MACs -> Virtualized with 70 MACs = 35 fold increase in MACs
per server!
High Density Switch Architectures Can Pack
Thousands of Servers in One STP Domain
4K Physical Servers = 4K * 2 = 8K MACs
4K Virtualized Servers:
Without VXLAN: 4K * 70 = 280K MACs IP Core
With VXLAN: 4K * 6 = 24K MACs
286 Uplink Ports each
2 Nexus 7000 2 VPC Peer Links each

(768 ports each)
480 Downlink Ports each
30 Uplink Ports each

32 Nexus 5596
(96 Ports Each)
2 VPC Peer 64 FEX Ports each
Links each
8 Fabric Ports each
256 Nexus 2232
(40 Ports Each)
32 Host Ports each
4096 Servers
2 x 10GE each
Multi-Tenancy and vApps Drive the Need for Many
L2 Segments
 Both MAC and IP addresses could overlap between two tenants, or even within
the same tenant in different vApps.
– Each overlapping address space needs a separate segment
 VLANs use 12 bit IDs = 4K
 VXLANs use 24 bit IDs = 16M
Spanning Tree Logical Port Limitations
 A Logical Port is the intersection of a VLAN with a physical switch port
– e.g. A single trunk port with 1000 VLANs uses 1000 Logical Ports
 Switches have a limited number of Logical Ports
− This is a STP software limitation
− Nexus 7000 NX-OS 6.x supports 16,000 for PVST+ and 90,000 for MST
− Nexus 5000 NX-OS 5.2 supports 32,000 for either PVST+ or MST
 e.g. A 96 port Nexus 5000 switch can support on average 333 VLANs per port
− Numbers get worse for a larger switch and/or with FEX
 e.g. The previous example topology had 288 ports per Nexus 5000 -> 111 VLANs per port
 When using VXLANs, all traffic travels over just one transport VLAN
Challenges Configuring VLAN Trunks to Servers
 Trunk ports to virtualized servers are typically manually configured
– Slow to react to dynamic needs of the cloud, which usually leads to over-provisioning
the trunks
 Over-provisioned trunk ports lead to
– Broadcast and Unknown unicast traffic arriving at servers that don’t need them
– Excessive use of Spanning Tree Logical Port resources on access switches
 VXLANs use the multicast IGMP protocol to automatically prune traffic on
demand
– Logical Port resources are traded for multicast IGMP Snooping state in switches and
IP Route state in routers
Extending Layer 2 Across the Data Center
Exacerbates 4K VLAN Limit
 Using FabricPath or OTV to extend layer 2 across the entire data center
increases VM mobility and deployment flexibility
 However...it makes the 4K VLAN limit a data center wide limitation
 With VLANs a tradeoff must be made between the number of segments within
a data center, and the span of those segments
– Small layer 2 domains give many islands of 4K VLANs, but limits VM placement and
mobility
 VXLANs can be extended data center wide and still support up to 16M layer 2
segments
VMware vCloud Director and vApps
What is VMware vCloud Director?
Organization 1 Organization m
Users
 Pools virtual infrastructure resources
into tiers called Virtual Datacenters
VMware vCloud Director
 Defines standard collections of VMs User Portals Catalogs Security
called vApps
 Creates Organizations and manages
users Virtual Datacenter 1 (Gold) Virtual Datacenter n (Silver)
 Provides UI for users to self provision VMware

vShield
vApps into Virtual Datacenters

 Automatically deploys VMware
vShield Edge VMs to provide secure
multi-tenancy VMware
vCenter Server
VMware
vCenter Server
VMware
vCenter Server
VMware vSphere VMware vSphere VMware vSphere
What Is A vApp?
 A Cloud Provider using vCloud Director offers catalogs of vApps to their Users
 When cloned, new vApps retain the same MAC and IP addresses
 Duplicate MACs within different vApps requires L2 isolation
 Duplicate IP addresses requires L2/L3 isolation (NAT of externally facing IP addresses)
 Usage of vApps causes an explosion in the need for isolated L2 segments
Org Network
vApp vApp Web Net

vApp App Net
vApp DB Net
DB App Web Edge

VM’s VM’s VM’s Gateway
Possible vApp Instantiation
 Edge Gateway: vShield Edge (now renamed to NSX Edge)
 Edge Gateway performs NAT or VPN to remote location
 VXLANs are perfect candidates for vApp internal networks
– Only VMs connect to vApp Networks
VLAN 100
vApp X VXLAN 5002

VXLAN 5001
VXLAN 5000
DB App Web vShield

VM’s VM’s VM’s Edge
VXLAN Benefits
 On demand network segments without physical network reconfiguration
 Massive scale of layer 2 segments for multi-tenant environments
 Allows virtual layer 2 segments to stretch across physical layer 2 network
boundaries
– Provides operational flexibility for deploying VMs anywhere in the data center
 VXLANs work over existing deployed data center switches and routers
– Alleviates network scaling issues associated with server virtualization
Part 1: Q & A
Part 2: Deeper Dive
VXLAN Network Model
Access Switch Access Switch
End End
Bridge Bridge System
System Domain
Domain
Switch Switch
VTEP
VTEP IP Multicast
Enabled Underlying
Network
End End
System System
VTEP = VXLAN Tunnel End Point
VXLAN Data Plane Model
VTEP VTEP
VXLAN’s IP Any Source Multicast Group (*,G)
acts as a bus for delivery to all relevant VTEPs
for a given VNI. (Carries
unknown/broadcast/multicast frames)
VTEP VTEP
Point to Point tunnel endpoints are

learned based on received traffic
VTEPs on the Nexus 1000V
 The Nexus 1000V VEMs act as the VXLAN Tunnel Endpoints (VTEP)
 Nexus 1000V uses a VMKNIC to terminate VTEP traffic
 The VMKNIC is connected to a VLAN to transport the encapsulated traffic
 The VMKNIC is assigned an IP address used to terminate the encapsulated
traffic
VXLAN Packet Structure
Transport MAC
Addresses
IP Addresses of Contains 24 bit MAC Addresses
(change each
the VTEPs VXLAN Network of the VMs
IP hop)
Identifier (VNI)
Outer Outer
Outer Outer Outer Outer VXLAN Inner Inner Inner Inner Original IP
MAC MAC CRC
802.1Q IP DA IP SA UDP Header MAC DA MAC SA IP DA IP SA Payload
DA SA
Transport Destination UDP Source UDP Port contains

Original Ethernet Frame
VLAN Port 4789 Identifies a Hash of the inner
packet as a VXLAN L2/L3/L4 headers of the
packet original frame
BRKVIR-2014 © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Public
VTEP Use Of IGMP
IGMP Used to Join Each VXLANs Assigned Multicast Group on Demand
Web DB DB Web
VM VM VM VM
Join Multicast Join Multicast

Group 239.1.1.1 L3 Core Group 239.2.2.2
Transport Join Multicast
Join Multicast
Group 239.2.2.2
Group 239.1.1.1
VXLAN Example Data Flow
VM1 Communicating with VM2 in a VXLAN
ARP
Request
ARP ARP
MAC: MAC: Request VM 3 Request
VM 1 abc
VM 2
xyz
VXLAN VXLAN VXLAN

VMKNIC VMKNIC VMKNIC
1.1.1.1 2.2.2.2 3.3.3.3
VEM 1 VEM 2 VEM 3
Multicast Multicast
Multicast
MAC Table: VEM 2

VM Source MAC Remote Host
VXLAN IP
VM1:abc 1.1.1.1
ARP
MAC: MAC: Response VM 3
VM 1 abc
VM 2
xyz
VXLAN VXLAN VXLAN

1.1.1.1 2.2.2.2 3.3.3.3
Unicast
MAC Table: VEM 2

VM Source MAC Remote Host
VXLAN IP
Layer 3 VM1:abc 1.1.1.1
ARP
MAC: Response VM 3
VM 1 abc
VM 2 MAC:
xyz
VXLAN VXLAN VXLAN

1.1.1.1 2.2.2.2 3.3.3.3
MAC Table: VEM 1 MAC Table: VEM 2

VM Source MAC Remote Host VM Source MAC Remote Host
VXLAN IP VXLAN IP
VM2:xyz 2.2.2.2 VM1:abc 1.1.1.1
MAC: VM 3
VM 1 abc
VM 2 MAC:
xyz
VXLAN VXLAN VXLAN

1.1.1.1 2.2.2.2 3.3.3.3
Unicast
MAC Table: VEM 1 MAC Table: VEM 2

VM Source MAC Remote Host VM Source MAC Remote Host
VXLAN IP VXLAN IP
VM2:xyz 2.2.2.2 VM1:abc 1.1.1.1
Multiple VXLANs Can Share One Multicast Group
Blue & Red VXLANs Share the 239.1.1.1 Multicast Group
Web App DB App

VM VM VM VM
• Encapsulate with Blue VXLAN ID VEM Discards Since No VM with

• Multicast to Servers Registered for Blue VXLAN ID
239.1.1.1 Multicast Group
VM Broadcast Frames Sent to More Servers

But Broadcast Domain Respected Within VXLAN Segment
What’s New for VXLAN on Nexus 1000V
Nexus 1000V VXLAN Enhancements
Available Starting In Release 4.2(1)SV2(2.1)
 Multicast not required within a single Nexus 1000V

 MAC Address distribution within a single Nexus 1000V
 Trunking of VXLANs to Virtual Machines
 VXLAN to VLAN (Layer 2) Gateway Virtual Service Blade
Multicast-less Mode
 Several customers have asked for a way to support VXLAN without using IP
multicast
 A single Nexus 1000V is actually one virtual switch, controlled by the same
Virtual Supervisor Module
 The VSM is already used to distribute MAC addresses between VEMs for
features such as:
– Private VLAN
– Port Security
 For this feature, the VSM is also used to distribute the VTEP IP addresses for
each VXLAN between the VEMs
 VEMs perform head-end replication of multi-destination frames only to the
other VEMs which are participating in the VXLAN
 Should only be used if the amount of multi-destination traffic is low (e.g. ARP,
DHCP, discovery)
MAC Address Distribution
 VSM distributes assigned VNIC MAC addresses and their VTEP IP address
mappings
 This pre-populates the VXLAN forwarding tables
– This eliminates the need for unknown flooding for these addresses
 Especially useful in conjunction with Multicast-less mode to minimize head-end
replication
VXLAN Trunking to VNICs
 VMs have a limited number of VNICs (e.g. 10 or 8)
– This typically limits the number of VLANs or VXLANs a VM can connect to
 Sometimes it is desirable for a VM to connect to many networks
– e.g. If the VM is a network service appliance or router
 For VLANs, the Nexus 1000V supports VLAN trunks
 It is possible for VMs to have there own VTEPs to terminate many VXLANs, but
most existing VMs do not support this.
 Solution:
– Map each VXLAN to a locally significant VLAN tag on the virtual Ethernet interface
– These locally significant tag values can be reused with different mappings on different
interfaces
– The VM thinks it is connected to a VLAN trunk
VXLAN to VLAN Virtual Service Blade
Bridging The Virtual/Physical Divide
??
Si
Si
VXLANs/virtual VLANs/physical
VXLAN to VLAN Gateway (Logical View)
L3
VLANs
VXLANs
L2 Domain 1 L2 Domain 2 L2 Domain 3
VXLAN GW VEM VXLAN GW VEM VXLAN GW VEM
VXLAN Gateway: A Two Port Bridge
VXLAN 10000 VLAN 100
bridge-domain red
VXLAN 20000 VLAN 200

bridge-domain blue
Uplink
VXLAN Gateway
Virtual Service Blade
Each VXLAN Gateway VSB can support multiple bridge domains

VXLAN Gateway Virtual Service Module
 Is a Virtual Service Blade running on Nexus 1010/1110
– Each VXLAN Gateway VSB can use one or two dedicated 1G NICs from the appliance
 Is managed as a module of the Nexus 1000V virtual chassis
 Supports Active/Standby High Availability
 Requires Nexus 1000V Advanced Edition License
 Available now
Future Cisco VXLAN Enhancements
 Extend VXLAN unicast-only mode to
– work across Nexus 1000V VSMs
– work across Nexus 1000V VSMs and hardware gateways
– using standards based protocols
 VXLAN support for Nexus 1000V for KVM/OpenStack
N1KV on KVM
OpenStack
Nexus 1000V Quantum/Neutron Plug-in
REST API
Nexus 1000V VSM Physical

CSR Nexus 1000V (VLAN)
VXLAN – VLAN
Gateway Network
ASA 1KV VSG
ASA 55xx
VEM KVM VEM
vWAAS Partners
Virtual Services
Tenant 1 Tenant 2 Tenant 3
Virtual Workloads Physical Workloads
VXLAN Segments
VXLAN on HW Platforms
Supported Functionalities
 VXLAN-to-VLAN Bridging (L2 Gateway) Inner Ethernet frame sent on
Configured Egress VLAN
 N5600, N7000 (F3), N9000, N3100 VXLANORANGE

VXLAN L2
Ingress VXLAN packet on
Gateway
Orange segment
 VXLAN-to-VLAN Routing (L3 Gateway) Destination is a tagged

VLAN interface.
Inner IP Packet is routed
 N5600, N7000 (F3), N9000 SVI to the new VLAN

VXLANORANGE
VXLAN
Ingress VXLAN Router
packet on Orange
segment
Destination is in another VXLAN segment.
 VXLAN-to-VXLAN Routing (L3 Gateway) Inner IP Packet is routed to the VXLAN
VXLANORANGE VXLANBLUE
 N5600, N7000 (F3), N9000 VXLAN
Ingress VXLAN packet on Router
Orange segment
VXLAN Overlay Comparisons
VXLAN Versus STT
Stateless Transport Tunneling Protocol
Similarities Differences
 Both carry Ethernet Frames  Encapsulation Format and Overhead
– VXLAN: UDP with 50 bytes
– STT: “TCP-like” with 72 to 54 bytes (not uniform) *
 Both use IP Transport
 Segment ID Size
 Both can use IP Multicast – VXLAN: 24 bit
– STT: 64 bit
– For broadcast and multicast frames
 Firewall ACL can act on VXLAN UDP port
 Both can take advantage of existing – Firewalls will likely block STT since it has no TCP state
machine handshake
Port Channel load distribution
algorithms  Forwarding Logic
– VXLAN: Flooding/Learning
– 5 Tuple Hashing (UDP vs TCP) – STT: Not specified
Note: STT uses the TCP header, but not the protocol state machine. TCP header fields are repurposed.
* The STT header does not exist in every packet. Only the first packet of a large segment, therefore reassembly is required.
VXLAN Versus NVGRE
Network Virtualization using Generic Routing Encapsulation
 Both carry Ethernet frames  Encapsulation Format and Overhead
– VXLAN: UDP with 50 bytes
– NVGRE: GRE with 42 bytes
 Both use IP Transport
 Port Channel Load Distribution
 Both can use IP Multicast – VXLAN: UDP 5-tuple hashing
– Most (if not all) current switches do not hash on the GRE
– For broadcast and multicast frames header
 24 Bit Segment ID  Firewall ACL can act on VXLAN UDP port

– Difficult for firewall to act on the GRE Protocol Type field
 Forwarding Logic
– NVGRE: Not specified
VXLAN Versus OTV
Overlay Transport Virtualization
 Both carry Ethernet frames  Forwarding Logic
 Same UDP based encapsulation – OTV: Uses the IS-IS protocol to advertise the MAC
address to IP bindings
header
– VXLAN does not use the OTV Overlay ID field  OTV can locally terminate ARP and doesn’t
flood unknown MACs
 Both can use IP Multicast
– For broadcast and multicast frames  OTV can use an adjacency server to eliminate
(optional for OTV) the need for IP multicast
 OTV is optimized for Data Center Interconnect
to extend VLANs between or across data
centers
 VXLAN is optimized for intra-DC and multi-
tenancy
VXLAN Versus LISP
Locator / ID Separation Protocol
 Same UDP based encapsulation  LISP carries IP packets, while VXLAN carries
header Ethernet frames
– VXLAN does not use the control flag bits or
Nonce/Map-Version field  Forwarding Logic
 24 Bit Segment ID – LISP: Uses a mapping system to register/resolve inner IP to
outer IP mappings
 For LISP, IP Multicast is only required to carry

host IP multicast traffic
 LISP is designed to give IP address (Identifier)
mobility / multi-homing and IP core route
scalability
 LISP can provide optimal traffic routing when
Identifier IP addresses move to a different
location
Part 2: Q & A
Part 3: Deployment
Nexus 1000V VEM VMKNICs
 Management VMKNIC
– For VSM to VEM communication
 VXLAN VMKNIC(s)
– For terminating VXLAN encapsulated traffic VM VM
Mgmt VMKNIC
VXLAN VMKNIC
Configure VMKNIC On Each ESX Host
 Allocate a separate VLAN to carry VXLAN traffic to/from ESX hosts
– Add this VLAN to allowed VLANs on trunk ports leading to ESX servers
– Add this VLAN to allowed VLANs on Nexus 1000V uplink port profiles
 Create an Access Port port profile connected to the above created VXLAN
transport VLAN
– Add the command “capability vxlan” to the port profile to indicate the associated
VMKNIC will be used to send/receive VXLAN encapsulated packets
 Using vCenter, create a new VMKNIC on each host that requires access to
VXLANs
– Assign the above port profile to this VMKNIC
– Assign an available IP address within the subnet of the VXLAN transport VLAN
VXLAN Infrastructure MTU Requirements
Increase MTU To Accommodate Added Encapsulation Overhead
 VXLAN encapsulation overhead is 50 bytes

– Recommendation: Increase MTU by 160 bytes to be ready for future. e.g. 1500 + 160
= 1660
– If VMs will be sending jumbo frames (> 1500), add accordingly
 Configure all Layer 2 switches carrying the VXLAN Transport VLAN (specifics
vary by switch)
– Increase global MTU config if applicable
– Increase interface MTU if applicable on trunk ports (to servers and inter-switch)
– Increase MTU in Nexus 1000V uplink port profiles
 Configure router interfaces carrying VXLAN traffic
– SVIs for VXLAN transport VLAN(s)
– Routed ports (if used)
What If I Can’t Increase The Network MTU?
 Alternatively, decrease the MTU of the VM’s VNICs by 50 bytes
 If you do neither, the Nexus 1000V will try to do the following to help
– If the VM performs Path MTU Discover, the Nexus 1000V will return an ICMP “Too Big”
message to cause the VM to segment traffic into smaller packets
– If the VM sends IP packets which are too large, the Nexus 1000V will fragment the
packets from the VM. The destination VM is responsible for reassembling the
fragments
– If the frame contains a non-IP packet which is too large to be sent after encapsulation,
the Nexus 1000V will drop the packet
 If the Nexus 1000V uplink MTU is increased, but the other switch ports along
the path between hosts are not increased, the other switches will silently drop
the frames!
Enable IP Multicast Forwarding
Layer 2 Multicast Configuration
 IGMP Snooping should be enabled on the VXLAN transport VLAN to avoid

delivery of unwanted multicast packets to the hosts
– Note: IGMP Snooping is enabled by default on Cisco switches
 If all hosts are connected to the same subnet, IP multicast routing is not
required
– However, an IGMP Querier is still required to make IGMP Snooping work on the
switches
– Use the command “ip igmp snooping querier <ip-addr>” for the VXLAN transport VLAN
on the aggregation switches.
– Use IP addresses which are unused within the VXLAN transport VLAN’s subnet
Enable IP Multicast Forwarding
Layer 3 Multicast Configuration
 If host VXLAN VMKNICs are on different subnets, IP multicast routing must be

enabled on the router(s) interconnecting the subnets
 VXLAN multicast traffic is bi-directional
– All hosts with VXLANs both send and receive IP multicast traffic
 VXLAN VTEPs join for “Any Source” (*, G) to the relevant VXLAN multicast
group using IGMPv2
 Using Bi-dir PIM on the routers will :
– Provide the most optimal forwarding trees
– Use the least amount of multicast routes in the routers
– Put less stress on the router control plane
 PIM-SM will also work, but be less optimal
Alternatives To Enabling IP Multicast Routing
 Use FabricPath to extend the layer 2 domain
– FabricPath supports efficient multicast L2 pruning within the fabric
– Place all VTEPs on the same VLAN
 Use OTV to extend just the VXLAN transport VLAN
– Place all VTEPs on the same VLAN
– Other VLANs do not need to be extended
Enable UDP Port Based Load Distribution
For Both Layer 2 and Layer 3
 VTEPs transfer inter-VM flow entropy into the outer IP encapsulation source
UDP port
– VTEP generates a hash value based on the VM’s IP or L2 headers and put this into the
outer UDP source port
 Take advantage of this in the underlying network by using UDP port based flow
distribution
 Enable 5-tuple (L3 Src/Dst, L4 Proto, L4 Port Src/Dst) based load distribution
for
– Port Channels and Virtual Port Channels to VXLAN enabled hosts
– Port Channels and Virtual Port Channels between switches
– For router Equal Cost Multi-Pathing (ECMP)
Enable Proxy ARP on Transport VLAN SVIs
 VEM VTEP function will always ARP for destination IP addresses
– This simplifies the ESX host routing table configuration
 If host VXLAN VMKNICs are on different subnets
– SVIs must be created on the VXLAN transport VLANs
– Proxy ARP must be enabled on these SVIs
 IOS and NX-OS defaults are different for Proxy ARP
– IOS defaults to enabled
– NX-OS defaults to disabled
Nexus 1000V VXLAN CLI
Manual Provisioning of VXLANs
 Enable the feature
switch(config)# feature segmentation
 Create a VXLAN Instance
switch(config)# bridge-domain my-vxlan-1
switch(config-bd)# segment id 20480
switch(config-bd)# group 239.1.1.1
 Assign a Port Profile to connect to a VXLAN
switch(config-port-prof)# switchport mode access
switch(config-port-prof)# switchport access bridge-domain my-vxlan-1
Nexus 1000V vCloud Director Integration
Four Main Components
Management of
1. VMware vCloud Tenant VMs
Director
Center (vCD)
Network Management of
Management vShield Edge
through vShield VMs
Manager
2. VMware vShield 3. VMware

Manager vCenter
Nexus 1000V Standard vCenter
Management and VSM
through REST integration
API
4. Cisco Nexus 1000V VSM
Integrating Nexus 1000V and vShield Manager
1. Turn on Network Segmentation Manager feature on Nexus 1000V
N1KV(config)# feature network-segmentation-manager
2. Add Nexus 1000V in vShield Manager as a Managed switch with VXLAN

and Multicast address pool range
Part 3: Q & A
Related Sessions
 LTRDCT-1223 - Implementing VXLAN in Datacenter
 BRKDCT-1301 - VxLAN Deployment - Use Cases and Best Practices
 BRKVIR-2017 - The Nexus 1000V on Microsoft Hyper-V: Expanding the Virtual
Edge
 BRKAPP-9004 - Data Center Mobility, VXLAN & ACI Fabric Architecture
 BRKDCT-2328 - Evolution of Network Overlays in Data Center Clouds
 BRKDCT-2337 - Virtual Services for Scalable Multi-tenant Cloud Architectures
Resources
 Whitepapers and Deployment Guides (www.cisco.com/go/1000v)
– Deploying the VXLAN Feature in Cisco Nexus 1000V Series Switches
– Deploying Cisco Nexus 1000V Series Switches with VMware vCloud Director and
VXLAN 1.0
– Scalable Cloud Networking with Cisco Nexus 1000V Series Switches and VXLAN
– Enable Cisco Virtual Security Gateway Service on a Virtual Extensible LAN Network in
VMware vCloud Director
 Cisco Cloud Lab (cloudlab.cisco.com)
– Demo: Virtual Extensible LAN (VXLAN)
Summary / Next Steps
 VXLANs can help you scale your cloud networking
 VXLANs work over your existing switches and routers
 The Nexus 1000V’s VXLAN support is fully integrated with VMware vCloud Director and
OpenStack
 Explore available resources
 Try VXLANs for yourself!
Complete Your Online Session Evaluation
 Complete your online session
evaluation
 Complete four session evaluations
and the overall conference evaluation
to receive your Cisco Live T-shirt

VXLAN Overview

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

VXLAN Overview

Enviado por

Direitos autorais:

Formatos disponíveis

Architecting Scalable Clouds using VXLAN

and Nexus 1000V

 Part 1: VXLAN Overview

 Use of server virtualization and cloud computing is stressing the network

2 Nexus 7000 2 VPC Peer Links each

30 Uplink Ports each

 Provides UI for users to self provision VMware

vApps into Virtual Datacenters

VMware vSphere VMware vSphere VMware vSphere

vApp vApp Web Net

DB App Web Edge

vApp X VXLAN 5002

DB App Web vShield

Access Switch Access Switch

VTEP = VXLAN Tunnel End Point

Point to Point tunnel endpoints are

Transport Destination UDP Source UDP Port contains

Join Multicast Join Multicast

VXLAN VXLAN VXLAN

MAC Table: VEM 2

VXLAN VXLAN VXLAN

MAC Table: VEM 2

Layer 3 VM1:abc 1.1.1.1

VXLAN VXLAN VXLAN

MAC Table: VEM 1 MAC Table: VEM 2

VXLAN VXLAN VXLAN

MAC Table: VEM 1 MAC Table: VEM 2

Web App DB App

• Encapsulate with Blue VXLAN ID VEM Discards Since No VM with

VM Broadcast Frames Sent to More Servers

 Multicast not required within a single Nexus 1000V

VXLAN GW VEM VXLAN GW VEM VXLAN GW VEM

VXLAN 20000 VLAN 200

Each VXLAN Gateway VSB can support multiple bridge domains

Nexus 1000V Quantum/Neutron Plug-in

Nexus 1000V VSM Physical

Virtual Workloads Physical Workloads

 N5600, N7000 (F3), N9000, N3100 VXLANORANGE

 VXLAN-to-VLAN Routing (L3 Gateway) Destination is a tagged

 N5600, N7000 (F3), N9000 SVI to the new VLAN

 24 Bit Segment ID  Firewall ACL can act on VXLAN UDP port

 For LISP, IP Multicast is only required to carry

 VXLAN encapsulation overhead is 50 bytes

 IGMP Snooping should be enabled on the VXLAN transport VLAN to avoid

 If host VXLAN VMKNICs are on different subnets, IP multicast routing must be

2. VMware vShield 3. VMware

2. Add Nexus 1000V in vShield Manager as a Managed switch with VXLAN

Você também pode gostar