Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers
RFC 7342
| Document | Type |
RFC - Informational
(August 2014; No errata)
Was draft-dunbar-armd-arp-nd-scaling-practices (individual)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | ISE | ||
| Formats | plain text pdf html bibtex | ||
| Reviews | |||
| IETF conflict review | conflict-review-dunbar-armd-arp-nd-scaling-practices | ||
| Stream | ISE state | Published RFC | |
| Consensus Boilerplate | Unknown | ||
| Document shepherd | Nevil Brownlee | ||
| Shepherd write-up | Show (last changed 2014-03-13) | ||
| IESG | IESG state | RFC 7342 (Informational) | |
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA action state | No IC | ||
Independent Submission L. Dunbar
Request for Comments: 7342 Huawei
Category: Informational W. Kumari
ISSN: 2070-1721 Google
I. Gashinsky
Yahoo
August 2014
Practices for Scaling ARP and Neighbor Discovery (ND)
in Large Data Centers
Abstract
This memo documents some operational practices that allow ARP and
Neighbor Discovery (ND) to scale in data center environments.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7342.
Copyright Notice
Copyright (c) 2014 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.
Dunbar, et al. Informational [Page 1]
RFC 7342 Scaling ARP and ND in Large DCs August 2014
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Common DC Network Designs .......................................4
4. Layer 3 to Access Switches ......................................5
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. Communicating with a Peer in a Different Subnet .....6
5.1.2. L2/L3 Boundary Router Processing of Inbound
Traffic .............................................7
5.1.3. Inter-Subnet Communications .........................8
5.2. Static ARP/ND Entries on Switches ..........................8
5.3. ARP/ND Proxy Approaches ....................................9
5.4. Multicast Scaling Issues ...................................9
6. Practices to Scale ARP/ND in Overlay Models ....................10
7. Summary and Recommendations ....................................10
8. Security Considerations ........................................11
9. Acknowledgements ...............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................13
1. Introduction
This memo documents some operational practices that allow ARP/ND to
scale in data center environments.
As described in [RFC6820], the increasing trend of rapid workload
shifting and server virtualization in modern data centers requires
servers to be loaded (or reloaded) with different Virtual Machines
(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 allow VMs to be moved to different server racks
without IP address reconfiguration, the networks need to enable
multiple broadcast domains (many VLANs) on the interfaces of L2/L3
boundary routers and Top-of-Rack (ToR) switches and allow some
subnets to span multiple router ports.
Note: L2/L3 boundary routers as discussed in this document are
capable of forwarding IEEE 802.1 Ethernet frames (Layer 2) without a
Media Access Control (MAC) header change. When subnets span multiple
ports of those routers, they still fall under the category of
"single-link" subnets, specifically the multi-access link model
Show full document text