ARMD L. Dunbar
Internet Draft Huawei
Intended status: Informational W. Kumari
Expires: June 2013 Google
Igor Gashinsky
Yahoo
December 11, 2012
Practices for scaling ARP and ND for large data centers
draft-dunbar-armd-arp-nd-scaling-practices-04
Status of this Memo
This Internet-Draft is submitted to IETF 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 June 11, 2013.
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.
Expires June 11, 2013 [Page 1]
Internet-Draft Pratices to scale ARP/ND in large DC
Abstract
This draft documents some simple practices that scale ARP/ND
in data center environments.
Table of Contents
1. Introduction ................................................ 3
2. Terminology ................................................. 3
3. Common DC network Designs.................................... 4
4. Layer 3 to Access Switches................................... 4
5. Layer 2 practices to scale ARP/ND............................ 5
5.1. Practices to alleviate APR/ND burden on L2/L3
boundary routers ............................................ 5
5.1.1. Station communicating with an external peer........ 5
5.1.2. L2/L3 boundary router processing of inbound
traffic .................................................. 6
5.1.3. Inter subnets communications ...................... 7
5.2. Static ARP/ND entries on switches ....................... 7
5.3. ARP/ND Proxy approaches ................................. 8
6. Practices to scale ARP/ND in Overlay models .................. 8
7. Summary and Recommendations .................................. 9
8. Security Considerations ...................................... 9
9. IANA Considerations ......................................... 9
10. Acknowledgements .......................................... 10
11. References ................................................ 10
11.1. Normative References.................................. 10
11.2. Informative References................................ 10
Authors' Addresses ............................................ 11
Dunbar-Kumari-Gashinsky Expires June 11, 2013 [Page 2]
Internet-Draft Pratices to scale ARP/ND in large DC
1. Introduction
As described in [ARMD-Problem], the increasing trend of
rapid workload shifting and server virtualization in modern
data centers requires servers to be loaded (or re-loaded)
with different VMs or applications at different times.
Different VMs residing on one physical server may have
different IP addresses, or may even be in different IP
subnets.
In order to allow a physical server to be loaded with VMs in
different subnets, or VMs to be moved to different server
racks without IP address re-configuration, the corresponding
networks need to enable multiple broadcast domains (many
VLANs) on the interfaces of L2/L3 boundary routers and ToR
switches. Unfortunately, when the combined number of VMs (or
hosts) in all those subnets is large, this can lead to
address resolution scaling issues, especially on the L2/L3
boundary routers.
This draft documents some simple practices which can scale
ARP/ND in data center environment.
2. Terminology
This document reuses much of terminology from [ARMD-
Problem]. Many of the definitions are presented here to aid
the reader.
ARP: IPv4 Address Resolution Protocol [RFC826]
Aggregation Switch: A Layer 2 switch interconnecting ToR
switches
Bridge: IEEE802.1Q compliant device. In this draft, Bridge
is used interchangeably with Layer 2 switch.
DC: Data Center
DA: Destination Address
End Station: VM or physical server, whose address is
either a destination or the source of a data frame.
EOR: End of Row switches in data center.
Dunbar-Kumari-Gashinsky Expires June 11, 2013 [Page 3]
Internet-Draft Pratices to scale ARP/ND in large DC
NA: IPv6's Neighbor Advertisement
ND: IPv6's Neighbor Discovery [RFC4861]
NS: IPv6's Neighbor Solicitation
SA: Source Address
Station: A node which is either a destination or source of a
data frame.
ToR: Top of Rack Switch (also known as access switch).
UNA: IPv6's Unsolicited Neighbor Advertisement
VM: Virtual Machines
3. Common DC network Designs
Some common network designs for data center include:
1) layer-3 connectivity to the access switch,
2) Large Layer 2,
3) Overlay models
There is no single network design that fits all cases.
Following sections document some of the common practices to
scale Address Resolution under each network design.
4. Layer 3 to Access Switches
This refers to the network design with Layer 3 to the access
switches.
As described in [ARMD-Problem], many data centers are
architected so that ARP/ND broadcast/multicast messages are
confined to a few ports (interfaces) of the access switches
(i.e. ToR switches).
Another variant of the Layer 3 solution is Layer 3 all the
way to servers (or even to the VMs), which confines the
Dunbar-Kumari-Gashinsky Expires June 11, 2013 [Page 4]
Internet-Draft Pratices to scale ARP/ND in large DC
ARP/ND broadcast/multicast messages to the small number of
VMs within the server.
Advantage: Both ARP and ND scale well. There are no address
resolution issue in this design.
Disadvantage: The main disadvantage to this network design
is that IP addresses have to be re-configured on switches
when a server needs to be re-loaded with an application in
different subnet or when VMs need to be moved to a different
location.
Summary: This solution is more suitable to data centers
which have static workload and/or network operators who can
re-configure IP addresses/subnets on switches before any
workload change. No protocol changes are suggested.
5. Layer 2 practices to scale ARP/ND
5.1. Practices to alleviate APR/ND burden on L2/L3 boundary
routers
The ARP/ND broadcast/multicast messages in a Layer 2 domain
can negatively affect the L2/L3 boundary routers, especially
with large number of VMs and subnets. This section describes
some commonly used practices in reducing the ARP/ND
processing required on L2/L3 boundary routers.
5.1.1. Station communicating with an external peer
When the external peer is in a different subnet, the
originating end station needs to send ARP/ND requests to its
default gateway router to resolve the router's MAC address.
If there are many subnets on the gateway router and a large
number of end stations in those subnets, the gateway router
has to process a very large number of ARP/ND requests. This
is often CPU intensive as ARP/ND are usually processed by
the CPU (and not in hardware).
Solution: For IPv4 networks, a practice to alleviate this
problem is to have the L2/L3 boundary router send periodic
gratuitous ARP [GratuitousARP] messages, so that all the
connected end stations can refresh their ARP caches. As the
result, most (if not all) end stations will not need to ARP
for the gateway routers when they need to communicate with
external peers.
Dunbar-Kumari-Gashinsky Expires June 11, 2013 [Page 5]
Internet-Draft Pratices to scale ARP/ND in large DC
However, due to IPv6 requiring bi-directional path
validation Ipv6 end stations are still required to send
unicast ND messages to their default gateway router (even
with those routers periodically sending Unsolicited Neighbor
Advertisements).
Advantage: Reduction of ARP requests to be processed by
L2/L3 boundary router for IPv4.
Disadvantage: No reduction of ND processing on L2/L3
boundary router for IPv6 traffic.
Recommendation: Use for IPv4-only networks, or make change to the ND
protocol to allow data frames to be sent without requiring bi-
directional frame validation. Some work in progress in this area is
[Impatient-NUD]
5.1.2. L2/L3 boundary router processing of inbound traffic
When a L2/L3 boundary router receives a data frame and the
destination is not in router's ARP/ND cache, some routers
hold the packet and trigger an ARP/ND request to resolve the
L2 address. The router may need to send multiple ARP/ND
requests until either a timeout is reached or an ARP/ND
reply is received before forwarding the data packets towards
the target's MAC address. This process is not only CPU
intensive but also buffer intensive.
Solution: For IPv4 network, a common practice to alleviate
this problem is for the router to snoop ARP messages, so
that its ARP cache can be refreshed with active addresses in
the L2 domain. As a result, there is an increased likelihood
of the router's ARP cache having the IP-MAC entry when it
receives data frames from external peers.
For IPv6 end stations, routers are supposed to send ND
unicast even if it has snooped UNA/NS/NA from those
stations. Therefore, this practice doesn't help IPv6 very
much.
Advantage: Reduction of the number of ARP requests which
routers have to send upon receiving IPv4 packets and the
number of IPv4 data frames from external peers which routers
have to hold.
Dunbar-Kumari-Gashinsky Expires June 11, 2013 [Page 6]
Internet-Draft Pratices to scale ARP/ND in large DC
Disadvantage: The amount of ND processing on routers for
IPv6 traffic is not reduced. Even for IPv4, routers still
need to hold data packets from external peers and trigger
ARP requests if the targets of the data packets either don't
exist or are not very active.
Recommendation: Do not use with IPv6 or make protocol
changes to IPv6's ND. For IPv4, if there is higher chance of
routers receiving data packets towards non-existing or
inactive targets, alternative approaches should be
considered.
5.1.3. Inter subnets communications
The router will be hit twice when the originating and
destination stations are in different subnets under on the
same router. Once for the originating station in subnet-A
initiating ARP/ND request to the L2/L3 boundary router
(5.1.1 above); and the second for the L2/L3 boundary router
to initiate ARP/ND requests to the target in subnet-B (5.1.2
above).
Again, practices described in 5.1.1 and 5.1.2 can alleviate
problems in IPv4 network, but don't help very much for IPv6.
Advantage: reduction of ARP processing on L2/L3 boundary
routers for IPv4 traffic.
For IPv6 traffic, there is no reduction of ND processing on
L2/L3 boundary routers.
Recommendation: do not use with IPv6 or consider other
approaches.
5.2. Static ARP/ND entries on switches
In a datacenter environment the placement of L2 and L3
addressing may be orchestrated by Server (or VM) Management
System(s). Therefore it may be possible for static ARP/ND
entries to be configured on routers and / or servers.
Advantage: This methodology has been used to reduce ARP/ND
fluctuations in large scale data center networks.
Disadvantage: There is no well-defined mechanism for devices
to get prompt incremental updates of static ARP/ND entries
when changes occur.
Dunbar-Kumari-Gashinsky Expires June 11, 2013 [Page 7]
Internet-Draft Pratices to scale ARP/ND in large DC
Recommendation: The IETF should consider creating standard
mechanism (or protocols) for switches or servers to get
incremental static ARP/ND entries updates.
5.3. ARP/ND Proxy approaches
RFC1027 specifies one ARP proxy approach. Since the
publication of RFC1027 in 1987 there have been many variants
of ARP proxy being deployed. The term "ARP Proxy" is a
loaded phrase, with different interpretations depending on
vendors and/or environments. RFC1027's ARP Proxy is for a
Gateway to return its own MAC address on behalf of the
target station. Another technique, also called "ARP Proxy"
is for a ToR switch to snoop ARP requests and return the
target station's MAC if the ToR has the information.
Advantage: Proxy ARP [RFC1027] and its variants have allowed
multi-subnet ARP traffic for over a decade.
Disadvantage: Proxy ARP protocol [RFC1027] was developed for
hosts which don't support subnets.
Recommendation: Revise RFC1027 with VLAN support and make it
scale for Data Center Environment.
6. Practices to scale ARP/ND in Overlay models
There are several drafts on using overlay networks to scale
large layer 2 networks (or avoid the need for large L2
networks) and enable mobility (e.g. draft-wkumari-dcops-l3-
vmmobility-00, draft-mahalingam-dutt-dcops-vxlan-00). TRILL
and IEEE802.1ah (Mac-in-Mac) are other types of overlay
network to scale Layer 2.
Overlay networks hide the VMs' addresses from the interior
switches and routers, thereby stopping the router from
having to perform ARP/ND services for as many addresses. The
Overlay Edge nodes which perform the network address
encapsulation/decapsulation still see all remote stations
addresses which communicate with stations attached locally.
For a large data center with many applications, these
applications' IP addresses need to be reachable by external
peers. Therefore, the overlay network may have a bottleneck
at the Gateway devices(s) in processing resolving target
stations' physical address (MAC or IP) and overlay edge
address within the data center.
Dunbar-Kumari-Gashinsky Expires June 11, 2013 [Page 8]
Internet-Draft Pratices to scale ARP/ND in large DC
Here are some approaches being used to minimize the problem:
1. Use static mapping as described in Section 5.2.
2. Have multiple gateway nodes (i.e. routers), with each
handling a subset of stations addresses which are
visible to external peers, e.g. Gateway #1 handles a
set of prefixes, Gateway #2 handles another subset of
prefixes, etc.
7. Summary and Recommendations
This memo describes some common practices which can
alleviate the impact of address resolution to L2/L3 gateway
routers.
In Data Centers, no single solution fits all deployments.
This memo has summarized some practices in various
scenarios and the advantages and disadvantages about all of
these practices.
In some of these scenarios, the common practices could be
improved by creating and/or extending existing IETF
protocols. These protocol change recommendations are:
- Extend IPv6 ND method,
- Create a incremental "download" schemes for static
ARP/ND entries,
- Revise Proxy ARP [RFC1027] for use in the data center.
8. Security Considerations
This draft documents existing solutions and proposes
additional work that could be initiated to extend various
IETF protocols to better scale ARP/ND for the data center
environment. As such we do not believe that this introduces
any security concerns.
9. IANA Considerations
This document does not request any action from IANA.
Dunbar-Kumari-Gashinsky Expires June 11, 2013 [Page 9]
Internet-Draft Pratices to scale ARP/ND in large DC
10. Acknowledgements
We want to acknowledge the following people for their
valuable inputs to this draft: T. Sridhar, Ron Bonica,
Kireeti Kompella, and K.K.Ramakrishnan.
11. References
11.1. Normative References
[ARMD-Problem] Narten, "Problem Statement for ARMD"
(http://datatracker.ietf.org/doc/draft-ietf-armd-
problem-statement/); Aug 2012
[GratuitousARP] S. Cheshire, "IPv4 Address Conflict
Detection", RFC 5227, July 2008.
[RFC826] D.C. Plummer, "An Ethernet address resolution
protocol." RFC826, Nov 1982.
[RFC1027] Mitchell, et al, "Using ARP to Implement
Transparent Subnet Gateways"
(http://datatracker.ietf.org/doc/rfc1027/)
[RFC4861] Narten, et al, "Neighbor Discovery for IP version
6 (IPv6)", RFC4861, Sept 2007
11.2. Informative References
[Impatient-NUD] E. Nordmark, I. Gashinsky, "draft-ietf-
6man-impatient-nud"
Dunbar-Kumari-Gashinsky Expires June 11, 2013 [Page 10]
Internet-Draft Pratices to scale ARP/ND in large DC
Authors' Addresses
Linda Dunbar
Huawei Technologies
5340 Legacy Drive, Suite 175
Plano, TX 75024, USA
Phone: (469) 277 5840
Email: ldunbar@huawei.com
Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: warren@kumari.net
Igor Gashinsky
Yahoo
45 West 18th Street 6th floor
New York, NY 10011
Email: igor@yahoo-inc.com
Dunbar-Kumari-Gashinsky Expires June 11, 2013 [Page 11]