Network Working Group M. Mahalingam
Internet Draft D. Dutt
Intended Status: Experimental K. Duda
Expires: February 2013 Arista
P. Agarwal
Broadcom
L. Kreeger
Cisco
T. Sridhar
VMware
M. Bursell
Citrix
C. Wright
Red Hat
August 22, 2012
VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over
Layer 3 Networks
draft-mahalingam-dutt-dcops-vxlan-02.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on February 22, 2013.
Mahalingam, Dutt et al. Expires February 2013 [Page 1]
Internet-Draft VXLAN August 2012
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Abstract
This document describes Virtual eXtensible Local Area Network
(VXLAN), which is used to address the need for overlay networks
within virtualized data centers accommodating multiple tenants. The
scheme and the related protocols can be used in cloud service
provider and enterprise data center networks.
Table of Contents
1. Introduction...................................................3
1.1. Acronyms & Definitions....................................3
2. Conventions used in this document..............................4
3. VXLAN Problem Statement........................................5
3.1. Limitations imposed by Spanning Tree & VLAN Ranges........5
3.2. Multitenant Environments..................................5
3.3. Inadequate Table Sizes at ToR Switch......................6
4. Virtual eXtensible Local Area Network (VXLAN)..................6
4.1. Unicast VM to VM communication............................7
4.2. Broadcast Communication and Mapping to Multicast..........8
4.3. Physical Infrastructure Requirements......................9
5. VXLAN Frame Format.............................................9
6. VXLAN Deployment Scenarios....................................12
6.1. Inner VLAN Tag Handling..................................16
7. IETF Network Virtualization Overlays (nvo3) Working Group.....16
8. Security Considerations.......................................17
9. IANA Considerations...........................................18
10. Conclusion...................................................18
11. References...................................................18
11.1. Normative References....................................18
11.2. Informative References..................................18
12. Acknowledgments..............................................19
Mahalingam, Dutt et al. Expires February 2013 [Page 2]
Internet-Draft VXLAN August 2012
1. Introduction
Server virtualization has placed increased demands on the physical
network infrastructure. At a minimum, there is a need for more MAC
address table entries throughout the switched Ethernet network due
to potential attachment of hundreds of thousands of Virtual Machines
(VMs), each with its own MAC address.
Second, the VMs may be grouped according to their Virtual LAN
(VLAN). In a data center one might need thousands of VLANs to
partition the traffic according to the specific group that the VM
may belong to. The current VLAN limit of 4094 is inadequate in such
situations. A related requirement for virtualized environments is
having the Layer 2 network scale across the entire data center or
even between data centers for efficient allocation of compute,
network and storage resources. Using traditional approaches like
Spanning Tree Protocol (STP) for a loop free topology can result in
a large number of disabled links in such environments.
Another type of demand that is being placed on data centers is the
need to host multiple tenants, each with their own isolated network
domain. This is not economical to realize with dedicated
infrastructure, so network administrators opt to implement this over
a shared network. A concomitant problem is that each tenant may
independently assign MAC addresses and VLAN IDs leading to potential
duplication of these on the physical network.
The last scenario is the case where the network operator prefers to
use IP for interconnection of the physical infrastructure (e.g. to
achieve multipath scalability through Equal Cost Multipath [ECMP])
while still preserving the Layer 2 model for inter-VM communication.
The scenarios described above lead to a requirement for an overlay
network. This overlay would be used to carry the MAC traffic from
the individual VMs in an encapsulated format over a logical
"tunnel".
This document details a framework termed Virtual eXtensible Local
Area Network (VXLAN) which provides such an encapsulation scheme to
address the various requirements specified above.
1.1. Acronyms & Definitions
ACL - Access Control List
Mahalingam, Dutt et al. Expires February 2013 [Page 3]
Internet-Draft VXLAN August 2012
ECMP - Equal Cost Multipath
IGMP - Internet Group Management Protocol
PIM - Protocol Independent Multicast
SPB - Shortest Path Bridging
STP - Spanning Tree Protocol
ToR - Top of Rack
TRILL - Transparent Interconnection of Lots of Links
VXLAN - Virtual eXtensible Local Area Network
VXLAN Segment - VXLAN Layer 2 overlay network over which VMs
communicate
VXLAN Overlay Network - another term for VXLAN Segment
VXLAN Gateway - an entity which forwards traffic between VXLAN
and non-VXLAN environments
VTEP - VXLAN Tunnel End Point - an entity which originates
and/or terminates VXLAN tunnels
VLAN - Virtual Local Area Network
VM - Virtual Machine
VNI - VXLAN Network Identifier (or VXLAN Segment ID)
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
Mahalingam, Dutt et al. Expires February 2013 [Page 4]
Internet-Draft VXLAN August 2012
3. VXLAN Problem Statement
This section details the problems that VXLAN is intended to address.
The focus is on the networking infrastructure within the data center
and the issues related to them.
3.1. Limitations imposed by Spanning Tree & VLAN Ranges
Current Layer 2 networks use the Spanning Tree Protocol (STP) to
avoid loops in the network due to duplicate paths. STP will turn off
links to avoid the replication and looping of frames. Some data
center operators see this as a problem with Layer 2 networks in
general since with STP they are effectively paying for more ports
and links than they can really use. In addition, resiliency due to
multipathing is not available with the STP model. Newer initiatives
like TRILL/Shortest Path Bridging (SPB) have been proposed to help
with multipathing and thus surmount some of the problems with STP.
STP limitations may also be avoided by configuring servers within a
rack to be on the same Layer 3 network with switching happening at
Layer 3 both within the rack and between racks. However, this is
incompatible with a Layer 2 model for inter-VM communication.
Another characteristic of Layer 2 data center networks is their use
of Virtual LANs (VLANs) to provide broadcast isolation. A 12 bit
VLAN ID is used in the Ethernet data frames to divide the larger
Layer 2 network into multiple broadcast domains. This has served
well for several data centers which require fewer than 4094 VLANs.
With the growing adoption of virtualization, this upper limit is
seeing pressure. Moreover, due to STP, several data centers limit
the number of VLANs that could be used. In addition, requirements
for multitenant environments accelerate the need for larger VLAN
limits, as discussed in Section 3.3.
3.2. Multitenant Environments
Cloud computing involves on demand elastic provisioning of resources
for multitenant environments. The most common example of cloud
computing is the public cloud, where a cloud service provider offers
these elastic services to multiple customers/tenants over the same
physical infrastructure.
Isolation of network traffic by tenant could be done via Layer 2 or
Layer 3 networks. For Layer 2 networks, VLANs are often used to
segregate traffic - so a tenant could be identified by its own VLAN,
for example. Due to the large number of tenants that a cloud
provider might service, the 4094 VLAN limit is often inadequate. In
Mahalingam, Dutt et al. Expires February 2013 [Page 5]
Internet-Draft VXLAN August 2012
addition, there is often a need for multiple VLANs per tenant, which
exacerbates the issue.
Another use case is cross pod expansion. A pod typically consists of
one or more racks of servers with associated network and storage
connectivity. Tenants may start off on a pod and, due to expansion,
require servers/VMs on other pods, especially the case when tenants
on the other pods are not fully utilizing all their resources. This
use case requires a "stretched" Layer 2 environment connecting the
individual servers/VMs.
Layer 3 networks are not a complete solution for multi tenancy
either. Two tenants might use the same set of Layer 3 addresses
within their networks which requires the cloud provider to provide
isolation in some other form. Further, requiring all tenants to use
IP excludes customers relying on direct Layer 2 or non-IP Layer 3
protocols for inter VM communication.
3.3. Inadequate Table Sizes at ToR Switch
Today's virtualized environments place additional demands on the MAC
address tables of Top of Rack (ToR) switches which connect to the
servers. Instead of just one MAC address per server link, the ToR
now has to learn the MAC addresses of the individual VMs (which
could range in the 100s per server). This is a requirement since
traffic from/to the VMs to the rest of the physical network will
traverse the link to the switch. A typical ToR switch could connect
to 24 or 48 servers depending upon the number of its server facing
ports. A data center might consist of several racks, so each ToR
switch would need to maintain an address table for the communicating
VMs across the various physical servers. This places a much larger
demand on the table capacity compared to non-virtualized
environments.
If the table overflows, the switch may stop learning new addresses
until idle entries age out, leading to significant flooding of
subsequent unknown destination frames.
4. Virtual eXtensible Local Area Network (VXLAN)
VXLAN (Virtual eXtensible Local Area Network) addresses the above
requirements of the Layer 2 and Layer 3 data center network
infrastructure in the presence of VMs in a multitenant environment.
It runs over the existing networking infrastructure and provides a
means to "stretch" a Layer 2 network. In short, VXLAN is a Layer 2
overlay scheme over a Layer 3 network. Each overlay is termed a
Mahalingam, Dutt et al. Expires February 2013 [Page 6]
Internet-Draft VXLAN August 2012
VXLAN segment. Only VMs within the same VXLAN segment can
communicate with each other. Each VXLAN segment is scoped through a
24 bit segment ID, hereafter termed the VXLAN Network Identifier
(VNI). This allows up to 16M VXLAN segments to coexist within the
same administrative domain.
The VNI scopes the inner MAC frame originated by the individual VM.
Thus, you could have overlapping MAC addresses across segments but
never have traffic "cross over" since the traffic is isolated using
the VNI qualifier. This qualifier is in an outer header envelope
over the inner MAC frame originated by the VM. In the following
sections, the term "VXLAN segment" is used interchangeably with the
term "VXLAN overlay network".
Due to this encapsulation, VXLAN could also be termed a tunneling
scheme to overlay Layer 2 networks on top of Layer 3 networks. The
tunnels are stateless, so each frame is encapsulated according to a
set of rules. The end point of the tunnel (VTEP) discussed in the
following sections is located within the hypervisor on the server
which houses the VM. Thus, the VNI and VXLAN related tunnel/outer
header encapsulation are known only to the VTEP - the VM never sees
it (see Figure 1). Note that it is possible that VTEPs could also be
on a physical switch or physical server and could be implemented in
software or hardware. One use case where the VTEP is a physical
switch is discussed in Section 6 VXLAN on VXLAN deployment
scenarios.
The following sections discuss typical traffic flow scenarios in a
VXLAN environment using one type of control scheme - data plane
learning. Here, the association of VM's MAC to VTEP's IP is
discovered via source learning. Multicast is used for carrying
unknown destination, broadcast and multicast frames.
In addition to a learning based control plane, there are other
schemes possible for the distribution of the VTEP IP to VM MAC
mapping information. Options could include a central directory based
lookup by the individual VTEPs, distribution of this mapping
information to the VTEPs by the central directory, and so on. These
are sometimes characterized as push and pull models respectively.
This draft will focus on the data plane learning scheme as the
control plane for VXLAN.
4.1. Unicast VM to VM communication
Consider a VM within a VXLAN overlay network. This VM is unaware of
VXLAN. To communicate with a VM on a different host, it sends a MAC
frame destined to the target as before. The VTEP on the physical
Mahalingam, Dutt et al. Expires February 2013 [Page 7]
Internet-Draft VXLAN August 2012
host looks up the VNI to which this VM is associated. It then
determines if the destination MAC is on the same segment. If so, an
outer header comprising an outer MAC, outer IP address and VXLAN
header (see Figure 1 in Section 5 for frame format) are inserted in
front of the original MAC frame. The final packet is transmitted out
to the destination. This is the IP address of the remote VTEP
connecting the destination VM (represented by the inner MAC
destination address).
Upon reception, the remote VTEP verifies that the VNI is a valid one
and is used by the destination VM. If so, the packet is stripped of
its outer header and passed on to the destination VM. The
destination VM never knows about the VNI or that the frame was
transported with a VXLAN encapsulation.
In addition to forwarding the packet to the destination VM, the
remote VTEP learns the Inner Source MAC to outer Source IP address
mapping. It stores this mapping in a table so that when the
destination VM sends a response packet, there is no need for an
"unknown destination" flooding of the response packet.
Determining the MAC address of the destination VM prior to the
transmission by the source VM is performed as with non-VXLAN
environments except as described below. Broadcast frames are used
but are encapsulated within a multicast packet, as detailed in the
next section.
4.2. Broadcast Communication and Mapping to Multicast
Consider the VM on the source host attempting to communicate with
the destination VM using IP. Assuming that they are both on the
same subnet, the VM sends out an ARP broadcast frame. In the non-
VXLAN environment, this frame would be sent out using MAC broadcast
which all switches carrying that VLAN.
With VXLAN, a header including the VXLAN VNI is inserted at the
beginning of the packet along with the IP header and UDP header.
However, this broadcast packet is sent out to the IP multicast group
on which that VXLAN overlay network is realized.
To effect this, we need to have a mapping between the VXLAN VNI and
the IP multicast group that it will use. This mapping is done at the
management layer and provided to the individual VTEPs through a
management channel. Using this mapping, the VTEP can provide IGMP
membership reports to the upstream switch/router to join/leave the
VXLAN related IP multicast groups as needed. This will enable
pruning of the leaf nodes for specific multicast traffic addresses
Mahalingam, Dutt et al. Expires February 2013 [Page 8]
Internet-Draft VXLAN August 2012
based on whether a member is available on this host using the
specific multicast address. In addition, use of multicast routing
protocols like Protocol Independent Multicast - Sparse Mode (PIM-SM)
will provide efficient multicast trees within the Layer 3 network.
The VTEP will use (*,G) joins. This is needed as the set of VXLAN
tunnel sources is unknown and may change often, as the VMs come
up/go down across different hosts. A side note here is that since
each VTEP can act as both the source and destination for multicast
packets, a protocol like PIM-bidir would be more efficient.
The destination VM sends a standard ARP response using IP unicast.
This frame will be encapsulated back to the VTEP connecting the
originating VM using IP unicast VXLAN encapsulation. This is
possible since the mapping of the ARP response's destination MAC to
the VXLAN tunnel end point IP was learned earlier through the ARP
request.
Another point to note is that multicast frames and "unknown MAC
destination" frames are also sent using the multicast tree, similar
to the broadcast frames.
4.3. Physical Infrastructure Requirements
When IP multicast is used within the network infrastructure, a
multicast routing protocol like PIM-SM can be used by the individual
Layer 3 IP routers/switches within the network. This is used to
build efficient multicast forwarding trees so that multicast frames
are only sent to those hosts which have requested to receive them.
Similarly, there is no requirement that the actual network
connecting the source VM and destination VM should be a Layer 3
network - VXLAN can also work over Layer 2 networks. In either case,
efficient multicast replication within the Layer 2 network can be
achieved using IGMP snooping.
5. VXLAN Frame Format
The VXLAN frame format is shown below. Parsing this from the bottom,
there is an inner MAC frame with its own Ethernet header with
source, destination MAC addresses along with the Ethernet type plus
an optional VLAN. One use case of the inner VLAN tag is with VM
based VLAN tagging in a virtualized environment. See Section 6 for
further details of inner VLAN tag handling.
Mahalingam, Dutt et al. Expires February 2013 [Page 9]
Internet-Draft VXLAN August 2012
The inner MAC frame is encapsulated with the following four headers
(starting from the innermost header):
O VXLAN Header: This is an 8 byte field which has:
o Flags (8 bits) where the I flag MUST be set to 1 for a valid
VXLAN Network ID (VNI). The remaining 7 bits (designated "R") are
reserved fields and MUST be set to zero.
o VXLAN Segment ID/VXLAN Network Identifier (VNI) - this is a 24
bit value used to designate the individual VXLAN overlay network
on which the communicating VMs are situated. VMs in different
VXLAN overlay networks cannot communicate with each other.
o Reserved fields (24 bits and 8 bits) - MUST be set to zero.
O Outer UDP Header: This is the outer UDP header with a source
port provided by the VTEP and the destination port being a well-
known UDP port to be obtained by IANA assignment. It is recommended
that the source port be a hash of the inner Ethernet frame's
headers. This is to enable a level of entropy for ECMP/load
balancing of the VM to VM traffic across the VXLAN overlay.
The UDP checksum field SHOULD be transmitted as zero. When a packet
is received with a UDP checksum of zero, it MUST be accepted for
decapsulation. Optionally, if the encapsulating endpoint includes a
non-zero UDP checksum, it MUST be correctly calculated across the
entire packet including the IP header, UDP header, VXLAN header and
encapsulated MAC frame. When a decapsulating endpoint receives a
packet with a non-zero checksum it MAY choose to verify the
checksum value. If it chooses to perform such verification, and the
verification fails, the packet MUST be dropped. If the
decapsulating destination chooses not to perform the verification,
or performs it successfully, the packet MUST be accepted for
decapsulation.
O Outer IP Header: This is the outer IP header with the source IP
address indicating the IP address of the VTEP over which the
communicating VM (as represented by the inner source MAC address) is
running. The destination IP address is the IP address of the VTEP
Mahalingam, Dutt et al. Expires February 2013 [Page 10]
Internet-Draft VXLAN August 2012
connecting the communicating VM as represented by the inner
destination MAC address.
O Outer Ethernet Header (example): Figure 1 is an example of an
inner Ethernet frame encapsulated within an outer Ethernet + IP +
UDP + VXLAN header. The outer destination MAC address in this frame
may be the address of the target VTEP or of an intermediate Layer 3
router. The outer VLAN tag is optional. If present, it may be used
for delineating VXLAN traffic on the LAN.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Outer Ethernet Header: |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Optional Ethertype = C-Tag 802.1Q | Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer IP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = xxxx | Dest Port = VXLAN Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mahalingam, Dutt et al. Expires February 2013 [Page 11]
Internet-Draft VXLAN August 2012
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
VXLAN Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|R|I|R|R|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0
Inner Ethernet Header: |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address | Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Optional Ethertype = C-Tag [802.1Q] | Inner.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype of Original Payload | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original Ethernet Payload |
| |
| (Note that the original Ethernet Frame's FCS is not included) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New FCS (Frame Check Sequence) for Outer Ethernet Frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 VXLAN Frame Format
The frame format above shows tunneling of Ethernet frames using IPv4
for transport. Use of VXLAN with IPv6 transport will be addressed
in a future version of this draft.
6. VXLAN Deployment Scenarios
VXLAN is typically deployed in data centers on virtualized hosts,
which may be spread across multiple racks. The individual racks may
be parts of a different Layer 3 network or they could be in a single
Layer 2 network. The VXLAN segments/overlay networks are overlaid on
top of these Layer 2 or Layer 3 networks.
Mahalingam, Dutt et al. Expires February 2013 [Page 12]
Internet-Draft VXLAN August 2012
Consider Figure 2 below depicting two virtualized servers attached
to a Layer 3 infrastructure. The servers could be on the same rack,
or on different racks or potentially across data centers within the
same administrative domain. There are 4 VXLAN overlay networks
identified by the VNIs 22, 34, 74 and 98. Consider the case of VM1-1
in Server 1 and VM2-4 on Server 2 which are on the same VXLAN
overlay network identified by VNI 22. The VMs do not know about the
overlay networks and transport method since the encapsulation and
decapsulation happen transparently at the VTEPs on Servers 1 and 2.
The other overlay networks and the corresponding VMs are: VM1-2 on
Server 1 and VM2-1 on Server 2 both on VNI 34, VM1-3 on Server 1 and
VM2-2 on Server 2 on VNI 74, and finally VM1-4 on Server 1 and VM2-3
on Server 2 on VNI 98.
Mahalingam, Dutt et al. Expires February 2013 [Page 13]
Internet-Draft VXLAN August 2012
+------------+-------------+
| Server 1 |
| +----+----+ +----+----+ |
| |VM1-1 | |VM1-2 | |
| |VNI 22 | |VNI 34 | |
| | | | | |
| +---------+ +---------+ |
| |
| +----+----+ +----+----+ |
| |VM1-3 | |VM1-4 | |
| |VNI 74 | |VNI 98 | |
| | | | | |
| +---------+ +---------+ |
| Hypervisor VTEP (IP1) |
+--------------------------+
|
|
|
|
|
|
| +-------------+
| | Layer 3 |
|---| Network |
| |
+-------------+
|
|
+ --------+
|
+------------+-------------+
| Server 2 |
| +----+----+ +----+----+ |
| |VM2-1 | |VM2-2 | |
| |VNI 34 | |VNI 74 | |
| | | | | |
| +---------+ +---------+ |
| |
| +----+----+ +----+----+ |
| |VM2-3 | |VM2-4 | |
| |VNI 98 | |VNI 22 | |
| | | | | |
| +---------+ +---------+ |
| Hypervisor VTEP (IP2) |
+--------------------------+
Figure 2 VXLAN Deployment - VTEPs across a Layer 3 Network
Mahalingam, Dutt et al. Expires February 2013 [Page 14]
Internet-Draft VXLAN August 2012
One deployment scenario is where the tunnel termination point is a
physical server which understands VXLAN. Another scenario is where
nodes on a VXLAN overlay network need to communicate with nodes on
legacy networks which could be VLAN based. These nodes may be
physical nodes or virtual machines. To enable this communication, a
network can include VXLAN gateways (see Figure 3 below with a switch
acting as a VXLAN gateway) which forward traffic between VXLAN and
non-VXLAN environments.
Consider Figure 3 for the following discussion. For incoming frames
on the VXLAN connected interface, the gateway strips out the VXLAN
header and forwards to a physical port based on the destination MAC
address of the inner Ethernet frame. Decapsulated frames with the
inner VLAN ID SHOULD be discarded unless configured explicitly to be
passed on to the non-VXLAN interface. In the reverse direction,
incoming frames for the non-VXLAN interfaces are mapped to a
specific VXLAN overlay network based on the VLAN ID in the frame.
Unless configured explicitly to be passed on in the encapsulated
VXLAN frame, this VLAN ID is removed before the frame is
encapsulated for VXLAN.
These gateways which provide VXLAN tunnel termination functions
could be ToR/access switches or switches higher up in the data
center network topology - e.g. core or even WAN edge devices. The
last case (WAN edge) could involve a Provider Edge (PE) router which
terminates VXLAN tunnels in a hybrid cloud environment. Note that in
all these instances, the gateway functionality could be implemented
in software or hardware.
Mahalingam, Dutt et al. Expires February 2013 [Page 15]
Internet-Draft VXLAN August 2012
+---+-----+---+ +---+-----+---+
| Server 1 | | Non VXLAN |
(VXLAN enabled)<-----+ +---->| server |
+-------------+ | | +-------------+
| |
+---+-----+---+ | | +---+-----+---+
|Server 2 | | | | Non VXLAN |
(VXLAN enabled)<-----+ +---+-----+---+ +---->| server |
+-------------+ | |Switch acting| | +-------------+
|---| as VXLAN |-----|
+---+-----+---+ | | Gateway |
| Server 3 | | +-------------+
(VXLAN enabled)<-----+
+-------------+ |
|
+---+-----+---+ |
| Server 4 | |
(VXLAN enabled)<-----+
+-------------+
Figure 3 VXLAN Deployment - VXLAN Gateway
6.1. Inner VLAN Tag Handling
Inner VLAN Tag Handling in VTEP and VXLAN Gateway should conform to
the following:
Decapsulated VXLAN frames with the inner VLAN tag SHOULD be
discarded unless configured otherwise. On the encapsulation side, a
VTEP SHOULD NOT include an inner VLAN tag on tunnel packets unless
configured otherwise. When a VLAN-tagged packet is a candidate for
VXLAN tunneling, the encapsulating VTEP SHOULD strip the VLAN tag
unless configured otherwise.
7. IETF Network Virtualization Overlays (nvo3) Working Group
The IETF has recently chartered the Network Virtualization Overlays
(nvo3) Working Group (WG) under the Routing Area. The charter
(http://datatracker.ietf.org/wg/nvo3/charter/) indicates that the WG
will consider the multi tenancy approaches residing at the network
layer. The WG will provide a problem statement, architectural
framework and requirements for the control and data plane for such
Mahalingam, Dutt et al. Expires February 2013 [Page 16]
Internet-Draft VXLAN August 2012
network virtualization overlay schemes. Operations, Administration
and Management (OA&M) requirements for the nvo3 are also within the
scope of the WG. The active Internet drafts being considered by the
working group are at http://datatracker.ietf.org/wg/nvo3/. This
draft on VXLAN addresses the requirements outlined in the nvo3 WG
charter. It outlines the data plane requirements as well as the
method to establish the forwarding entries in each VTEP.
8. Security Considerations
Traditionally, layer 2 networks can only be attacked from 'within'
by rogue endpoints - either by having inappropriate access to a LAN
and snooping on traffic or by injecting spoofed packets to 'take
over' another MAC address or by flooding and causing denial of
service. A MAC-over-IP mechanism for delivering Layer 2 traffic
significantly extends this attack surface. This can happen by rogues
injecting themselves into the network by subscribing to one or
more multicast groups that carry broadcast traffic for VXLAN
segments and also by sourcing MAC-over-UDP frames into the transport
network to inject spurious traffic, possibly to hijack MAC
addresses.
This proposal does not, at this time, incorporate specific measures
against such attacks, relying instead on other traditional
mechanisms layered on top of IP. This section, instead, sketches
out some possible approaches to security in the VXLAN environment.
Traditional Layer 2 attacks by rogue end points can be mitigated by
limiting the management and administrative scope of who deploys and
manages VMs/gateways in a VXLAN environment. In addition, such
administrative measures may be augmented by schemes like 802.1X for
admission control of individual end points. Also, the use of the
UDP based encapsulation of VXLAN enables exploiting the 5 tuple
based ACLs (Access Control Lists) functionality in physical
switches.
Tunneled traffic over the IP network can be secured with traditional
security mechanisms like IPsec that authenticate and optionally
encrypt VXLAN traffic. This will, of course, need to be coupled with
an authentication infrastructure for authorized endpoints to obtain
and distribute credentials.
Mahalingam, Dutt et al. Expires February 2013 [Page 17]
Internet-Draft VXLAN August 2012
VXLAN overlay networks are designated and operated over the existing
LAN infrastructure. To ensure that VXLAN end points and their VTEPs
are authorized on the LAN, it is recommended that a VLAN be
designated for VXLAN traffic and the servers/VTEPs send VXLAN
traffic over this VLAN to provide a measure of security.
In addition, VXLAN requires proper mapping of VNIs and VM membership
in these overlay networks. It is expected that this mapping be done
and communicated to the management entity on the VTEP and the
gateways using existing secure methods.
9. IANA Considerations
An IANA port will be requested for the VXLAN destination UDP port.
10. Conclusion
This document has introduced VXLAN, an overlay framework for
transporting MAC frames generated by VMs in isolated Layer 2
networks over an IP network. Through this scheme, it is possible to
stretch Layer 2 networks across Layer 3 networks. This finds use in
virtualized data center environments where Layer 2 networks may need
to span across the entire data center, or even between data centers.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and Kouvelas, I.,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification", RFC 4601, August 2006.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and Vicisano, L.,
"Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC
5015, October 2007.
[RFC4541] Christensen, M., Kimball, K., and Solensky, F.,
"Considerations for Internet Group Management Protocol (IGMP)
and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541,
May 2006.
Mahalingam, Dutt et al. Expires February 2013 [Page 18]
Internet-Draft VXLAN August 2012
[nv03-Charter] Network Virtualization Working Overlays (nvo3)
charter, http://datatracker.ietf.org/wg/nvo3/charter/
12. Acknowledgments
The authors wish to thank Ajit Sanzgiri for contributions to the
Security Considerations section and editorial inputs, Joseph Cheng,
Margaret Petrus and Milin Desai for their editorial reviews, inputs
and comments.
Authors' Addresses
Mallik Mahalingam
Email: mallik_mahalingam@yahoo.com
Dinesh G. Dutt
Email: ddutt.ietf@hobbesdutt.com
Kenneth Duda
Arista Networks
5470 Great America Parkway
Santa Clara, CA 95054
Email: kduda@aristanetworks.com
Puneet Agarwal
Broadcom Corporation
3151 Zanker Road
San Jose, CA 95134
Email: pagarwal@broadcom.com
Mahalingam, Dutt et al. Expires February 2013 [Page 19]
Internet-Draft VXLAN August 2012
Lawrence Kreeger
Cisco Systems, Inc.
170 W. Tasman Avenue
Palo Alto, CA 94304
Email: kreeger@cisco.com
T. Sridhar
VMware Inc.
3401 Hillview
Palo Alto, CA 94304
Email: tsridhar@vmware.com
Mike Bursell
Citrix Systems Research & Development Ltd.
Building 101
Cambridge Science Park
Milton Road
Cambridge CB4 0FY
United Kingdom
Email: mike.bursell@citrix.com
Chris Wright
Red Hat Inc.
1801 Varsity Drive
Raleigh, NC 27606
Email: chrisw@redhat.com
Mahalingam, Dutt et al. Expires February 2013 [Page 20]